New feature: high speed continuous recording

[Nils Roos]

- 260 MB are allocated in each channel?

The ramdisk that is mounted at /tmp/ has a total capacity of 260MB, not per channel.

- What is the up-limit of ramdisk for one channel (allocating all ramdisk to one channel, if it is possible) and for two channels (ramdisk used by two channels)?

During normal operation there is about 450MB free memory (including unused space on the ramdisk). rp_remote_acquire does not have a large memory footprint, so increasing the ramdisk to somewhere around 400MB should pose no problems. The current version of rp_remote_acquire can not write both channels to files simultaneously. The dual channel mode is only implemented for network targets.

- Is it possible to implement a trigger event so that when hi speed is required (i.e. 32 MSPS or higher), we can continuously store the relevant data into the buffer starting from trigger event?

It is possible to implement a register in the logic that holds the address where data was stored when a trigger event occured. The transfer code could then use this information to start reading data from the internal ringbuffer at the appropriate position.
Gating the recording with a trigger seems impractical, and unneccessary, it's much easier to keep recording continuously and just select which data to copy for keeping.

[Amraam]

The current version of rp_remote_acquire can not write both channels to files simultaneously. The dual channel mode is only implemented for network targets.

Ok, I use rp_remote_acquire with network target. Has new version allocated 260 MB per channel? (I assume that the old one has 128 MB per channel)

[Nils Roos]

I think you misunderstand the situation.
The ramdisk is just a ramdisk, it is not allocated for anything, you can store what you want in it.

The rpad_scope driver allocates internal buffers of 2MB per channel. These are the regions into which the FPGA continuously writes samples with direct memory access (DMA).

rp_remote_acquire copies samples from the DMA region into intermediary buffers (~16kB) and then sends them over network or writes them to a file.

The DMA buffers and the intermediary buffers have not been changed, only the size of the ramdisk is different in the version I posted for Simon.

[uqdqj]

Hi Nils,

sorry for bothering you again, but we're facing a further problem now. The new ecosystem with the increased ramdisk size is running great, but we need to install some packages like e.g. python.

As far as I can remember your work is not (yet) compatible with the newest OS versions, or? Is there any chance to install apt-get on the older ecosystems?
We would prefer the option to have apt-get installed if we need to install some more packages in the future.

Before we have to build our own image with the required packages, we wanted to check if there is another way to install some packages.

[Nils Roos]

Installation of additional packages at runtime was not practical before the 0.94 releases, because the root filesystem is on the ramdisk. Adding things in the buildroot image was the only persistent way.

Here is a thread how somebody successfully built the rpad driver and rp_remote_acquire for the 0.94 ecosystem. You'd have to load the bitstream and insmod the driver yourself, but you could install all the packages you want and also have an easier time adjusting the ramdisk (because changes to /etc/fstab are permanent in 0.94).

[MeinBAAccount]

Dear Nils, dear all.

I'm new to Red Pitaya and it's great how easy it is to start and to find information and help in the forum.
Now I started a small project using rp_remote_acquire function. Thank you Nils, it's really great
Actually it work's great, but I have one question:
I only need raw data, because the measurement of voltage values will be one function of my program. So rp_remote_acquire function is perfect for my purpose.
I use Qt to implement my program and a TCP socket to receive the data from my Red Pitaya. My Qt-TCP-socket is receiving big data packages of different sizes with loads of data, but not constantly one raw value after another. As I want to save the data with time stamp, receiving data continuously and at regular intervals would be great.
I suppose this behavior is because of how Qt handles the TCP socket or because of buffer overflow. Can there be a different reason?
I would be very grateful for any ideas how to improve data reception.
Thanks in advance
Jo

[Nils Roos]

Hi Jo,

but not constantly one raw value after another.

What exactly do you mean by that? Do you need each sample to be transmitted individually?

In general, rp_remote_acquire does the following:
When at least 16kB of new samples have accumulated in its internal buffer, rp_remote_acquire takes 16kB from the buffer and hands them over to the socket, which breaks the chunk down into smaller payloads and sends them out. The actual size of each packet is determined by the network stack.

[MeinBAAccount]

Thank you for your fast reply and the explanation.

And I'm really sorry, I just reviewed the data I receive. I realized that actually it really doesn't matter how the data is sent/received. It would only be easier for me to work with the data, if each sample would arrive individually and round about in the same time interval, it gets a time stamp and I can use it easily later.
My idea of continuous recording was, that samples will arrive continuously and individually. I think I just misunderstood it a bit.

[Nils Roos]

No need to apologize, the behaviour of most of the components is far from obvious ;O)

This whole project's central idea is bulk processing. At the very first stage, samples are collected in blocks of 1024, so I'm afraid even at low sample rates it wouldn't be possible to assign acurate timestamps to individual samples.

You can only deduce the time of each sample by its relative position from the starttime, with the assumption that the sample rate is constant.

[swartjean]

Hi Nils, thanks for the fantastic work on this program.

We've been looking for a way to incorperate high-speed continuous recording to files for a SAR platform. One question, do you see simultaneous recording of both channels to files happening any time soon? It would be ideal for what we are looking to do.

Since first writing this post I've stumbled into a bigger problem.

I would like to modify your source code and integrate it into the C code we have for setting up other parts of the system. The goal would be to have it simply run the rp_remote_acquire function at a certain point in code with certain settings, so it should be simple. I modified your code and combined everything where necessary, but upon attempting to execute it on the new ecosystem I encountered a number of strange problems:

Firstly, I noticed that upon loading the new ecosystem the red LED indicating heartbeat is no longer blinking. I have tested loading the image from the quick start page and the LED blinks normally then. I have not had to update the ecosystem before this so I am not sure if I am doing it correctly. I simply downloaded the ecosystem zip you linked, extracted it and copied the contents to my SD card, merging and overwriting where applicable. Am I missing something huge here? Do I need to rebuild the RP image and rewrite the whole SD card?

Secondly, assuming that there are no problems with how the ecosystem was installed, I now find that running any custom-written code that worked before with the quick start image now result in:

-sh: ./RP_Controller: not found

Where RP_Controller is the executable.

I have done some digging on possible causes but so far I have not found any fixes, do you have any ideas about why executables would all suddenly stop working on the new ecosystem? I find it a bit suspect and I am almost certain I have done something stupid.

Thanks very much

Edit: So I've tried loading the ecosystem using the steps here viewtopic.php?f=8&t=1433&start=10
And I still get the same issue with the heartbeat LED and files. So that doesn't seem to have been the problem.

I think the file not found error is due to a missing ld-linux-armhf.so.3 library. If I try and symlink it to ld-2.17.so like ld-linux.so.3 is I just get segmentation faults (This feels wrong to do anyway, but I saw someone having similar issues on a Raspberry Pi and this solved it for them). I also had to change the librp.so file to the one linked in that forum post I mentioned. So now I'm feeling very stuck.

Another edit!
I have it working and running beautifully! I found that it all boiled down to two things, swapping out the librp.so file for an older version, and compiling using gnueabi instead of gnueabihf, it looks like the architecture was changed somewhere between ecosystem releases. That seems to have made everything work wonderfully. I still have the issue of no heartbeat LED but it doesn't seem to be affecting operation in anyway.

I'm sorry for the lengthy post, it's been a voyage of discovery. If you have any ideas on things I may have missed or consequences I've overlooked I would love to hear them!