[DSTAR_DIGITAL] More open source D-Star repeater progress

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 th

[DSTAR_DIGITAL] Re:callsign routing

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 conne

[DSTAR_DIGITAL] Re: callsign routing

Dave Cooley Brandon, Fl.

[DSTAR_DIGITAL] Re: callsign routing

Tony and John , I agree fully. And yes it is best to announce how you are coming in. */Here is a question for the Gateway Experts:/* On the issue of Update Latency; When a user call sign routes into a repeater does that repeater update the users table with their current information? Example:

Re: [DSTAR_DIGITAL] More open source D-Star repeater progress

Where to find more information about this ? (software/hardware etc) 73s Robbie ON4SAX On Fri, Oct 16, 2009 at 1:00 PM, Jonathan Naylor wrote: > > > 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

[DSTAR_DIGITAL] Re: More open source D-Star repeater progress

Hi Robbie I have a Yahoo group to distribute and support the software, which also includes an analogue repeater controller, and eventually a full dual-mode repeater. It's located at . The current hardware support is for the Velleman K8055 for

RE: [DSTAR_DIGITAL] Re:callsign routing

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 know

RE: [DSTAR_DIGITAL] Re: callsign routing

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

Re: [DSTAR_DIGITAL] Re: Beeps

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

Re: [DSTAR_DIGITAL] callsign routing

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 tim

Re: [DSTAR_DIGITAL] Re: More open source D-Star repeater progress

At 11:18 PM 10/16/2009, you wrote: >Hi Robbie > >I have a Yahoo group to distribute and support the software, which >also includes an analogue repeater controller, and eventually a full >dual-mode repeater. It's located at >. > >The current har

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 >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 und

Re: [DSTAR_DIGITAL] Re:callsign routing

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 correcti

Re: [DSTAR_DIGITAL] Re: Beeps

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

RE: [DSTAR_DIGITAL] Re: Beeps

And you can tell that there is some error detection/correction because how often do you see a bad call sign displayed? If there wasn't, you'd see also sorts of crap in the Last Heard list. Ed WA4YIH From: dstar_digital@yahoogroups.com [mailto:dstar_digi...@yahoogroups.com] On Behalf Of Tony La

RE: [DSTAR_DIGITAL] Re: Beeps

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 (

[DSTAR_DIGITAL] Re: Beeps

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 th

Re: [DSTAR_DIGITAL] Re: Beeps

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 missin

RE: [DSTAR_DIGITAL] Re: Beeps

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 transmissions" It's only when the two stations have different ro

Re: [DSTAR_DIGITAL] Re: Beeps

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 tr