On 01/18/2013 01:48 AM, John Wilson wrote: I'd do it with an HDLC/SDLC-capable chip like a Z8530...offload as much from the firmware as possible, leave those cycles for protocol handling. FWIW, I'm in the middle of writing a Z8530 driver for E11 (in heavily commented x86 code), which I'd be happy to contribute (after modifying as needed) if you aren't already neck-deep in SCC code. I built a Z8530-based AX.25 PAD for ham packet radio...but that was 25 years ago! I remember being thoroughly impressed with the Z8530, and I've used it in several projects since then...but only in async mode. So yes...if you're doing sync stuff with it, that might be very handy if we do this and it goes this route. We could certainly do the framer in firmware; there's a certain appeal to that...but I'm a big fan of distributed processing, and as the iOS device saying goes, "there's a chip for that". Wrapping the data in UDP is simple. The HDLC layer could deal with error detection/correction. Yes! Careful -- UDP doesn't guarantee in-order delivery. How does HDLC feel about little surprises? I would imagine it'd be offended. ;) However if memory serves, HDLC frames contain a few bits' worth of sequence numbers. These could be checked and buffered/re-issued to recover from most bad situations, I would think. -Dave -- Dave McGuire, AK4HZ New Kensington, PA