New feature: high speed continuous recording
-
- Posts: 7
- Joined: Sun Mar 22, 2015 10:54 am
Re: New feature: high speed continuous recording
Hello,
Timestamping is a great idea.
For my work, I will need to synchronize a bunch of RPs. I was thinking of using the Linux internal clock (CLOCK_REALTIME). I would have set a certain t = 0 by sending a high on one of the DIOx_P pins of each RP and read it. We usually minimize propagation effects by using same length of cables but I understand we cannot eliminate all errors. However, as fisafisa mentioned, we could possibly calibrate. Finally we would introduce time stamps using function clock_gettime( ). The CLOCK_REALTIME resolution is of the order of nanoseconds, but I admit I don't exactly know how the pins react electrically, so they might reduce the accuracy of the clock.
Timestamping is a great idea.
For my work, I will need to synchronize a bunch of RPs. I was thinking of using the Linux internal clock (CLOCK_REALTIME). I would have set a certain t = 0 by sending a high on one of the DIOx_P pins of each RP and read it. We usually minimize propagation effects by using same length of cables but I understand we cannot eliminate all errors. However, as fisafisa mentioned, we could possibly calibrate. Finally we would introduce time stamps using function clock_gettime( ). The CLOCK_REALTIME resolution is of the order of nanoseconds, but I admit I don't exactly know how the pins react electrically, so they might reduce the accuracy of the clock.
-
- Posts: 29
- Joined: Fri Jun 06, 2014 6:02 pm
Re: New feature: high speed continuous recording
I would consider an external hardware to generate all the t=0 trigger .
This trigger may be generated by an hardware controlled by linux in some PC.
Then the time of the data would be that coming with the RP packets.
You may also use this hardware trigger a DIO board within a PC so that to establish
a local PC clock with the same 0 realative reference. With this you can measure latency of the RedPitaya system.
Another issue is the relative calibrations of oscillators.
You may consider using the RP as reference, and the calibrate the clock speed by matching
it to the correct multiple of the average packet rate.
local_time = local_counter * adjusted_clock_period
This trigger may be generated by an hardware controlled by linux in some PC.
Then the time of the data would be that coming with the RP packets.
You may also use this hardware trigger a DIO board within a PC so that to establish
a local PC clock with the same 0 realative reference. With this you can measure latency of the RedPitaya system.
Another issue is the relative calibrations of oscillators.
You may consider using the RP as reference, and the calibrate the clock speed by matching
it to the correct multiple of the average packet rate.
local_time = local_counter * adjusted_clock_period
-
- Posts: 9
- Joined: Mon Jan 19, 2015 9:20 am
Re: New feature: high speed continuous recording
Hi!
Has anyone attempted to do a triggered reading with the DDR dump method? I am very interested in getting a higher sampling rate for an ultrasound pulse/echo application, but getting a read out from a triggerpoint is essential.
Here is how I do it today using the old red_pitaya_scope.v, fpga_osc.c and fpga_osc.h:
(Data is sent using a TCP socket).
I've looked at rp_remote_acquire which acquire the data in a bit different way. My question is if it is at this time possible to use the trigger in a similar way I have done in my code with the new DDRdump, or perhaps integrate it in rp_remote_acquire?
I guess what I am asking is if it is possible to do this in software for DDRdump as it is today, or if I would be wasting my time trying?
Has anyone attempted to do a triggered reading with the DDR dump method? I am very interested in getting a higher sampling rate for an ultrasound pulse/echo application, but getting a read out from a triggerpoint is essential.
Here is how I do it today using the old red_pitaya_scope.v, fpga_osc.c and fpga_osc.h:
Code: Select all
int start = osc_fpga_init();
if(start)
{
printf("osc_fpga_init didn't work, retval = %d",start);
return -1;
}
int * cha_signal;
int * chb_signal;
// set acquisition parameters
osc_fpga_set_trigger_delay(sampleSize);
g_osc_fpga_reg_mem->data_dec = decimation;
// put sampling engine into reset
osc_fpga_reset();
// define initial parameters
int trig_ptr;
int trig_test;
int trigger_voltage= 1;
g_osc_fpga_reg_mem->chb_thr = osc_fpga_cnv_v_to_cnt(trigger_voltage);
while (1)
{
osc_fpga_arm_trigger();
osc_fpga_set_trigger(trigger);
trig_test=(g_osc_fpga_reg_mem->trig_source);
while (trig_test!=0)
{
trig_test=(g_osc_fpga_reg_mem->trig_source);
}
trig_ptr = g_osc_fpga_reg_mem->wr_ptr_trigger;
osc_fpga_get_sig_ptr(&cha_signal, &chb_signal);
if (trig_ptr > (BUF-sampleSize)) // Enter logic to transition from end to beginning of cha_signal buffer.
{
write(connfd, &cha_signal[trig_ptr], sizeof(int)*(BUF-trig_ptr));
write(connfd, &cha_signal[0], sizeof(int)*(sampleSize-(BUF-trig_ptr)));
}
else // Enter simple logic to send sampleSize from trigger point
{
write(connfd, &cha_signal[trig_ptr], sizeof(int)*sampleSize);
}
}
I've looked at rp_remote_acquire which acquire the data in a bit different way. My question is if it is at this time possible to use the trigger in a similar way I have done in my code with the new DDRdump, or perhaps integrate it in rp_remote_acquire?
I guess what I am asking is if it is possible to do this in software for DDRdump as it is today, or if I would be wasting my time trying?
-
- Posts: 29
- Joined: Fri Jun 06, 2014 6:02 pm
-
- Posts: 16
- Joined: Mon May 04, 2015 10:50 am
- Location: France
Re: New feature: high speed continuous recording
Hello Nils,
Thank you for your work, the result is amazing.
With your current program (I tookthe source on your github fork), the acquisition is saved as a binary file, am I right?
Is there a simple way to change this and save it as a .txt or .csv file? (in fact, I'd like to be able to draw the signal with labview afterwards...)
Thanks!
Simon
Thank you for your work, the result is amazing.
With your current program (I tookthe source on your github fork), the acquisition is saved as a binary file, am I right?
Is there a simple way to change this and save it as a .txt or .csv file? (in fact, I'd like to be able to draw the signal with labview afterwards...)
Thanks!
Simon
-
- Posts: 1441
- Joined: Sat Jun 07, 2014 12:49 pm
- Location: Königswinter
Re: New feature: high speed continuous recording
Sorry I didn't reply earlier, I must have missed that question in the course of the website updates.trollhassel wrote:I guess what I am asking is if it is possible to do this in software for DDRdump as it is today, or if I would be wasting my time trying?
The short answer is, with the current DDRDump there is no reliable way to correlate a trigger event with a position in the data stream.
Together with the timestamping that is still under development, this situation changes, though. It is relatively easy to save the current timestamp to a register when a trigger event occurs. This timestamp would allow you to find the exact position of the trigger event in the timestamped data stream.
Unfortunately nothing that is worth reporting - reducing the packet size as discussed led to a significant drop in performance. I have been trying different approaches to counter that, none of which were satisfactory. I am not out of options, but the going gets more complicated.fisafisa wrote:any news?
Yes there is, but you have to be aware that the on-the-fly conversion to text will approximately quadruple the volume of data that has to be moved around. This will have a huge impact on the achievable sample rates.Simonx wrote:Is there a simple way to change this and save it as a .txt or .csv file?
-
- Posts: 16
- Joined: Mon May 04, 2015 10:50 am
- Location: France
Re: New feature: high speed continuous recording
Thank your for your quick reply, Nils.
I'm considering writing a binary file and transfer it then.
Could you give me a hint on how to convert these binary datas please? I tried to read them using LabView but didn't succeed (I tried to read them as big-endian, native and little-endian)
Thank you
Simon
I'm considering writing a binary file and transfer it then.
Could you give me a hint on how to convert these binary datas please? I tried to read them using LabView but didn't succeed (I tried to read them as big-endian, native and little-endian)
Thank you
Simon
-
- Posts: 7
- Joined: Tue May 05, 2015 8:29 pm
- Location: Ilmenau Germany
Re: New feature: high speed continuous recording
Nils Roos wrote:I've attached a zip with updated components. They have been tested with the latest ecosystem available from redpitaya.com (Downloads -> SD Image).The remote acquire tool will stream data from either ADC channel to a socket or file in binary format.
- copy to /tmp and unzip
- "chmod 755 /tmp/preview_rp_remote_acquire"
- "cat /tmp/ddrdump.bin >/dev/xdevcfg"
- "insmod /tmp/rpad.ko"
- "/tmp/preview_rp_remote_acquire -h" (lists usage instructions)
With UDP, the highest rate is 30MSps (decimation factor 4) with the full 14bit resolution (expanded to short).
Have fun ;O)
Nils
Hi Nils,
can you attach a zip once more, looks like "attachment doen't exist anymore".
Thank you in advance,
Tisho
-
- Posts: 33
- Joined: Fri Jan 23, 2015 9:53 am
- Location: Zurich
Re: New feature: high speed continuous recording
https://dl.dropboxusercontent.com/u/218 ... drdump.ziptisho88 wrote: can you attach a zip once more, looks like "attachment doen't exist anymore".
Here you go. I hope it's the latest version. I also wrote a script enableddrdump that does all the necessary steps for you to get started.
Uploading files doesn't work here on the Forum at the time...
Cheers
-
- Posts: 7
- Joined: Tue May 05, 2015 8:29 pm
- Location: Ilmenau Germany
Re: New feature: high speed continuous recording
Thank you noah, looks I will have a lot of fun during the weekend
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 2 guests