[drats_users] Field use & questions

[Dan Smith]

> "Thing 1 is that D-STAR data seems to like really strong signals in
> order to actually cause the checksums to match.  It almost seems
> like without line of sight anything except 2 meters is a real
> challenge.  I think packet is more resistant to fading.

This is true.  Remember that D-STAR is transmitted at 4800bps, even
though the data is only 900 or so.  This means that your signal is
significantly (4x) more susceptible to all the typical digital killers
than 1200 baud packet.

> We were all using D-RATS 0.2.11b3.  It seems that although we can
> Ping and Chat with a station, there doesn't seem to be any way to
> tell the quality of the data path until we try it by sending a file.

That's likely true, yes.  The ping (or chat) packet is very small and
can get through easier than a larger data packet that's more likely to
take a hit.  You can mitigate this by reducing your packet size (and
optionally increasing the window size).  This won't eliminate the need
for retransmissions, but it does mean that a smaller amount of data
will have to be resent for a given number of bit errors.

> Even when listen carefully to voice on that frequency/path and can't
> detect any oddities, it doesn't seem to give any indication as to
> the usability of that path for data.

Right.  The voice side has 100% error correction.  By the time you
detect *any* sort of voice quality degradation, the data side has been
unusable for quite some time.

> a) Can there be some sort of larger ping which can test the quality
> of a path?  The ping would need to send and return a large block
> each way, then give some sort of report.

Yes, I can add something to allow you to set how much padding goes
with the ping which will help (thus letting you send a bigger ping
packet to see if it gets through).  I can also do a more coordinated
multi-packet ping where it starts small and ramps up to some larger
ones.

> We tried to send a 16K picture file, and we never were able to get
> it through.  The simplex station originating the picture attempted
> to transfer it on 1.2g (low speed) and D-RATS got to 96% then just
> sat there.  Re-sending the picture had it get to 112%, but the
> picture was garbled.

This is because it tried to resume the picture when you re-sent it
using the image send tool.  If you had stopped it in the sessions
window and then attempted an actual resume of the temporary image
file, it would have gone through (from the sound of it).

The interface in 0.3 makes it easier to not trip over this particular
situation and it's something I knew would be an issue the way it was
implemented in 0.2.  I definitely don't fault you for attempting the
procedure that you did, because the 0.2 interface for this is quite
confusing (hence the work to make it better).

> b) We seemed to discover that we needed to re-name any large file to
> be able to attempt to re-send it, or it didn't seem to transfer
> properly.  Was this something we didn't understand, or something
> else?

This is likely because it would attempt a resume so it didn't have to
send the whole file again.  If you're sending a picture (or any file
that you have changed since the first attempt), then you're going to
hit the resume issue mentioned above.  Renaming the file makes D-RATS
think it's a different file and thus won't attempt the resume.

I've not had a single instance where the resume of a normal file has
not gone through as expected.  So, I assume you're hitting the above
scenario.

> Having a file transfer just appear to stop and have D-RATS just
> sitting there is quite frustrating.  "I didn't interrupt it, so what
> happened?" is the only thing I know.  Having D-RATS get to 96% of a
> file transfer, then stop without even an "interrupted" message just
> leaves us wondering.
> c)  What happened???  If it does say "Transfer Interrupted", by what?

"Transfer Interrupted" means that it gave up trying to get a packet to
the remote side.  It's completely an RF thing in that case, where it's
not able to get data through to the other end.  There's not much else
it can do in that case, of course.

> Plain old Packet would have been more reliable, but more equipment,
> radios, and adjustments would have been needed.

Well, unfortunately they have a 20+ year head start on me, what can I
say? :)

There are adjustments you can make, which may have helped (such as a
transmit delay and the block size adjustments mentioned above).
Locally, we have actually done very few transfers over the repeater,
comparatively.  This is usually due to availability, but also because
we have a solid 2m simplex connection between all the stations we care
about.  Simplex is faster and more reliable than the repeater, for a
given transmission path.

Do you have any plans to recreate some of the scenarios not under the
gun to perform for the event?  That may help us get a better handle on
what sorts of things to work on.

> D-Star with D-RATS got what we needed accomplished, even with the
> problems.

Thanks a lot for the write-up!  Real-life usage stories are *always*
welcome!

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