There are other reasons why the radio may generate a beep.
The main one is loss of bit-sync.
Every 21st frame has 0x55 0x2d 0x16 at the end - if you generate these at 20 or
22 frame intervals, sure enough, you get a beep.
If you miss several, you get a beep.
So, under weak conditions, you can
On Oct 16, 2009, at 9:22 PM, Woodrick, Ed wrote:
The “ignoring the call if it can’t be decoded” IS the attempt to
assure that the protocol works. That allows subsequent transmissions
to follow the initial transmission. If this didn’t occur, then there
would be a lot more “dropped
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
At 07:20 AM 10/17/2009, you wrote:
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.
My
My reading of the protocol specification is that the header has a
checksum (2.1.1 (11) page 4 - http://www.arrl.org/FandES/field/regulations/techchar/D-STAR.pdf)
for error detection, but forward error correction (FEC) only
applies to the audio portion of the AMBE payload (and performed by
...@yahoogroups.
com [mailto:dstar_digi...@yahoogroups.com] On Behalf Of Tony
Langdon
Sent: Friday, October 16, 2009 5:09 PM
To: dstar_digi...@yahoogroups.comsubject: Re: [DSTAR_DIGITAL] Re:
Beeps
At 07:20 AM 10/17/2009, you wrote:
That is not what I read in previous discussions by folks who
were
Nate,
If you look at the D-Star protocol you'll see in AP2 (in the file shogen.pdf)
the details of the FEC applied to the header, doubling its length to 660 bits.
It's a convolution code as opposed to concatenated block codes as used by AMBE.
The checksum in the header is then used to ensure
Okay, interesting. Please review and note that I never said a
receiving station gets a CORRUPTED callsign. The result is
actually that the receiving station gets *no callsign* at all.
Then the firmware in the controller or the software in the GW was
programmed in such a way as to treat that
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
