Continuous recording ?

[TomW]

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 ?

[Crt Valentincic]

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.

[plauria]

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.

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;
}

[Kev' Ttn]

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.

[plauria]

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.

[Crt Valentincic]

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.

[TomW]

Thank you very much for these solutions !
I will dig into them and let you know if I stumble upon some issues.

[DashPi]

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.

[TomW]

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.

Hi Crt,

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 ")")

I tried many commands but without success. For example:

Code: Select all

./acquire_loop 64 > test

The same result is obtain if compiling with a simple "make".

Thank you for your time.

[Crt Valentincic]

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.