That is not what I read in previous discussions by folks who were actually doing protocol-level work, but if you insist that the headers are encapsulated inside the portion of the stream that's covered by FEC, I can't really refute it technically.
What I can be sure of, is that the statement makes no sense. If a voice is copyable in a signal, but the header was mangled, that would certainly appear that either: a) FEC wasn't applied to the header. b) The way the FEC was applied to the header/the way the protocol handles header/callsign information is... well, busted. c) Voice is copyable by the human ear even with artifacts from errors. But we all already knew the b) version of that, anyway. Headers should have been continuously interlaced in the slow data field or actually designed into the protocol as a continuous repetitive stream, so the GW software and controller firmware could have been designed to "pick up mid-stream" if a copyable version of the callsigns were to pass a CRC (or other mathematical) check in the middle of a transmission, after missing the header completely at the beginning of one. It's also "too bad" that the repeaters weren't designed for field firmware updates. If they were, they could at least be patched to watch the slow-speed data callsigns, but my understanding is that only Your Call is sent in that way, not the UR, RPT1, or RPT2... so I can see why it wouldn't really matter if the Controller or GW had visibility to it. It seems to have been added only to help the receiving radio. In layman's terms, and in how we all know the system behaves in the wild: "Callsign headers from mobile/weak stations get missed, far too often." And that led to the GW design allowing "tailgating" to handle mobile drop out at the critical time at the beginning of the transmission. Those two statements pretty much cover it without getting overly technical for those not interested... D-STAR is a great learning experience for the NEXT major mobile digital mode. Nothing "wrong" with it that couldn't easily be fixed with protocol changes to match current telecom protocol "best practices". -- Nate Duehr, WY0X n...@natetech.com On Wed, 14 Oct 2009 21:23 +0000, "Jonathan Naylor" <naylo...@yahoo.com> wrote: Hi Nate You're wrong about the callsigns in the header not having FEC, they are. In fact they're probably better protected than the AMBE data if you equate the amount of protection with the extra data added for the FEC. What is not protected is the header data that is repeated in the slow data field, but AFAIK the repeater itself doesn't use that. Jonathan G4KLX __._,_._
