Page 27 of 29

Re: New feature: high speed continuous recording

Posted: Sun Mar 19, 2017 11:04 pm
by Nils Roos
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.

Re: New feature: high speed continuous recording

Posted: Mon Mar 20, 2017 2:58 pm
by achimoe
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

Re: New feature: high speed continuous recording

Posted: Thu Mar 23, 2017 8:26 pm
by Nils Roos
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 .

Re: New feature: high speed continuous recording

Posted: Sat Apr 08, 2017 5:19 am
by kumeet
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?

Re: New feature: high speed continuous recording

Posted: Tue Apr 11, 2017 7:51 pm
by Nils Roos
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.

Re: New feature: high speed continuous recording

Posted: Fri Apr 14, 2017 5:55 pm
by kumeet
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

Re: New feature: high speed continuous recording

Posted: Fri May 05, 2017 1:49 pm
by ak83
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

Re: New feature: high speed continuous recording

Posted: Wed Jun 21, 2017 7:38 am
by DavSte
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.

Re: New feature: high speed continuous recording

Posted: Thu Jun 29, 2017 4:02 pm
by niko_c
Hello.
When I load ddrdump.bit to redpitaya can I continue to use also DAC module?
Tnks

Re: New feature: high speed continuous recording

Posted: Tue Jul 04, 2017 4:06 pm
by queissman
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!