Working on more versatile trigger and continuous acquisition

Share it with others! So what you are up to do these days?
Post Reply
Nils Roos
Posts: 1441
Joined: Sat Jun 07, 2014 12:49 pm
Location: Königswinter

Working on more versatile trigger and continuous acquisition

Post by Nils Roos » Thu Jun 12, 2014 8:21 pm

Right from the start, I've thought that the RedPitaya scope application could use more trigger options

Plan for action goes like so:
1. Measure sustainable data rate over LAN
2. Think of fun ways to trigger and see what can realistically be achieved
3. ...
4. Profit (just kidding)

I've thrown together some simple programs to measure maximum sustainable network throughput between RedPitaya and PC. Without any tweaking, my RP can pump 50MBytes/s over a TCP socket to a java application that just receives and forgets. This is over a direct 1000 MBit connection between RP and PC.
25Msps on one channel would be a good start for a long-term acquisition run, so this is promising.

Further along the way I'm thinking about doing a short burn-in test at start of application and limit the available settings accordingly.
All in a day's work for Bicycle Repair Man

fisafisa
Posts: 29
Joined: Fri Jun 06, 2014 6:02 pm

Re: Working on more versatile trigger and continuous acquisi

Post by fisafisa » Thu Jun 12, 2014 9:50 pm

consider UDP.
Here in our project we are building real-time streaming of data over it.
It has the lowest overhead.
You can loose data on bad hardware and no retry will be performed.
But that is fine for real-time.

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

Re: Working on more versatile trigger and continuous acquisi

Post by Nils Roos » Thu Jun 12, 2014 11:19 pm

Good point.
With UDP the experiment topped out at 80MB/s (out of the raw available 125MB/s).
I also got up to 5% losses on the receiving end, but that might be problems in the receiver. It has been hinted at that Windows tends to loose UDP packets during context switches. Doing all this in java might also have something to do with it.
All in a day's work for Bicycle Repair Man

fisafisa
Posts: 29
Joined: Fri Jun 06, 2014 6:02 pm

Re: Working on more versatile trigger and continuous acquisi

Post by fisafisa » Fri Jun 13, 2014 9:58 pm

java.... you won't get far with that!
You need C or C++ and a bit of low level windows programming knowledge....
In your receiver app you need:
1) a receiver thread at high priority (highest of real time class)
2) block on a select to sync on the upcoming packets
3) avoid any unnecessary OS calls. They will introduce jitters in your execution. every call consists in a potential rescheduling, a potential hanging on a shared resource and a kernel context switch.
4) have an auxilliary thread (high priority but below that of the receiver) to use the data, plot it save it or whatever...
5) implement a non blocking fifo queue between the two thread to exchange packets and to allow coping with inevitable jitters of the slow thread.

Hopefully you have more than one core in your pc so that if you do make a mistake in the receiver thread sync mechanism you do not need to reboot....

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

Re: Working on more versatile trigger and continuous acquisi

Post by Nils Roos » Mon Jun 16, 2014 11:41 am

Yeah, I didn't expect to get very far, this was just an experiment to get a feeling for the setup. It took me all of 20mins to throw together the java receiver, just something for the tcp packets to go to and measure the time.

Next up is a serious effort, and I will gladly take your advice into consideration.
My rig should be powerful enough for that - it did get to 50MB/s TCP in java ;) - but maybe now is a good time to finally buy that SSD.
All in a day's work for Bicycle Repair Man

Matthias Weber
Posts: 11
Joined: Tue Jun 24, 2014 9:16 pm

Re: Working on more versatile trigger and continuous acquisi

Post by Matthias Weber » Tue Jul 15, 2014 9:07 pm

So did you already manage to handle the BRAM as a ring buffer and send the data over the network? Could you give some details?

Best,
Matthias

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

Re: Working on more versatile trigger and continuous acquisi

Post by Nils Roos » Wed Jul 16, 2014 7:22 pm

I can give some details about what the current goals are, but there isn't really anything in the way of code that is fit for showing right now.

My main objective is to have a huge ringbuffer in DDR memory that is continuously filled with fresh acquisition data from the BRAM buffers. This will ideally be handled by the PL via AFI. The trigger will then just raise an interrupt with the PS and store the current write pointer for the PS (and possibly also pause continuous acqusition after the triggered recording time has passed).
Secondary objective is to have a process that dumps all the new data in the DDR memory buffer to the network as it arrives.
All in a day's work for Bicycle Repair Man

patrick
Posts: 10
Joined: Thu Jul 10, 2014 3:31 pm
Contact:

Re: Working on more versatile trigger and continuous acquisi

Post by patrick » Thu Jul 17, 2014 1:29 pm

Indeed, improving triggers would be great.

What about using NodeJS on the server? With the fast event loop of Node, it should be possible to process the data. And, there are many JavaScript libs, that could help in plotting the data.

Illidann
Posts: 8
Joined: Wed May 27, 2015 11:00 pm

Re: Working on more versatile trigger and continuous acquisi

Post by Illidann » Mon Jun 15, 2015 7:41 pm

Is there any update with this post? I am also looking for some similar features.

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