[drats_users] Rig Control & D-RATS

[Dan Smith]

> Can you explain the tweaking, warm up, and pipeline settings in brief  
> for me. 

I'll explain what they mean and let Dave share his preferred values.

There are two warm-up related values.  The goal of the "warm-up" is to
prime the data stream with something before the real data is
transmitted.  I initially added this to defeat the power save feature on
the handhelds.  After a while, they go to sleep and only wake up every
few hundred milliseconds to see if something is being received.  By
prefixing the data you're transmitting with enough pad, you can wake
them up before the real data comes across.

The "Warm-up timeout" setting specifies how long since the last
transmission before deciding to transmit a warm-up block.  If you last
transmitted a half-second ago, then the handheld listening hasn't gone
to sleep yet, so there's not much point.  If you set this to, say, 5,
then a warm-up block will only be transmitted if you haven't transmitted
in the last 5 seconds.  If you set it to 0, it will always be
transmitted before any real data (which will slow things down, of course).

The "Warm-up length" specifies how much data goes in the pad itself, and
thus depends on how long you must be transmitting before the remote side
will wake up.

Unrelated to warm-up, there is also a "force transmission delay" value.
 This lets you tell D-RATS to *always* wait a certain number of seconds
before transmitting anything.  No intelligence, just a delay.  This
will, of course, slow things down a *lot*, but can be helpful to make
sure D-RATS doesn't start transmitting too quickly after receiving a
transmission, which can help avoid collisions gateway connections, I
imagine.

The pipeline settings shouldn't really affect how things go across the
gateway, but they do affect how quickly the file transfer logic can
recover from a bit of corruption, and how long your radio transmits
before asking the remote end for an acknowledgment.

The "block size" setting defines the largest chunk of data that will be
sent with a single checksum.  If you have a single bit error, this is
the minimum amount of data that will have to be retransmitted.  The
larger this value, the less overhead, but the more you have to
retransmit in the case of a bit error.

The "pipeline blocks" setting controls how many of the above blocks get
sent at a time before asking the remote end for a status report.  If
"block size" is 256 and "pipeline blocks" is 4, then each time we
transmit, we will send 4x256 = 1024 bytes of data.  When those are sent,
the receiving side responds with a list of blocks it received.  If only
two of the four were clean, then the sending side sends the original two
blocks, plus two more (since the pipeline is set to 4) and the process
repeats.

Dave (et al), I'm not sure if you've played with the new suspend/resume
stuff, but I imagine this will be helpful for gateway operation.  With
that, you can transmit a piece of a file, and then pause it to handle
some voice traffic.  Then, you can resume it and transfer some more,
pause for voice traffic, etc.  It should make getting a large file
through a single channel much more doable than if you have to make the
whole thing in one go.

Wow, that was a lot of text.  I think I'll shut up now :)

-- 
Dan Smith
dsmith#danplanet.com, s/#/@/
www.danplanet.com
KK7DS