search

pflarue / ardop

Source for various version of ARDOP
Other
29 stars 5 forks source link

PingAck should also send ID #95

Open cbs228 opened 6 days ago

cbs228 commented 6 days ago

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 commented 5 days ago

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.