low frequency continuous recording on two channels

[berndj]

Hi,
I am trying to record both input channels for longer times (~2days). I can for now live with lower frequencies it the signal is averaged. I would record either onto the /tmp folder or a NFS mounted drive. Binary output would be possible as I plan to analyse the data using R afterwards offline.
Can you please advise me on how to achieve this?
I am not very savvy with all the hardware aspects involved, so please forgive my ignorance. I tried reading the post from Nies Roos about continuous reading, but I guess this is already too advanced and I was wondering if there wouldn't be a simpler solution...

thanks for any comments/suggestions or pointers to get further information.

Bernd

[Nils Roos]

Hi,
what range of frequencies are you interersted in? If you do not need sampling rates of more than a couple of 100kSps, you can get by with a not-too-complicated C program, for still lower rates you could even use the scpi-server.
The approach in both cases would be to start the scope without setting a triggersource and then observe the buffer write pointer and request a portion of the current buffer contents once the pointer crosses a threshold (eg. read samples 0-8191 when the pointer crosses 8192, and read 8192-16383 when the pointer wraps to 0, repeat for 2 days).

[berndj]

Hi,
it always takes me too long to find the time to test/implement... Thanks a lot for your help. I have implemented a small program that I believe is working. It can be found here: github.com/baj12/redpitaya

acquireLong.c

is the one to look at the moment. If anyone can think of a better name... please let me know. Also it is not well documented, but this will be done in due time (see comment above). If you want to share any comments I would be happy to discuss. Since I am quite new to all this there might be something that I am missing...

Thanks again for your kind support,

Bernd

[berndj]

Hi,

it seems there is still a problem with the program... The signal read seems to be same on both channels, which it should not be....

The file can be found here:

https://github.com/baj12/redpitaya/blob ... uireLong.c

It would be really great and much appreciated if you could have a look at the code and let me know where you think I could check ...

Thanks

Bernd

[Nils Roos]

Hi Bernd,

the code seems to be alright, and when I compile and run it on my Red Pitaya, it gives the expected results. There are different values for each block of 8192 from channel 1 and channel 2, not duplicated waveforms.

Here's the console output from the test, and the recorded data as attachment.

Code: Select all

root@rp-f00fa5:~# cat /opt/redpitaya/fpga/fpga_0.94.bit >/dev/xdevcfg
root@rp-f00fa5:~# LD_LIBRARY_PATH=/opt/redpitaya/lib ./test 2 /tmp/testout 10
version size 4
decimation size 4
nCount size 4
buff size: 8192
buffer size: 16386
sizeof(int16_t) 2
version: 1
decimation: 2
nCount: 10
count: 0
count: 2
count: 4
count: 6
count: 8
count: 10

[Nils Roos]

Maybe you supplied a wrong decimation parameter? (You need to use the int-value of the decimation enum, 0=RP_DEC_1, 1=RP_DEC_8, 2=RP_DEC_64, ...)

[berndj]

Maybe you supplied a wrong decimation parameter? (You need to use the int-value of the decimation enum, 0=RP_DEC_1, 1=RP_DEC_8, 2=RP_DEC_64, ...)

I think that is what happened.... But do you mind explaining what will happen if the is above 5?

Thanks a lot for the help.

PS. May I also comment that the change of the root password should be changed. Since it SHOULD be obvious it is always a good idea to remind people about this. (Please don't ask why I am stating this )
as a consequence of this I had to reinstall and now get the following message after compiling...
root@rp-f01775:~/RedPitaya/Examples/C# ./generate_continuous
Runtime error: cmn_Init() returned "Failed to open memory device." at rp.c:36
Rp api init failed!

Could this be due to a wrong api infrastructure?

Thx so much for all your help. And please let me know if there is any other way for me to better share my experience?

B

[Nils Roos]

But do you mind explaining what will happen if the is above 5?

rp_AcqSetDecimation returns an error and does not change anything. The default value of the decimation is RP_DEC_1 after rp_Init, which is much too fast to apply the method of polling the write pointer. Still, I would not have expected to see identical readings for channel 1 and 2 in that situation. It should lead to very frequent discontinuities on both channels, but individually different on each channel.

Runtime error: cmn_Init() returned "Failed to open memory device." at rp.c:36
Rp api init failed!
Could this be due to a wrong api infrastructure?

Could be - if you compile the api from current sources, it tries to open /dev/uio/api for fpga access, which may not be present on your OS release.
The only other situation where I would expect such an error is if your appication is not running as either root or a member of the kmem group and therefore can't open /dev/mem .

[tknopp]

Hi,

I would be interested if the proposed approach works for decimation factors 8 and/or 16.
Would doing this over SCPI really be much slower when using binary data to transfer? I thought that the network is faster then the CPU on the RP.

Thanks,

Tobias

[Nils Roos]

Hi,
it will not work reliably on RP_DEC_8, because the api won't be able to read from the FPGA buffers fast enough. There is no RP_DEC_16, the next step is RP_DEC_64, which should work without loosing samples.
I don't really know just how much overhead the scpi handling adds if you use the binary format - try it.