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.
I think i’ve found a bug.
When i record a signal, and then change to 10s/DIV and record again, without completing the record there is still the part from the previous recording in the buffer.
