New feature: high speed continuous recording

Discussions about active development projects
Post Reply
noah
Posts: 33
Joined: Fri Jan 23, 2015 9:53 am
Location: Zurich

Re: New feature: high speed continuous recording

Post by noah » Fri May 22, 2015 2:16 pm

tisho88 wrote:Thank you noah, looks I will have a lot of fun during the weekend :)
Nice! I also had lots of fun with it :D Let me know if you run into trouble.

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 » Fri May 22, 2015 2:59 pm

I'll see to it that current stable versions will be available via dropbox again when I get home in the evening. Drop me a note - PM or email - if you run into problems.

Edit: Cleaning my code of some experimental stuff will take me a liitle while, so there's a slight delay before I can upload stable versions. Sorry for any inconvenience.

tisho88
Posts: 7
Joined: Tue May 05, 2015 8:29 pm
Location: Ilmenau Germany

Re: New feature: high speed continuous recording

Post by tisho88 » Sat May 23, 2015 7:09 pm

Hi again, I sucssesfuly load all files and load the FPGA with the new bit file. Build simple UDP reciever in Labview and establish the connection and comunication.
I use "/tmp/ddrdump/preview/preview_rp_remote_acquire -m 1 -a 192.168.1.101 -p 9930 -u -c 0 -r -d 32 " to start communication

Question now is how the data is formed and how I can restore it to the voltage? I think somethinh is wrong with tha data that i recived (every second recieved byte is "FF" - "1BFF 18FF 17FF 15FF 16FF " - for example)
As far as I remember right noah wrote some program to recieve the data and calc. to the voltage but is not available to download.
Thank you in advance.

PS:
Input of the firs channel is floating but asume that the value is around zero
Last edited by tisho88 on Sat May 23, 2015 7:22 pm, edited 1 time in total.

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 » Sat May 23, 2015 7:18 pm

Hi, there's nothing wrong with that data, you just have to swap the bytes since they are signed 16bit values in little endian byte order. The actual values would then be 0xff1b = -229, 0xff18 = -232, 0xff17 = -233, ...

To convert these to correct voltages you'll need to apply the calibration values of your Red Pitaya (Volts per count and offset).

tisho88
Posts: 7
Joined: Tue May 05, 2015 8:29 pm
Location: Ilmenau Germany

Re: New feature: high speed continuous recording

Post by tisho88 » Sat May 23, 2015 7:32 pm

aha now it make sense.
Thank you very much, will fight with this tomorrow, today was very successful :)

tisho88
Posts: 7
Joined: Tue May 05, 2015 8:29 pm
Location: Ilmenau Germany

Re: New feature: high speed continuous recording

Post by tisho88 » Mon May 25, 2015 10:30 pm

Hi again I menaged comunication and calibration sucsessfuly, soon will upload here my LabView example because I guess will be useful for beginners like me. Just need some time to make it beautiful :)
Now to the question (sorry if i ask something stupid ):
I tried to build - the ecosystem from here:
Nils Roos wrote:The code for rp_remote_acquire can be found in this repository.
The modified ecosystem including the code for the kernel module is in this branch of my RP fork.

There is currently no detection of a buffer overflow condition. If the data cannot be sent before new samples are written to unsent buffer-space, the old samples will simply be lost. It is possible to detect this in the transmitter, but we had no good idea for a suitable reaction to that condition. Any suggestions ?
But unfortunately I am geting folowing error:

Code: Select all

patching file drivers/net/phy/Makefile
(Stripping trailing CRs from patch; use --binary to disable.)
patching file drivers/char/xilinx_devcfg.c
Hunk #2 FAILED at 242.
1 out of 6 hunks FAILED -- saving rejects to file drivers/char/xilinx_devcfg.c.rej
make[1]: *** [linux-xlnx] Error 1
make[1]: Leaving directory `/home/tisho/Documents/RedPitaya/RedPitaya-dev_ddrdump/OS/linux'
make: *** [build/uImage] Error 2
Do you have an idea what is the reason for this error?
I managed first to build successfully the default ecosystem from github, following the instructions from http://wiki.redpitaya.com/index.php?title=Red_Pitaya_OS
and
viewtopic.php?t=49

Thank you in advance

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 May 26, 2015 7:59 pm

Do you have an idea what is the reason for this error?
After taking a closer look, it turns out I am the reason for this error - I fudged the patch, sorry for that. A fix will be pushed forthwith.

edit: pushed

Simonx
Posts: 16
Joined: Mon May 04, 2015 10:50 am
Location: France

Re: New feature: high speed continuous recording

Post by Simonx » Thu May 28, 2015 4:30 pm

Hello again,

Thanks to Tisho and Nils, I was able to solve my problem...

But I have some troubles when I try to read a binary file.
For this test, I sent a 1 Hz sinusoidal signal, through an oscilloscope directly to channel B. I used a USB console to send this command for example :

Code: Select all

rp_remote_acquire -m 3 -r -c 1 -d 8 -k 256 -f /tmp/out
Then I'm using my labview VI to try to read it, but here's what I got:
http://www.zupimages.net/up/15/22/y671.jpg

Here's a screenshot of my VI.
http://www.zupimages.net/up/15/22/ugiq.jpg

It seems like some kind of noise randomly appears out of nowhere. It doesn't happen all the time, and I don't have this problem when I'm reading datas via UDP, but I need to write datas since it appears streaming doesn't support really well decimation 8...
Changing decimation, frequency or kb to transfer number doesn't matter.

Does anyone have an idea about how to solve this?
Thanks!

pavel
Posts: 789
Joined: Sat May 23, 2015 5:22 pm

Re: New feature: high speed continuous recording

Post by pavel » Sun May 31, 2015 11:00 pm

Hi Nils and Brandon,

I've just got an idea on how to improve the network transfer rate. I think that it won't be difficult to implement this idea in the rp_remote_acquire program.

I started from your idea to copy the ADC data to a cached memory buffer before sending it over the network and then I told myself that the second CPU should be made to do some useful work.

As I'm not good with threads, I'm using two processes with shared memory and pipe. The first process copies the ADC data to a cached memory buffer (shared memory) and then sends an empty string to the pipe. The second process waits until it receives a string from the pipe and then sends the data over the network.

Here is the source code of my test program that illustrates this idea:

https://github.com/pavel-demin/red-pita ... t-server.c

This program works with the Debian based SD card image and with my adc_test project:

https://github.com/pavel-demin/red-pita ... s/adc_test

With this program, I can transfer 2 bytes per sample at 31.25 MSPS. The client program is running on my Windows laptop and the Windows network monitoring shows 63-65 MB/s.

Cheers,

Pavel

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 Jun 01, 2015 7:44 pm

Hi Pavel,

Thank you for this suggestion. I will incorporate it into rp_remote_acquire later and let you know how it went.

Do I interpret it correctly that you have taken the top 32MB of RAM out of the linux address space and use that as the shared mem ?

Cheers
Nils

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 24 guests