firmware 2.4

Moderators: lily.li, violet, jeremy882, crail.lyu969

dnordenberg
Kindergarten
Kindergarten
Posts: 92
Joined: Sun Jan 31, 2010 6:29 pm

firmware 2.4

Post by dnordenberg » Wed Aug 18, 2010 12:12 am

Hi!

Can we get an announcement of new features and fixes in the new firmware?

Kind regards
David

BenF
Elementary-2
Elementary-2
Posts: 231
Joined: Mon Nov 23, 2009 1:01 am

Re: firmware 2.4

Post by BenF » Wed Aug 18, 2010 2:10 am

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.
Last edited by BenF on Wed Aug 18, 2010 12:59 pm, edited 1 time in total.

dnordenberg
Kindergarten
Kindergarten
Posts: 92
Joined: Sun Jan 31, 2010 6:29 pm

Re: firmware 2.4

Post by dnordenberg » Wed Aug 18, 2010 7:25 am

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?

BenF
Elementary-2
Elementary-2
Posts: 231
Joined: Mon Nov 23, 2009 1:01 am

Re: firmware 2.4

Post by BenF » Wed Aug 18, 2010 2:17 pm

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.

dnordenberg
Kindergarten
Kindergarten
Posts: 92
Joined: Sun Jan 31, 2010 6:29 pm

Re: firmware 2.4

Post by dnordenberg » Wed Aug 18, 2010 6:39 pm

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.

BenF
Elementary-2
Elementary-2
Posts: 231
Joined: Mon Nov 23, 2009 1:01 am

Re: firmware 2.4

Post by BenF » Wed Aug 18, 2010 10:16 pm

then you are dealing with ten million samples in memory and 12 bit vertical resolution, that is 120 Mbit or 15 MB in memory
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.

User avatar
esp
Elementary-3
Elementary-3
Posts: 361
Joined: Fri Aug 22, 2008 5:45 pm

Re: firmware 2.4

Post by esp » Wed Aug 18, 2010 10:29 pm

The changes are posted here: http://www.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.
BenF wrote: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).
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!

User avatar
esp
Elementary-3
Elementary-3
Posts: 361
Joined: Fri Aug 22, 2008 5:45 pm

Re: firmware 2.4

Post by esp » Wed Aug 18, 2010 10:33 pm

BenF wrote: what I ask for is that we get an option to see all of it (whatever was captured) through a pan left/right control..
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...

BenF
Elementary-2
Elementary-2
Posts: 231
Joined: Mon Nov 23, 2009 1:01 am

Re: firmware 2.4

Post by BenF » Thu Aug 19, 2010 1:08 am

ESP wrote:I seldom use continue single triggering myself, but it would be feasible to modify per user's favor.
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
ESP wrote:For FIT mode, it's like AUTO on most oscilloscopes, maybe we make it a function rather than "MODE".
That would be much better.
ESP wrote:When hold, you may go menu item "T0" and PAN it to different part of the sampled buffer.
So I thought, but the captured data is not shifting left/right, only the trigger-point and buffer indicators are.

Thanks for your feedback!

BenF
Elementary-2
Elementary-2
Posts: 231
Joined: Mon Nov 23, 2009 1:01 am

Re: firmware 2.4

Post by BenF » Thu Aug 19, 2010 2:07 am

ESP wrote:Sorry but maybe I might miss some conversation, did our engineer say it can't be done?
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.

Post Reply