ashim at shell servo

The message “ashim at shell servo” must be an important one.

I have heard VK2UBQ-9 sending this message to VK2XSO-5 for many months, a couple of hundred times a day when VK2UBQ-9 has his radio switched on.

The intended recipient was last reported on in May 2014, seven months ago, yet the APRS system is still wasting bandwidth trying to deliver this message, presumably waiting for a delivery acknowledgement.

VK2UBQ is located 8 hours drive from here, VK2XSO-5 was last heard 12 hours drive from here so you might ask why this message is repeated three times every two minutes on air here.

Is this VK2UBQ’s fault to resending this message?

Is it VK2XSO’s fault for not being available to receive the message and acknowledge it?

In my view, it is the fault of the APRS infrastructure that exposes the system to traffic that has little or no worth but occupies valuable bandwidth. Evidence of the design failure of APRS messaging and the failure of infrastructure to ignore such traffic and limit its impact.

There are staunch advocates of APRS messaging, but the simple fact is that in a network with limited bandwidth that uses UI packets without any higher level confirmation for position reports (posits),  and has no method of prioritising traffic types, non posit traffic degrades real-time posit performance… they are fundamentally incompatible traffic types on this type of network infrastructure.

Expansion of APRS to generalise the traffic types has made sure that it is worse than mediocre for position reporting. Little wonder there is growth in mobile phone APRS-IS applications that report position direct via the public telecommunications network.

Isn’t APRS so dumb?