Dan, One of the issues when repeaters are connected to the reflectors is that there is a significant delay between when you finish transmitting and when it is safe to start transmitting again. In general, the delay is about 6 seconds. What happens is that the VOIP data stream has to clear all of the way out of all of the queues before you can safely start streaming again. In a reflector situation, you have the source gateway, reflector, and the destination gateway all queuing the signal.
In most instances, if I am transmitting and I quickly drop my carrier (as would be common by shifting your hand on the radio) for less than even a second, any additional transmissions will be lost, just thrown into the bit bucket. The implementation of data out of the controller is half-duplex, but the radios are of course full-duplex. That just doesn't mix that well. In testing 0.2.4, it doesn't seem as if you ever recognized the start of transfer message. But even if you did, you'd need to wait about 6 seconds before responding, or else the transmission will never get back to the source. In addition to the file transfer, it seemed as if there were a fairly high number of instances where the leading bytes evidently got stripped off, which of course meant the message was lost. The remainder of the message seemed to be 100% copy, so I don't think that it was noise related. Just for your info, Hurricane and Weather updates were being sent numerous times during the net. These are copied off of another data source and then pasted into the itsy bitsy transmit window. Having some method to make the end to end process more efficient would be nice. It's not as much the original cut and pasting as being able to see and manipulate the received message. Something along the line of a different type of form that you can just paste the data into and hit send, with no specific destination would be nice, a broadcast message. And then have the option to ring bell and blink screen at the receiving stations. From: dstar_digital@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Dan Smith Sent: Tuesday, September 02, 2008 6:43 PM To: dstar_digital@yahoogroups.com Subject: Re: [dstar_digital] D-RATS Problem > 2) Any errors in the non-error-corrected 1200 baud data -- e.g. > You're not REALLY all that solid into the repeater, compound VERY > quickly to kill the whole session. Shortening the packet size > considerably gives that individual packet a much higher chance of > success when you're on the fringe, and Dan's recovery code can > sometimes "fix" things if you can get "most" packets through without > error. Yeah, that's pretty accurate. The new pipelined transfers in 0.2.4 (yes, the broken one) actually send smaller packets, but several at at time, which makes it easier to recover. I could add in a FEC scheme, but I really doubt the usefulness at 1200 baud. The speed is so slow as it is, I think it would slow down solid users and just exacerbate the issue of not having a good enough signal. > Another thing that causes D-RATS some trouble, as well as other 1200 > baud application software is the "bounce-back" of you hearing the > tail end of your own transmission. This is inherent in the > repeaters... there's some delay between reception of your signal to > the repeater and re-transmission. You can see this when using an > older chat program like D*Chat also... you see your rig unkey, and > you get a snippet of your last text message back in your received > data. This is really old information (well, the effect on D-RATS bit anyway). In v0.2.x, everything is packetized. Echo is just garbage and D-RATS treats it as such (unless you tell it to pass garbage to the chat window). Version 0.1.x added "echo cancellation" as a stop-gap, but fully-packetized data transfer is definitely the way to go. > We DID eventually transfer some files via D-RATS via the repeater, > even on that older version many weeks ago... but the settings had to > be "just right" and the path from both stations had to be FLAWLESS > (no garble of callsigns or other data EVER) to/from the repeater. It > wouldn't recover (back then) from individual data errors properly, > and the stations participating would go into never-ending timeouts > until they timed out and gave up. I really can't comment on gateway activity, but with 0.2.x I have done a fair bit of testing with clobbering the transmission. Keying up another radio in FM mode on the same frequency seems to do pretty well :) I think there is a fine line between too much retry logic and knowing when to give up, especially when you're tying up a voice repeater for other people. As the logic progresses, it should be easier to determine when the magic "give up" point is, but right now, it's relatively pessimistic. I'm sure your voice users will appreciate that :) -- Dan Smith dsmith#danplanet.com, s/#/@/ www.danplanet.com KK7DS [Non-text portions of this message have been removed]
