PingAck should also send ID

[cbs228]

A PingAck frame contains:

1. frame type
2. SNR
3. quality
4. two copies of (3)

The PingAck does not include the transmitting station's callsign. On receipt of a Ping, an ardopcf station will send a PingAck, but it does not send any ID—either immediately or after any reasonable delay. This likely does not meet FCC station identification requirements.

To meet FCC requirements and best practices, I think ardopcf should transmit an IDFrame a "short time" after sending a PingAck. The ACKing station should wait "long enough" to make sure no more pings are incoming.

The Ping frame itself contains the sending station's callsign, so it does not have the same problem.

We might also consider appending the ID information (and some reed-solomon coding) to the end of the PingAck frame. This would likely require a protocol revision, however, so that is definitely a long-term solution. An IDFrame with optional CWID would be backwards-compatible with all implementations.

[pflarue]

I had not previously considered this, but I agree that a station that has sent a PingAck should follow up with an IDFrame.

I suspect that Ping/PingAck frames are most commonly used in FEC mode. In that case, perhaps the ID handling already implemented for FEC mode is sufficient. I don't recall exactly how that is handled. If it is already handled there, then it might be necessary only to implement a change that is triggered when a PingAck is sent while ProtocolMode is ARQ.

An alternative would be to require host programs to ensure that an IDFrame is sent after a PingAck has been sent in response to a Ping. However, since ardopcf will send a PingAck even if no host program is connected, this would not be an adequate solution.

I agree that it makes sense for an IDFrame sent after responding to a Ping to be delayed to allow time to hear and respond to additional Pings sent because the station sending them failed to decode the first PingAck. I also suggest that the IDFrame should not be sent while the busy detector is detecting other traffic. It might be possible to reduce the likelihood and duration of a delay due to the busy detector by temporarily reducing the ARQ bandwidth setting (used by the busy detector), and then resetting it to its prior value after sending the IDFrame.

While I would also prefer that the PingAck contain some additional information, I will not accept any changes which would make ardopcf transmissions incompatible with other Ardop implementations. However, it might be worth exploring whether additional data symbols could be added to the end of a PingAck or other frame type without breaking compatibility. I believe that a receiving Ardop station ignores anything after the expected end of a frame, such that additional 4FSK tones would not cause any problem. For frame types used in ARQ connections, this would disrupt the expected timing, but that would not be a problem for a PingAck. If this is possible, it would be necessary to also adjust ardopcf to facilitate decoding of both standard and extended PingAck frames.

My dislike of the current contents of a PingAck is that the only way to associate a PingAck with the Ping it is responding to is by its timing immediately following the Ping frame. I wish that it contained some additional data to make this link more definitive. A minimal solution to this would have been to use a session ID derived from the two callsigns for the PingAck frame rather than using the generic/FEC session ID of 0xFF. This would also require the station sending the Ping to temporarily listen for a response with that session ID. So, while this would be a minor change, it would break compatibility and thus will not be implemented in ardopcf.

The ability to correct (with RS) or detect (with CRC) errors in some non-data frames is something that might be considered for future protocol developments that break compatibility with Ardop (and thus take a new name). It does not make sense to do very much error correction for most short non-data frames because if these non-data frames require much error correction, then data frames, which mostly use less robust encoding, are unlikely to be usable. The repeated 3 copies of the data carried by a PingAck do provide some error correction capability, since it is assumed that if any two of the three copies match, then they were correctly decoded. This is useful since it allows a station to correctly decode a PingAck when conditions are marginal. In that case, the poor results carried by the PingAck may prompt the user to try connecting on a different band or to wait for conditions to improve.

[pflarue]

PR #105 provided a partial fix for this Issue. PR #106 provides a better solution. Those PRs have been merged into the develop branch, and will be merged into the master branch when the next release of ardopcf is produced.

WIth those changes, an IDFrame will be sent soon after a PingAck is sent. The callsign used for the ID will also match the target callsign from the received Ping. If additional repeated Pings are received because the station sending them failed to decode the PingAck, then the ID will be deferred until the repeated Pings have stopped. If CWID is set to TRUE by the user/host, then a CW ID will also be sent after the 4FSK encoded IDFrame.

I'd prefer that the PingAck frame also be identifiable as related to a specific set of Pings, which is not entirely satisfied by this fix. However, these changes do provide a good solution to the legal requirement to send an ID, and they do so without breaking compatibility with other Ardop implementations. The IDFrame sent after the PingAck does not currently provide an automated mechanism for the station which sent the Ping to confirm that the PingAck received was indeed from the target of the Ping. However, the contents of the IDFrame received soon thereafter can be reviewed by the user to provide this confirmation.