[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
