Alan King <[EMAIL PROTECTED]> wrote: > Has nothing to do with dropped bytes, has to do with figuring where > the start is in a repeating variable length data stream. If I send you > a few thousand FF's how do you propose to tell which ones are starts and > how many channels?
If you can live with a fixed limit to the number of channels (64), then you might borrow from this approach: http://document.ihg.uni-duisburg.de/cgi-bin/viewcvs.cgi/osprey/include/listener.h?rev=1.1.1.1&content-type=text/vnd.viewcvs-markup We 'designed' this for a computerized model airplane remote control that should be able to fallback to GSM communication if the primary radio fails. The pattern meets the requirement to transmit 15 channels at 20 Hz over a lossy 9,6 kBit/s line: If one dataset (packet of four bytes) gets partially or completely lost, then the reciever will notice because the checksum doesn't match. He is supposed to drop the packet - knowing that he'll have to wait only 1/20 second for the next one. I'm not shure if the current configurable serial interface is capable to do bit-mangling and I'm quite confident that it lacks support for checksumming. But this may come in the future, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
