DSO firmware version 2.5x

I understand the DSO nano project originated as an open source effort. Unfortunately these contributions appear to have been offered by individuals with limited programming skills and even with the most recent 2.5e version we’re not much further than a pretty enclosure with potential. All in all the DSO is not useful other than for a few basic tasks.

A proper digital scope will need a three phase approach to sampling. That is pre-fetch, trigger phase and post fetch. The trigger phase must last until a trigger is found (forever if need be) while the sampling buffer is continually reused in a round-robin fashion (no samples must be lost or disregarded in this phase). When a trigger condition is met, post fetch will start and at the end all sampled data will be presented with the trigger point centered on the display. Unfortunately this is not the way 2.5e and prior versions work. The approach taken with the DSO Nano is the simplistic single buffer capture followed by trigger search. This makes it more or less useless for digital analysis (e.g. SPI, I2C, serial) and also of limited use for signals like electronic ignition (narrow, infrequent pulses) and many (if not most) other real life measuring and fault finding challenges.

Thanks to SeedStudio however, the current software is open source and based on the most recent 2.5e source release I’ve rewritten it to fix the more fundamental issues. This includes the following fixes:

• Proper three phase sampling (pre-fetch, trigger-fetch, post-fetch) guaranteed never to miss infrequent events
• More efficient screen update (10-100 times faster than current version)
• Eliminate all flickering and stuck pixels
• Code is re-written to allow full compile time optimization (much faster and compact code all over)
• A bug in Vrms calculation is fixed (Vrms is incorrect in 2.5e)
• A number of overflow bugs have been fixed (calculations for large time/div settings)
• Scan has been replaced with a proper continues real-time scan mode
• Configuration can be saved to /restored from SD card or flash (default power on settings).
• Wave data (reference signals) can be saved/restored from SD
• Screen capture can be saved to SD files
• A number of issues with incorrect SD file handling in 2.5e have been fixed
• FIT mode is implemented as a function
• A captured signal can be panned left right for further inspection
• A more relevant collection of data is selected for display on screen
• A more relevant selection of measurements
• Use proper ISO abbreviations (e.g. milliseconds is “ms” not “mS”)
• A completely redesigned user interface (no annoying blinking or color abuse)

All menu items are available from the right hand side of the display. These are organized in the following groups:

VD - Voltage/Div
TD - Time/Div
YA - Y-axis options
XA - X-axis options
TR - Trigger options
ME - Measurements
FI - File options
FR - Frequency out
OT - Other

Use arrow up/down to move between groups. Moving past upper/lower wraps around to other side. Within each group there are one or more sub-commands. As an example YA (Y-axis) have sub commands for V1 Cursor, V2 Cursor and Gnd position. Use the “M” button to display a popup window with supported sub-commands, up-down to change selection and M to close the popup.

Use left/right to change the setting of the active command within the currently selected group. Use either the B button (new version of Nano) or a long press of M to show/hide cursors or save/load files.

Choose Trigger Mode (in TR group) and press B (or long M) to activate the FIT function.

Choose Time/Div greater or equal to 100ms to activate real.-time scan mode (use Auto trigger for test).

For those who want to try the extended and updated version, you need to upload the attached version (use together with LIB version 2.2).

Hi BenF,

Just as Pauls software you’ve taken the open-source release as a basis of your new (improved) design. Unfortunately the improvements are not put back into an open-source package and shared (only the compiled version is). The whole idea of open-source software/hardware is that people work together and share there knowledge to improve on an idea or product.

So my question to you is when do you plan to have this as an open-source package available for the DSO community?

Kind regards,
pjve64

BenF,

Wow, that sounds fantastic! I would love to check that out. Do you have your work in a git tree? I can suggest using something like gitorious.org/ for sharing the code. I hope also Seeedstudio and Jerry would get into that practice as well, so that different versions can be merged easily and we get the best of all trees.

Does your code build with GCC? That would be totally cool. Where can I send all the beer?

Hi BenF,
Sorry for unable to followup with your previous suggestions due to limited resources, but glad you made one yourself! Our firmware just provides basic functionality for everybudy like you to start play with. Thank you so much for the great work!

Oh…oh… all I get is a blank screen after update to your firmware.

I agree, I too thought that true open source meant that others could add to the code, when people just post the compiled code there’s no opportunity to learn from others or help by making improvements.

Perfect, must test this soon

I also love the idea that everyone’s work could be combined in a GIT repository.

I tried your firmware and it works quite well. The new menu and colour scheme are perfect. The only anomaly I have found is with testing signals over the 400 kHz mark. From a cold start it reads fine, but if I feed in a different tone and return to anything above 400 kHz I get random results (usually it displays something in the range of 25kHz). I tested this with a reliable tone generator and will still continue to use this firmware even if I can’t test above that threshold. . Thank you for the great work.

Regards,
Jordan

Hi BenF
Thanks for the new firmware - I love the new menus - much more logical, and the whole scope feels much smoother in operation. I have a problem, though - I have been posting SD error problems on another thread, and still have the same problem with your code - I get the No File error message when reading or writing the SD card, despite the fact that it is formatted FAT16 and is read and writable from a Mac or PC via the NANO’s USB interface. It doesn’t matter whether the USB is connected or not, I get No File messages - I would expect to see the SD card error with the USB connected, as presumably the card is not visible to the NANO scope firmware.
Tony

Hi BenF，
I have tried your firmware,it’s cool.Thank you! But I also found your firmware have SD error. When saving bmp file,it shows No file.Can you see viewtopic.php?f=12&t=1132 ? I tried his firmware and some cards are ok. If you have time,could you try it?

Hi

Now I have tried BenF’s firmware and I found it quite buggy Most of the time when changing time/div the waveform disappears and it doesn’t look like a drawing bug because the frequency counter changes to “freq” too. The freq popup shows --.- or something like that. And I can’t get rid of that reference waveform (may be a RTFM but it is just not logical anyway). But I’m very happy that the SING works now

And the FIT function, yes it’s a separate button now but it still changes the mode in the top left corner??? Shouldn’t it be possible to use FIT after a SING trigger event has happend to adjust it on the screen?

Anyway thank you very much for your efforts and I really hope you will continue your work

Thanks for the feedback! Mostly positive I would say and obviously some of you appreciate the differences.

As for making the modified source public – I think the best option would be a single source with some type of managed/official maintenance (possibly by Seedstudio). I’m not sure however what ambitions Seedstudio have on the software/firmware side so I will keep the source private for now.

As for using SD cards - the “No File” error suggests that the SD card works. You need to pre-create all files however as the DSO firmware lacks the functionality to maintain the SD card file system. The only capability is to update file content, not to create new files. Also filenames must be all uppercase plus digits and the file must have the right size.

I’m not sure how to follow up on the input from “jordana”. A 400 kHz signal is approaching the hardware limit of the scope (bandwidth wise) and this may be part of the issue. If you have some specific instructions on how to trigger an issue, I may look further into this.

Comments from dnorderberg suggest he doesn’t quite understand how to use the firmware yet. You may want to re-read the brief instructions I posted and try again. You may also like to know that it has been tested extensively with a large range of signal sources with no issues found. When “Freq” is displayed (rather than a value) it is because no value can be calculated from the signal source (e.g. no trigger).

Also I have some news for all of you.

I have rewritten the library part of the firmware from scratch and added support for a mountable file system. That is, the DSO will now show up as a removable drive when connected to a host computer through USB. Files can then be read / written using the host computer without having to remove the SD card from the DSO nano. For me, this was the final “must have” issue. I will post the update shortly.

Hi BenF

I’m confused by the last bit you just wrote - in the previous versions the SD card always appears as a removable drive which can be read and written by the host computer. It has never been necessary to take the SD card from its socket. The only (slight) problem is that when the USB is connected, the card cannot be written to by the scope firmware, so waveforms can only be saved from the scope with the USB disconnected, and then read into the computer subsequently, so the NANO cannot be used as a USB scope for the PC in real time.
BTW I have tried both upper and lower case filenames - nothing seems to work. Perhaps you can tell me exactly what file sizes are needed - I might have that wrong on my card.

Tony

BenF, I totally agree that the best would be a single official tree accepting patches from contributors, managed at the best by Seeed. But in doubt of Seeed’s ambitions, why keep your source closed? I do not see the logic. The sooner you publish it, the more likely it will be part of the main code, whether it be from Seeed or another de facto maintainer.

Your rewrite of the LIB is excellent news, since the Seeed LIB can not be opensourced.

I think the only right way to go is fully free, open source code (both app and lib) and having it maintained in a CVS system like git, so that people can track the development and contribute patches. From what I can see your code is superior to the Seeed code, so you have all the cards in your hand.

BenF and all, it was GREAT to see people having better stuff over our previous shabby one! Our ambition (alpha idea) is to have an open source portable instrument with diversified firmwares and mutants filling different needs. If any client needs customization service or consultant, might they contact the contributors directly, or we will recommend the contact.

Our support would be more on making the hardware better and add more functional accessories. Jerry will help organize, promote, facilitate and maintain the codes. A good news is we have a gcc porting went on great with help from community, hope it will remove the limits from IAR. dsonano.googlecode.com/, but ready to migrate to any place crowds prefer.)

Thanks again for being interested, and the wonderful firmware shaming us

Why not just put up the source code on the Google Code site? I really don’t care two straws about how (git/svn/whatever) or where as long as the code can be improved upon by all. Jerry (or someone else from Seeedstudio) should be admin of course to keep submissions of a good quality.

So since the latest and greatest is BenFs version it would really get the process going if he checked in his code first. This would also greatly help with the switch to GCC.

Just my 0.02$

There are issues with the way this is implemented and I’ve not been able to reliably access files without removing the card from the DSO Nano and putting it in a generic card reader. Also I could never get it to work if I allowed the SD card to be formatted while inserted in the DSO Nano. This may also be the reason why you have issues with using SD cards.

The updated version should solve these issues.