WOW, Ok I think I have it now!
Thanks to everyone, but especially Nate who put lots of time into answering my question. I don't know if I should pose my next question. I might wear Nate out! :-) Fran <http://www.miele-family.com/weather> <http://www.miele-family.com/weather> _____ From: dstar_digital@yahoogroups.com [mailto:dstar_digi...@yahoogroups.com] On Behalf Of Nate Duehr Sent: Wednesday, October 14, 2009 3:38 PM To: dstar_digital@yahoogroups.com Subject: RE: [DSTAR_DIGITAL] Beeps p.s. Hey, I took something else for granted in my reply Fran, and realized I should mention it more clearly... The above is ALL dependent on PERFECT RF CONDITIONS and ZERO BIT LOSS. With only the voice portion of the D-STAR stream Forward Error Corrected, and never the callsigns, all it takes is a single blip of noise in the received signal to trash the callsign header and/or fail the CRC check on the frame. Setting aside that the "beep" is a function of the radio, but it's too hard to type "watch for the little data/info packet", we'll shorten that to "beep" for this discussion still, since that's what you really see on any rig in default settings... If you're not always getting the double-beep, monitor with more than one radio (sometimes it happens too fast for the turn-around time in YOUR rig, but other folks can hear it) or call someone on the phone and listen to theirs after you un-key. Also watch the dplus.log and other logs on the GW to see if EVERY transmission you're hearing or not hearing double-beeps on is REALLY being 100% copied by the GW server. It doesn't take much to trash the callsign headers in a D-STAR transmission. The GW implements a strange, but somehow amazingly workable "I'll just use the last known good callsign header if I don't get one for this transmission" principal that is counter-intuitive if you're playing with callsign routing and one of the stations is weak into the repeater. They'll seem to work sometimes, other times they won't, but they're "riding on the coat-tails" of the strong signal station if both are callsign routing to the same place. The ubiquitous use of "CQCQCQ" all the time in D-Plus links has an advantage here. Every transmission is "going to the same place", so to speak, and people who would be too noisy to use the repeater properly, are still routed to "CQCQCQ". You can see this "problem" in action by having a strong signal station COMMAND the D-Plus link up, then have the weak station key up. You'll get the announcement "REMOTE SYSTEM LINKED" *twice*, even though the second station was sending "CQCQCQ" and not a Reflector command. If you look in the logs, you'll see that the system NEVER COPIED the callsign header from station #2, it just ASSUMED that it was a continued transmission from Station #1. Obviously this "feature" was added to handle mobile flutter and drop-outs... when you come back into coverage after driving down into a "hole", you would prefer to have the second-half of your transmission routed to the far end. The only way to do this in D-STAR was to "pick up where you left off" even if the system had no callsign header to utilize. Other digital systems have done this in a MUCH more intelligent way. Just as an example, P25 continuously sends the equivalent of the "header packet" as a very low speed interlaced series of bits in the ENTIRE transmission. This allows the repeater to actually SEE that the transmission that "just popped back up from down in the hole" in that mobile rig, is a proper system user ID, etc... and not have to assume/guess, like the D-STAR Gateway has to. Unfortunately, this is a limitation of how the D-STAR protocol itself is designed, and a lack of foresight many many years ago by the Icom engineers about noisy signals... so I doubt it'll ever be "fixed" in D-STAR. It'll just be a "fact of life" that noisy users can "tailgate" on non-noisy ones, and most of the time, get away with it... even though if you look at their data/callsign routing headers in the logs, they're completely trashed and/or never pass even a CRC check. Any "fix" for this would have to be implemented as a backward-compatible change to the D-STAR protocol, driven through the standards body, and put into future radios, without adversely affecting current rigs. A non-trivial task unless some of the "Reserved" bits were used... and some already are for un-documented features from Icom... or so I hear... -- Nate Duehr, WY0X n...@natetech.com On Wed, 14 Oct 2009 10:35 -0400, "Fran Miele" <f...@miele-family.com> wrote: I think I understand some of this. In our situation we are using DPLUS routing from our repeater to Ref010 along with several other repeaters. Why would we not get any beeps yet everyone heard the transmission? Thanks, Fran, W1FJM -----Original Message----- From: dstar_digital@ <mailto:dstar_digital%40yahoogroups.com> yahoogroups.com [mailto:dstar_digital@ <mailto:dstar_digital%40yahoogroups.com> yahoogroups.com] On Behalf Of Nate Duehr Sent: Wednesday, October 14, 2009 10:14 AM To: dstar_digital@ <mailto:dstar_digital%40yahoogroups.com> yahoogroups.com Subject: Re: [DSTAR_DIGITAL] Beeps This is correct from my experience, and it makes sense from a "systems design" standpoint, also. Read on. Starting with an additional data point/example, if you remove the RPT2 route to the Gateway from your radio, you won't receive a confirmation transmission from the Gateway, and thus... one beep only. If you use direct callsign routes, the original way the system was designed/engineered, the behavior is also slightly different. The second transmission from local repeater (beep) w/confirmation that the transmission properly routed, takes longer because it's a confirmation that the Gateway on the FAR END received and routed the transmission, not just a "I don't know who you're trying to route to, but CQCQCQ doesn't exist on any Gateway". The latter being the actual message that's being sent in the "second beep" that most folks are seeing in the 2nd beep in a D-Plus linked QSQ. In a callsign route, useful information is passed back to the end- radio-user in that second (beep) transmission from the local GW/ repeater. In D-Plus linking, the software is not FULLY integrated in its implementation, and has no control over that reply transmissions, and D-PLUS can "see" if it routed to the far-end or not, but has no mechanism for reporting that back the the user. It only reports connectivity in it's logs, accessible only to the GW admin. The original design passed that information all the way back to the end-radio-user. It's actually a desirable feature, and both conveys information directly, and also indirectly about the quality of the link. (Lots of errors, or slower/faster gives clues to connectivity problems, even if they're not explicitly shown in data.) Sadly, so few people actually try out/use the original callsign routed mode... that it's easy to see how the double-beep makes less sense, than it does when the system is used as originally engineered. And it's hard to see how it was well-thought-out/designed the behavior is, by observing it. It should be a confirmation transmission from the far-end saying, "Your transmission made it here, so you have a reasonable expectation that the person you're calling/talking to, heard it." In a D-Plus QSO, there's zero confirmation that anything other than the local GW computer heard your transmission. Not knocking it, but it's one magnitude less "informative" than the much-maligned, originally-engineered design. Nate WY0X On Oct 14, 2009, at 7:52 AM, Robbie De Lise wrote: > As I experience it i think something like this: > > No beep: The repeater did not confirm your TX, prolly no RX on the > repeater side > 1st beep: The repeater (CALL A, B or C) confirms your TX > 2nd beep: The gateway (CALL G) confirms your TX. > > Ofcourse, when someone pushes the PTT right after the BEEP or before > the BEEP, > the repeater does not have the time to send the confirmation out. > (The confirmations are send seperately from the DV transmission) > > so: > > DV TX > stop TX > Confirm Repeater TX (BEEP) > stop TX > Confirm Gateway TX (BEEP) > stop TX > > if someone pushes the mike faster its like: > > DV TX > stop TX > Confirm Repeater TX (BEEP) > stop TX > DV TX > stop TX > Confirm Repeater TX (BEEP) > stop TX > Confirm Gateway TX (BEEP) > stop TX > > or even: > > DV TX > stop TX > DV TX > stop TX > Confirm Repeater TX (BEEP) > stop TX > Confirm Gateway TX (BEEP) > stop TX > > > > I could also be completely wrong :) > > Let me know if someone else has the same experience. > > 73s > Robbie > > > On Wed, Oct 14, 2009 at 3:42 PM, Fran Miele <f...@miele-family. <mailto:fran%40miele-family.com> com> > wrote: > > > Several of the users on our system have been discussing the beeps > heard on a repeater and it is clear we really don't understand them. > > > I'm sure this has been asked many times before but I can't seem to > find a definite answer. Can someone explain the beeps that are heard > at the end of a transmission on a repeater? Sometimes there are two, > sometimes one and sometimes none. > > > What do they mean, and why the variation? > > > Thanks in advance, > > > Fran, W1FJM > > ------------------------------------ Please TRIM your replies or set your email program not to include the original message in reply unless needed for clarity. ThanksYahoo! Groups Links
<<image001.gif>>
