improved user interface
group things together (eg trigger: level, edge and range should be next to each other)
-try have menus - with the default firmware pressing up but going right is a bit odd
display battery charging status / have this information available.
ability to make changes and submit them with the potential for them to become part of the official firmware
Thanks, we will queue the requirements, to the many improvements DSO nano desire… 
The UI is very preliminary, we will have dedicated resource to keep improving the firmware.
Just got my DsoNano, and it looks great.
I don’t know the capability of the ARM processor, but would it be possible to implement an FFT?
Even if that was only for an audio bandwidth, it might suit a lot of users.
Cheers
Hi Captain - just what I was thinking of using the scope for - various FFT algorithm’s are available for the ARM processor - there are designs from NXP etc. We need to think about resolution - being able to zoom in on a small part of a spectrum would be great but perhaps require too much processing. A broader waterfall display of a wider piece of spectrum would be great.
Possibilities are endless - from guitar tuners to quick EMC sweeps to amateur radio receivers.
Once you have such a beautiful colour display like this in a tiny case attached to a user programmable ARM processor, the possibilities are endless.
Does anyone out there know about the compatibility of the ST toolchains with the other manufacturers stuff - eg NXP and MBED?
Tony
I’ve been working on a FFT display that could be of interest, it’s only in the first cut and nowhere near ready to see the light of day see attached bmp file for current display image. This has been produced in about 1 second using the Goertzel algorithm to extract spectrum data.
image002.rar (2.96 KB)
Hi pwdixon,
Well done - that’s a great start. I’m not familiar with that algorithm. Do you know how much code space - you used - presumably we need to keep within the 32K limit of the free tool chain. if you want to share any code with me, I wold be a willing tester/modifier.
Tony
Thanks Tony
I’ve used the V4 IDE with optimise for speed with:
maximum (high) optimisation the code is 22706 bytes,
with optimise set to low the code is 30110 bytes,
with optimise set to none the code is 30570 bytes.
I want to get a bit further with a more usable user interface and do some work on the limitations of the algorithm before releasing my child into the world, otherwise I know that it’ll just come rushing back in my face.
I hadn’t tried actually using the optimised code on the Nano and when I did it didn’t work, it did get past the “System Initializing…” message and then the app stalled.
I’m guessing that the library wasn’t compatible, probably they need to be compiled with the same optimisation level so until I can work out how to compile the library I’m going to have to stick with the non-optimisation setting. Can anyone explain how to compile the library source files?
Done a bit more work on compile options.
Maximum optimisation for size all options unchecked 26758 bytes
‘Code motion’ unchecked only 25430 bytes
both configurations compile and run ok.
Maximum optimisation for size all options checked 22966 bytes, compiles ok but does not run.
Hi folks, I too would really be interested in a FFT option if you get it working. Good luck! What an incredible instrument DSO NANO would be in you get that to work 
It turns out that the iPhone has “oScope” “Frequency Analyzer” apps
youtube.com/watch?v=StYAyhBxDbI
youtube.com/watch?v=_rqV45cBrI0
The frequency analyzer option would be very nice to have for the DSO Nano as it is so much cheaper than the iphone …
Hi dkriz
I looked at some of the iphone fft implementations and they look really good. There are some open source apps, but I didnt see any for an fft. The iphone appears to use some flavour of ARM processor so there will be a level of compatibility with the NANO. The specialist iphone libraries may not help with the simpler NANO. Lets see what people come up with - exciting stuff. I am trying to do something similar with an MBED development kit, but its a long way from being able to display like those iphone apps.
Tony
Hi,
I am just studying FFT algorithm . If we use the common algorithm in c language, the efficiency could not meet the need. Fortunately,ST provide the DSP library including the FFT algorithm which is written in assembly language. Because of the limitation of the RAM (just 20K bytes, the current firmware has used about 16K),I think we could only do FFT function without the current firmware.
ST FFT.rar (140 KB)
Hi Tony, thanks for looking into this. Jerry (note after yours) has also looked into it. Apparently, there are also some FFT functions available in the ST’s DSP library. The question, of course, becomes how to use them.
Hi Jerry, the DSP library indicates the 256 point algorithm would use 1.6K memory, the more accurate 1024 point algorithm would use 4.8K memory. In both cases, the coefficients are stored in flash memory. Maybe the 256 point algorithm is the best that can be used for now.
Hi
I’m new to DSO and I’m using it for basic audio measurements.
My requests are:
Many thanks.
Virgil
Hello Jerry,
I’ve been looking into the FFT stuff recently. ST DSP library best FFT implementation (1024 points) uses about 4.5K of Flash memory (coefficients are by default stored as code and not as data). The only restriction I see is on the memory needed for saving the output: 1024 32-bit points, ie 4K of RAM. Is this feasible with current firmware?
Antonio
There’s an interesting DSP library written by Embedded Signals, of which a (free for non-commercial use) sample is available here.
Antonio
Hi Antonio,
The 2.5e firmware has cost 16k RAM, I think Ben’s firmware uses more.So It’s a risk to do FFT arithmetic in the current firmware. Maybe we just write it without current firmware.
Thanks!
From looking at the elf files, it seems to me there is enough RAM:
LIB uses ~1k, of which 512 bytes is the Data_Buffer for writing to the SD card.
APP uses ~8k, of which 6k is the Scan_Buffer where the samples are stored.
The stack has currently 1k allocated in the linker script.