APRS Comment

[sv1]

Hello,

I am using svxlink from the latest git pullout and I have the issue bellow:

$ svxlink SvxLink v1.4.99.23 (Jun 8 2015) Copyright (C) 2003-2015 Tobias Blomberg / SM0SVX

SvxLink comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it in accordance with the terms and conditions in the GNU GPL (General Public License) version 2 or later.

Using configuration file: /usr/local/etc/svxlink/svxlink.conf --- Using sample rate 48000Hz * ERROR: Config variable [LocationInfo]/TONE=88.5 wrong or not set. * Example: TONE=0 *\ ERROR: Could not init LocationInfo, check configuration section LOCATION_INFO=LocationInfo

The problem is decimal on the PL tone. If I set TONE=88 then everything is working perfect.

Also the same problem is with the frequency. If I set the frequency to 145.2375, then on the beacon sent to aprs.fi, is rounded to 145.238MHz.

73 DE SV1LJJ

[pe1chl]

It is true that it is handled like this in the code. Values are unfortunately stored as integers and then handled in a difficult way with modulo and divide. They should of course be floats. However, before digging through all of this and fixing it, it is advisable to first check what the APRS spec allows. Maybe it explicitly says 3 digits after the decimal for frequency, and only integer numbers for tone? (I see in the config of our repeater that tone is set to 885 instead of 88.5 probably to overcome the same problem)

[dl1hrc]

It was not the idea of SvxLink but the definition inside the APRS-network, the "APRS Local Frequency Info Initiative". The ctcss tone has to be defined as integers without thenth:

"FFF.FFFMHz Tnnn RXXm". The Tone (and Offset) are fixed field formats followed by additional text such as Range (XX miles or km). If the offset is omitted, then the standard offset in the region will be used by radios on receipt. The tone does not include decimals.

I do not see a problem here because the integer "88" is known as 88.5Hz ctcss and can be displayed as 88.5Hz on clients. There is no e.g. 88.2Hz defined in ctcss system. So changes inside the SvxLink code shoudn't be done to stay compatible with aprs network.

For further information take a look here: http://www.aprs.org/info/freqspec.txt

[pe1chl]

That is why I mentioned that in the comment.... the APRS spec is wellknown for its strange, inflexible definitions and emphasis on data length. As it is written by an American, the notion of 12.5 kHz channel spacing was unknown to him and not catered for. I guess we will have to live with that...

[sm0svx]

Maybe it would be nice if SvxLink then just truncate the decimal from the configuration automatically so that users are not exposed to the strange things in the APRS protocol?

[pe1chl]

That is happening for the transmit frequency, it appears, but not for the DTMF tone. Of course in the case of the DTFM tone it would have to be truncated, not rounded as the frequency now is. Maybe it is better to truncate the frequency as well, probably more users would recognize 145.2375 represented as 145.237 more easily than the rounded 145.238 (we have DTMF tone 88.5 and now have 88 in the config, it should not be 89 in this case)

[sm0svx]

I guess you mean CTCSS, not DTMF. I was pretty confused there for a while ;-)

Yes, I agree about the transmit frequency. Truncating is better there as well.

[pe1chl]

Sorry... should be CTCSS tone indeed!