I have done some more testing with what I could scramble in terms of Micro SD cards and different formatting options. Some issues were found and fixed. Those who’ve had no success with SD cards until now should try out the new version.
Also, I’ve collected notes on using the firmware and added it to a readme file included in the download.
With the calibration in place, this DSO v2 is now close what I had hoped it would be.
Also good job with the manual, one note, on the v2 there is no “M” button, it’s called “OK”, otherwise it makes sense all the way through.
Seeing the notice about the firmware being available in binary format in the public domain. Does this mean we should stop bothering with asking you about the source? I think it would be nice if you could just say either “working on it”, or “not going to happen”. So we can move on… I think it’s a shame if you don’t release it. Since anyone is probably going to want to run your firmware, it probably also means that very few will now look into hacking the code since they would have to go back to original crappy 2.5.
In any case, you’ve made the DSO Nano much more useful, so thank you for that.
(Crossing fingers for the rest to happen).
Thanks, Tomas
Btw. Any plans to look into some simple spectrum analysis feature ?
This feature is exactly what I have been working on but to be honest when I found that the library was closed source and working out how to completely integrate my code into the project became such a pain I’m pretty much disheartened and I’m not sure that I’ll bother to continue.
Having to base my code on versions even earlier than V2.5 to be able to access the library code is such a step backward that I might as well not bother.
In effect as everyone is raving about V3 (BenF) if it remains closed source then the whole project has been cut off at the knees and there won’t be any further enhancements except from BenF. That means I’ve learnt everything I can from this kit and will move on and just use it on my workbench and forget about making improvements.
Thanks for feedback guys! And, as”lindquist” put it – this is pretty much what I expected when buying the Nano - as well. Actually, I dropped mine in a drawer after just an hour of frustration and disappointment and didn’t really expect to ever use it. This fall however a friend of mine needed help with sorting out ignition issues on his outboard. Buying a $2000 Fluke for this field job (the issue was intermittent and only showed when at sea) was out of the question, but a couple home built probes and a modified Nano with the current sampling logic allowed us to indentify and fix the problem.
Releasing the source (as seems to be such a hot topic for many) is not a big issue for me. I’ll give some consideration to how we can best accommodate this. After all - Christmas is coming up soon! As for you “pwdixon” – going about this with tons of attitude isn’t helping. With all due respect, I think none is worse off now than before we had my contribution. If you can’t do anything useful with the current open source, you’re not likely to do much better building on what I wrote.
It seems like Tormod, Jerry and others are doing an excellent job on the open source GCC tool chain initiative, so I trust something good will come out of this. Jerry made a valid point with respect to FFT. This is probably better approached as a separate application due to resource limitations (RAM in particular).
“Altitude” suggests there may still be issues with SD card support. Can you reformat (e.g. using the “sdformatter” utility or otherwise and give a more detailed feedback? It would also be nice to hear back from others who had “No File” issues in the past with respect to the latest update.
“picpic020960” wants to capture the sampling buffer to SD card and yes, I’m sure this is doable and possibly something to look into.
That everyone bugs you about releasing the source should be taken as the highest praise! You have taken the software from “promising but not really usable” to “great”.
Personally I am a great fan of the open source model that Google is using for android; people can submit patches and new functionality into the external branch but Google decides if the change is good enough before integrating it into the mainline. Been around the 'net for a while and are sick and tired of quarrels between developers in a typical open source project which then ends up in a gazillion forks
Ben,
The 3.1 firmware is great and many thanks for getting it to a practical useful stage. The DSO is a real tool now for low-freq waveforms like serial signals, automotive, audio etc. The sampling and triggering/display mode is just right.
Also of course well done to Seeedstudio for getting the idea off the ground in the first place. This is also a nice introduction to ARM.
To answer you about the SD card (for me): the revision by pjve to the version 2.5e was the first time I was able to write images etc to the SD card. He corrected some logic in the initial read of the SD info. With Ben’s 3.1 version I can write to the SD card, formatted from Win as FAT16 or 32. I can also read the card files from the DSO while connected to the PC. I have a Sandisk 2Gb.
The Calibrate function is useful and works well at 1x, but I sem to have a problem trying to calibrate for 10x. Is this my problem or is there something odd at 10x? Doesn’t matter, 1x probe is fine in this freq range.
SDformatter did the trick, I was using the windows FAT format and that seem to mess things up (although it still worked in 3.01). I was getting a SD ERR btw…
BenF, just tried your latest firmware: your work really boosted the usefulness of my Nano - now I have a very handy tool for audio measures
Also, thank you for taking the time to write the manual - without it, I would have missed a few things.
And last but not least, thanks a bunch for considering about sharing your work with us also in source form: I for one would love to see your code - I’m sure I could learn a lot from it (got still a loooong way to go before thinking into improvements!).
I was getting Prob saving image (or other) on my SanDisk SD 2GB with 3.0 or 3.01 (2.5too) (see earlier post)
I just upgraded to 3.1 and it work fine now without using SDformatter or any new format with XP.
Many Thanks Ben now i can use every function on my DSO V2.
Hello BenF,
working with another embedded system I saw its bootloader
uses the library FatFs, which implements a very complete
FAT driver for embedded systems:
With that you could create files directly, without having
to preload templates on the SD card - do you think the
Nano has still some memory to devote to this?
<buggin’ mode on>
If only I had the sources, I’d give it a go at implementing
that part myself
</buggin’ mode off>
I haven’t had my DSO Nano delivered yet so I haven’t had the opportunity to use your code yet. I’ll confess that when I first read your change about searching for the trigger in real time, my reaction was “Surely that’s the way it already is?” It sounds to me like you have not just improved the code but made the DSO a practical tool for the first time.
I’d like to throw my very modest weight behind picpic020960’s suggestion of being able to save the whole working buffer to the SD Card. IMHO that seems like a great payoff for time invested. In addition to a host of other uses, it would let people do FFTs on their PC with the data grabbed. That’s not to say a built in FFT wouldn’t be great, but it sounds to me like a lot more work to implement.
Hi,
I’m a German user, so I’m sorry for my English.
So First:
This firmware is very much better then the 2.2 FW.
But I have a Ideas:
Can the DSO nano v2 give Funktions from file to funcion generator port out, so you can use old scoped datas as output?
Thanks!!!
From a sofware perspective this is doable, but analog output would require a hardware modification. The frequency out pin has a digital gate (74HC125) on its output and so can only be digital (square pulses).
Would it be possible to use the output pin for generating a PWM signal?
That way the hardware modification could just be an external low-pass filter. On the other hand, the resulting waveform won’t be very precise, I guess - but it could be suitable for not too high frequency applications.
