Nils Roos wrote:Hi Amraam,
The one improvement which might be implemented soon is the recording into onboard RAM for later transmission/storage. This would mean you could record 300-400MB of continuous samples at full speed and transmit or store them at a slower pace without incurring gaps in the stream - it would only not be realtime anymore.
This is an interesting functionality for limited time acquisition.
Just my opinion for realtime acquisition: after I've experienced a great performance in realtime acquisition at lower frequency (decimation >=8), I think that one possible solution that allows to increase the sampling frequency (standing the up-limit of data rate) could be the acquisition of certain amount of data every trigger event. This will limit the amount of data to transmit over TCP/IP.
Probably this is not your original idea of rp_remote_acquire but I think that your work could be the starting point for a fork of rp_remote_acquire. This allows me (and other users in this thread) to experiment higher sampling frequency when a trigger event is available.
I've no idea if the architecture of rp_remote_acquire is compliant with the management of external trigger, what do you think about this?
In any case, thank you for your time.