KD0TLS: A note on the Kenwood D710 digipeater function

  While we have a few digipeaters in the metro using the Kenwood D710 rig (and variants of it), there are probably other digipeaters out there in other parts of the world using that rig. 

 There's nothing wrong with using a D710 as a digipeater. It has native APRS, an internal TNC, and it's easy to put a digipeater on the air in minutes. 

 But -- especially with the older variants -- they weren't designed for APRS as it exists today. The good news is that they can easily be adapted to make a strong contribution to the network wherever they are on-air. 

 APRS messaging has grown exponentially over the past few years. The D710 stores received messages that it digipeats in a buffer. When that buffer is full, the rig's TNC starts issuing rejects. 

 I'm just speculating, but I think the design was intended for the rig to be used for short-term service as a digipeater. In that case, the operator would want to be able to see all of the message traffic that it passed while in service. That's why the internal TNC stores all messages received in a buffer within the rig. 

 Just in the last five days, my indoor gateway has picked up nearly 500 messages being transmitted across the metro. I'm sure that iGates with better coverage see far more messaging traffic than that. That wasn't the reality ten years ago. 

 Ack and rej 

 When an APRS message is sent over RF through a gateway, an "ack" is issued if the sending is successful. Most APRS client software will request an "ack" automatically. Some client software will allow the sender to request, or not request, an "ack". 

 Things like bulletins and QST messages should not use an "ack", and the client software will usually not automatically request one in those cases. 

 An "ack" is an acknowledgement. It means that the message has arrived at the intended recipient's station. If the recipient is not a messaging-capable station, the sender will not receive an "ack". An "ack" does not mean the message has been read; merely that it arrived. 

 So... an "ack" is a gateway telling you, "I have successfully transmitted your message to the intended recipient". 

 A "rej", or reject, is a station telling you, "I refuse to handle your message". This is quite different than a failed "ack". The recipient could very well be valid, and even expecting your message. Instead, a "rej" is a gateway or digipeater refusing to even pass your message on any further. 

 A "rej", or rejection, is the gateway or digipeater's TNC telling you that something is seriously wrong with the message you sent. It might be a bad N-path, an invalid recipient (e.g. "4"), or the packet has become garbled and can't be salvaged. The gateway or digipeater is simply unable to move your message any further, and it's given up. 

 Of course, that same message might reach another gateway/digi intact, and be passed on. It may even issue an "ack". 

 The D710 reject, and the solution 

 However, when a D710 (or some variant) issues a "rej", it usually means something different. Instead, it means that the buffer that's storing messages internally is full, and the TNC can't move forward with your message. 

 While I don't have a Kenwood D710, I have contacted people who do. They tell me that the buffer can be cleared with a reboot of the rig. Apparently, the newer models either have a larger buffer, or they don't store received messages. 

 Fortunately, we have several gateways and digipeaters in the metro that will pass on APRS messages that a D710 digipeater rejects. But, there may be situations elsewhere in which a D710-style digipeater is the only option for RF-based messaging. 

 The answer in these cases is for the operator of the digipeater to reboot the D710 rig on a regular basis. 

 The fallout 

  APRS messaging is new to many operators, and the idea that they are "doing something wrong" is understandable. Further, things like APRS Thursday have served as a kind of "stress test" on many local networks. Infrastructure elements that have served well over the years suddenly aren't up to the task. 

 For months now, operators have seen their APRS Thursday messages get reject messages in various parts of the world. Even long-time hams who are dipping their toe into the waters of packet operation for the first time can become discouraged by finding their packets rejected by a local digipeater. 

 Usually, these digipeaters are tracked down and the operators are advised to maintain them properly. 

 I would rather not see operators that are otherwise conscientious and community-oriented be blamed for something that isn't their fault. 

 Wherever you are in the world, if you use a D710 rig as a digipeater, please reboot that rig on a regular basis.