[aprssig] New Open Source APRS Bot and some questions wrt APRS TOCALL

[Jörg Schultze-Lutter]

Greetings from Germany

Let me introduce you to my way of dealing with the never-ending lockup: I
got familiar with the APRS protocol and wrote my first APRS bot (yay).
Besides the usual things like weather forecasts, I added a few things to
the bot that could be potentially useful for the APRS community.

My bot in a nutshell:

- runs on a Raspberry 4 along with a local Pi-Hole server and some Telegram
bots: https://aprs.fi/#!call=a%2FMPAD&timerange=3600&tail=3600
- Features, keywords, source code, instructions, technical details,known
issues, caveats and examples: https://github.com/joergschultzelutter/mpad.

The bot was developed with an international audience in mind. For those of
you who (still ... ? :-) ) prefer/use the imperial system over the metric
system, MPAD applies some magic (based on the country of origin of your
callsign) and provides the data in Fahrenheit, miles, etc., while the rest
of the world gets its data in Celsius, kilometers, etc..

Thanks to: Hessu (aprs.fi), Steve Dimse (findu.com), Pete Loveall (aprs-is)
- without your APIs and services, my bot wouldn't exist. Special thanks to
Martin Nile for releasing his WXBOT source (which was a perfect starting
point for me to understand how APRS message processing works). Finally:
thank you Bob Bruninga for inventing APRS - I literally use APRS every day.

There remain two questions for which I have been unable to identify any
information:
---
1) Similar to Martin's WxBot, my bot uses the generic "APRS" TOCALL
identifier (http://www.aprs.org/aprs11/tocalls.txt). Is it
mandatory/recommended/... to use a unique ID for my bot? If yes, how do I
apply for one?

2) Thanks to the power of Python 3, my bot is fully UTF-8 capable for both
incoming and outgoing content. Based on http://www.aprs.org/aprs12/utf-8.txt
(and some tests I did with IOS's APRS software), I have to assume that the
APRS protocol is also fully UTF-8 capable. However, none of my transceivers
can digest this content - and so my bot is forced to downconvert everything
to plain ASCII when I send a message. UTF-8 content with Cyrillic
characters, for example, results in an unreadable message on my HT's - all
you see are character placeholders.

Q: Are there any plans to expand the existing APRS "TOCALL" identifier list
so that software authors can check for the TOCALL identifier of an incoming
message to determine whether or not the device/software that originally
triggered the message is UTF-8 capable? This way, a program could send out
UTF-8 messages when *responding* to another user's message whose
device/software supports UTF-8. However, for general messages such as
bulletins or messages that do not respond to another user's message, the
ASCII message content would still be mandatory.
---

Thanks for taking the time to read this mail. Feel free to give MPAD a test
run, let me know how the software works for you - and where I may have
screwed things up. The source code is not that pretty - but the program
works just fine. I'll clean up those source files ... "tomorrow" :-)

Kind regards
Joerg
DF1JSL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20210421/33de7e1b/attachment.html>