Does not accept longer callsigns.

[dandrzejewski]

One of the recommendations here is that digipeaters should use location names for their callsigns (with their FCC issued callsigns in the comment).

When I do this with the callsign of PEPPRPIKE (which is valid), I get this:

parse_ax25addr('PEPPRPIKE') failed. [1]

Looking at ax25.c, it looks like it's hardcoded to expect a callsign of up to 6 characters, then a dash and SSID. So when it doesn't see the dash (or a * or null), it bombs and returns 1.

The request here is that it should properly support up to 9 characters without an SSID.

[kd7lxl]

AX25 specifies 7 bytes for the source address--6 bytes for the callsign and one byte for the SSID. Valid SSID values are 0-15. Your request is simply not supported by the underlying protocol.

http://www.aprs.org/doc/APRS101.PDF page 12

[PhirePhly]

AX.25 limits callsigns to "3-6 characters - [0-15]" APRS has a looser requirement of 3-9 characters, and no more than two characters for the optional SSID, so yes, PEPPRPIKE is a valid APRS callsign, but not at all a valid AX.25 callsign, and there's no way to work around that. I've used callsigns like W6KWF-TS when testing something that isn't using AX.25 as the transport layer, but there's no way I could use that over VHF AX.25.

I believe APRX will accept APRS but not AX.25 callsigns when it can, but warns you that it's using a callsign it can't use to transmit with. Regardless, if you want your digipeater to be a digipeater, and not an RX-only I-gate, you need to meet the 3-6 character callsign and numeric 0-15 SSID requirement of AX.25.

Does that address your concerns?

[dandrzejewski]

Ah okay, that makes sense. I only reviewed the packet format for APRS which is 9 characters, but didn't realize that ax25 limitation. Disregard!

Although it would be nice to have a few extra characters ;)

• Dave/KD8TWG

Kenneth Finnegan wrote:

AX.25 limits callsigns to "3-6 characters - [0-15]" APRS has a looser requirement of 3-9 characters, and no more than two characters for the optional SSID, so yes, PEPPRPIKE is a valid APRS callsign, but not at all a valid AX.25 callsign, and there's no way to work around that. I've used callsigns like W6KWF-TS when testing something that isn't using AX.25 as the transport layer, but there's no way I could use that over VHF AX.25.

I believe APRX will accept APRS but not AX.25 callsigns when it can, but warns you that it's using a callsign it can't use to transmit with. Regardless, if you want your digipeater to be a digipeater, and not an RX-only I-gate, you need to meet the 3-6 character callsign and numeric 0-15 SSID requirement of AX.25.

Does that address your concerns?

— Reply to this email directly or view it on GitHub https://github.com/PhirePhly/aprx/issues/18#issuecomment-128165598.

[kd7lxl]

Just curious, where are you guys seeing the 9-character limit for APRS? I've only ever found reference to 9 character callsigns in the APRS-IS spec, not in the APRS spec.

[PhirePhly]

I don't think the APRS "spec" actually spells it out, but since APRS-IS is more permissive than AX.25, APRS systems should be tolerant of the 9 character limitation, so it should be in the APRS spec.

[dandrzejewski]

I may have been looking at the object packet format.

Tom Hayward wrote:

Just curious, where are you guys seeing the 9-character limit for APRS? I've only ever found reference to 9 character callsigns in the APRS-IS spec, not in the APRS spec.

— Reply to this email directly or view it on GitHub https://github.com/PhirePhly/aprx/issues/18#issuecomment-128174080.

[PhirePhly]

APRS-IS definitely allows nine character callsigns, so you were right to think you should have been able to use that, but it wouldn't be able to transmit.

[hessu]

APRS-IS servers will not accept nine character callsigns. They're fine as object/item names, though.