NEW FIRMWARE APx_P100 - source / manual / bugs

Hello

The new official firmware “AP3_P100” is available now (“AP1_P100” can be found on the chinese forum at http://www.minidso.com/forum/viewtopic.php?f=7&t=117).

It looks good, the feeling when navigating (responsiveness, design) is - at least in my opinion - much better than with 2.51.

My question to SeeedStudio (or to the developpers of the DSO Quad/203):

  • where is the manual for this firmware?
  • where can we download the source code?

There are some annoying bugs which we could maybe correct with the source code, like the signal generator (below: saw signal with 10kHz… alle signal types except square have a bad waveforms and a wrong frequency):IMAG001.jpg
I think the measurements (Vpp and so on) are still a little wrong, too.

Patrick

In my opinion, the old interface with the changes from marcosin much more compact and more rational.

In any case, the main problem of the device - not an interface, it is a terrible triggering on rare single events, such as UART packs. So now that the device can not be called an “oscilloscope”, it is something like “low accuracy broadband tester”

I found the new version referred here works much more reliably than before especially with NORM triggering. AUTO fails miserably even now. Overall impression I get is there is some hope for a better quad.

I tested the new version, with short single pulses. Triggering more reliable. But this only applies to a large sweep times. For a short times the situation begins to deteriorate in proportion to.
it looks like this (see image)

if T_act >> T_busy (in 10 times or more) probability of triggering is high
but if T_act <= T_busy probability is 50% or less

in my case 50% triggering probability for 30uS imp reaches for 50uS\div sweep

snap.gif

Since triggering is not done at the APP level, the only difference in behaviour can only come from other factors, like the processor load…

maybe app not react on triggering event from FPGA (when some sys routines, int’s, etc)

Could be, but the APP processing is not interrupt driven. It just reads the FIFO buffer (or waits until the buffer is filled with data) in a loop.
It doesn’t make decisions on the triggering itself. That logic is ‘bellow’.

fpga, on triggering event, must fix her state and wait until app read fifo
may be some errors in this sequence

sorry for my English. i am Russian commie :slight_smile:

No problem - I’m a bankrupted Portuguese :slight_smile: