[drats_users] Field use & questions

[Dan Smith]

> I don't understand how making the window size larger will help 
> communications.  Obviously I'll see more on the larger screen,
> but... 

Hah, you almost had me there for a second... :)

> OK, just kidding.  I know these parameters are in Transfers and
> Tuning.  Is there something already written up on their usage?

It's been discussed here a couple of times, but not formally
documented anywhere permanent that I know of.

Here is some explanation of it, grafted from the list archives:

| 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.

Note that the "pipeline blocks" setting is the window size.  I really
need to rename that in the UI.  If the above makes sense perhaps we
can post it on the wiki somewhere for future generations.

> This would be a help.  Could it somehow be a bounce, where both
> directions get tested?  ACKs are short, and don't tell much. Then it
> only takes one operator to do the test while the "far end" can do
> other tasks until asked to change frequency, or see the file.

Yeah, I figure it can behave the same way the forms and files do,
where it's considered a remote request to initiate a ping (which
effectively pushes the buttons on the remote machine on behalf of the
operator).  That way, I can easily add another check box in the config
to allow you to prevent remote stations from causing you to do a ping
(like you can currently disable remote stations from seeing your
files).

> OK, operator error.  At least we tried...

I'll share the blame with you 50/50 since the GUI is utterly confusing
and doesn't help the operator do the right thing :)

> But what about the couple of cases where it just sat there...  no
> "Transfer Interrupted" or anything?  Sorry I can't supply much in
> the way of details, but I'd hit send, then walk off to do other
> chores, come back to see what's going on.

Yep, it's hard to say in that case.  If you make a tiny bit of
progress now and again, it will continue marching forward and appear
to have stalled if you come back after a while and expect it to be
done.  However, it's equally likely that something burped and there
was an error on the log.

> How long, or how many sessions of log might get kept?  Since I was
> on battery power I turned off the computer a couple of times when it
> clearly wouldn't be needed.

The log is cleaned each time D-RATS starts, so that it doesn't get too
big (and so it's not too confusing for me to determine old events from
new ones).  You'd either need to save the log before shutting down, or
after you restarted but before launching D-RATS.  Not very
user-friendly in the field, for sure.  I guess I need to figure out
how to make that easier.

> Probably not from these locations.  Just getting to the locations
> takes a minimum of an hour (for me, 2 1/2).  For example, load these
> coordinates into Google Earth: 37 23.544N 121 29.406W This is where
> my car was located.  The only reachable voice repeater was 8 miles
> away to the east, and I put this temporary voice repeater there
> about 2 hours before I need to be at my stop, then at the end of the
> day, pull the voice repeater down.

Ah, okay.  You're really pushing the limits of D-STAR propagation, I
guess.  Pretty impressive :)

> Some of the Hams testing D-RATS within 10 miles of the repeater had
> a much more difficult time getting data through.  Again, knowing how
> the tuning parameters adjust stuff will be a help.

Yep, but multipath will kill you even with a strong signal and a
stationary transceiver.  Occasionally just moving a hundred feet from
a given position will improve things because of some reflection taking
you out.

It's too bad the radios can't show the error rate on the display.
That would make it easier to determine if there's really any chance of
getting data through.

> We are planning on doing a much nicer and larger write-up.  I know
> I've had D-Star for almost 3 years, and it keeps getting better.

Great, be sure to drop us a link here when it's up...

Thanks!

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