Products > Test Equipment
121GW App Testing
<< < (22/38) > >>
Seppy:
Alright, I don't know who reported this error but it is resolved with another firmware update.

Pre-1.22 firmware the main value was sent to the app via a 16 bit unsigned value.
In frequency measurement on the multimeter it was possible to display 99.993 xHz.
The 16 bits that were allocated in the packet for the 50000 count multimeter wasn't sufficient as 16 bits can represent a maximum of 65535. To resolve this the packet format was revised in a backward compatible way. I.e. future versions of the App will work with old versions of firmware (except for this error condition).

We added 2 extra bits to the packet we can now display 99.999 kHz if needed. This fix will be included in Build 1.4. This fix has been tested and confirmed functional.
Seppy:

--- Quote from: rs20 on June 20, 2018, 12:26:28 am ---
--- Quote from: IanB on June 18, 2018, 02:13:03 am ---I think the way to do this is to have a partial grid division on the right hand side of the time axis.

--- End quote ---

Something like this?  :)




(Obviously it'd move a lot more smoothly and slowly in reality.)

Incidentally, I think it's also important to have an option to display relative vs absolute times. I'm sure there are people out there who are interested in actual absolute timestamps (e.g. Sep 15th, 4:30pm), but most of the time I'm just running a test so I just want (t=0s, t=4.5s), etc. Code that supports both (and the code that generated the animations above) is below. Obviously Octave/MATLAB code isn't directly useful; but it should be easy to translate/adapt.


--- Code: ---function setup_x_axis(xmin, xsize)
  % Set axes limits of the plot
  axis([0 xsize -1.2 1.2])
 
  % Choose most readable time units
  if (xsize < 100)
    label = 'time (seconds)';
    divider = 1;
    dateformat = 'HH:MM:SS';
  elseif (xsize < 100 * 60)
    label = 'time (minutes)';
    divider = 60;
    dateformat = 'HH:MM';
  elseif (xsize < 60 * 60 * 40)
    label = 'time (hours)';
    divider = 60 * 60;
    dateformat = 'HH:MM';
  else
    label = 'time (days)';
    divider = 60 * 60 * 24;
    dateformat = 'dd-mmm HH:MM';
  endif
  xsize = xsize / divider;
 
  % Choose most readable x tick spacing
  best_step_size = 1;
  for candidate = [0.1 0.2 0.5 1 2 5 10 20 50 100]
    if candidate*2 > xsize
      break
    endif
    best_step_size = candidate;
  endfor
 
  % Place x ticks
  xticks = 0:best_step_size:xsize;
 
  % Format x tick labels
  xticklabels = char([]);
  if xmin
    xlabel('');
   
    % Nudge the x ticks to nice round times/dates
    adjustment = ceil(xmin / (best_step_size * divider / 86400)) * (best_step_size * divider / 86400) - xmin;
    xticks = xticks + adjustment / (divider/86400);
   
    for xtick = xticks
      xticklabels = [xticklabels; datestr(xmin + xtick*divider/86400, dateformat)];
    endfor
  else
    xlabel(label, 'fontsize', 14 );
    for xtick = xticks
      xticklabels = [xticklabels; num2str(xtick)];
    endfor
  endif
 
  % Apply to the plot
  set(gca, 'xtick', xticks * divider);
  set(gca, 'xticklabel', xticklabels);
 
endfunction


t = 0:0.01:200;
x = 1.1 .^ t - 1;
y = sin(t);

plot(x, y);


recorded = 2;

start_duration = 2; %0.5;
end_duration = 300000;
frame_count = 240 - 25;
durations = logspace(log10(start_duration), log10(end_duration), frame_count);

for indexx = 1:numel(durations)
  setup_x_axis(730736.6514, durations(indexx));
  set(gca, 'fontsize', 14)
  drawnow
  print(num2str(indexx, 'frames/grame%04d.png'), '-S640,160')
endfor

--- End code ---

--- End quote ---

Yes that looks good, but I don't think log scale works well with pinch to zoom, would have to be linear, otherwise zooming into the the start of a large data set would be horrid.
rs20:

--- Quote from: Seppy on June 20, 2018, 01:17:54 am ---Yes that looks good, but I don't think log scale works well with pinch to zoom, would have to be linear, otherwise zooming into the the start of a large data set would be horrid.

--- End quote ---

??? Where is a log scale mentioned anywhere? The only thing that is log is the animation I did (to show a few seconds and a few days in a single animation consistently), but that has nothing to do with the implementation of the axes ticks and in-app behaviour.
Seppy:

--- Quote from: rs20 on June 20, 2018, 01:28:35 am ---
--- Quote from: Seppy on June 20, 2018, 01:17:54 am ---Yes that looks good, but I don't think log scale works well with pinch to zoom, would have to be linear, otherwise zooming into the the start of a large data set would be horrid.

--- End quote ---

??? Where is a log scale mentioned anywhere? The only thing that is log is the animation I did (to show a few seconds and a few days in a single animation consistently), but that has nothing to do with the implementation of the axes ticks and in-app behaviour.

--- End quote ---

t = 0:0.01:200;
y = sin(t);

^
That is a linearly sampled function, the plot displays a log scaled function.

The function linearly scaled should look like the attached:

rs20:

--- Quote from: Seppy on June 20, 2018, 01:33:24 am ---
--- Quote from: rs20 on June 20, 2018, 01:28:35 am ---
--- Quote from: Seppy on June 20, 2018, 01:17:54 am ---Yes that looks good, but I don't think log scale works well with pinch to zoom, would have to be linear, otherwise zooming into the the start of a large data set would be horrid.

--- End quote ---

??? Where is a log scale mentioned anywhere? The only thing that is log is the animation I did (to show a few seconds and a few days in a single animation consistently), but that has nothing to do with the implementation of the axes ticks and in-app behaviour.

--- End quote ---

t = 0:0.01:200;
y = sin(t);

^
That is a linearly sampled function, the plot displays a log scaled function.

The function linearly scaled should look like the attached:

--- End quote ---

Nono, ignore that. That's just to make the blue curve in the plot look interesting when scaled hugely. Don't look at the blue curve at all if it's confusing you; the behaviour of the tick marks on the axis (which clearly aren't a log scale) is what's actually being demonstrated here. x is time (in seconds), y is voltage. Sorry, didn't expect people to be inspecting that part of the code.

I can modify the code to just have a normal linear sin wave if you want; but again that's nothing to do with the axis behaviour. It'd just look a bit silly because the plot would just be a solid blue block for most of the demonstration.
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod