[OZAPRS] Foundation and RF APRS

Scott Evans vk7hse at gmail.com
Fri Dec 20 23:10:06 AEDT 2019

For the Tier2 servers T2TAS & T2SYDNEY(I'm the sysop of T2TAS) they will reject all non verified stations. So if you forget to include your pass code then you will be ignored by the server for passing your traffic to the internet. I can't answer on behalf of T2QLD or T2PERTH (is that still online?) and for any of the ZL (New Zealand) based servers. Whereas I-Gates generally don't do any filtering. Only exception to this would be for RFONLY NOGATE to destinations.

I realise this is a little bit off the topic, but just wanted to clarify the Tier2 internet side of things...


VK7HSE Scott Evans

Get Outlook for Android<https://aka.ms/ghei36>

From: OZAPRS <ozaprs-bounces at aprs.net.au> on behalf of Mark Jessop <lenniethelemming at gmail.com>
Sent: Friday, December 20, 2019 10:49:05 PM
To: Australian APRS Users <ozaprs at aprs.net.au>
Subject: Re: [OZAPRS] Foundation and RF APRS

For positioning the use of an object is a good way of having a valid foundation callsign show up on the various mapping services. As you mention it still needs to be sourced from an AX.25 compatible callsign when produced via RF, but this could be a modified callsign as mentioned previously. If the source callsign is valid from an AX.25 standpoint, then it should make its way through igates into APRS-IS fine. Whether packets will make their way back *out* of APRS-IS into RF is another good question - I'm not sure what IS-RF filtering is used on the various TX-capable igates around Australia.
I'm not sure if any of the commonly available APRS trackers (be it standalone devices like the tinytrak/opentracker, or rigs like the various kenwoods/yaesus) support emitting of objects instead of position reports, so that will be a seriously limiting factor.
Anyway, the above is a possible option for getting packets out on RF that look show up nicely on a map or APRS-capable device and don't require additional poking around to find out the actual callsign. However, i suspect finding trackers that will produce objects instead of position reports may be difficult. (Hopefully I'm wrong on that!)

As for the APRS-IS passcode, well there's also an online calculator here: https://apps.magicbug.co.uk/passcode/
It's just a hash function... I guess the original designers of APRS-IS decided security-through-obscurity was good enough :-/

Mark VK5QI

On Fri, Dec 20, 2019 at 9:55 PM <vk7hse at gmail.com<mailto:vk7hse at gmail.com>> wrote:

APRS also has the option to add an object to a map, it is with this that you could provide the Foundation callsign. In most cases in the US where special event stations are in use they are not using the primary ax25 mycall as a station identifier but instead using the object to place the operators valid callsign. Now this doesn’t address the protocol layer restriction for ax25, as that’s hard coded and restricted to XXNXXX (or variations thereof) As Australian Foundation callsigns (decided to be the better choice in 2005) have the XXNXXXX suffix I believe this was chosen with the intention to prevent foundation calls from “accidently” trying to use packet radio, and if that was the case then it was a bit silly. But it is what it is and now that the foundation call is permitted digital modes (something I feel they should have always had access to) that decision in 2005 has come back to bite them (whoever they were at the time!)

Granted I haven’t read the determinations to the letter in recent months, but a station ID is only required every “TEN” minutes, not on “EVERY” transmission! Packet radio was always overkill for that but it was logical that the station ID be it’s callsign hence why the ax25 protocol has the limit of a 6 letter call.

Now what can we agree upon in the interim to be acceptable until the callsign suffix for the foundation is resolved? Bearing in mind that could take some time as there’s now 3 entities involved with the process (WIA, AMC & ACMA)

My take would be a tactical name with the operator callsign in the status text field (>VK7FABC John Citizen QE37pa) this would work for all RF aprs clients but because of the use of a tactical call it would be prohibited into the APRS-IS side (unless you are sneaky and generate a valid aprs pass code *the software for that is available under GNU hint think Xastir)

So that’s my initial thoughts …


VK7HSE Scott Evans

From: OZAPRS <ozaprs-bounces at aprs.net.au<mailto:ozaprs-bounces at aprs.net.au>> On Behalf Of Jack Schultz
Sent: Friday, 20 December 2019 12:45
To: Australian APRS Users <ozaprs at aprs.net.au<mailto:ozaprs at aprs.net.au>>
Subject: Re: [OZAPRS] Foundation and RF APRS

Hi Marcos (and Carlos), interesting to read both your thoughts on the topic.

Though my preference is obviously to have a 'valid' callsign for AX.25, what I use now is the best I could come up with. Every packet contains my full callsign in the comment, which I think works well for those that use APRS through a PC interface, but not as handy in a mobile rig or handheld where my full call is hidden behind several screens.

My thinking is that while transmitting my full callsign makes it a legal transmission, I should try and fit as much as possible in the designated callsign field, with the lowest priority being the leftmost part of the callsign since it is the least specific.

I hear a similar take on local repeaters where there is a usual crowd that chats to each other, often simply omitting 'VK' altogether when referring to each others callsigns, or the callsign of a repeater for example. In the world of APRS, I feel there is a similar level of community in that aspect within the local RF zone. I generally see a dozen or so core users, so there is that immediate recognition when I decode one of their packets.

In Melbourne I've also seen VK3FSPD using APRS first as VKFSPD, then using 3FSPD. I prefer the latter form as it avoids ambiguity when travelling interstate.


Jack Schultz


OZAPRS mailing list
OZAPRS at aprs.net.au<mailto:OZAPRS at aprs.net.au>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.aprs.net.au/pipermail/ozaprs/attachments/20191220/ed348bc1/attachment.html>

More information about the OZAPRS mailing list