New feature: high speed continuous recording
-
- Posts: 3
- Joined: Tue Jul 10, 2018 7:47 pm
Re: New feature: high speed continuous recording
Hi,
My issue may sound primitive and unrelated to this discussion. However, since it is sort of a data acquisition issue that I'm dealing with, I hope someone would help me fix it.
I am using the current code to perform: 1- real-time plotting and 2- real-time data recording vs time of the "iq2" and "iq2_2" outputs of the iqs module. Although the animation seems to be wokring, the t (x axis) is not updates as the time goes by. In addition, I am not exactly sure how to save the data for these two curves. I am planning to run this code for at least 30-120 seconds and continuously save the iq2 and iq2_2 in a CSV file. I would appreciate it if anyone could share some insight on this. Here is the code:
from matplotlib import pyplot as plt
from matplotlib import animation
from pyrpl import Pyrpl
import csv
import os
import math
import numpy as np
duration = 20
#p = Pyrpl(hostname="169.254.99.100")
p = Pyrpl('LIA')
r = p.rp
##Redpitaya (RP) Oscilloscope Settings
s = r.scope
s.input1 = "iq2" #Output X from the RP Locked-in Amplifier
s.input2 = "iq2_2" #Output Y from the RP Locked-in Amplifier
s.trigger_source = 'immediately'
s.threshold = 0
s.hysteresis = 0.01
s.trigger_delay = 0
s.decimation = 65536
##Locked-in demodulation settings:
iq_I = r.iq2
iq_I.setup(frequency=500, bandwidth=[0,1.186], gain=0.0, phase=0, acbandwidth=0, amplitude=0.2, input='in1', output_direct='out1', output_signal='quadrature', quadrature_factor=1)
print("Available decimation factors:", s.decimations)
R = np.zeros((1907,))
ch1 = np.zeros((16384,))
ch2 = np.zeros((16384,))
ch1 = s._data_ch1
ch2 = s._data_ch2
##Real-time figure plot
fig, ax = plt.subplots()
signal_axis = ax.twinx()
signal_axis.set_ylabel('X (Volt)', color=(31 / 255., 119 / 255., 180 / 255.), size=20)
ax.set_ylabel('Y (Volt)', color=(255 / 255., 127 / 255., 14 / 255.), size=20)
ax.set_xlabel('Time (s)', size=20)
ax.set_ylim(-1.0, 1.0)
signal_axis.set_ylim(-0.2, 0.2)
ch1, = ax.plot([], [], color=(255 / 255., 127 / 255., 14 / 255.))
ch2, = signal_axis.plot([], [], color=(31 / 255., 119 / 255., 180 / 255.))
def animate(i):
ax.set_xlim(0, s.times[16383])
ch1.set_data(s.times[0:16384], s._data_ch1[0:16384])
ch2.set_data(s.times[0:16384], s._data_ch2[0:16384])
ani = animation.FuncAnimation(fig, animate, interval=50)
plt.show()
##Saving the data
#tempDir=os.getcwd()
#csvDirectory = 'C:\Users\kkera\Desktop\Python data'
#os.chdir(csvDirectory)
#with open('iq-R5.csv', 'wb') as csvfile:
# spamwriter = csv.writer(csvfile, delimiter=',', quotechar='|', quoting=csv.QUOTE_MINIMAL)
# spamwriter.writerow(["t", "iq2", "iq2_2"])
# spamwriter.writerow(s.times)
# spamwriter.writerow(s._data_ch1)
# spamwriter.writerow(s._data_ch2)
#os.chdir(tempDir)
My issue may sound primitive and unrelated to this discussion. However, since it is sort of a data acquisition issue that I'm dealing with, I hope someone would help me fix it.
I am using the current code to perform: 1- real-time plotting and 2- real-time data recording vs time of the "iq2" and "iq2_2" outputs of the iqs module. Although the animation seems to be wokring, the t (x axis) is not updates as the time goes by. In addition, I am not exactly sure how to save the data for these two curves. I am planning to run this code for at least 30-120 seconds and continuously save the iq2 and iq2_2 in a CSV file. I would appreciate it if anyone could share some insight on this. Here is the code:
from matplotlib import pyplot as plt
from matplotlib import animation
from pyrpl import Pyrpl
import csv
import os
import math
import numpy as np
duration = 20
#p = Pyrpl(hostname="169.254.99.100")
p = Pyrpl('LIA')
r = p.rp
##Redpitaya (RP) Oscilloscope Settings
s = r.scope
s.input1 = "iq2" #Output X from the RP Locked-in Amplifier
s.input2 = "iq2_2" #Output Y from the RP Locked-in Amplifier
s.trigger_source = 'immediately'
s.threshold = 0
s.hysteresis = 0.01
s.trigger_delay = 0
s.decimation = 65536
##Locked-in demodulation settings:
iq_I = r.iq2
iq_I.setup(frequency=500, bandwidth=[0,1.186], gain=0.0, phase=0, acbandwidth=0, amplitude=0.2, input='in1', output_direct='out1', output_signal='quadrature', quadrature_factor=1)
print("Available decimation factors:", s.decimations)
R = np.zeros((1907,))
ch1 = np.zeros((16384,))
ch2 = np.zeros((16384,))
ch1 = s._data_ch1
ch2 = s._data_ch2
##Real-time figure plot
fig, ax = plt.subplots()
signal_axis = ax.twinx()
signal_axis.set_ylabel('X (Volt)', color=(31 / 255., 119 / 255., 180 / 255.), size=20)
ax.set_ylabel('Y (Volt)', color=(255 / 255., 127 / 255., 14 / 255.), size=20)
ax.set_xlabel('Time (s)', size=20)
ax.set_ylim(-1.0, 1.0)
signal_axis.set_ylim(-0.2, 0.2)
ch1, = ax.plot([], [], color=(255 / 255., 127 / 255., 14 / 255.))
ch2, = signal_axis.plot([], [], color=(31 / 255., 119 / 255., 180 / 255.))
def animate(i):
ax.set_xlim(0, s.times[16383])
ch1.set_data(s.times[0:16384], s._data_ch1[0:16384])
ch2.set_data(s.times[0:16384], s._data_ch2[0:16384])
ani = animation.FuncAnimation(fig, animate, interval=50)
plt.show()
##Saving the data
#tempDir=os.getcwd()
#csvDirectory = 'C:\Users\kkera\Desktop\Python data'
#os.chdir(csvDirectory)
#with open('iq-R5.csv', 'wb') as csvfile:
# spamwriter = csv.writer(csvfile, delimiter=',', quotechar='|', quoting=csv.QUOTE_MINIMAL)
# spamwriter.writerow(["t", "iq2", "iq2_2"])
# spamwriter.writerow(s.times)
# spamwriter.writerow(s._data_ch1)
# spamwriter.writerow(s._data_ch2)
#os.chdir(tempDir)
-
- Posts: 6
- Joined: Fri Mar 06, 2015 4:59 am
Re: New feature: high speed continuous recording
Using Nils' rp_remote_acquire code and ddrdump.bit I am trying to stream data from the ADC over TCP.
The received data is strange consisting of two samples of data (int16) followed by 0xFFFFFFFF before another two samples. I also get two zero samples every 128bytes.
Is anyone out there still working on this? It looks like Nils Roos left the forum over two years ago and this kind of development seems dead but perhaps I am looking in the wrong place. If anyone is has any other high speed acquisition projects for the Pitaya please let me know.
Code: Select all
./rp_remote_acquire -m 2 -p 5353 -k 0 -c 0 -d 32 -l -r
Is anyone out there still working on this? It looks like Nils Roos left the forum over two years ago and this kind of development seems dead but perhaps I am looking in the wrong place. If anyone is has any other high speed acquisition projects for the Pitaya please let me know.
-
- Posts: 9
- Joined: Tue Oct 09, 2018 5:01 pm
Re: New feature: high speed continuous recording
Hi all!
I'm super interested in making this work, but my attempts so far haven't worked. If anybody else is still interested in this and wants to discuss it, please reply or send me an email.
I'm super interested in making this work, but my attempts so far haven't worked. If anybody else is still interested in this and wants to discuss it, please reply or send me an email.
-
- Posts: 4
- Joined: Thu Sep 26, 2019 3:56 pm
Re: New feature: high speed continuous recording
So, what's the status of this feature so far? It sounds quite interesting to me, that's something I can see myself using.
-
- Posts: 5
- Joined: Fri Dec 13, 2019 6:31 pm
Re: New feature: high speed continuous recording
I'm getting some distortion on the aquisitions by rp_remote_acquire compared to a 12 bit oscilloscope (picoscope 4227) and even the red pitaya standard oscilloscope (through web interface). Has anyone noticed this, and compared with the new "Data Stream Control" on the RP beta?
I've detailed my experiment and results in an attached pdf, with some waveform captures from each. I've also included some python code (which might be the source of the problem) for decoding the stream from rp_remote_acquire.
I've detailed my experiment and results in an attached pdf, with some waveform captures from each. I've also included some python code (which might be the source of the problem) for decoding the stream from rp_remote_acquire.
You do not have the required permissions to view the files attached to this post.
-
- Posts: 4
- Joined: Thu Jul 13, 2017 7:48 am
Re: New feature: high speed continuous recording
Hello, I also have big problems with the Remote-Acquire-Tool.
In my application two ADC - channels are used.
The communication is done via wlan in server mode.
At the same time as we changed the operating system on the remote PC from win7 to win10, we often had problems with redPitaya.
Trouble means that the connection crashed and redPitaya restarts.
So we took another RedPitaya and used the sd card of the old one.
In the new RedPitaya, the filesystem crashed (or exactly the SD card with the data was partially destroyed and I could not repair it).
Also the old redpitaya os (I'm sure - because it was not my work and the exact version was not documented).
it would probably have to be 0.93 is no longer available.
Although there was a backup to SD - but this was also corrupted.
So I installed a newer operating system, after that the wlan dongle was not usable in server mode anymore.
The problem was known, so I ordered a new working Wlan dongle.
Then the dongle worked but not the tool, so I read here in the forum and downloaded the latest version of the remote aquire tool.
Afterwards I copied/exchanged the necessary files in the operating system.
The result is an unstable SW in connection with the Wlan server mode.
The connection via WLAN is necessary,
because the Redpitaya is on grid potential so it is "hot".
I can't get any further here - does anyone have a solution yet? Or do we want to join forces and try to work out a solution together.
I'm under a lot of pressure at work, because I've pushed through this open source solution against resistance and now we urgently need this special measurement setup to analyze other problems.
It would be great if we could work out a solution together.
Best regards,
Frank
In my application two ADC - channels are used.
The communication is done via wlan in server mode.
At the same time as we changed the operating system on the remote PC from win7 to win10, we often had problems with redPitaya.
Trouble means that the connection crashed and redPitaya restarts.
So we took another RedPitaya and used the sd card of the old one.
In the new RedPitaya, the filesystem crashed (or exactly the SD card with the data was partially destroyed and I could not repair it).
Also the old redpitaya os (I'm sure - because it was not my work and the exact version was not documented).
it would probably have to be 0.93 is no longer available.
Although there was a backup to SD - but this was also corrupted.
So I installed a newer operating system, after that the wlan dongle was not usable in server mode anymore.
The problem was known, so I ordered a new working Wlan dongle.
Then the dongle worked but not the tool, so I read here in the forum and downloaded the latest version of the remote aquire tool.
Afterwards I copied/exchanged the necessary files in the operating system.
The result is an unstable SW in connection with the Wlan server mode.
The connection via WLAN is necessary,
because the Redpitaya is on grid potential so it is "hot".
I can't get any further here - does anyone have a solution yet? Or do we want to join forces and try to work out a solution together.
I'm under a lot of pressure at work, because I've pushed through this open source solution against resistance and now we urgently need this special measurement setup to analyze other problems.
It would be great if we could work out a solution together.
Best regards,
Frank
-
- Posts: 5
- Joined: Fri Dec 13, 2019 6:31 pm
Re: New feature: high speed continuous recording
I eventually gave up on rp_remote_acquire and switched to the streaming server built into the beta version of the Red Pitaya SD card image. I wrote a streaming client in python, and a simple GUI. I also wrote a python program to interact with the RP Nginx server. Here's the code:
https://github.com/awmlee/red_pitaya_st ... ent_python
It streams at 10's of MSPS in dual channel at 14 bit resolution.
https://github.com/awmlee/red_pitaya_st ... ent_python
It streams at 10's of MSPS in dual channel at 14 bit resolution.
-
- Posts: 33
- Joined: Fri Oct 30, 2015 3:33 pm
Re: New feature: high speed continuous recording
Is it possible to also use the streaming server for playing large earlier acquired files (on network disk file mounted) via the high speed DAC's ? I am using ecosystem 0.99 now.
I am also looking for a solution to use the RedPitaya "just" as 'slave', under control by a own developed Python PC user program, just as Awmlee does (see May 14).
Originally I was hoping to be able to let this PC program to just start and stop appropriate "ADC_player and DAC-player programs" in the RedPitaya .
Does anyone have suggestions how to approach this using the streaming server ?
I am also looking for a solution to use the RedPitaya "just" as 'slave', under control by a own developed Python PC user program, just as Awmlee does (see May 14).
Originally I was hoping to be able to let this PC program to just start and stop appropriate "ADC_player and DAC-player programs" in the RedPitaya .
Does anyone have suggestions how to approach this using the streaming server ?
- redpitaya
- Site Admin
- Posts: 912
- Joined: Wed Mar 26, 2014 7:04 pm
Re: New feature: high speed continuous recording
Sorry to interrupt. Black Friday 2020 is here!
-
- Posts: 1
- Joined: Mon Sep 19, 2022 3:21 pm
Re: New feature: high speed continuous recording
There's a tantalising amount of discussion about x Msps continuous streaming of:
[2 channels] -> 16-bit samples -> UDP
...but I can't find any applications for the currently available ecosystem, and many of the code samples/binaries uploaded previously seem to have expired. Am I missing something?
The StreamServer bundled with the
By inspection I can see ~62 bytes of header before what looks be the data for channel 1, followed by a block of channel 2 data(?) Before I start spending hours reverse engineering the packets, can someone point this old C-language dinosaur at the document I've obviously overlooked?
In return, I'll post my:
UDP socket -> dual 16-bit arrays of sample data ...code back to the forum!
Many thanks RP gurus,
J![Smile :)](./images/smilies/icon_e_smile.gif)
[2 channels] -> 16-bit samples -> UDP
...but I can't find any applications for the currently available ecosystem, and many of the code samples/binaries uploaded previously seem to have expired. Am I missing something?
The StreamServer bundled with the
ecosystem seems to do what I need and generates packets at an appropriate rate. Can anyone point me at information on the headers/protocol/packing format to extract the data from the received packets?Red Pitaya OS 1.04-15 / SDRlab 122-16
By inspection I can see ~62 bytes of header before what looks be the data for channel 1, followed by a block of channel 2 data(?) Before I start spending hours reverse engineering the packets, can someone point this old C-language dinosaur at the document I've obviously overlooked?
In return, I'll post my:
UDP socket -> dual 16-bit arrays of sample data ...code back to the forum!
Many thanks RP gurus,
J
![Smile :)](./images/smilies/icon_e_smile.gif)
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 133 guests