TCP/IP connection will guarantee no data loss at the cost of possibly 
greatly increased latency.  I've done such in the past using UDP which, if 
client and server are on the same subnet, is about as deterministic as 
standard Ethernet gets, but is generally blocked by default on most 
firewalls.  If the data leaves your subnet you will need error correction 
and likely just end up reinventing TCP badly.

I've done pseudo-simultaneous sampling systems (all the A/D channels are 
sampled at the maximum rate once per tick of a slower timer that sets the 
system sampling rate) using this method with the server sending each 
multi-channel sample to a different system via UDP for further  processing 
at every tick of the sample clock.  It works very well when the systems are 
on the same subnet and the data rate is not too high compared to the 
network overhead.

If your data rate is low enough the  "file system" based solutions might be 
easier to code and troubleshoot, but you have extra overhead from the 
network transport and the file system layer to contend with.  IMHO the 
easiest to code, troubleshoot, and document architecture is the way to go 
as long as all requirements can be met.

The UDP client/server solution can be pretty fast -- I've controlled a 
6-DOF motion base (Stewart Platform) with a 100Hz servo loop where one 
system calculated the desired motion profile from user input while another 
did the matrix calculations to set the actuator link lengths for the 
desired motion, and a third processed the visual scene presented to the 
user, all talking via UDP on an isolated network (only these three systems 
were connected).


On Friday, March 11, 2016 at 11:22:18 AM UTC-6, Dhanesh Kothari wrote:
>
> Thank you @Wally and @William.
> My goal is to send continuous data stream from my system and my beaglebone 
> should be receiving data serially and than process the data as per my 
> algorithm without any data loss.
> We are using sshfs to mount a directory on beaglebone to our system.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to