I'm happy to report that last night a QSO was made on D-Star using a
combination of my open source repeater software and the open source gateway and
reflector from Scott KI4LKF. The QSO was between Jon G4TSN and Scott KI4LKF via
the GB3IN dual-mode repeater and the XREF005A reflector. I expect
A few questions
I've used Callsign Routing as well as most of the other methods available on
the system. All have been both successful and at other times not so much.
Here are the questions as well as my thoughts to date which are subject to
correction.
1. If the repeater I am using is
I'll start with what might be an enlightening description...
Repeater linking is not performed by the Icom software, it is provided by
AA4RC's DPLUS. Call sign routing is performed by the Icom software and has no
concept that DPLUS is running . So, in short, since the Icom Software doesn't
AFAIK, the ONLY updating that occurs is to the Trust Server and then replicated
out. So one repeater will not update another repeater system.
The only exception, with the latest gateway software, is that if you move
between modules on the same system, the local system will redirect the call to
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
The information is in a table on the local GW that's updated
periodically from the central Trust Server. The user radios
aren't involved at all, other than sending the callsign(s)
required.
The local GW's don't update often enough to make jumping from GW
to GW always feasible. Various update
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
At 10:31 PM 10/16/2009, you wrote:
A few questions
I've used Callsign Routing as well as most of the other methods
available on the system. All have been both successful and at other
times not so much.
Here are the questions as well as my thoughts to date which are
subject to correction.
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
I see empty callsigns displayed all the time on weak signals
(HT's usually) on the receiving radio (error detection... it was
bad, so... chuck it), and in the D-Plus logs on the W0CDS
Gateway, all the time. Never on strong signals.
In fact, seeing the callsign go missing is a great way for me
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
12 matches
Mail list logo
