Re: Message acks
On 10/29/2013 5:53 PM, Denis wrote:
I just sent you a message on HF and your station sent about 8 ACKS back in one transmission.
Yes, and thanks for bringing that to my attention. My KJ4ERJ-2 instance is an interesting test platform for 30m HF APRS. Here's the deal...
The APRS spec says that clients should send an ack for each copy of a message that is received. There is no specification for duplicates, and in fact, when you think about it, just because a client has already acked a given message doesn't mean that the sender received the ack, so if the message is received again, even though it is already known, it's likely a retry and therefore a new ack should be sent to satisfy the originator.
The spec (somewhere) further recommends that a double-ack be fired on message reception on RF. 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: