DSO firmware version 3.2

Attached is the most recent BenF V3 firmware.

Using the DSO Nano with the V3 firmware has been both fun and helpful, but without a PC it has been challenging to keep track of files on the micro-SD card. Questions such as “did I prepare sufficient template files?” and “which is the next free number in the series?” become difficult to answer after a few power on/off cycles with various measurements.

This update include a number of new features to help overcome these challenges and I trust you will find them useful when using your Nano’s for field work.

Major new features in this version includes (see version.txt for all changes):

  • Automatic creation of files and directories on micro-SD cards (template files no longer needed)
  • Snapshots of the full DSO sample buffer can be exported to XML files
  • Usability enhancements

Update 2010.11.23 - APP V3.21

  • Fix issue with incorrect trigger position when t/div less equal 20us
  • Fix issue with incorrect “Write Err” message when saving profile and reference files

Looks nice. Will try it.

Will you post your source also?

Hello BenF,

First of All Thanks for your endeavour and the source code of your firmware version 3.11!

About the version 3.20, I tried under Linux (Mint 9 ~ Ubuntu 10.04) to flash it (I did it twice after downgrading to version 3.12), but something is going wrong in my case because I don’t see any trace on the screen (only something which seems to be a small trace in the bottom-right) and the firmware seems to be frozen.

To be fair, I use the dfu-util enhanced by tormod and perhaps it is related to this tool:

[code]dfu-util -V
dfu-util - © 2005-2008 by Weston Schmidt, Harald Welte and OpenMoko Inc.
© 2010 Tormod Volden (experimental DfuSe support)
This program is Free Software and has ABSOLUTELY NO WARRANTY

dfu-util does currently only support DFU version 1.0

dfu-util version 0.2+
[/code]
here is the command used to flash this firmware:

dfu-util --dfuse default -d 0x0483:0xdf11 -i 0 -D DSO_BenF_LIB_v3.02.dfu dfu-util --dfuse default -d 0x0483:0xdf11 -i 0 -D DSO_BenF_APP_v3.20.dfu
and in attachment you have the ouputs of this command.

Also too, in attachement there is a picture of the screen (don’t bother with the blue pixel in mid-upper-left, it is a dead pixel on my new DSO Nano v2!) showing its drawing state.

Thank you for reading and Thank you for the last improvment.
DSO_Nano_v2-DSO_BenF_Firmware_v3.20.png
DFuse_DSO_BenF_APP-LIB_v3.02-20.dfu.v4.log.tar.bz2 (1.51 KB)

Most likely! I can see in your LIB flashing log that something went wrong, but the program did not catch it and stop as it should have done. Please retry it. And always get the latest version of my dfu-util, I fixed some bugs some minutes ago that would break on some dfu files (but not these I think). If there are still problems, please report it in the dfu-util thread: http://www.seeedstudio.com/forum/viewtopic.php?f=12&t=1353

Thanks for the grid intensity control.

Thanks for the improvment.

Hello BENF

thank you for the Safeguarding of the buffer.

Could we have a 'LOAD BUFFER, which would replace

‘LOAD DAT’ by remembering the location of the screen?

.XML Format Requires Excel 2002 while .CSV works

with Excel 97.

Could you one choose the length of prefetch to store

more data to analyze.

Thanks again.

google translation

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.