DSO firmware version 3.2

Hi BenF. Many thanks for your excellent work on the DSO code.

I have a request that you may like to consider for a future enhancement. Or it may just be a misunderstanding on my part.

When setting the zero offset it seems that the DSO needs a different offset for each V/div range. I can go through and set the offset for each range, and all the offsets are remembered so long as I leave the DSO powered up.

But if I save the profile and turn it off, when it powers up again only the offset for the range it was on when I did the save has been remembered.

It would be nice if a profile save saved the offsets for ALL V/div ranges.

Thanks again,
Adrian.

Hello again BENF

I fail to work on debugging your program version 3.11

with IAR 4, whereas with version 2.5 it is possible.

Am I doing something wrong?

Thank you.

google Translation

Hello Benf!

Congratulations for your beautiful work.
However, after upgrading to version 3.2 to write to the SD card (SanDisk 512MB) indicates “SdErr” when trying to burn.
The card needs some preparation prior to recording (creation of directories or files)?

Sorry my poor English :blush:

Thanks

Thanks for your feedback!

For your questions I have the following:

Xml as an export format is preferred (over CVS) when you have more than one record type (we have configuration profile + points) and is also widely supported across multiple platforms and a range of applications.

Import is possible using the ”FILExxx.DAT” format and I’ll try to add a description of this format in the readme file for those interested.

Calibration is from a single pair (offset and range) for all ranges and will be saved/restored as part of the profile.

The BenF V3 firmware is developed using a demo version of IAR 4.0 and a complete working project (including source for V3.11) can be downloaded from the SeeedStudio site on Google code. For more information on development, I suggest you post in a different thread.

No special steps are needed to use SD cards with the Nano. If you have issues, you may want to try the following steps:

  • Check that your card meets the requirements stated in the BenF readme file
  • Upgrade to the latest version of the firmware (LIB and APP)
  • If possible, verify that the card works outside the Nano
  • Reformat the card with your OS (FAT16 or FAT32)
  • Or if no success - reformat using “sdformatter” (version 2.x is a good choice)
  • Try a different card

Hi BenF,

I have played some time with the firmware you have created and I have to say that I am impressed.
This FW brings the DSO Nano on a completely different level. You have done very good job, congratulations!

Benf Hello!

I formated by SDFormatter and it worked.
Your firmware created the directories and files automatically.

Thanks again.

Hello benf

I found a converter xml2csv.

If we could choose the sampling frequency more

precisely (list of values introduced in the. cfg

by a host editor) and the duration of the PREFETCH

(Also in the. CFG) might have a logic analyzer analog!

I need to analyze the frames of the ECU

my car.

Thank you

google translation

Hi,
I try new firmware on my DSO Nano v2. Its fine and more usable as original 2.5;
and now I have some questions:

About “FL”
Try Saving Ref to new file - get Write Err msg, but file is saved.
Load and Show Ref will show refrence signal, but if I adjust “VD” or “TD” Ref signal is not changing on screen (as static picture).
So if I saved ref and changed VD" or “TD”, I can’t know what is this signal values.

Ahh! - me to. The error message is wrong and I’ll prepare a fix for that (will post in this thread).

This is by design.

You will when you change VD/TD until the input signal match up with the reference. The idea here is to capture a waveform from a known good signal source, let’s say ignition pulse on cylinder one. Then you load and use this as a background reference when you check the other cyclinders.

When you need to record both waveform and settings, you can use either the bitmap or xml export formats.

The Nano can be somewhat useful as a rudimentary single channel logic analyzer (especially if nothing else is within reach), but it is not the right device to use or build on for this purpose. It can however add to the logic analyzer and show you the true nature of the input signal. This can help you identify noise, ripple, transients etc. It will also allow you to do a quick verification of signal frequency (do I have the right baudrate/speed) and also check for presence of clock and other digital bus signals.

For capturing and analyzing long streams of logic however, it is totally inadequate.

Here is a link to an SD Org Forum discussion about using HC flash cards with SPI protocol.

forums.sandisk.com/t5/Mobile-Car … m-p/198461

The fifth message down states that using block addressing versus byte addressing will allow the use of HC cards with SPI?
Those of you with necessary skills such as BenF and others, may wish to look into this for the DSO.

Hi BenF,

Thanks for the clarification regarding calibration.
In that case I’ll revise my request/suggestion! As the DSO appears to NEED different offset calibration, and probably different gain too, for each range, would you consider adding a calibration pair for EACH V/div range, to be saved in the profile?

Thanks,
Adrian.

There was a discussion on this in the 3.1 thread with no real consensus. A full calibration of all ranges will require two points for each range (10*2 = 40) which is quite a task for the user. Another issue is if one-time calibration is sufficient, e.g. will it remain consistent across temperature variations? It is less of an issue to implement, but it is not clear to me if it will be worth the effort. My Nano is pretty consistent across all ranges, but others may indeed be different in this respect.

Mine varies quite a bit between ranges. If I zero it on the 1V range, I get a 400mV offset on the 2V range for example. My experience with analog electronics makes me think it is unlikely to drift much with temperature, particularly over the ‘operating range’ of a human being, who must be operating it! Although the TL082 doesn’t have the best characteristics… Drift with time may be experienced, but this is likely to be over a very long period (years).

I would personally be very happy to calibrate the necessary points - particularly if I only had to do it once. What may be worthwhile would be to use an average of calibrated ranges for the cal of any range the user neglects to do.

I personally think it IS worth the effort. I hope you will consider it further!

But I can’t use it as Ref , may be add function to load xml as Ref? or Load Buf as “Virtual 2-nd chanal”?

BenF,

My DSO Nano arrived today. After a quick check to verify that the hardware was fine, I upgraded to 3.21.

Dude it rocks!

My one request is that I do a lot of work on 125KHz RFID tags. As you may know, that’s a pretty standard speed for LF tags and the Nano has just enough bandwidth to work at that frequency.

Is there any chance that you could add 125KHz to the list of output frequencies from the PWM? It would allow me to insert a signal into a tag to test resonance.

Apart from my eternal gratitude, I’ll buy you a beer next time you’re in Western Australia. :slight_smile:

…and if you can’t or don’t want to…it’s all good. You still have my thanks for what you’ve done so far.

Assuming this is offset – what about range. Any qualified guesses on whether we’re good with one only, or better yet can someone share actual calibration data?

Developing for embedded devices isn’t quite like Windows. As an example, the buffer file is an image that would occupy more than 150kB of RAM, which is far more than we have to work with altogether.

You also have the option to capture settings in files and one approach could be to always do both and use the same file sequence number (e.g. load profile 100 and reference 100).

Look for the next update, there should be something for you here. (I’ tempted to stop by and collect that beer – right now it’s freezing cold where I alive).

Ok. Here is some calibration data. I did the calibration on the x1 1V range, where it needed an offset of -40mV and gain of -1.5%.

x1 attenuation:
Range Zero Vin Reading
0.1V 0mv 0.30V 304mV
0.2V 40mV 0.60V 640mV
0.5V 20mV 1.50V 1.52V
1V 0mV 3.00V 3.00V (cal range)
2V 400mV 3.00V 3.44V
5V 200mV 15.0V 15.2V
10V 0mV 25.0V 25.2V

x10 attenuation:
Range Zero Vin Reading
0.2V 48mV 0.60V 664mV
0.5V 40mV 1.50V 1.56V
1V 0mV 3.00V 3.08V
2V 400mV 6.00V 6.32V
5V 200mV 15.0V 15.2V
10V 0mV 25.0V 25.2V
20V 3.2V 25.0V 28.8V
50V 2.0V 25.0V 26.0V
100V 0mV 25.0V 24.0V

That didn’t format too well! It seems to have compressed multiple spaces into single ones. Oh well… Just copy/paste then replace spaces with tabs.
Basically it looks to me as if zero calibration is needed for each range, but we only need a single gain cal for each attenuation setting? I used a Fluke 8840A meter so the Vin readings are known to be accurate.

Thanks for sharing the calibration data.

To get a better handle on the deviations, I converted the data to relative values and compensated for offset before calculating range errors.

There appears to be some correlation across ranges for offset errors, but less so for range. Still there is sufficient variation to suggest that handling each range separately is better than trying to device some common scheme. I will consider this for a future update.

[code]Offset Range
0 % 1,3 %
7 % 0,0 %
1 % 0,0 %
0 % 0,0 %
13 % 1,3 %
1 % 0,0 %
0 % 0,8 %

8 % 2,7 %
3 % 1,3 %
0 % 2,7 %
7 % -1,3 %
1 % 0,0 %
0 % 0,8 %
13 % 2,4 %
8 % -4,0 %
0 % -4,0 %[/code]

Just installed this on one of the first batch dso nano’s ( yep i have had it that long)

Thanks ben I love it.