Page 28 of 29

Re: New feature: high speed continuous recording

Posted: Wed Jul 05, 2017 12:20 am
by tknopp
I have recently build a simple tcp server, which is IMHO easier than digging through the SCPI code. Just search for tcp examples in the net.

Re: New feature: high speed continuous recording

Posted: Wed Jul 05, 2017 2:04 pm
by queissman
I solved the problem for now, by simply using copying the raw data to my host PC using scp within Cygwin, which I call using Labview system execute. The problem I have now is that after two subsequent calls of system the RP cuts off the connection and the blue and red LEDs are not illuminated anymore, but only the green one, so I have to restart the RP and reconnect.

Re: New feature: high speed continuous recording

Posted: Mon Jul 17, 2017 12:06 pm
by jmoederl

I'm trying to record both chanels with 10MS/s continously into a ringbuffer with 20MS for each chanel(=2 seconds worth of signal). your project seems to do exactly that, with additonal stuff like UDP transmitting.
given that i'm new to the RedPitaya Ecosysetem and FPGA programming i'm lost in the code on github because its just too much at once. i'd be great if you could give me a few hints on where exactly the magic of getting the buffer to the linux userspace happens. do you still use the kernel module to make it look like a file? did you modify the kernel itself to share a specific region of the RAM? and where exactly in the FPGA code can i find that address and experiment with its size? and which parts of the whole RedPitaya ecosystem do i need to rebuild in order to get this working?

thanks in advance

Re: New feature: high speed continuous recording

Posted: Tue Nov 07, 2017 8:26 pm
by MateoConLechuga
Impressive work! I am currently working on a project that will need around 5 seconds of continuous sampling, as I would like to do post-processing on the raw ADC data. Is this feasible to do with this project, and is it possible to stream via TCP to an external computer once the data has been captured? Thanks for your reply.

Re: New feature: high speed continuous recording

Posted: Thu May 17, 2018 6:52 pm
by JMapel
I've been attempting to get rp_remote_acquire working for some time now with no luck. As I've understood its function from this thread, it's well suited to my needs.

I'm using with the boot loader replacements from ecosystem 0.94. I've used WinSCP to transfer rp_remote_acquire + bitstream to the /tmp (or other directories), and changed their file permissions to all. I'm able to view the help files and when I run acquire with
/tmp/rp_remote_acquire -m file -k 8 -c 0 -d 8 -f /tmp/out.dat
using putty link. It creates an empty output file and the command never completes. I've tried in various other directories and provided rw permission first by running rw from that directory with the same results, and I've tried other acquire options with same results. Can anybody offer guidance on what I may be doing incorrectly? I've tried with other OS versions with same results.

EDIT: The absence -l flag was the ultimate cause of my issue.
/bin/rp_remote_acquire -m file -k 128 -c 0 -d 64 -f /bin/out1.dat -scope-HV -l &
produces the files I was seeking. I've used Putty to send these commands and WinSCP to retrieve the files for post processing. Note to interpret files: The files produce the two interleaved channels, even when one channel is chosen with the -c option. Still have to select the valid data from the file, which I implemented in Matlab.

Re: New feature: high speed continuous recording

Posted: Mon Jun 04, 2018 8:46 pm
by doertepeter
Try it with changing the ecosystem. For the link see last post from Nils Roos from site 10

Download the first ecosystem.
Changing the ecosystem is easy - just delete all files from your 124 Volume and copy the downloaded files to it. Then try to connect using ssh - and hopefully that will work for you. Worked for me :)

Re: New feature: high speed continuous recording

Posted: Tue Jun 19, 2018 8:59 am
by JoWo1994
Hi Nils,

Hi wrong alert. After resynthesizing the design again it worked. Sry for the Inconvenience.

thank you everyone for this awesome project. I am currently using it and wanted to make some small modifications to reduce the power consumption of the ddrdump fpga design. Which commit of the dev_ddrdump branch did you use to create the bit file mentioned in your post?

I tried resynthesizing the latest commit (with Vivado 2017.1 but that should not make a difference right.. :? ) but when I loaded it linux crashed. I deactivated the rp_acquire services before reloading the bit file.
Nils Roos wrote:
Sat Oct 18, 2014 1:22 am

For OS versions of 0.94 and later: rp_remote_acquire + bitstream

Re: New feature: high speed continuous recording

Posted: Tue Aug 07, 2018 1:15 pm
by david_warner
Hi All,

I have similar requirements as mentioned in this chain.
Since the discussion is quite long, I am confused from where can I start to test the code.
My queries are:
1) how to build the bit file (from vivado project)
2) which program to start for server
3) Is it possible to view the data or log the data in file

From the discussion I understand the maximum sampling rate achieved is 125/4 MSps.

Pls help from where can i start in order to understand and test this wonderfull project.


Re: high speed continuous recording - ready to use ?

Posted: Thu Aug 23, 2018 10:43 pm
by Carsten

this thread discusses what we need.

1 channel - max. Sample rate - maximum memory/ recording time : One shot after digital trigger input signal -> Reading of Raw data, when DAQ is finished over TCP/UDF

We have not the time and capacity to develope, but we would like to have this solution.

We are looking for a ready to use application to buy / to pay for software and manual.

Is anyone interested or has an hint, where to get practical support.

Carsten Gottschalk /

Re: New feature: high speed continuous recording

Posted: Tue Nov 27, 2018 12:11 pm
by AndrewGough

I'm looking to use this project high speed signal generation/acquisition.

I have adapted Nils' project to allow for the high speed signal generation as required which works by itself without any issues, however when I start the data acquisition c program the generation stops whilst data acquisition takes place. Stopping the c program and reprogramming the FPGA with the same bitstream file allows signal generation to take place again.

Initially I thought this would be due to an interrupt causing the signal generation to stop however having looked through the verilog code I'm unable to see anything which would affect this generation.

Any help would be appreciated.