Hi!
Can we get an announcement of new features and fixes in the new firmware?
Kind regards
David
There’s definitely some progress made.
A quick test on my part revealed the following:
- SING mode has been reworked
SING will now trigger and hold as requested by many since version 1.
Unfortunately, it is not sampling continuously. Sampling appears to be done in cycles (e.g. capture, analyze, capture …).
So events may (and will) be lost. My understanding is that they use DMA for sampling, and I can’t really understand why they can’t analyze (look for trigger) in one part of the buffer while capturing the next (no timegap). With this update, I can look at repetitive events, but not single events.
Another issue is that the currently captured waveform is not updated (redrawn) when you change settings. That is, I can not pan or resize the waveform on screen. This is less of an issue for repeating waveforms (you can always capture a new event), but a must have for single events.
-
Transparency is gone (hopefully for good).
-
FIT mode
I’m also having issues with the “FIT” mode trigger. The problem is that whenever I change trigger mode and incidentally cycle passed FIT, all settings change. My take is that if you don’t know how to set the DSO parameters, you probably don’t need a scope either. Really, I would rather see this mode removed from the firmware altogether.
Despite my issues, I’m happy to see the progress. Thanks for the update.
Thank you BenF for the update, nice to hear that there is some progress in the right direction 
I’m on vacation so I can’t try the firmware myself right now but I’m sorry to hear that SING only work for repetitive events and not single ones 
I also really want SING mode to mean “single”, not “any of many” events And of course it would be better to continuosly watch for a flank and capture at the same time so the trigging edge always shows on the same place on the screen too. I’m used to oscilloscopes where you can chose where to place the trigging point on the x axis and I guess that would be impossible to do with the capture-analyze-capture thing. Maybe the CPU is hindering continuously analyzing? I don’t mind if it can’t update the screen while capturing, some professional oscilloscopes doesn’t to that either. Btw, can you capture falling flanks too or will it trigger immediatly if you try to do that? Falling or rising must be selectable, lets say you want to see the falling flank of a pulse with 1ms/div resolution but the pulse may be like 1 sec long and you don’t know when the pulse may happen.
And I guess the buffer is of the same resolution as the screen has sampling points (or pixels) so that is why you can’t change time/div to zoom in/out or pan left/right as it wouldn’t do anything useful anyway. I think we could live with that if it would be possible to select where on the screen the trigging should be drawn.
Btw, what does the FILL do?
It is unclear to me if the lack of continues capturing in SING mode is due to the programmers not understanding the requirements (which should be easy to sort out) or if they don’t know how to program it (they say it can’t be done). The basic idea here is to leave the screen as is and devote the full CPU to capture and look for a trigger. I’m sure it can be done (without missing a single sample), considering the modest bandwidth and the relatively powerful CPU.
As for panning (and possibly changing the x/y axis) for a captured waveform, data should be redrawn from the sampling buffer. The sampling buffer should hold the raw captured data around the trigger point and the waveform should be resized (stretched/compressed) to match settings as they’re changed.
My guess is that the memory and CPU is far from capable to handle the captured data in raw form. Lets say you want to “zoom out” to the extremes (10s/div) and there are one million samples on one sec then you are dealing with ten million samples in memory and 12 bit vertical resolution, that is 120 Mbit or 15 MB in memory at the same time. Don’t know what kind of memory the ARM has available but it’s not in this magnitude I’m pretty sure.
As I said earlier, I would be happy if I can select where on the screen the trigger will happen. Then atleast I would not have any needs for “zooming” or panning.
But we both agree on that it’s not OK to miss events and that full power should be devoted to capturing, nothing else mathers while waiting for a trigger event.
I think you’ve got this backwards.
The capture buffer uses a dedicated part of available RAM capable of holding a fixed number of samples. Sampling time is then adjusted to match this buffer capacity, based on your selection of time/div. Number of samples (x-axis) is typically much larger (2 times or more) than what will fit on screen, and what I ask for is that we get an option to see all of it (whatever was captured) through a pan left/right control. This is not asking for the impossible or even pushing the DSO/ARM in any way - it is just using what is already there.
If you select an exceedingly large time/div however, the buffer can no longer hold a full screen. This is when you see the signal extending from left to right as it is drawn in near real time on the display. In this case of course, pan left/right is not possible, but also not needed nor desired.
The changes are posted here: seeedstudio.com/blog/2010/08 … or-update/ I’ll post a sticky topic with upgrading info and to collect inputs.
For the single mode, the design was to hold after triggering once.
Sorry but maybe I might miss some conversation, did our engineer say it can’t be done? I seldom use continue single triggering myself, but it would be feasible to modify per user’s favor.
For FIT mode, it’s like AUTO on most oscilloscopes, maybe we make it a function rather than “MODE”.
We are allocating more resources on DSO Nano product lines, thanks for the inputs!
When hold, you may go menu item “T0” and PAN it to different part of the sampled buffer. Excuse me if I’m not answering to the right question…
You have to read it in the context of above - this is not about continues triggering (I don’t have or see a need for that in SING mode). It is about continues sampling while waiting for a trigger and when in SING/RUN mode. As it is now, you seem to be doing the following:
- Sample data
- Stop sampling
- Check buffer for trigger event (while checking, the trigger may come and will be lost)
- If no trigger, start sampling again
- If trigger, hold and display data
That would be much better.
So I thought, but the captured data is not shifting left/right, only the trigger-point and buffer indicators are.
Thanks for your feedback!
They might have, but this is me asking and trying to understand why single capture is not implemented correctly yet (as of 2.4). If the requirements are unclear, I will be happy to assist with detailed specifications. If it is the engineers saying it can not be done, further clarifications may not help.
Ah, “FIT”, someone wrote “FILL” before 
And I also think it would be better as a function then a mode on its own.
And I fully agree with BenF on the single trigger fuction, that is how oscilloscopes should work and mostly does 
Very happy to hear that seeedstudio will allocate some more power on this ultra cool product and I hope something good will come out of Slimfish’s and shazam’s research and ideas. By polishing both hardware and software a little bit more I’m sure it could sell like ice cream in the summer. With a more polished product really big resellers might be interested and that equals to seeedstudio hiring even more people to work on the nano
I got the idea now, thank you so much for the patient explanation. I just found the other topic you posted, viewtopic.php?t=508 We own you a big thank you for all the feedback and professional insights. Freezing has left Seeed Studio and I’m in charge of DSO Nano Project now.
The Panning code for single mode is not right, which should be the same as HOLD in other modes. We will fix it and add resizing.
I will get back to you with other issues you mentioned. Thanks!