Page 29 of 30

Re: New feature: high speed continuous recording

Posted: Thu Dec 20, 2018 9:00 pm
by keramatnejad
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)

Re: New feature: high speed continuous recording

Posted: Thu Jan 24, 2019 12:39 am
by hadmack
Using Nils' rp_remote_acquire code and ddrdump.bit I am trying to stream data from the ADC over TCP.

Code: Select all

./rp_remote_acquire -m 2 -p 5353 -k 0 -c 0 -d 32 -l -r
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.

Re: New feature: high speed continuous recording

Posted: Tue Jan 29, 2019 4:31 pm
by gerardpc
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.

Re: New feature: high speed continuous recording

Posted: Thu Sep 26, 2019 4:12 pm
by November_SSN
So, what's the status of this feature so far? It sounds quite interesting to me, that's something I can see myself using.

Re: New feature: high speed continuous recording

Posted: Fri Jan 03, 2020 2:03 am
by awmlee
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.
Results_from_rp_remote_acquire_v2.pdf

Re: New feature: high speed continuous recording

Posted: Sun May 10, 2020 10:09 pm
by FrankMuenzner
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

Re: New feature: high speed continuous recording

Posted: Thu May 14, 2020 6:54 pm
by awmlee
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.

Re: New feature: high speed continuous recording

Posted: Thu Sep 03, 2020 2:24 pm
by cdekker
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 ?

Re: New feature: high speed continuous recording

Posted: Thu Nov 19, 2020 2:40 pm
by redpitaya
Sorry to interrupt. Black Friday 2020 is here!

Re: New feature: high speed continuous recording

Posted: Mon Oct 31, 2022 9:40 am
by thylacine1975
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
Red Pitaya OS 1.04-15 / SDRlab 122-16
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?

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 :)