Back to the discussion about the "trigger out", I'm guessing what you're getting at, is does the trigger show edges when the scope is acquiring samples. I.e. is it just a pass through from the trigger circuitry. I can defiantly say it's not. You can throw as many pulses you like at it, and it will only have a rising edge when the scope actually is triggered.
i would not say pass through, the trigger flag/option etc. need to be set and fullfiled to produce output here, but this
still didn't means the DSO postprocessed the data and stored it in some buffer (like on DPO or all modern DPO-like DSOs)
or send it to display (or display buffer) which is the case for typical DSOs.
When you check the available memory in DS1000E, you will see there is not enough to have 2 x 8k or 1x16k buffer
within FPGA. There are 423936 bits, div by 10 ADCs and by 8bit per ADC thats 5299.2bits - more realistic from
implementation point of view is therefore 4096bit max. Even if not full 4k but e.g. 1k are used per ADC, the DSP
still need to read multiple times or there is different architecture in FPGA (which we don't know, see below).
In HanTekway DSOs i can see in FPGA two FIFOs, each 2048bit deep and 16bit wide. That's 65536bit
and already twice the reqiered size for "4ksamples per channel", so i assume this are the DPO-like buffers.
I assume the FPGA is using dual port ram for sampled data, so 8 ADCs x 8bit x 4096deep, that's are 262144bits.
So together there are 327680bits used (from 423936 available), and still lot of (96256bit) for what so ever function.
Knowing this (and the fact that i can set trigger by writing specific FPGA register and read back sampled data without
running the ARM app) i could say that IF there is similar trigger-out signal on FPGA (it is actually there as specific
FPGA register readback) then this will be a real trigger-out data.
Did i forgot something? Yes is did, this is only valid for 4ksamples per channel, when HanTekway is using more
(24k, 40k, 512k, 1M or 2M) then that data is going then to external SRAM before moved into display buffer.
That means trigger-out should send "triggered pulse" 10x when memory depth is set to 40ksamples (or only once
when the FPGA design is smart enough). I assume it is the last case, because as i patched once the ARM firmware
to beep on trigger it was only once beep per 40k.
All the other things the DSO is doing with the sampled data need to be count as well as part of acuisition step
- especially when we talk about DSO, for DPO-like gears this might be difficult to say. Example Tek TDS700A,
when DPO enabled the DSO can be still getting slower when adding measure, cursor, etc (but the trigger out didn't
drop here as it comes from the sampling core and not UI).
I can only guess what Rigol DS1000E is doing in FPGA, two 4k deep FIFOs, each 16bit wide (two FIFOs mae sense
as we have two DSO channels). Then 10 dual port buffers (for 10ADCs) x 2k deep x 8bit wide. The remained
129024bit are for what so ever DSO functionality in FPGA. However there is still open question how they managed
to run 5 clock domains in EP3C5 FPGA, and are they skipping sampled data 4 times to write FIFO? They can as well
use external SRAM to store the 16k, this is what we don't know.
An hardware "clone", e.g. ATTEN (what so ever, one of the old models) is having only 4k when the SRAM is not populated,
so it can be that Rigol is using the external SRAM for these 16k already. If that's the case, the question "is the trigger out
you found a real trigger out or only sync signal to LA" is still valid. Additionally Rigol DS1000 was never announced to work
as DPO-like DSO, so we need for sure take into calculation how the data is being sampled, stored and postprocessed before
we use the signal you found for what so ever calculations.
Home
Help
Search
Login
Register
