Page 7 of 30

Re: New feature: high speed continuous recording

Posted: Wed Apr 29, 2015 11:40 am
by Aragorn2101
Hello,

Timestamping is a great idea. :D

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.

Re: New feature: high speed continuous recording

Posted: Wed Apr 29, 2015 6:55 pm
by fisafisa
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

Re: New feature: high speed continuous recording

Posted: Fri May 08, 2015 12:55 pm
by trollhassel
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:

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);
			}
		}	
(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? :)

Re: New feature: high speed continuous recording

Posted: Tue May 19, 2015 7:53 am
by fisafisa
any news?

Re: New feature: high speed continuous recording

Posted: Tue May 19, 2015 4:37 pm
by Simonx
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

Re: New feature: high speed continuous recording

Posted: Wed May 20, 2015 12:49 pm
by Nils Roos
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? :)
Sorry I didn't reply earlier, I must have missed that question in the course of the website updates.

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.
fisafisa wrote:any news?
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.
Simonx wrote:Is there a simple way to change this and save it as a .txt or .csv file?
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.

Re: New feature: high speed continuous recording

Posted: Wed May 20, 2015 2:31 pm
by Simonx
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

Re: New feature: high speed continuous recording

Posted: Fri May 22, 2015 9:52 am
by tisho88
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).
  • 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)
The remote acquire tool will stream data from either ADC channel to a socket or file in binary format.
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

Re: New feature: high speed continuous recording

Posted: Fri May 22, 2015 12:40 pm
by noah
tisho88 wrote: can you attach a zip once more, looks like "attachment doen't exist anymore".
https://dl.dropboxusercontent.com/u/218 ... drdump.zip
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

Re: New feature: high speed continuous recording

Posted: Fri May 22, 2015 2:09 pm
by tisho88
Thank you noah, looks I will have a lot of fun during the weekend :)