aprsorg / aprs-deviceid

APRS device identification data: tocalls.txt + mic-e-types.txt current master allocations (YAML, JSON, XML)
59 stars 23 forks source link
aprs

APRS device identification database

Beginning from 2022-02-19, this is the master database for APRS device identifier allocations. Previously APRS device identifiers were allocated by Bob Bruninga in http://aprs.org/aprs11/tocalls.txt and http://www.aprs.org/aprs12/mic-e-types.txt and any new allocations had to be made by Bob Bruninga in one of those files, before being added to this database. As Bob is sadly no longer with us, new allocations are now being done directly to this database.

This may change in the future, if and when a new organization for APRS standards and documentation is formed, as I can then pass on the allocations responsibility to them. I hope the new organisation will retain this machine-readable format and continue the work directly from this git repository.

This is a machine-readable index of APRS device and software identification strings. For easy manual editing and validation, the master file is in YAML format. A generator tool, provided in this repository, checks the YAML file for correctness and converts the database to XML and JSON. The generated versions are also made available for download.

This database is maintained by Hessu, OH7LZB, and a soon-to-be-named team of volunteers.

The database is published in a machine-readable format so that it would be easy for developers to implement automatic identification of APRS devices and software. If you choose to use the database, and update from here regularly, your APRS app will automatically detect new devices added in the future.

Validated and generated files are automatically published, after every change in the master database, at the following URLs. APRS applications can automatically fetch fresh versions, for example, once per week. Just remember to pick a random day and time - don't schedule all instances to download precisely on the same second.

The XML and JSON files were previously published in the generated/ directory of this repository. Since they're actually build products they do not belong in the source code repository. The copies in the repository are no longer updated, and will be removed in 2025.

Licensing

The database is licensed under the CC BY-SA 2.0 license, so you're free to use it in any of your applications, commercial, free or open source. For free. Just mention the source somewhere in the small print.

http://creativecommons.org/licenses/by-sa/2.0/

Adding new devices

If you have created a new APRS device, or written a new APRS app, and would like to add it in the database, please read through the ALLOCATING policy document, and then file an issue ticket in Github (https://github.com/aprsorg/aprs-deviceid/issues) - we'll be notified by email.

Please include all the relevant fields (vendor, model, class, os, contact). The master file is tocalls.yaml, and all the other files are generated from that file, so please use that format.

Do not submit new devices on others behalf, let the author of the device or application to request addition directly. Thank you!

Thank you!

Contents

The files are UTF-8 encoded Unicode. Vendor names may contain non-ascii characters where required for correct spelling of a name, but let's not get silly with emojis and funny formatting.

Tocall index (tocalls):

Mic-E device identifier index (mice):

This index contains the new-style two-character comment suffix part, which is assigned to new Mic-E devices. The first comment prefix character indicates whether the device is messaging capable (` for messaging capable, ' for a non-messaging capable dumb tracker).

Mic-E legacy device identifier index (micelegacy):

This index contains the old-style prefix + suffix parts for Kenwood devices. Messaging capability is listed in this index. A device may be identified by only a 1-character prefix (the old devices), or both a 1-character prefix and a 1-character suffix.

Device class index (classes):

Libraries and applications directly using this database

Others? Let me know.

Lookup algorithm for destination callsigns

  1. Try an exact match against those tocalls in the index which have no wildcards (?, lower-case n, *). The quickest way to do this is to preload those tocalls from the database to a hash table or binary tree of some sort.
  2. Go for the wildcarded entries next. Look for an entry having the longest match: APXYZ? should match before APXY??.