Page 1 of 1

Working on more versatile trigger and continuous acquisition

Posted: Thu Jun 12, 2014 8:21 pm
by Nils Roos
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.

Re: Working on more versatile trigger and continuous acquisi

Posted: Thu Jun 12, 2014 9:50 pm
by fisafisa
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.

Re: Working on more versatile trigger and continuous acquisi

Posted: Thu Jun 12, 2014 11:19 pm
by Nils Roos
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.

Re: Working on more versatile trigger and continuous acquisi

Posted: Fri Jun 13, 2014 9:58 pm
by fisafisa
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....

Re: Working on more versatile trigger and continuous acquisi

Posted: Mon Jun 16, 2014 11:41 am
by Nils Roos
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.

Re: Working on more versatile trigger and continuous acquisi

Posted: Tue Jul 15, 2014 9:07 pm
by Matthias Weber
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

Re: Working on more versatile trigger and continuous acquisi

Posted: Wed Jul 16, 2014 7:22 pm
by Nils Roos
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.

Re: Working on more versatile trigger and continuous acquisi

Posted: Thu Jul 17, 2014 1:29 pm
by patrick
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.

Re: Working on more versatile trigger and continuous acquisi

Posted: Mon Jun 15, 2015 7:41 pm
by Illidann
Is there any update with this post? I am also looking for some similar features.