New feature: high speed continuous recording

Discussions about active development projects
Post Reply
Nils Roos
Posts: 1441
Joined: Sat Jun 07, 2014 12:49 pm
Location: Königswinter

Re: New feature: high speed continuous recording

Post by Nils Roos » Mon Nov 07, 2016 5:52 pm

rp_remote_acquire needs the appropriate bitstream to function. If you don't have the ddrdump bitstream loaded when you call it, it will hang and ignore signals like ctrl-C.
If you use the "-l" parameter, rp_remote_acquire will look into the current working directory and try to load the ddrdump.bit bitstream from there before starting.
generated a triangle signal with vpp 1 V
Be careful how you operate the generator. The Bazaar-apps and the scpi-server will load their own bitstreams when you start them. I have not yet checked the new generate tool if it is safe to use with rp_remote_acquire.

one more remark:
I connected OUT2 with IN1
with "-c 1" you read from IN2
All in a day's work for Bicycle Repair Man

Klarco
Posts: 7
Joined: Thu Oct 27, 2016 8:04 pm
Location: Kiel

Re: New feature: high speed continuous recording

Post by Klarco » Mon Nov 07, 2016 10:36 pm

Thanks a lot again.

Code: Select all

mount -t vfat /dev/sda1 /mnt/hdd
cd /opt/redpitaya/tmp
rw
chmod 755 rp_remote_acquire
cat ddrdump.bit >/dev/xdevcfg
I do that every time I start my RP, there might be a better way but I do not know it yet. Anyway after

Code: Select all

 ./rp_remote_acquire -m 3 -c [b]0[/b] -d 4 -f /mnt/hdd/out.dat
The same behavior crtl + c does not work and an empty file was created.
This time I just wanted to record the noise, so no generator was generating something ;-)

What am I doing wrong? My goal is it to write a measured signal from IN1 into a file on my external hdd.

Nils Roos
Posts: 1441
Joined: Sat Jun 07, 2014 12:49 pm
Location: Königswinter

Re: New feature: high speed continuous recording

Post by Nils Roos » Tue Nov 08, 2016 1:38 am

What am I doing wrong?
Do you maybe boot an original 0.96 ecosystem? If so, there's a post a page or two back that describes how to prep the 0.96 version.
All in a day's work for Bicycle Repair Man

Amraam
Posts: 18
Joined: Fri May 20, 2016 3:55 pm

Re: New feature: high speed continuous recording

Post by Amraam » Tue Nov 08, 2016 1:58 pm

Nils Roos wrote: Other than that I don't plan to do much further development, because in the meantime similar functions have been introduced into the standard Red Pitaya software.
Hi Nils,

I'm using Ecosystem 0.92. As experienced by other users, when I acquire with decimation 8, all is ok but with decimation 4 (31.25 Msps) there are missing data as you had explained in a previous post.
If I upgrade my OS to v0.96, can I continuously acquire with decimation 4? If not, do you foresee a future improvement?

Thank you for your work, I hope that your continuous acquisition will be integrated into official OS. It 's a great feature for scientific community.

Nils Roos
Posts: 1441
Joined: Sat Jun 07, 2014 12:49 pm
Location: Königswinter

Re: New feature: high speed continuous recording

Post by Nils Roos » Tue Nov 08, 2016 9:50 pm

Hi Amraam,

thank you for your encouraging words.
If I upgrade my OS to v0.96, can I continuously acquire with decimation 4?
Changing the OS would have no impact on the current limits of storage/transmission - or only a slight one through the better performance of the hard-float architecture. The latest changes I posted only mean that you now can use rp_remote_acquire on the latest OS, with some caveats.

The one improvement which might be implemented soon is the recording into onboard RAM for later transmission/storage. This would mean you could record 300-400MB of continuous samples at full speed and transmit or store them at a slower pace without incurring gaps in the stream - it would only not be realtime anymore.
All in a day's work for Bicycle Repair Man

Klarco
Posts: 7
Joined: Thu Oct 27, 2016 8:04 pm
Location: Kiel

Re: New feature: high speed continuous recording

Post by Klarco » Tue Nov 08, 2016 11:12 pm

Hi Nils,

thanks a lot again, and again I did it wrong or just was not reading the right text.

I had a look and I've got the OS 0.96-86. I was a bit confused, because 0.94-0.97 and 0.96 and later.
Due to popular demand, there is now a version that works with OS releases 0.94 - 0.97 for you to download.
...
If you want to use it on OS 0.96 or later, you need to replace some boot components with their 0.94 counterparts. When you boot the Red Pitaya with these replacements, it will not be possible to use the logic analyzer, so make backups to be able to switch back!

But I did the following steps:

Code: Select all

1) Make new sdcard with last stable release of OS
2) place u-boot.scr, devicetree.dtb, bootbin in root of sdcard - replace files ( eco94.zip)
3) create 'tmp' folder in root of sdcard
4) place rp_remote_acquire, fddrdump.bit in 'tmp' folder (rp_remote_acquire.zip)
5) insert sdcard in RP and boot
7. in case you did not unpack the rp_remote_acquire.zip on a linux system, you will have to change the executable flags of the program with the following commands (the first time only)

cd /opt/redpitaya/tmp
rw
chmod 755 rp_remote_acquire
cat ddrdump.bit >/dev/xdevcfg
./rp_remote_acquire -m 3 -c 0 -d 4 -f /mnt/hdd/out.dat
Still the same result as above... I am new, and haven't got much experience so I guess I just make a big mistake anywhere.

Amraam
Posts: 18
Joined: Fri May 20, 2016 3:55 pm

Re: New feature: high speed continuous recording

Post by Amraam » Wed Nov 09, 2016 5:27 am

Nils Roos wrote:Hi Amraam,
The one improvement which might be implemented soon is the recording into onboard RAM for later transmission/storage. This would mean you could record 300-400MB of continuous samples at full speed and transmit or store them at a slower pace without incurring gaps in the stream - it would only not be realtime anymore.
This is an interesting functionality for limited time acquisition.
Just my opinion for realtime acquisition: after I've experienced a great performance in realtime acquisition at lower frequency (decimation >=8), I think that one possible solution that allows to increase the sampling frequency (standing the up-limit of data rate) could be the acquisition of certain amount of data every trigger event. This will limit the amount of data to transmit over TCP/IP.

Probably this is not your original idea of rp_remote_acquire but I think that your work could be the starting point for a fork of rp_remote_acquire. This allows me (and other users in this thread) to experiment higher sampling frequency when a trigger event is available.

I've no idea if the architecture of rp_remote_acquire is compliant with the management of external trigger, what do you think about this?

In any case, thank you for your time.

rothmart
Posts: 14
Joined: Fri Nov 13, 2015 3:10 pm

Re: New feature: high speed continuous recording

Post by rothmart » Wed Nov 16, 2016 12:36 pm

I'm using ecosystem 0.94 and did the following steps:

Copied the content of rp_remote_acquire.zip wird card reader on new tmp folder
cd /opt/redpitaya/tmp
./rp_remote_acquire
./rp_remote_acquire -m 3 -f /tmp/out.dat -l ./ddrdump.bit

The out.dat is created and i copied it with WinSCP to desktop. Now i want to analyse and display that data, but i can't determine the data type.

Can you explaine how to use this data? I also didn't recognized what is client/server mode. How is it possible to stream continuous data to pc via ethernet? What's the configuration for the client on pc?

As far as possible i want to use the data in Matlab to do further operations.

For any documentation i would be appreciate,

Regards!

Nils Roos
Posts: 1441
Joined: Sat Jun 07, 2014 12:49 pm
Location: Königswinter

Re: New feature: high speed continuous recording

Post by Nils Roos » Thu Nov 17, 2016 12:25 am

The data format is 2 bytes per sample, two's complement signed numbers, little endian. The 14bit samples are each padded with 0 on the right (in effect multiplied by 4).

In client mode, the program will (repeatedly) try to open a connection to the address/port you specifiy with -a/-p. Once a connection has been established, it will start to stream data in the format described above. So to receive the sample stream, you just have to open a listening network socket, accept the connection from the RP, and read data.

In server mode, the program will open a listening socket at the port given with -p and wait for incoming connections. When a connection attempt arrives it will accept it and immediately start sending samples.

No protocol to observe, just connect and be hosed.
Apropos protocol, the default is TCP traffic.
All in a day's work for Bicycle Repair Man

Nils Roos
Posts: 1441
Joined: Sat Jun 07, 2014 12:49 pm
Location: Königswinter

Re: New feature: high speed continuous recording

Post by Nils Roos » Thu Nov 17, 2016 12:36 am

Amraam wrote:Probably this is not your original idea of rp_remote_acquire but I think that your work could be the starting point for a fork of rp_remote_acquire. This allows me (and other users in this thread) to experiment higher sampling frequency when a trigger event is available.

I've no idea if the architecture of rp_remote_acquire is compliant with the management of external trigger, what do you think about this?
It was not designed with triggering in mind, and some design choices might turn out to be unfavourable for a trigger function. The blockwise data dumping in particular could become awkward. But I don't see insurmountable obstacles, so if you want to have a go at it, I'll gladly tell you more.
All in a day's work for Bicycle Repair Man

Post Reply
jadalnie klasyczne ekskluzywne meble wypoczynkowe do salonu ekskluzywne meble tapicerowane ekskluzywne meble do sypialni ekskluzywne meble włoskie

Who is online

Users browsing this forum: No registered users and 1 guest