So it is understandable but I see DDS mainly uses UDP to pass its data back and forth. I was wondering how one would use it with character devices/uarts such as rs232.
One idea I had was the ppp protocol with pppd in persistent mode to get IP over serial but I have the following concern: I have at best 115200 bauds of bandwidth in the link I'm using. It is an unreliable (packet?) radio link on a UAV flying some miles away.
So I was worried pppd trying to recover from the radio link losses and auto-discovery overheads with DDS.
I came across this:
https://community.rti.com/archive/limited-bandwidth-plug-ins-dds-integrating-applications-over-low-bandwidth-unreliable-and
So one question is, in those spanish army radios, how was DDS getting sent over those radios?
Another: can I get access to the limited bandwidth pugins?
FInally, is it sane to - for a 115200kbaud link, use DDS -> IP/UDP-> pppd (linux) -> serial (rs232 uart)? Would I be having comparable effective data throughputs and latencies equal to me writing a simple messaging protocol with 32-bit crcs and fixed POD structs? Will it recover fast when the link comes back up?
Hello Jason,
That Spanish Army Radio scenario is quite extreme. Those radios only have 4800 bauds (i.e. 600 Bytes/second) aggregate capacity. So this is really a lot less that your serial link. The 4800 bauds secario really needed thise plugins which do many things, not only they compress messages but that also use a special file-based discovery mechanism.
You can find a lot of detail on the Limited Transport Plugins and the Spanish Army Radio scenario on this presentation: http://www.slideshare.net/RealTimeInnovations/dds-over-low-bandwidth-data-links-jaime-martin-losa-london-connext-conference
If you have 115200 kbauds I think you should be able to run the full RTI Connext DDS with the regular transport and discovery plugins.
I know od several experiments where they used DDS over radio/microwave links with a lot of latency and noise. E.g. between the Space Station and Earth and between the Atacame desert (Chile) and California. I am nort sure what bandwidth they actually had avalable but I think they may be not too dissimilar with the scenario you describe. See http://www.esa-telerobotics.net/news/16/67/First-robotic-force-feedback-experiment-in-Space-ever and http://vislab-ccom.unh.edu/~schwehr/papers/nomad-fsr97.pdf
-Gerardo
Hi Gerardo,
Hmm, just as a clarification I meant 115200 baud (not Kbaud) - 24x than 4800 - by my math that's 11.25kbyte/s for 8-bit characters with a start and stop bit or 10 bits per character.
I got some documentation on the radio today. It's packet sizes are in the range of 100-200 bytes. I'd been advised previously that I should assume only half that datarate as things get "far" and stick to smaller messages to improve likelyhood they are transmitted complete - and the radio has a robust option which takes 20kbaud all by itself. It may sound like alot of bits until you start looking at all the data I would want to transmit in addition to basic telemetry - tracks, multiple intruders, true/false detections so we can be aware what the system is thinking (autonomous uav collision avoidence, not an autopilot). Quite a few floats and doubles in there so I intended to use compression, be spartan as I can, potentially some bit packing and reduce discovery overhead.
I've not really fooled around with a radio link like this before but on link recovery, which I'm not sure how often would occur in practice but I'm betting it will happen whenever the aircraft banks and the antenna line of site is obstructedm pppd might have it's own recovery overhead while it is seeking for next packets in the serial stream then there's whatever the whatever the discovery overhead is - I don't recall finding a clear number for that though. I can know all my services and the like before hand though.
You can see that the internet connection to the ISS isn't too shabby: http://www.nasa.gov/directorates/heo/reports/iss_reports/2013/ISS_Daily_Summary__040213.html although the latency is high and reliablity can be questionable. Cool usage though.