[drats_users] Field use & questions

[Arnold Harding]

I have some questions, but I'll say a little about what we did first.

Our club, Livermore Amateur Radio Klub, just finished supporting a 206 
mile with 20,000 feet of climbing bicycle ride.  There were about 190 
riders.  We used D-RATS from 3 rest stops to relay rider data back to 
the net control location.  The farthest station from Net Control was 
35 miles, and that station is on the side of a mountain and almost has 
line of site to the Net Control station.  We transferred data the best 
we could considering the resources available at each end;  Sometimes 
2m, or 440 or 1.2g.  Radios and antennas were also tied up with other 
communications including voice, so everything was not always 
available.  We were able to use several combinations of single 
repeater, and/or linked repeaters and in one case a simplex transfer 
of files to a station that could relay was required.  It worked, we 
got it done and it was successful, but we had issues.  We're planning 
on doing a larger write-up, but I need to ask these questions first.

One of the first comments I received is as follows:
"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.  On the other hand, the fact 
that you can use the same repeater for voice and data is nice on 
D-STAR, even if we didn't really use that feature at the event.  The 
strong signal issue comes up primarily due to our event coverage being 
commonly in very marginal areas.  Fill-in digis are a lot easier to 
put in that fill-in dstar systems."

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.  Only when 
it is unsuccessful do we discover that this path and frequency aren't 
the best.  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.

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.

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.  Another attempt was "Transfer Interrupted".  Sending it on 
440 simplex got it to the 'middle station'.  The middle station was 
unable to transfer it to Net Control, and after several attempts, 
since both stations had higher priorities it was not attempted again.

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?

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?

Unfortunately our priorities were with the event, and not with D-RATS 
so we don't have any log files.

Plain old Packet would have been more reliable, but more equipment, 
radios, and adjustments would have been needed.  D-Star with D-RATS 
got what we needed accomplished, even with the problems.

Arnold
KQ6DI