[aprssig] [APRS] CQ FD server
Pete Loveall AE5PL Lists
hamlists at ametx.com
Sun Jun 23 11:26:36 CDT 2013
It actually will send an ack for each retry by your client. If your client uses the message embedded ack format, the first ack will be part of the reply message (this is as it is defined). Acking should only be in response (either to a message or a message retry). Unlike original messages which are going to keep trying to get an ack. This prevents flooding of the frequency with unneeded acks (ack only if requested).
If the ack is part of a message (newer format) and that message is not acked by the recipient, CQSRVR will retry the message up to 4 times at one minute intervals (better for APRS-IS due to the 30 second sliding dupe window). This is also true for any numbered message from CQSRVR.
The messages sent out by CQSRVR to everyone part of a group (the message generated to the FD group members when you send CQ FD to CQSRVR, for instance) are unnumbered messages appearing to be generated by your station and gated to APRS-IS by CQSRVR. This ensures your client is not inundated with acks that are for a message it did not generate and it ensures the packets appear as though they came from RF and were IGated to APRS-IS by CQSRVR (keeps all direct messaging working).
In summary, single ack for each numbered message received (either part of a response message if the client indicated it was capable of processing an embedded ack or as a separate message if the client did not indicate it was capable of processing an embedded ack) which includes number message retries received by CQSRVR, up to 4 retries of numbered message responses sent from CQSRVR at one minute intervals (until an ack is received), CQ messages sent from CQSRVR are unnumbered (no acks) appearing to be received from the originating station and IGated to APRS-IS by CQSRVR. This properly follows messaging ack procedures (client indicates if it has not received an ack by retrying original message) and ensures that direct messaging between stations is not broken.
You are absolutely correct that the purpose of CQSRVR is to call CQ and then execute direct messaging with the stations you want. CQSRVR purposefully restricts, for the reasons you state, the ability to directly communicate via CQSRVR.
Hope this helps.
> -----Original Message-----
> From: Robert Bruninga
> Sent: Sunday, June 23, 2013 9:04 AM
> > No, you rarely get the ACK or the response, because the CQSRVR only
> > tries twice and it is usually lost in QRM,
> I hope Pete will correct me. I made that up just to make the point that we
> don't want to have the CQSRVR doing maximum retries everywhere on
> already busy channels. A CQ is not a required delivery message, It is
> somthing that might get through... just like in the real world.
> Ths is why it is so important for users of the CQSRVR to realize its only use is
> to find other calls of other similar stations playing radio at the same time.
> Then do ALL QSO's as addressed messages between the found callsigns. The
> reliability of addressed messages will be an order of magnitude better since
> now your messages will be retried as needed until successful and will not be
> adding to QRM all over the world, but just a few retries in your and his local
> Bob, WB4APR
> > Maybe what people do not understand is how that is really just for
> > CALLING CQ and seeing who else on the planet is also calling CQ. Then
> > when you see the other call, you are supposed to then send them an
> > APRS message addreessed to their actuall call so that you can exchange
> > or keep chatting.
> > Remmebr, once you know someone's call, you can communicate all you
> > want in real time. The CQSRVR message just lets you know WHO else is
> > out there live.
> > Bob, WB4APR
More information about the aprssig