Slashes in callsign

195 views
Skip to first unread message

Tom Ahola

unread,
Sep 24, 2011, 2:56:08 PM9/24/11
to apr...@googlegroups.com
Hi Hessu and all,

Today I thought I would send my secondary QTH location to the aprs-is.  I sent the callsignals I typically use from there: OH2FRM/1 and OH2FRM/6.  I noticed that if I do a search on aprs.fi and click one of these new callsigns with the slash I get a 404 not found error.  Maybe because the URL with the callsign including slash will probably be interpreted so that the part of the callsign before slash is a directory.  Maybe this is a bug or maybe using slashes is not allowed?

73 de OH2FRM Tom


Search results for OH2FRM*

Found 6 targets:

callsign
age comment
OH2FRM
17m10s Tom's home QTH
OH2FRM-12
348d 2h6m browser geolocation via aprs.inversi0n.org
OH2FRM-7
4h24m Tom`s handheld VX-8
OH2FRM-9
277d 5h48m Tom`s handheld VX-8
OH2FRM/1
17m8s Tom's cottage QTH
OH2FRM/6
17m6s Tom's cottage QTH

Tom

unread,
Oct 25, 2011, 6:04:52 AM10/25/11
to aprs.fi
Hi,

As nobody familiar with APRS name specification could answer my
question if slashes were allowed in my callsign I did investigate this
myself. It seems they are allowed! Special characters are allowed
and encouraged to distinguish between several station of the same
callsign. Some people use different SSID numbers but that it not the
right way to do it. SSID should only reflect the type of station
(nowadays the icon is used but SSID is still there for backwards
compatibility). Even the space character is allowed in the name but
that is not recommended.

So certainly this is a bug in aprs.fi. The slash (/) character
should be transformed into the %2F construct in the URL and the web
server should decipher those special characters as part of the name to
look for. Likewise space should be %20 and any other special
character that can be part of a name (callsign) in the APRS network
should be transformed into a valid URL.

I would be great if this could be fixed so that people can click on
stations from the search list without an error. There are many
stations with slashes in the name. Just do a search for callsign */
* - then try to click on one of them.

http://aprs.fi/?call=oh2frm*
http://aprs.fi/?call=*%2F*

Thanks,
73 de OH2FRM Tom



On Sep 24, 9:56 pm, Tom Ahola <ahola...@gmail.com> wrote:
>  Hi Hessu and all,
>
> Today I thought I would send my secondary QTH location to the aprs-is.  I
> sent the callsignals I typically use from there: OH2FRM/1 and OH2FRM/6.  I
> noticed that if I do a search on aprs.fi and click one of these new
> callsigns with the slash I get a 404 not found error.  Maybe because the URL
> with the callsign including slash will probably be interpreted so that the
> part of the callsign before slash is a directory.  Maybe this is a bug or
> maybe using slashes is not allowed?
>
> 73 de OH2FRM Tom
>
> Search results for *OH2FRM**
>
> Found 6 targets:
> callsign
> age comment OH2FRM <http://aprs.fi/a/OH2FRM>
> 17m10s Tom's home QTH OH2FRM-12 <http://aprs.fi/a/OH2FRM-12>
> 348d 2h6m browser geolocation via aprs.inversi0n.org
> OH2FRM-7<http://aprs.fi/a/OH2FRM-7>
> 4h24m Tom`s handheld VX-8 OH2FRM-9 <http://aprs.fi/a/OH2FRM-9>
> 277d 5h48m Tom`s handheld VX-8 OH2FRM/1 <http://aprs.fi/a/OH2FRM/1>
> 17m8s Tom's cottage QTH OH2FRM/6 <http://aprs.fi/a/OH2FRM/6>

Heikki Hannikainen

unread,
Oct 25, 2011, 11:54:06 AM10/25/11
to aprs.fi

Hi,

On Tue, 25 Oct 2011, Tom wrote:
>
> As nobody familiar with APRS name specification could answer my
> question if slashes were allowed in my callsign I did investigate this
> myself. It seems they are allowed! Special characters are allowed
> and encouraged to distinguish between several station of the same
> callsign.

They are not allowed in *callsigns* (i.e. the source or destination
callsign of an AX.25 packet, or in the path).

But they *are* allowed in item and object *names*, which are less
restricted than *callsigns*. But I haven't seen them encouraged (and I
wouldn't think it would be wise to really encourage using all sorts of
special characters there).

Yes, this is a bug in aprs.fi's links, I'll look into fixing it next
weekend (or earlier).

> Some people use different SSID numbers but that it not the
> right way to do it.

Different SSID numbers are a completely right and valid way to do it,
there's nothing wrong about that.

> (nowadays the icon is used but SSID is still there for backwards
> compatibility). Even the space character is allowed in the name but
> that is not recommended.

Space is as valid as /. Who does not recommend it (besides yourself)?
Please provide some references. It's in pretty common use with D-Star/DPRS.

- Hessu

Tom

unread,
Oct 26, 2011, 2:46:45 AM10/26/11
to aprs.fi
Thanks in advance for fixing the links!

Yes, I was not discussing AX.25 packet source and destinations fields
but the packets over APRS-IS.
My sources of information are specifications, addendum and manifestos
from aprs.org.
You got me wrong about me not recommending spaces in names. I could
not care less. Here is the document by Bob Bruninga discouraging
spaces (row 10):
http://aprs.org/aprs11/aprs-names-and-spaces.txt

The story about SSID and icons is there too somewhere. I don't like
the way people put random SSID numbers just to separate their
stations. That fools me to try to make a QSO or digipeat with a
station that is not what it seams. The recommendation to use special
characters in names to separate stations with same callsign is there
too on aprs.org, most likely written by Bob Bruninga. Did not find
the exact reference on a quick browse. I recommend you go through the
material, there is a lot of useful info about APRS there.

Thanks,
Tom OH2FRM/P

James Ewen

unread,
Oct 26, 2011, 3:21:02 AM10/26/11
to apr...@googlegroups.com
On Wed, Oct 26, 2011 at 12:46 AM, Tom <ahol...@gmail.com> wrote:

> The story about SSID and icons is there too somewhere.  I don't like
> the way people put random SSID numbers just to separate their
> stations.  That fools me to try to make a QSO or digipeat with a
> station that is not what it seams.

Stop making assumption about station capabilities based on outdated
information, and use the information available in the packets. If you
could rewrite the AX.25 specifications, and make it so that we could
have 65,536 different SSIDs on RF, then you could probably enforce
some type of numbering scheme for each of the different types of APRS
stations out there. With only 16 available, there's no way to stick
with some "standard" deployment scheme. Tell me where I'm supposed to
assign my TH-D7, TH-D72, TM-D700, TM-D710, home station, laptop,
mobile station, and the 8 digipeaters that I sponsor under my callsign
without mucking up the "standard". Oh yeah, I still have a few
trackers for balloon payloads and a couple TNCs laying around too that
I could put on the air.

You need to look at the icons, possibly the device type, and maybe
even the status or comments appended to the packets to help make a
decision about the capabilities of a station. Even then there's no
guarantee...

You can send a message to my message capable TM-D710, but there's no
guarantee that I'll see it and respond, I might not be in the vehicle
when you send the message. You can also digipeat through my TM-D710
because I have not disabled the digipeater function that is factory
enabled by default, but I'm not going to run a specific SSID or icon
on the D710 just because digipeating is enabled.

There are no hard fast rules about APRS capabilites versus SSIDs.

Now if you want a guy that's getting crazy with SSIDs on the APRS-IS,
have a look at Lynn!

http://aprs.fi/info/?call=kj4erj*

--
James
VE6SRV

Heikki Hannikainen

unread,
Oct 26, 2011, 4:17:26 AM10/26/11
to aprs.fi
On Tue, 25 Oct 2011, Tom wrote:

> Yes, I was not discussing AX.25 packet source and destinations fields
> but the packets over APRS-IS.

I still believe you are talking about names of objects and items (like
OH2FRM/P is). Punctuation characters or spaces are still not allowed in
the source and destination *callsign* fields on APRS-IS. They're allowed
in object and item *names*, both on APRS-IS and on the radio channel,
embedded within AX.25.

> My sources of information are specifications, addendum and manifestos
> from aprs.org.
> You got me wrong about me not recommending spaces in names. I could
> not care less. Here is the document by Bob Bruninga discouraging
> spaces (row 10):
> http://aprs.org/aprs11/aprs-names-and-spaces.txt

Ok, so Bob discourages it. Fine, I don't like it's use there either, but
it's still in very widespread use (do a search for "* *"). Holy cow, those
links don't work either. They used to!

> too on aprs.org, most likely written by Bob Bruninga. Did not find
> the exact reference on a quick browse. I recommend you go through the
> material, there is a lot of useful info about APRS there.

Heh. You'll have to take my word that I have gone through that material
(and APRS101.PDF), several times, while implementing aprs.fi and the
related tools.

A lot of stuff that is on aprs.org are *recommendations* and *opinions*
from Bob. Some of those opinions and suggestions have not been implemented
in the actual software, or have been implemented differently, since the
authors have not agreed with Bob, or seen the features as very useful, or
because they have not been defined in the documents with enough technical
detail so that the programmers could interpret them in the same way (many
will remember the discussion on the APRSSIG about the definition of
"printable ASCII character" and it's invalidity in the linked document -
even line feeds and newlines are printable ASCII characters, but
technically, there is no way they could be used there).

The doc linked above is one of those that I have a problem with, both
because of the imprecise technical definitions, and of the intent. For
example, case sensitivity is an user experience pain – it just confuses
regular users. Allowing punctuation makes it hard to do convenient user
interfaces (try to think of an user friendly interface to search for
stations with either a ',' or a '*' in the callsign, while supporting
multiple-station lookups and wildcard searches, and while assuming
non-technical users who do not understand the concept of escaping with '\'
which would also be a valid character in object names). Anyone trying to
implement an APRS application will find the technical mess of those
documents painful.

Ok, enough of that rant.

- Hessu

Lynn W Deffenbaugh (Mr)

unread,
Oct 26, 2011, 6:50:22 AM10/26/11
to apr...@googlegroups.com
On 10/26/2011 3:21 AM, James Ewen wrote:
> Now if you want a guy that's getting crazy with SSIDs on the APRS-IS,
> have a look at Lynn! http://aprs.fi/info/?call=kj4erj*

Wow! That's a cool page Hessu! I've had some trouble remember when I
last used a given -SSID and now I can find it! Never thought of using
the multi-target resolution page for such a purpose.

It's even better when you click the Age heading and see which of them
was active how long into the past. 12 different -SSIDs active in the
past 2 days, I like it!

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

Reply all
Reply to author
Forward
0 new messages