Clarity about Trigger

[Farren]

Hi All,

I am very new to the Red Pitaya, so please forgive if I ask something obvious.

I am busy working through the C code examples from the Quick Start Page.
Very nice examples and easy to experiment with, change and recompile to get to know the board functions. What an amazing board with good quick start guides, Thanks to all who put an effort into this !!

I noticed the "Signal acquisition on external trigger" example does not seem to use an external trigger but the example uses internal trigger from CHA ( Channel 1, RF ADC input).
The line of code setting the Positive Edge trigger source is : rp_AcqSetTriggerSrc(RP_TRIG_SRC_CHA_PE);
Should it not be : rp_AcqSetTriggerSrc(RP_TRIG_SRC_EXT_PE); ??

I have some questions regarding Trigger.
I see on the forum that there is a bit of confusion related to trigger modes and start of data in relation to the Trigger.
Are the fast ADC converters running continuously all the time even in external trigger mode or does the external trigger start the ADC's running from a state machine in the FPGA ?
My application ( Weather radar signal processor ) requires a burst of data collection started by an external Trigger.
The radar is a pulse modulated radar, so I am not interested in pre trigger samples as there is no signal to digitise before the Trigger starts anyway.
I also don't want my code to spend time trying to find start of data in a big block of data.
So the first word of data in the buffer must be the closest to the Trigger as far as timing is concerned.

Please point me to any information that clarifies the Trigger versus data buffer alignment etc.

Thanks for any advise.
Farren

[Nils Roos]

Hi Farren,

The scope module records data into an internal circular buffer of 16384 samples while waiting for a trigger event to occur. This happens inside the FPGA and does not consume any processor time. It's just the way the whole thing is designed.

Once your application notices the trigger event - eg. by polling rp_AcqGetTriggerState() - you can use rp_AcqGetOldestData[V|Raw] to read the buffer. From the descriptions of these functions I conclude that they will fill the target buffer in a linear fashion from oldest to newest sample, where the oldest sample should be the one that was taken at the moment the trigger happened.

[Farren]

Hi Nis,
Thanks for your assistance.
I agree that the description of how it works is what you say but what actually happens is not the same thing.

The last few days I have done many test with the Scope API.
I have tried several different methods and keep running into the same problem.
It seems that only half ( 8192 ) of the buffer returned by the AcqGetOldestDataV is correct.

I inject a one shot trigger into External Trigger DIO0_P, this works and triggers the acquisition.
At the same time I inject a 1V pulse synchronised to the trigger, so when the trigger goes from low to high the Pulse also goes high at the same time.
The length of the pulse is 600 mS then goes back to low ( 0V ).
The decimation is set to 8, so the time to fill 16k buffer is 1.048 mS, and my pulse will easily fit in this time as it is less than 1.048mS.

I use the provided example with small modification to printf the data to the screen.
In the code I use the API function: AcqGetOldestDataV
Note that TriggerDelayNs is set to zero.

After triggering the pulse I look at the 16k data buffer from the start ( 000 ) to the end ( 16384 )
I see the following:
from 000 to 8191 are all ZERO ( -0.01 V, noise base line )
from 8192 to 16383 are all HIGH ( 1.00 V) ( the pulse ), the actual pulse is longer than 8192 samples.

So it looks like only 8192 ( half ) of the samples are valid, the rest of the pulse data is missing.
What is happening here ?

I have verified the pulse width and trigger with a logic analyser and all looks correct, so its not the pulse that is short.

If I run the Generator & Oscilloscope app display all looks correct, so the hardware is good, the pulse I am injecting and trigger is good but I am starting to think that there is something wrong with the API function that gets the raw data from the 16K FPGA buffer and loads it into the user buffer.
Hopefully I am wrong and I am making a mistake, or is it possible that there is a bug in the API ??
I see that others have complained about the same problem.

If I can get this sorted out I should be able to progress with the rest of the project.

Thanks
Regards
Farren

[albertryou2]

Hi Farren,
I've been confused about the nature of this trigger for a very long time. Were you able to sort it out? Why does the returned data seem to have a discontinuity around the 8190th point, before which is the previous buffer and after which is the new buffer? It seems like I can make it go away by setting the delay to 8191. What is actually going on here?
Alb