Re: [aprsfi] ToCall.txt: APxxxx devices allocation on aprs.fi

[Lynn W Deffenbaugh (Mr)]

If you look at  you'll see:

 APS  APSxxx  APRS+SA, etc

So yes, everything starting with APS will belong to APRS+SA, except fot the exceptions that follow:

      APSARx  ZL4FOX's SARTRACK
      APSCxx  aprsc APRS-IS core server (OH7LZB, OH2MQK)
      APSFxx  F5OPV embedded devices - was APZ40
      APSK63  APRS Messenger -over-PSK63
      APSK25  APRS Messenger GMSK-250
      APSMSx  Paul Dufresne's SMSGTE - SMS Gateway
      APSTMx  for W7QO's Balloon trackers
      APSTPO  for N0AGI Satellite Tracking and Operations

But Bob's list isn't very machine readable.  It takes manual intervention to adopt his newly defined tocalls into the various software that attempts to interpret and display the originating platform.  Hessu has apparently not picked up the newest, and I can also say that APRSISCE/32 is also due for an update for the recently added definitions.

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


On 2/3/2017 6:48 AM, Pierre F5OPV wrote:

Hi everybody,

having recently requested to wb4apr, an add to the tocall list of aprs devices, (APSFxx),
il seems to me that the tocalls' parsing on aprs.fi does only take into account the 3 first characters of the tocall string:

so, all devices begining by "APS" are allocated to APRS+SA (software) , discarding the following characters of the tocall chain.

Ex: F5OPV-IoT

Commentaire:	Client APRS-IS embarqué (Météo,Télémesure,Objets APRS,SMS,...)
Dernier statut:	Hardware: Wemos D1 Mini / Firmware: Aquitania_WW v1.16
Position:	43°49.98' N 0°48.51' W - locator IN93OT29XW - Carte - Carte statique 68.1 m Nord-est Cap 32° de Tartas, Département des Landes, Aquitaine, France [?] 3.4 km Est Cap 72° de Bégaar, Département des Landes, Aquitaine, France 113.4 km Sud Cap 189° de Bordeaux, Département de la Gironde, Aquitaine, France 131.5 km Nord-est Cap 31° de Pamplona, Provincia de Navarra, Navarre, Spain
Dernière position	2017-02-03 12:31:35 CET (1m40s Il y a) 2017-02-03 12:31:35 CET Heure locale Tartas, France [?]
Altitude:	25 m
Dernier rapport météorologique:	2017-02-03 12:26:17 CET (6m58s Il y a) – Graphiques météo 13.3 °C 70% 1006.7 mbar 0.0 m/s Nord
Dernière télémétrie:	2017-02-03 12:31:25 CET (1m50s Il y a) – télémétrie Trame: 104 #, Vbat: 13.900 V, Vmcu: 9.100 V, Text: 0 C, Tmcu: 21 C  I1     I2     I3     I4     O1     O2     O3     O4
Appareil:	Brent Hildebrand, KH2Z: APRS+SA (software)
Dernier chemin:	F5OPV-IoT>APSF40 via TCPIP*,qAC,T2DENMARK
Positions enregistrées	4
Débit de paquets:	37 seconds between packets on average during 1830 seconds.

Here's an abstract of tocall list:

 APS  APSxxx  APRS+SA, etc
      APSARx  ZL4FOX's SARTRACK
      APSCxx  aprsc APRS-IS core server (OH7LZB, OH2MQK)
      APSFxx  F5OPV embedded devices - was APZ40
      APSK63  APRS Messenger -over-PSK63
      APSK25  APRS Messenger GMSK-250
      APSMSx  Paul Dufresne's SMSGTE - SMS Gateway
      APSTMx  for W7QO's Balloon trackers
      APSTPO  for N0AGI Satellite Tracking and Operations

Any way to get a complete parsing of tocalls' string Heikki ?

Thanks in advance for your answer.
73 de F5OPV.

--
You received this message because you are subscribed to the Google Groups "aprs.fi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aprsfi+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Heikki Hannikainen]

Hi Pierre,

Like Lynn explained, tocalls.txt is not directly usable as a configuration
file for aprs.fi or any software. Any changes in it need to be manually
merged into a machine-readable config of some sort.

aprs.fi and a few other systems use https://github.com/hessu/aprs-deviceid
as their config for device identification, so we'll have to put your
tocall allocation in there and then install the new YAML config on
aprs.fi.

The APSFxx definition just says "F5OPV embedded devices" - does your
embedded device or device have a name that should be used / shown?

- Hessu

[Nosey Nick VA3NNW]

On Tuesday, February 7, 2017 at 4:47:54 PM UTC-5, Heikki Hannikainen wrote:

Like Lynn explained, tocalls.txt is not directly usable as a configuration
file for aprs.fi or any software. Any changes in it need to be manually
merged into a machine-readable config of some sort.

I smell a feature request   :-)
It OUGHT to be possible for tocalls.txt to be both human-readable and machine-readable.
It's almost machine-readable if you start at /^ APn/, end at the next blank line, and remove /for */ from the start of the description.
If we wanted to make it a bit more machine-readable without unduly sacrificing human-readability, how would we fix it?

Nick VA3NNW

[Heikki Hannikainen]

In addition to the actual format and parsing, the file's contents would
need to be normalized in terms of text style, so that they could be shown
nicely in an application. tocalls.txt unfortunately only has a single
free-form description string: "aprsc APRS-IS core server (OH7LZB,
OH2MQK)", "for N0AGI Satellite Tracking and Operations", "APRSdroid
(pre-release) http://aprsdroid.org/". You can't sensibly get out whether
it has a name of an application or a product, or which part is the author
/ vendor producing that. Punctuation varies, some strings contain a
sentence, some don't.

I would propose maintaining it in a format which:

* is already defined and widely used elsewhere, instead of a new format
invented just for this purpose
* has existing parsers for a wide array of programming languages, so that
people don't need to write parsers for this format
* can be validated after editing by running a simple script, to find
syntax errors before publishing
* can be converted to other formats (XML, JSON, etc) by running a simple
script, to be used in environments which cannot use the primary format

Incidentally, that's what I'm doing already; my master file is in YAML
format (tocalls.yaml) which fits the requirements above:

https://github.com/hessu/aprs-deviceid/blob/master/tocalls.yaml#L418

There is a small script there to read it in and validate the contents a
little bit, and it also puts out XML and JSON files for those who have
those parsers in and don't want to add a YAML parser:

https://github.com/hessu/aprs-deviceid/tree/master/generated

The only problem now is that Bob's additions to tocalls.txt don't get
there automatically, and Bob's additions do not always contain as much
information as I'd like (the product / software name, vs. the author's
name/callsign), but often those can be googled up.

- Hessu