[drats_users] Test patterns

[Dan Smith]

> Rather than spending a bunch of time trying to find out if a path
> might work with a bunch of test patterns, wouldn't it be more
> efficient to just try sending the file?

To some extent, yes.  However, some more advanced logic can help you
determine the proper packet size for the tuning section.

> Sure, we can determine what bits got blown if we want, but what's
> the point.

I think Nate was also looking for a metric by which he can say to a
user on the fringe: "Hey, you're only making it about 50% of the
time".

> If we do a medium size ping and reply (my request), and get a decent
> reply, then go for it.  If the medium ping doesn't work that well,
> then try something else.  I think that's the point of Pipeline
> parameters; to do the retries to get the message through.  The only
> way you can ever expect to get a perfect message through every time
> is to have a direct coax or fiber connection from end to end.
> Rarely will you ever have a perfect connection.  If you are really
> trying to get a message through, and spend an excessive amount of
> time testing everything, then the message will never go, but you
> will annoy everyone else wanting the frequency.  (Just s--- and get
> off the pot.)

Yep, I don't disagree with any of that.  However, with the goal of
understanding propagation conditions, repeater signal quality, etc, I
think building this tool into D-RATS is useful.  I have a bunch of
scripts that I used in the early days and I occasionally get them out
to measure a particular connection even now.

I wouldn't expect anything too advanced to be used on a regular basis
(like before you try any sort of transfer), but it should be helpful
for diagnosis.  But, as you say, it really only matters if you can get
*real* data through :)

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