Triggering again before the buffer duration is up in acquire

[albertryou2]

Hey guys,
Thanks for the help in advance. I'm recently getting into Red Pitaya and this forum has been invaluable. I have a very basic question about the order of decimation, trigger, and acquire. From the available SCPI/API documents, including the code comments in the Matlab part, it's not clear to me what's going on in the simple acquire code. Let me know if my understanding below is correct.

1. What's relationship between "ACQ:START" and "ACQ:TRIG"?
My understanding is that at "ACQ:START", Red Pitaya starts grabbing the raw ADC data at @ 125MHz, applies the decimation, and writes the treated data to an internal circular buffer and continues until I call "ACQ:STOP". The trigger merely marks the reading position in this buffer. Since the buffer gets updated constantly, if I trigger but then don't read the buffer, then the trigger position remains but the data may get overwritten?

2. What happens if I trigger again before the full duration of buffer has passed? That is, I trigger once with decimation 8192 and then proceed to read, but repeat the acquire loop and trigger again before 1.074s have passed?

3. If the above works without any problem and I can read with overlap, where does the eventual bottleneck appear (what breaks?)?

Thanks as always,
Albert

[Nils Roos]

Hi Albert,

regarding 1.:

My understanding is that at "ACQ:START", Red Pitaya starts grabbing the raw ADC data at @ 125MHz, applies the decimation, and writes the treated data to an internal circular buffer

So far you are correct. But sending "ACQ:STOP" does not end the recording - in fact, this command does nothing of consequence.

The "armed for trigger" state which is entered with "ACQ:START" only ends when a trigger has been recognized and the trigger delay expired. At that moment, writing into the circular buffer seizes and you can read the data out. Recording will only start again with the next "ACQ:START".

Since the buffer gets updated constantly, if I trigger but then don't read the buffer, then the trigger position remains but the data may get overwritten?

As explained above, after a trigger, the buffer is not updated anymore, so you have all the time you need to read the buffer. The trigger position is recorded as a reference point for reading the buffer.

2. You can re-arm the circular recording with "ACQ:START" immediately after a trigger, even if the trigger delay is not over. However, the acquired data may be overwritten if you don't read them out in time. The trigger source remains set at its previous mode in this situation, so the next valid event will be recognized immediately.

3. The bottleneck is that recording stops automatically after the trigger delay has passed in the wake of a trigger event. You can work around that by using a very large trigger delay and use "ACQ:WPOS?" to observe the write position and "chase" it with the read-out. Then, the bottleneck is the speed of the scpi-server and data transfer.

[albertryou2]

Thanks Nils!

Whether it actually does anything inside the buffer or not, the command "ACQ:STOP" does seem to stop the position of the write pointer from continuing to climb and loop around the 16384 buffer. Again, as you say, this might not do anything internally, but it is nice to see that when I do call "ACQ:STOP" in the trigger while loop (when the trigger condition is met), then the distance between TPOS and WPOS is always 8192 (this is with 0 delay; with delay=1000, the distance is 9192). That confirms the suspicion that this SCPI server(?) has been designed in such a way that a 0-delay trigger point appears at the midpoint of the buffer (like an oscilloscope, I suppose).

It's still not clear to me how this explains the discontinuities I sometimes see when the trigger happens very soon after "ACQ:START". I attached a picture of an example here. The discontinuity in this case appears at the 7169 point, but it moves around from run to run. Sometimes, for even faster trigger, there more more discontinuities. See the second picture.

Could you explain this phenomenon in terms of WPOS and TPOS?

Again thank you very much,
Albert

[alport]

Nils,
Any chance of answering Albert's question about the discontinuities that he sees?
I am trying to implement a relatively slow (~10kHz) continuous input sampling.

[Nils Roos]

If we are talking about very low sample rates, it may be that the trigger happened before enough pre-trigger samples had been written to the buffer. The beginning of the pre-trigger part would be old data from the last acquisition and there could be a discontinuity where the current acquisition started.
The RP api examples have a sleep-call after arming the trigger (for scpi, that would be after the "ACQ:START") to prevent that from happening. You could also use a trigger delay of at least 8192 (= no pre-trigger) to avoid it.