Page 1 of 1

Sampling on external trigger

Posted: Sun Mar 05, 2017 8:49 pm
by dangraf
Hello!
I'm new to red-pitaya and need some advise for how to accomplish my goal.
I have an external trigger at about 200-300Hz
On every rising edge, i would like to sample:
- 4096 samples from both fast AD channels
- Read out 1 sample from 2 or 4 of the slow AD channels.
- get a counter value for each trigger to correlate it and track lost frames. (might not be needed)

I need to get this data from every trigger, and I have a train of about 20.000 triggers. I'm allowed to lose frames but I then need to know exactly which frame that is lost.
When i calculate it seems possible.
4096 samples * 2 bytes * 300Hz * 2 channels = 4915200 => 5mb/Sek

I have not used the pitaya much (only the oscilloscope using the browser) and have some questions:
1. Is this possible to accomplish using standard software or visual programming? Or do I need to write my own C-code?
I'm thinking of the trigger examples. It seems like you are setting up the trigger and then wait for trigger to fire and then setup the trigger again. Is it possible to collect the data in the example above and setup the trigger again in 300hz using a windows system without loosing any frames?
2. In short, how would you set up the system for acquisition?

Best regard/
Daniel

Re: Sampling on external trigger

Posted: Sun Mar 05, 2017 10:39 pm
by Nils Roos
Hi Daniel,

you could do that with a relatively straight-forward C program that runs on the RP using the RP api. I am not sure the scpi-server's performance is enough to achieve your required rates. An outline for the approach for both (since the scpi-server is more or less just a remote control for the RP api) would be:
  1. setup acquisition parameters: decimation, trigger delay (a value of -4096 will give you 4096 post-trigger samples)
  2. arm the scope and set the trigger source
  3. poll the trigger state in a loop until it changes to triggered
  4. read the slow analog inputs
  5. poll the trigger source until it changes to idle
  6. read the last 4096 samples from each fast ADC's buffer
  7. store or transmit all data and repeat from 2.
edit: Just had a look, it seems the scpi-server does not expose the function for reading the trigger state.

Re: Sampling on external trigger

Posted: Mon Mar 06, 2017 2:55 pm
by dangraf
Thanks!
I will check it out.

Re: Sampling on external trigger

Posted: Mon Apr 03, 2017 1:36 pm
by dangraf
Hello again!
The SCPI server is way too slow to poll and read out data. I need something a lot faster.
I have read a lot of the documentation page but still have questions about the redpitaya.

The solution i would like at the moment is to:
1. have the SCPI (or similar) in the background to setup how to sample, number of samples and how to trigger the system.
2. Setup a loop to read out the values as mentioned above and send it over the network in 3 or 4 network messages.

But there are some questions that I don't understand.
1. How do I setup the red-pitaya to be able to connect to it using my own socket-server (i don't want to use a web browser) and send my own packages directly to the connected computer? It seems like all the examples are buffering the results and lets the browser get the result when ready.
2. How do I modify the SCPI server? I have lookedinside the "RedPitaya\scpi-server\src" but can't find the main-file ant it seems like this is just a part of a bigger project. Can I find more information about how it's working somewhere?

Re: Sampling on external trigger

Posted: Thu Apr 20, 2017 10:04 pm
by ayarema
Nils Roos wrote:Hi Daniel,

you could do that with a relatively straight-forward C program that runs on the RP using the RP api. I am not sure the scpi-server's performance is enough to achieve your required rates. An outline for the approach for both (since the scpi-server is more or less just a remote control for the RP api) would be:
  1. setup acquisition parameters: decimation, trigger delay (a value of -4096 will give you 4096 post-trigger samples)
  2. arm the scope and set the trigger source
  3. poll the trigger state in a loop until it changes to triggered
  4. read the slow analog inputs
  5. poll the trigger source until it changes to idle
  6. read the last 4096 samples from each fast ADC's buffer
  7. store or transmit all data and repeat from 2.
edit: Just had a look, it seems the scpi-server does not expose the function for reading the trigger state.
Thanks for those steps. Their examples still are missing most of them and using the API just gets the wrong values.