Re: Message acks (delayed ack)


Robert Bruninga
 

Ø  The APRS spec says that clients should send an ack for each copy of a message that is received.

 

Yes,

 

Ø  The spec (somewhere) further recommends that a double-ack be fired on message reception on RF.

 

The actual recommendation was to “schedule a duplicate 30 second delayed ACK”.  I use the word “schedule” to mean that if say 3 copies of a message come in within 29 seconds of each other, then 3 ACKS are sent immediately, and all three set a 30 second timer for a delayed ack (BUT are not buffered).  Meaning, there is only one timer that is reset to 30 on each message received so no matter how many dupes were received, only the last 30 second delayed ACK goes out.

 

This was intended to prevent a piling on of ACKS but to assure that ONE dupe would go out 30 seconds later after some momentary channel problem had cleared.

 

Hope that helps.

Bob, WB4aPR

 

   This "improves" the chances that the ack is received by the sending station.

APRSISCE/32 is coded to do all of the above.  Acks are triggered for every reception of a message, regardless if it was received and acked before, and a second ck is fired on RF ports (RF-Only on the second one).

Enter KJ4ERJ-2, my 30m HF APRS test instance.  I have it configured with the following ports.

DireWolf - via TCP/IP and an AGW-type port
DireWolf KISS - via TCP/IP and a KISS-type port
UZ7HO's SoundModem which is running both channels offset +/- 25hz (1675 and 1725 configured)

Both DireWolf and UZ7HO are talking to the same "SoundCard" which is actually a SignaLink USB connected to a single iCom 706 tuned to 10.147.60 USB.

So for every packet received, KJ4ERJ-2 receives up to FOUR copies of it, provided that it was decoded by both DireWolf and both channels of UZ7HO.  Some packets are slightly off frequency and are only decoded by one channel of UZ7HO, so I only get three copies of those packets.  And others, for various reasons that I'm still observing, are only decoded by DireWolf or only by UZ7HO, one or both ports.

But back to the point of this posting...  Couple receiving four copies of an incoming message with the double-ack and put it all in a near instantaneous time frame and you have 8 acks being transmitted in a single burst.  These are all sent via the first (25hz low) channel of UZ7HO since I have both DireWolf ports Receive-Only because I don't have any COMM ports to hand it for PTT and I haven't seen how to configure DireWolf for VOX which is what the SignaLink USB looks like.  UZ7HO handles transmitting through the SignaLink with aplomb.

So, to "fix" this non-bug (since it is WAD - Working As Designed and only occurs on multiple ports on a single frequency) redundancy requires the following:

1) Send acks only on the port from which a message was received along with APRS-IS (if messaging is enabled).  This requires that APRSISCE/32 internally track the reception port.  Acks are currently issued after all incoming has merged into a single packet flow and they no longer "know" which port they came from, only if it was RF or -IS.  Also, APRSISCE/32 doesn't currently have the internal ability to target outbound packets (like acks) to a specific RF port.  It can do -IS vs RF, but not target a specific RF port.  This is all due to my naivity when implementing RF ports, I never imagined multiple ports into a single APRSISCE/32 instance and still recommend against it for most installations, hence this poll http://tinyurl.com/l82p273 (see below).

2) Support individual configuration and enable flags for multi-port devices like stereo SignalLinks.  Without this, acks are not able to go out the "second" port of a SignaLink.

I've got this all in mind, but am currently trying to stabilize APRSISCE/32 development loose ends so that I can release a new stable, general release.  Once that gets out the door, I can rip into the internals to try to do some of this stuff.

But I was truly amazed last night at how smoothly the QSO flowed with HF/RF only!  (See http://aprs.fi/?c=message&call=KJ4ERJ-2 from 10/29 17:49 through 23:18)  Thanks for that opportunity., outside of when my radio locked in transmit for more seconds that I was expecting due to the ack burst(s)!  You should have seen my mouse ripping around the screen trying to figure out what locked up.  My finger was actually on the 706's power switch when PTT finally released on its own.  I just got the radio back from repair (blown finals, SWR-sensing diodes, and the stupid pad corrosion causing it to not power up (http://www.n1eq.com/tech/page_03.html)), so I really didn't want to do something stupid within the first week of operation!

Most RF installations (hopefully) aren't running multiple ports to a single radio, so they won't suffer from the packet multiplication effect on message reception.  Now that I'm aware of the "feature", I'll try to remember to disable the DireWolf ports to reduce the duplications when in a QSO.  I normally keep them all enabled to compare the decode capabilities of the various soundcard soft TNCs.

Lynn (D) - K4JERJ - Author of APRSISCE for Windows Mobile and Win32

PS.  On 2m RF-only, you'll see similar behavior if your station receives an incoming message and shortly thereafter a digipeated copy of the message.  Double-acks will be sent for each reception, but 1200 baud is so much faster than 300 baud that the behavior has not been noticed, or at least, not reported.

PPS.  The Poll mentioned above (http://tinyurl.com/l82p273) was:


How many concurrently active RF ports do you use per APRSISCE/32 instance?

ldeffenb

 

55 Votes

 

August 3, 2012

 

Never end

Zero. I use APRSISCE/32 on the APRS-IS only.

11% (6)

One. I only have one radio/TNC/interface.

55% (30)

One. I run separate instances for each radio/TNC/interface/frequency.

24% (13)

Two or more, and I'm anxious for cross-port repeating too!

11% (6)

RF? APRS does RF? I thought it was Internet based.

0% (0)

Other - Details sent to the group.

0% (0





Join APRSISCE@groups.io to automatically receive all group messages.