benf i just bought 4 version2’s and sent a friend one of them, and let me say your software updates for the nano is amazing to say the least, i have a pico 3423 and a fluke 196c also, i like the nano for my at home project stuff, also would like to use it for on the job automotive–>but is there anyway to make the nano have real time trigger where it only displays the screen and not saves the next 12 screens after the trigger so the update rate is quicker in the 1-20 milisecond per division ranges, like an option to eliminate buffer when needing the extra screen update rate?
Agreed, we have the capabilities now to make this a useful feature.
This would also fall into the “development required” category. Is there a specific auto related measurement you had in mind for this?
I started looking at what brandonb was talking about. I used the freq-out = 1Khz 50% duty cycle and found the following.
At 50ms/Div or greater, the signal drops out and no longer appears on the display, only the baseline appears. I saved the captured buffer and it also ignores the input freq-out signal transitions. At 20ms/Div the captured buffer is correct.
I noticed that the auto trigger never flashes yellow as it should while in 50ms/Div.
As you step through T/Div greater that 20ms/Div, the sweep randomly appears either high or low (+Vcc or Gnd).
If I drop the freq-out to 900hz or less, then all is good. Is this a problem or is there a reason that it doesn’t work as I expected?
[quote]
Is there a specific auto related measurement you had in mind for this?
[quote=“lygra”]
you know what ben, if i had fuel injector pulsewidth as a measurement that would be awsome, and would be way cooler than the eliminate buffer thing, thanks for looking into this
This is to be expected as 50ms/Div (2ms between samples) is inappropriate for a 1kHz input signal (1ms between cycles).
I think brandonb is concerned with refresh time. At 20ms/Div we need 20ms * 4098 / 25 for each capture cycle and this adds up to 3.28s. An alternative might be to trade sample depth for refresh time and so with 400 samples only we could speed up cycle time by an order of magnitude. For some measurements this may be desired. For T/Div’s less than 1ms, refresh rate is better than 10Hz and at 100ms and above the Nano will default to real-time scan. The proposed change would apply as a user option to T/Div’s in the 1ms to 50ms range.
I think I understand your response. Just to paraphrase, are you saying that when the period of the input signal is less than the period of that sweep time, then a full wave isn’t seen, thus only the DC portion seen at that trigger time is displayed?
That sounds stellar. Are you considering a percentage capture buffer reduction or a binary capture buffer reduction count as user option?
Just for general information, the typical injector on time at idle is in the neighborhood of 1.5ms; so maybe a T/Div a little faster than 1ms could be included.
ben- how much work would that take to increase the screen update rate from 1m/s to 50m/s per division by eliminating buffer option and to add a measurement of pulsewidth take? i was curious if it was a huge burdon or a hour of key strokes, i dont know much about software
Perhaps you can attach a capture file (XML format) as an example of what you would like to measure?
Hi,
i just received my nano v2 today, and i dont exactly understand what your are talking about but i think its about the same thing i found out today 
.
First on i want to thank you Benf, for all the work you put in and giving us this great firmware for free
Now my Problems/suggestions:
There is no scan mode from 1ms to 50ms. But this would be an important option for me.
Btw. i cant set the timecursor to 0 or to the exact end of the screen. Also it might be an idea to save the T-/T/Div settings before you use FIT to load them back if you deactivate FIT.
Another thing i just discovered 
: If i record with a a signal to the, i think its called the capture buffer, it has still the last recording from the previous recording. For example i record 2 seconds, but after this 2 seconds there is the leftover from the previous.
Ill put a picture in late rif i can.
Cheers Tobey
Hi BenF,
Using your firmware is a great fun for me as a hobbyist.
If possible, can you make the measurements value to display
2 decimal places for more accuracy? At the moment, it only
have 1 decimal places. For audio calibration, 0.1v is a huge gap.
I’m not sure I fully understand your comments Tobey - are you planning to use the Nano as a logger/recording device for extended time periods?
Measurements are currently displayed with 3 significant digits covering the range from +/- 0.00mV to 999V. This choice of precision reflects on the underlying accuracy we can get from the Nano hardware. How does this tie in with your 0.1V?
Hi Ben,
i would like to have a scan mode from 1ms to 50ms, so i can see whats happening in realtime (just like at 100ms).
Furthermore when i make an acquisition there is always some other signal (from the last acquisition) behind my actual acquisition (refer to the pictures in my last post).
tobey- i dont thing a real time scan mode at 1-50m/s would be all that usefull without being able to trigger
Actually it triggers at 100ms 1us and 1-50ms. Why should it not trigger?
To me its a advantage of the digital oszilloskop to show signals with greater time/div and keep them on the screen. The analog oszilloscope would have a flickerung screen.
Why cant the scan with 1-50ms be like with 100ms??
Hello! (Sorry for my English) I have the DSO NANO V1.0, which is as follows:
seeedstudio.com/depot/micro- … p-512.html
I can use this firmware update on it? 
thanks
Yes! The V3 firmware is written to support both old (V1) and new (V2) versions of the Seeed Studio DSO Nano.
Thanks! Thanks for the excellent work! 
Dear BenF,
Great work. I got myself a DSO Nano v2 today and the first thing I did was to load your firmware onto it. Much nicer without all the garbage dots on the screen and nice pop-up menus.
Just wanted to ask whether we can get logging to SD card working? Even if the sample rate is only say 100Hz, I would love to be able to say log the voltage across a battery running down over half an hour. Would make a very nifty hand-held pocket sampler. Would be great if you could say add different sample rates, and or a timed-logging function. If to save processing power and SD-card bus speed limitations, I don’t mind if it’s raw PCM or what - just something we can post-process on a computer. I think that would truly get me off my old cheap USB Oscilloscope units that are always crashing my PC!
- Gough
Yes, I think a data logger feature might be a useful extension and especially so for a self contained battery operated unit. Sampling speed is an issue, but up to 250 Sa/s might be realistic for 16-bit binary data (about 1MB for half an hour).
Do you think a standard file format such as WAV (PCM audio) would be more useful than a proprietary binary format?
I think FLAC works on ARM