It's like using burst for repeater access - the burst tone opens up the repeater and anyone can use it until it resets. D-STAR is using the same concept. Once the repeater is open, anyone can use it until it sees a new header with a different repeater ID.
Correct? Joe M. Nate Duehr wrote: > > [EMAIL PROTECTED] wrote: > > At 8/31/2007 11:18, Nate Duehr wrote: > >> FYI. > >> > >> Cross-posting to IllinoisDigitalHam list and Repeater-Builder list from > >> the [EMAIL PROTECTED] list. > >> > >> Thoughts folks? > >> > >> Thanks to Mark N5RFX for doing real testing. > > > > Thanks Nate. This is most informative. Now if you throw in the added > > benefit of DStar's error correction coding, I believe 10 kHz is the ideal > > channel spacing. > > > > Which is good for us here in SoCal because TASMA just voted to create 4 > > auxiliary link pairs for very narrow band digital systems at 145.585, > > 145.595, 145.605 & 145.615 outputs (inputs all -600 kHz). With the 10 kHz > > spacing, currently only DStar systems are compatible so they're essentially > > DStar pairs. > > > > I expect all 4 pairs to be assigned to 1 or more DStar systems at our next > > coordination meeting. > > > > Bob NO6B > > Bob, since the discussion has been happening on the D-Star list > ([EMAIL PROTECTED]) -- many people on the RB list and maybe > IllinoisDigitalHam may not be aware that there's been some investigation > into how D-Star repeaters that are co-channeled behave. > > You may want to hop over to the D-Star list and look over the archives > for the full discussion. > > My understanding of it is this: > > D-Star (the protocol, not just Icom's implementation of it) uses > callsigns for traffic routing... example "CQCQCQ" in a field means you > want to place an "all-call", and there are other fields for what > repeater you want to use to make the call, and what repeater you want to > come out on. > > Without going into the details of D-Star call routing, it should be > known that there's a field called "RPT1" that you put your repeater > you're talking on into. The repeater under normal circumstances will > refuse to repeat (but might ID after your transmission??? that's > unclear to me as to why) if you have a different callsign in the RPT1 field. > > [Understand that this is my understanding of the various e-mails and > discussion, and that I could have some of this wrong. But I think I've > kept it straight. Steve NU5D and others have been doing some testing in > Texas that has helped everyone greatly to better understand this scenario.] > > Here's the rub. That RPT1 callsign information is only sent ONCE in the > header during the initial key-up of a user radio, and is not sent > continuously throughout the transmission like a NAC on a P25 system, or > similar. > > The repeater designers, understanding that fades and nulls happen in the > real world, put an algorythm/rule set in the repeater that I don't > like... perhaps you won't either, but it's "debate-able"... and it still > meets the D-Star (protocol) specification. Icom chose to do this: > > If the repeater hears ANY validly encoded D-Star digital signal and > missed the callsign information, it uses the LAST KNOWN callsign > information and goes ahead and repeats the person's transmission. > > The problem here is in co-channeled D-Star repeaters with overlapping > coverage, but you have to build a scenario to understand it... > > Let's say stations A & B are talking on their local repeater 50 miles > north of the second repeater. We'll give the repeaters fake callsigns > to follow along. W1ABC is the "north" repeater, K1ABC is the south > repeater. > > In A & B's radios, they have RPT1 set to "W1ABC" and let's assume that > K1ABC can't "hear" either user of the north repeater. > > Station A talks and unkeys and a third station started transmitting down > south through the K1ABC repeater during his transmission. We'll call > him Station C. Station C lives in the overlap coverage between the two > repeaters, but is attempting to use K1ABC, not W1ABC. > > When A unkeys his transmission to W1ABC, the W1ABC repeater "hears" a > weak digital signal but it "missed" the callsign packet. W1ABC will > repeat the signal using the last known callsign information it had, and > K1ABC will also repeat Station C's transmission, per normal, since it > heard his full transmission just fine and he captured the receiver for > the full transmission. > > Radios monitoring W1ABC will see Station A's callsign and will continue > to hear audio but from a new voice, that of Station C. > > (This gets more complex if any of the stations are using the internet > gateway system or doing radio-to-radio (callsign to callsign) chat, not > intended for everyone to hear... but I'm not going into that here.) > > So basically the "bug" in my mind is this. If W1ABC and K1ABC have > slightly overlapping coverage in the analog world, they'd be coordinated > with seperate CTCSS tones required for access. At first glance in > D-Star, the "RPT1" field LOOKS like it can be used for this purpose also > to help coordinators and planners when systems have slightly overlapping > co-channel coverage areas. > > However, due to the limitation in the protocol of D-Star itself, not > just Icom's implementation -- the header with the callsign information > is only sent ONCE and the repeater only has "one chance" to properly > hear it and choose whether or not to repeat the received signal, or not > repeat it. > > Since Icom knew that this would cause a lot of "hey the repeater won't > repeat me!" complaints from noisy/weak users... they chose to repeat ANY > valid digital signal UNLESS the callsign header was heard. If it was > heard, the repeater behaves "appropriately". > > I think this will cause some grief as D-Star systems are co-channeled, > and the overall spacing between systems laterally will have to be higher > than mixing D-Star with Analog, D-Star with P25, whatever... D-Star > against D-Star co-channeled is going to have some "hiccups" when user > stations are in the overlap coverage area. > > More testing needs to be done, and there's even MORE things that can > affect this. The user radios can be set to program THEMSELVES with the > RPT1 field from the "last heard" repeater... imagine the interesting > effects of that in Station D's radio if he can also hear both repeaters > during this mish-mash of transmissions... his radio could be switching > back and forth between repeaters -- and if he keys up to break into the > conversation, he could be on either repeater... RPT1 could be set to > either W1ABC or K1ABC. > > Anyway... this is my understanding of it all... I don't particularly > like it, but I welcome folks who actually have systems that are > co-channeled or can simulate such to see what really happens, because > the information from the initial testers could still have some > ambiguities... no offense to them, but there's a lot of "moving parts" > in the overall system. Complex protocols lead to complex "bugs". > > :-) > > Hopefully that's helpful for anyone planning the management of D-Star > coordinations, etc. Or at least confusing enough that they'll ask for > some more real-world tests, before deciding on a plan. (GRIN!) > > I think the main place it becomes an issue is probably VHF in most > areas... where folks are going to try co-channeling them thinking > "they're digital, they can handle it"... the design choices made mean > that they can't. (Not saying that's bad or good, just saying -- plan > for it, and/or try -- good luck -- to get more official information out > of Icom about it.) > > Nate WY0X > > > Yahoo! Groups Links > > >
