[drats_users] testing report from tonight on Beta-7

[Dan Smith]

> - Dan, did you put the "temporary fix" in both the fixed size and
> the ascending size Connectivity Tests?  It's acting like the
> ascending size isn't fixed for the multiple rig support, but I'm not
> sure on that.

Hrm.  I only tested the fixed size, but expected the other to work as
well.  I'll have to check.

> - KF0RW and I are able to send messages back and forth.  We both
> upgraded from Beta-5 to Beta-6, and then to Beta-7.  W0RMT upgraded
> direct from Beta-5 to Beta-7 (if that matters) and when I send
> messages to him, they never show up on his Messages window, but the
> Event Log on both ends says the messages were transferred
> successfully.  Is there a path thing of some sort going on here?

Oh, hmm.  I can think of something that needs checking relating to
that, so I'll reserve comment until I take a look.

> - I've noticed for a while now that if the packet for the "response"
> between the "Waiting for Reply" and when a file or message transfer
> starts, gets hammered... the whole thing stops with "Transfer
> Interrupted"... but if packets get hammered AFTER that, the transfer
> code does retries, and eventually seems to get the message or file
> through.  Could the initial Negotiation also try a little "harder",
> maybe three times, before giving up?

I think the clear solution here is to time your packets better so you
don't lose that special one, no? :D

Definitely file a bug for that one.  It's really hard to test in one
environment and hit all those possibilities.  I try to use an FM HT to
take out selective bits, but it's a pretty inaccurate methodology :)

> - I attempted something that never has really worked all that well,
> and it relates to the above request, I think.  We had Bud W0RMT
> start a file download from my station, and at the SAME time I tried
> to send a Message to Steve KF0RW.  The initial negotiation of the
> message transfer gave up with "Transfer Interrupted" because the
> frequency was already busy with W0RMT's station and mine going back
> and forth with the file transfer.  It would be nice if multiple
> stations could do multiple things and it would just "take longer"
> but not give up... or at least not give up quite that easily.  I was
> eventually able to stuff the message through with three "Send"
> attempts during the relatively large file transfer, but it had to
> make it past "Negotiation Completed" and get the message transfer
> thing going before it then has retries and other "error correction"
> working for it.

Here's the problem with that.  The two second delay between keying the
repeater on the input and your signal coming out of the output makes
that possibility nearly, well, impossible.  It's the
hidden-transmitter problem made worse by a fatal "hiding" of every
transmitter on frequency.  Without resorting to a tokenized system
where one station controls who can transmit and when, I don't see that
improving much.

It works much better on simplex when everyone can hear each other, and
I'd be willing to work on making that scenario better, but very few
people seem to use it in that capacity.

> - During a voice discussion the other night, someone mentioned that
> it would be REALLY nice in true emergency type comms to be willing
> to set a setting where EVERYTHING is heavily error-corrected, which
> of course eats up bits in the already tiny 1200 bps... but we were
> generally discussing the topic, "Do you want it ultra-reliable, or
> do you want it fast"?  We were both saying that with Icom's voice
> implementation so HEAVILY error-corrected, there would be times when
> it would be nice to do the same to data transfer in software.
> Someone could have an extremely sucky signal, but there would be a
> bunch of software-driven FEC in the low-speed data stream (making it
> ULTRA low speed, we understand...) that the messages or files would
> eventually get through.

Well, this is certainly something to experiment with.  I don't know
enough about the real behavior of various FEC algorithms to know how
well this will work.  One thing about voice is that you can just drop
entire packets here and there and it only starts to sound a little
rough.  That doesn't work very well with a reliable data transfer
where you're dropping bits of a file and possibly control messages.

However, after Dayton (and some other things) cools off, I'll see
about cooking up a test program we can use on some shaky connections
to see if it's doable.

> - Another thought I had one night was whether or not there could be
> an "ACK'ed" chat mode... I think you also had something similar to
> this in Version 1 Dan... where you could set up a list of stations
> that MUST receive your chat messages, and your station would keep
> track of who in the "group" had ACK'ed the chat message.  Maybe
> that's another way in the future "wishlist" item?

I think you're thinking of the multicast file transfer.  I've always
planned to have a one-to-one ack'd chat capability, I just get annoyed
at the GUI organization when trying to do it, and move on to something
more interesting.  I think I justify it by saying that if you need to
send an important message to someone and make sure it gets there,
shove it into a memo form :)

> Brian of "D*Chat" fame was on-air on REF014C driving home the other
> night and he was joking that he should "just drop D*Chat support"
> since everyone was talking about D-RATS Dan.  Heh heh.  He was
> obviously kidding, but one comment he DID make was that he thought
> he should take a look at your packet format and see if he could get
> D*Chat to copy D-RATS chat packets.  If you have the format
> documented somewhere, you should toss him a copy of the packet
> format maybe... don't know how serious he was, but interop between
> the "ultra-simple" chat program and the more "advanced" D-RATS would
> be nifty, I suppose.

I've talked about it with him before, I documented the frame format
online and never heard back:

  http://www.d-rats.com/wiki/DDT2Protocol

What is there is enough to send and receive chat packets.

> Have fun... sure looks like you're coding your brains out, perhaps
> as a run up to a "Dayton Release" with new features for 2009?  :-)
> ;-)

I'd liked to have 0.3.0 done for Dayton this year, but it just isn't
going to happen, of course.  I will be using it for demos, though, and
telling people that this is what is coming down the pipe.

Thanks!

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