Nice! I also had lots of fun with it Let me know if you run into trouble.tisho88 wrote:Thank you noah, looks I will have a lot of fun during the weekend
New feature: high speed continuous recording
-
- Posts: 33
- Joined: Fri Jan 23, 2015 9:53 am
- Location: Zurich
Re: New feature: high speed continuous recording
-
- Posts: 1441
- Joined: Sat Jun 07, 2014 12:49 pm
- Location: Königswinter
Re: New feature: high speed continuous recording
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.
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.
-
- Posts: 7
- Joined: Tue May 05, 2015 8:29 pm
- Location: Ilmenau Germany
Re: New feature: high speed continuous recording
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
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.
-
- Posts: 1441
- Joined: Sat Jun 07, 2014 12:49 pm
- Location: Königswinter
Re: New feature: high speed continuous recording
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).
To convert these to correct voltages you'll need to apply the calibration values of your Red Pitaya (Volts per count and offset).
-
- Posts: 7
- Joined: Tue May 05, 2015 8:29 pm
- Location: Ilmenau Germany
Re: New feature: high speed continuous recording
aha now it make sense.
Thank you very much, will fight with this tomorrow, today was very successful
Thank you very much, will fight with this tomorrow, today was very successful
-
- Posts: 7
- Joined: Tue May 05, 2015 8:29 pm
- Location: Ilmenau Germany
Re: New feature: high speed continuous recording
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:
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
Now to the question (sorry if i ask something stupid ):
I tried to build - the ecosystem from here:
But unfortunately I am geting folowing error: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 ?
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
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
-
- Posts: 1441
- Joined: Sat Jun 07, 2014 12:49 pm
- Location: Königswinter
Re: New feature: high speed continuous recording
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.Do you have an idea what is the reason for this error?
edit: pushed
-
- Posts: 16
- Joined: Mon May 04, 2015 10:50 am
- Location: France
Re: New feature: high speed continuous recording
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 :
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!
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
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!
-
- Posts: 799
- Joined: Sat May 23, 2015 5:22 pm
Re: New feature: high speed continuous recording
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
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
-
- Posts: 1441
- Joined: Sat Jun 07, 2014 12:49 pm
- Location: Königswinter
Re: New feature: high speed continuous recording
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
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
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 38 guests