New feature: high speed continuous recording

[Nils Roos]

Hi,

the thing is, you can't mix the 0.92-based ecosystem that includes rp_remote_acquire with any software that is compiled for 0.94 or later. There was an architectural change between 0.93 and 0.94 that made all executables incompatible. That's the cause for the "-sh: ./RP_Controller: not found" problem.

You can, however, use some components from my project to achieve your goals in much the same way you already outlined, by integrating pieces of rp_remote_acquire into your own program. Email me if you'd like to discuss this further.

[swartjean]

Hi again,

That's exactly what I thought must be the issue. I have my code compiling and running but I may take you up on your offer soon and drop you an email with some more specific questions.

One thing I am still looking forward to is the ability to record on both channels simultaneously to channel. Is this currently in development?

Thanks once again

[Nils Roos]

Well, it's not specifically "in development", but since it'll take less than an hour to do it, it might happen at any time^^

[swartjean]

Hah, brilliant! I was worried that there was a huge complication with writing to files as opposed to over the network.

I've observed a slightly weird phenomenon. Do you have any idea why using the API's generation functions in the same program as a modified version of your continuous recording program would cause it to not record properly? I am calling the generate functions to create a 50MHz sine wave, and when I do a simple loop to try and record that it just repeats one value, there isn't even noise.

However, if I include a quick system("generate 1 1 50000000 sine"); instead of using the API functions to generate it works perfectly, so I'm pretty sure it's some sort of clash between the API and code behind the rp_remote_acquire program.

[Nils Roos]

The rpad framework starts to continuously record when you open /dev/rpad_scope0 . rp_Init() and rp_Reset() do things that stop the continuous recording again, so you must not use them after opening the device. The rp_Gen... functions should be safe to call.

[uqdqj]

Hi Nils,

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).

Thanks for the link, we could succesfully build the rpad driver and rp_remote_acquire for the 0.94 ecosystem. Unfortunately we see some gaps again in our measurements depending on the decimation. With a sample rate of 15.625 MS or lower the results are fine, but as soon as we acquire a signal with a sample rate of 31.25 MS we can detect gaps in a regular order (every 5.xx MS). The distance of the gaps is getting shorter, the higher the sample rate.

Do you have any idea what could cause this problem? I forgot to mention that we also adjusted the ramdisk in /etc/fstab or do we have to adjust another parameter? Seems like the buffer of the kernel module is not read out fast enough.

[sro30]

Hi Nils,
Sincerely, thanks for all of the work!
This post just to say that i see exactly the same behaviour as "uqdqj"
Actually i followed the same way but i did not change the ramdisk size.

Hi Nils,

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).

Thanks for the link, we could succesfully build the rpad driver and rp_remote_acquire for the 0.94 ecosystem. Unfortunately we see some gaps again in our measurements depending on the decimation. With a sample rate of 15.625 MS or lower the results are fine, but as soon as we acquire a signal with a sample rate of 31.25 MS we can detect gaps in a regular order (every 5.xx MS). The distance of the gaps is getting shorter, the higher the sample rate.

Do you have any idea what could cause this problem? I forgot to mention that we also adjusted the ramdisk in /etc/fstab or do we have to adjust another parameter? Seems like the buffer of the kernel module is not read out fast enough.

[Nils Roos]

I'll try to reproduce your findings over the weekend and maybe see what's happening with added diagnostics. Please correct me if I'm wrong with my assumptions:

You are saving samples from one channel to a ramdisk file at decimation 4, using the original code of rpad and rp_remote_acquire built with an arm-linux-gnueabihf toolchain on ecosystem version 0.94 RC 24?

[uqdqj]

In our case we use the 0.94 RC 22 ecosystem. We had already downloaded it and we assumed it should behave the same way. Or was there any important change in the versions?
Loading the module rpad.ko with insmod and running rp_remote_acquire worked fine, so we didn't consider to check the versions.

Apart from that our build environment was like you mentioned. We used the original code of rpad and rp_remote_acquire from your repo on github (branch: dev_ddrdump) and cross-compiled it with the arm-linux-gnueabihf toolchain.
Furthermore we used the ddrdump file provided by you in the mentioned thread.

[Nils Roos]

Well, I see it too: at 31.25MSps, 1MS of data is missing approximately every 5 million samples (the exact number fluctuates).

The interpretation is clear, the throughput of sustained writing to ramdisk is on average some 16% slower than it needs to be to support 31.25MSps indefinitely.

I'd say there is some room for optimization. As a first step I switched off the circular buffer for the channel that is not recorded, thus reducing the background write load on the external ram. This increased the average distance between gaps from 5MS to 5.5MS - noticable, but not enough to make a real difference.

I am sure there are more efficient ways to write to file than fwrite(), but I don't expect to have the time to research that in depth anytime soon.

Another option would be to malloc huge buffers in rp_remote_acquire (with a minimally sized ramdisk) and store the samples there instead of using the filesystem during recording. After recording is finished, the buffers could be written out to a thumbdrive or network share.