New feature: high speed continuous recording

Discussions about active development projects
Nils Roos
Posts: 1441
Joined: Sat Jun 07, 2014 12:49 pm
Location: Königswinter

Re: New feature: high speed continuous recording

Post by Nils Roos » Sun Mar 19, 2017 11:04 pm

Amraam wrote:I'm considering the possibility to implement mods to manage triggers, could you tell me all the infos that you consider relevant?
All details are appreciated.
Hi Amraam,

My idea for this was to have a counter running from 0 with the effective sample rate and just store the counter value when a trigger condition is recognized. On the software side, you could poll the corresponding register and take appropriate actions when it changes. The new value would allow to identify the position in the sample stream where the trigger happened. Another idea would be to tie the transfer to ram to the trigger signal, start the transfer upon trigger and leave it running for a configurable time. You'll still need to implement a counter for when the trigger happened exactly, because the transfer logic stores blocks of 512 samples and you only know that the trigger position is somewhere in that frame without a counter.

achimoe
Posts: 2
Joined: Fri Mar 17, 2017 1:59 pm

Re: New feature: high speed continuous recording

Post by achimoe » Mon Mar 20, 2017 2:58 pm

Hi Nils,
thanks a lot for the quick answer, it worked as described.
According to my quick tests loading this binary has no effect to subsequent usage of the oszilloscope app.
Are the standard apps always reloading the standard binary?
Or is the modified binary compatible with the oszilloscope app?
Sorry if these are FAQs but so far I didn't find too much answers to such questions, any pointers are welcome.
Thanks,
Achim

Nils Roos
Posts: 1441
Joined: Sat Jun 07, 2014 12:49 pm
Location: Königswinter

Re: New feature: high speed continuous recording

Post by Nils Roos » Thu Mar 23, 2017 8:26 pm

When you start a web-app, the bazaar infrastructure will load the bitstream that the app needs (configured in the app's fpga.conf).

The modified binary is mostly compatible with the standard apps, with the one exception that the decimation settings do not match. The standard bitstream allows settings of 1, 8, 64, 1024, 8192, 65536, whereas the ddrdump.bit supports 1, 2, 4, 8, 16, ... 65536 .

kumeet
Posts: 2
Joined: Sat Apr 08, 2017 5:04 am

Re: New feature: high speed continuous recording

Post by kumeet » Sat Apr 08, 2017 5:19 am

Hi Nils.

Thanks for your work on rp_remote_acquire. I have managed to get this working, however I would like to try to add some simple data processing to acquired values, before they are sent to data socket. I have some prior programming experience on c from years ago, but willing to give this a shot. Can you point me to right direction how to get started on this?

Nils Roos
Posts: 1441
Joined: Sat Jun 07, 2014 12:49 pm
Location: Königswinter

Re: New feature: high speed continuous recording

Post by Nils Roos » Tue Apr 11, 2017 7:51 pm

Hi Kumeet,

the functions transfer_buf_* in transfer.c copy samples from the DMA region into a local buffer before moving them to the network or storage. These local buffers would be the place to do some more processing.

kumeet
Posts: 2
Joined: Sat Apr 08, 2017 5:04 am

Re: New feature: high speed continuous recording

Post by kumeet » Fri Apr 14, 2017 5:55 pm

Nils Roos wrote:Hi Kumeet,

the functions transfer_buf_* in transfer.c copy samples from the DMA region into a local buffer before moving them to the network or storage. These local buffers would be the place to do some more processing.
I managed to recompile your work and got it running and working on RP.

I have been trying to understand your code for the change I need to make, can you correct if I am totally lost:
So I see the data is transfered to the datasocket in chunks sized 16384 int16. What I would like to do is to take this data, scale all points with 16 (2^4), reshape it to 2D array (16 x 1024) and then sum array elements by row to get 1x1024 array of int16. Then instead of 16384 int16 values, only 1024 int16 values are sent to datasocket. So effectively the data sent to socket represents an average of 16 "waveforms" with a length of 1024 values.

I have not yet looked how to realize this in C, but do you see any problems in my idea? Should I be able to do this just by modifying the transfer_buf function?

Thanks in advance

ak83
Posts: 1
Joined: Wed May 11, 2016 8:48 am

Re: New feature: high speed continuous recording

Post by ak83 » Fri May 05, 2017 1:49 pm

Hi,

is it possible to combine the high speed remote-acquire-feature (with 31MSps) and the PID feature without losing adc speed?
Has anybody tried this yet or is this even possible with the remote_acquire bitstream?


Thanks in advance

DavSte
Posts: 6
Joined: Wed Jun 21, 2017 7:17 am

Re: New feature: high speed continuous recording

Post by DavSte » Wed Jun 21, 2017 7:38 am

Hello,

Is anyone of you able to get both Channels out?
One Channel works fo me like this :

Code: Select all

./rp_remote_acquire -m 1 -a 10.220.2.99 -p 4100 -u -c 0 -r -d 64 -k 1 -l 
But when I try this:

Code: Select all

./rp_remote_acquire -m 1 -a 10.220.2.99 -u -p 4100 -q 4101 -c 2 -r -d 64 -k 1 -l
I get nothing on each ports.

When I try to write the samples into a file, then it's empty in the second case, too.

niko_c
Posts: 1
Joined: Thu Jun 29, 2017 2:04 pm

Re: New feature: high speed continuous recording

Post by niko_c » Thu Jun 29, 2017 4:02 pm

Hello.
When I load ddrdump.bit to redpitaya can I continue to use also DAC module?
Tnks

queissman
Posts: 3
Joined: Wed Mar 15, 2017 11:07 am

Re: New feature: high speed continuous recording

Post by queissman » Tue Jul 04, 2017 4:06 pm

Hello there

I am using axi_adc.c (https://github.com/DF4IAH/RedPitaya_Rad ... /axi_adc.c) from Nils Roos for high speed data acquisition (I acquire chunks of 200 kS from two channels each time) and I am able to save the data to either a file or USB on the RP. So far so good. Other than saving the data to file I also need to read this data into a Labview VI for further processing. It does not have to be very fast, a lag of a few s is ok. UDP is not working for some reason, plus it is supposed to be lossy. So I thought I could read the data from the file on the RP using SCPI. Since, to my knowledge, there is now adequate SCPI command I need to define a new one. How do I define a new SCPI command that will open, read and close the file? Has anyone a idea or an alternative suggestion? Cheers!

Post Reply
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 5 guests