Continuous recording ?
-
- Posts: 4
- Joined: Fri Jul 11, 2014 10:14 am
Continuous recording ?
Hi !
Proud owner of a RedPitaya, I am a complete noob about C/C++ and FPGA programming (much more capable in matlab and bash scripting).
I am trying to record a signal at 10MHz sampling during 10 seconds. If I understand correctly how the buffers are working and what people are saying about it in these two topics (one link per word), this is not possible yet.
The only thing I was able to do with my limitied abilities is to create an ash script looping the "acquire" built-in command. Only problem being that an acquisition of only 1 second worth of signal already takes 2 minutes, which is quite bad for a "real-time continuous" acquisition...
Am I missing something important ?
On a different topic, what exaclty is the unit of the values returned by the "acquire" command ? By comparing with the output of the oscilloscope app, I'm guessing it is dB but with respect to which reference ?
Proud owner of a RedPitaya, I am a complete noob about C/C++ and FPGA programming (much more capable in matlab and bash scripting).
I am trying to record a signal at 10MHz sampling during 10 seconds. If I understand correctly how the buffers are working and what people are saying about it in these two topics (one link per word), this is not possible yet.
The only thing I was able to do with my limitied abilities is to create an ash script looping the "acquire" built-in command. Only problem being that an acquisition of only 1 second worth of signal already takes 2 minutes, which is quite bad for a "real-time continuous" acquisition...
Am I missing something important ?
On a different topic, what exaclty is the unit of the values returned by the "acquire" command ? By comparing with the output of the oscilloscope app, I'm guessing it is dB but with respect to which reference ?
-
- Posts: 67
- Joined: Wed May 28, 2014 12:15 pm
Re: Continuous recording ?
It is true, this feature is currently still on our wish list, but I hope that we will soon have time to implement it, anyhow it is still possible
to modify current acquire tool to sample continuously at lower sample rates.
I don't know exactly what was causing these delays in your script, but I would suggest you to try redirecting the acquisition output data into a file. You can also measure the execution time using time command.
time acquire 16384 64 > acq.log
The acquired data is in ADC raw signed format (-8192 to 8191) that equals same voltage range as it is defined by http://wiki.redpitaya.com/index.php?tit ... %20setting.
to modify current acquire tool to sample continuously at lower sample rates.
I don't know exactly what was causing these delays in your script, but I would suggest you to try redirecting the acquisition output data into a file. You can also measure the execution time using time command.
time acquire 16384 64 > acq.log
The acquired data is in ADC raw signed format (-8192 to 8191) that equals same voltage range as it is defined by http://wiki.redpitaya.com/index.php?tit ... %20setting.
-
- Posts: 11
- Joined: Wed Jul 23, 2014 6:57 pm
Re: Continuous recording ?
Hi,
I developed some c code to do just this. it outputs to stdout, which (given the limited size of the redpitaya's onboard memory) you can stream it over network using netcat. But perhaps if you're only running 10 seconds you will have enough space.
I'm curious if this can be done bertter --- there is in fact a slight delay after the buffer is filled to when the buffer begins filling again, in the for loop. This can be seen as a discontinuity in a sine wave, for example. I'm not sure how I can improve on this delay -- ideas, Crt? You once mentioned monitoring the write pointer, but never had any luck with that.
I developed some c code to do just this. it outputs to stdout, which (given the limited size of the redpitaya's onboard memory) you can stream it over network using netcat. But perhaps if you're only running 10 seconds you will have enough space.
I'm curious if this can be done bertter --- there is in fact a slight delay after the buffer is filled to when the buffer begins filling again, in the for loop. This can be seen as a discontinuity in a sine wave, for example. I'm not sure how I can improve on this delay -- ideas, Crt? You once mentioned monitoring the write pointer, but never had any luck with that.
Code: Select all
// simple_loop.c
//
// Acquire's data from the RedPitaya Channel A in a continuous
// loop. The user may specify on the command line the desired
// sampling rate (decimation).
//
// Send SIGINT (CTRL+C) to quit safely.
//
// PL v0.2 (5-8-14)
#define _BSD_SOURCE // Needed for usleep() to work
#include <math.h>
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <getopt.h>
#include <string.h>
#include <stddef.h>
#include <sys/param.h>
#include <time.h>
#include "fpga_osc.h"
//RedPitaya's sample buffer length
const int BUF = 16*1024;
// Output step factor. If it's, e.g., 2, then the
// output will skip every 2nd sample, etc. Set to
// 1 to keep all samples in a trace.
const int step = 1;
// This must be of type `volatile` to prevent
// the compiler from optimizing away the
// while loop condition.
volatile sig_atomic_t stop;
// Called when we recieve SIGINT (CTRL+C)
// which then stops the infinite loop in main().
void inthand(int signum)
{
stop=1;
}
int main(int argc, char *argv[])
{
signal(SIGINT, inthand);
int start = osc_fpga_init();
if(start)
{
printf("osc_fpga_init() didn't work, retval = %d",start);
return -1;
}
// Get desired decimation from command line. Make sure it's valid.
int decimation;
if(argc > 1)
{
int t = atoi(argv[1]);
if(t == 1 || t== 8 || t == 64 || t == 1024 || t == 8192 || t == 65536)
decimation = t;
else
{
printf("Invalid decimation %d; set to 1.\n" \
"Valid decimations are {1, 8, 64, 1024, 8192, 65536}\n");
usleep(1e6);
decimation = 1;
}
}
else
decimation = 1;
// Length of time after the trigger the FPGA should write
float after_trigger = OSC_FPGA_SIG_LEN * c_osc_fpga_smpl_period * decimation;
// Convert that time value into some number of samples
uint32_t fpga_delay = osc_fpga_cnv_time_to_smpls(after_trigger, decimation);
osc_fpga_set_trigger_delay(fpga_delay);
g_osc_fpga_reg_mem->data_dec = decimation; // set decimation level
g_osc_fpga_reg_mem->other = 0; // disable averaging at decimation step
osc_fpga_reset();
int * cha_signal; // pointer to channel A's signal buffer
int * chb_signal; // don't actually care about this yet
int trig_ptr; // index in sig. buffer where trigger occurs
int curr_ptr; // where current write pointer is (not used)
int idx;
osc_fpga_get_sig_ptr(&cha_signal, &chb_signal);
osc_fpga_get_wr_ptr(&curr_ptr,&trig_ptr);
while(!stop)
{
osc_fpga_arm_trigger(); // Start acquiring
osc_fpga_set_trigger(0x1); // Trigger immediately
osc_fpga_get_wr_ptr(&curr_ptr,&trig_ptr);
// wait until done acquiring (trig_source becomes 0)
while(g_osc_fpga_reg_mem->trig_source);
// for sampling rate ~950Khz at max decimation
// use step = 2
for (int i=0; i < (BUF-1); i=i+step)
{
idx = (trig_ptr+i)%BUF;
printf("%e\n",osc_fpga_cnv_cnt_to_v(cha_signal[idx]));
}
}
osc_fpga_exit();
return 0;
}
-
- Posts: 55
- Joined: Tue Jun 24, 2014 3:06 pm
- Location: Dourdan (France)
Re: Continuous recording ?
Hi !
You said you have a discontinuity after the acquisition. If I am right, it is normal because when the buffer is full, the RP needs to reset it. So you have some µs (or ms I don't know) which are used to do this. That's why you can observe a discontinuity.
I hope I helped you to understand.
You said you have a discontinuity after the acquisition. If I am right, it is normal because when the buffer is full, the RP needs to reset it. So you have some µs (or ms I don't know) which are used to do this. That's why you can observe a discontinuity.
I hope I helped you to understand.
-
- Posts: 11
- Joined: Wed Jul 23, 2014 6:57 pm
Re: Continuous recording ?
hi,
Thanks, yea I understood that. I just was wondering if there was a way to get around it. I'm not sure there is at the moment.
Thanks, yea I understood that. I just was wondering if there was a way to get around it. I'm not sure there is at the moment.
-
- Posts: 67
- Joined: Wed May 28, 2014 12:15 pm
Re: Continuous recording ?
You can do it by chasing the write pointer and reading the acquired data that it lefts behind. The only problem is that this kind of polling approach only works at lower sampling rates when the OS is still fast enough and the write pointer doesn't wrap around the circular buffer before the data is read out by OS. I have attached an example (based on your code) that is still working fine at decimation 64.
You do not have the required permissions to view the files attached to this post.
-
- Posts: 4
- Joined: Fri Jul 11, 2014 10:14 am
Re: Continuous recording ?
Thank you very much for these solutions !
I will dig into them and let you know if I stumble upon some issues.
I will dig into them and let you know if I stumble upon some issues.
- DashPi
- Posts: 13
- Joined: Tue Jun 10, 2014 8:16 pm
Re: Continuous recording ?
Another example of continuous samples tracking at lower rates is the LTI app. Initially the acquisition FPGA machine is "armed" in order to loop around the circular buffer (ref1:line 366) and left looping forever. No triggers are applied, because those would stop the buffer! The trigger source must be set to zero to avoid signal based triggers.
Then the write pointer is checked regularly (ref2:line 340) and the samples are read behind it (ref2: line 356 & 407).
My experience is that about 8 ms are necessary by CPU to read the 16k samples, this then limits the rate.
Those samples can be fprinted to a file or differently locally stored or transferred through the network...
References:
1) https://github.com/dashpi/RedPitaya/blo ... c/worker.c
2) https://github.com/dashpi/RedPitaya/blo ... fpga_lti.c
Check also "acquisition upgrade: spectrum an. Refresh rate improvement" under new ideas and wishlist, where the same concept of continuous acq. Is applied to spectrum analyzer app to improve refresh rate performance.
Then the write pointer is checked regularly (ref2:line 340) and the samples are read behind it (ref2: line 356 & 407).
My experience is that about 8 ms are necessary by CPU to read the 16k samples, this then limits the rate.
Those samples can be fprinted to a file or differently locally stored or transferred through the network...
References:
1) https://github.com/dashpi/RedPitaya/blo ... c/worker.c
2) https://github.com/dashpi/RedPitaya/blo ... fpga_lti.c
Check also "acquisition upgrade: spectrum an. Refresh rate improvement" under new ideas and wishlist, where the same concept of continuous acq. Is applied to spectrum analyzer app to improve refresh rate performance.
-
- Posts: 4
- Joined: Fri Jul 11, 2014 10:14 am
Re: Continuous recording ?
Hi Crt,Črt Valentinčič wrote:You can do it by chasing the write pointer and reading the acquired data that it lefts behind. The only problem is that this kind of polling approach only works at lower sampling rates when the OS is still fast enough and the write pointer doesn't wrap around the circular buffer before the data is read out by OS. I have attached an example (based on your code) that is still working fine at decimation 64.
Sorry for the late response, I just came back on my project.
I tried to use your program but all I got was an error message at execution. Please tell me if I am doing something wrong:
1) I downloaded your files, and according to the head of your Makefile I compiled the binary with the command "make all" without any error.
2) I transfered the newly created "acquire_loop" (renamed to avoid conflict with the onboard acquire function) to the /tmp folder of the redpitaya. Then, every time I try to call it, the output shows only:
Code: Select all
./acquire_loop: line 1: syntax error: unexpected word (expecting ")")
Code: Select all
./acquire_loop 64 > test
Thank you for your time.
-
- Posts: 67
- Joined: Wed May 28, 2014 12:15 pm
Re: Continuous recording ?
Please check if you have properly compiled the program (make CROSS_COMPILE=arm-linux-gnueabi- clean all).
I have also attached a binary file that should work with no problems. You can simply copy it to /tmp and execute ./acquire 64 that will create a acquire.txt file.
I have also attached a binary file that should work with no problems. You can simply copy it to /tmp and execute ./acquire 64 that will create a acquire.txt file.
You do not have the required permissions to view the files attached to this post.
jadalnie klasyczne ekskluzywne meble wypoczynkowe do salonu ekskluzywne meble tapicerowane ekskluzywne meble do sypialni ekskluzywne meble włoskie
Who is online
Users browsing this forum: No registered users and 49 guests