> 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

Reply via email to