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.
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?
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).
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??
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!
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?
Storage capacity is not much of an issue so a raw uncompressed format such as WAV may be preferred.
This would not be suitable for audio recording, but the file format could work equally well for sensor data which from a Nano point of view is just voltage variations over time as is raw audio. It might have applications for recording temperature variations, battery charge/discharge voltage and infrequent signals such as relay control signals. A programmer might read the data and process it on a PC for further analysis, but any simple audio editor could also be used to just load and display the waveform on a PC.
With the latest firmware updates we’re close to using every single byte of RAM on the Nano and so new features will be hard if at all possible to add. Considering that this may be the last feature we can add to the V3 firmware, is this the best candidate?
What might be a issue is that 250 sa/s is certainly not a standard sample rate, I think the lowest I’ve seen in audio progs is like 11025 or 8000Hz so they might not want to load the file if it is out of spec.
Well, a binary format or WAV is no biggie. I think dnordenberg is right though, I don’t think WAV will go down to less than 1kS/s. I know my preferred editor, GoldWave, won’t create a file lower than 1kS/s.
After all, it’s just a case of writing a program on the PC to translate the values into something we can work with - so whatever is easiest for the scope (i.e. uses less processing power, maybe saves bandwidth or memory on the SD card if that’s an issue) is probably gonna yield better sampling rates. After all, the logging “feature” will probably mainly be used to provide data for other applications, so it doesn’t really matter the format as long as it’s simple, documented and doesn’t chew more space than absolutely necessary.
EDIT: I would cast my vote for this feature. If anything, it opens a whole new world of possibilities for display and analysis on a more powerful platform - i.e. the PC.
benf- if there was one thing to make this product better–>i vote again for option to eliminate buffer in 1m/s- 50m/s division that would be very useful for automotive techs like myself as the expensive scopes have such a slow screen update rate in the 1m/s range, i would use this option and the buffer that currently exists to get the info i need from the diagnostic situations that i get into, its like the best of both worlds(resolution of the current buffer and the speed of the elimination of buffer option to see the fast trends that occur)
I vote for this feature (datalogging) and for logging it to a textfile.
Dont use xml file, because most calculationprogramms can import the data from simple files like this style:
0 3.02093
1 3.25430
2 3.46667
…
That would use much less space, and i would suggest it for the same this with “saving reference”. A Value to set would be awesome, to make settings like 4 seconds etc. .
Another idea: if there is not much space left for the firmware, why not vote for the important and not important things, and make a “customers choice” version??
The trigger is found within the capture buffer (there is no hardware trigger circuit), so as BenF says in the following quote, reducing the capture buffer size (depth) could increase the refresh rate by a factor of 10 which would improve the viewing of non-repeating waveforms in this T/Div range. What you are wanting would require some form of hardware trigger and the Nano does not have that. A fast scan mode would simply have the waveform jumping all around on the screen x-axis.
I really hope that you are considering this option in a future release.
Well - this is the way it works. Real-time scan paints a screen at the time. Why this obsession with changing things - is it not better to first learn to use what’s already there?
There is a user’s guide in the download and you may also want to check out the instruction videos prepared by forum user lygra.
.
: 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.
