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

Thu Apr 22 07:33:36 EDT 2021

Andrew - thank you for your feedback.

- The reason for writing my own bot is quite simple: WXBOT does not work
for international users but only for users on U.S. soil. As much as I'd
love to use WXBOT, it simply does not work for me. Last year, I had a chat
with Martin about changing his WxBot's source for its weather data to
OpenWeatherMap (which I use as my wx data source) and I suggested this
change for a future release. Due to the pandemic and mainly because my Perl
skills suck, I then decided to come up with my own little bot rather than
extending Wxbot. It is my understanding that the current constraint wrt
U.S. wx data made other APRS operators clone Martin's wxbot and have them
run their own instances. For example, WXYO and WXSVR-AU are -to my
knowledge- WXBOT clones which have been amended to support local wx needs.
Last but not least, developing the bot was a nice programming exercise.
- Good point regarding "places of interest". The list of supported
OpenStreetMap categories can be amended easily by simply changing the list
of entries in the program config file. Such a modification would have a
global impact but it's definitely doable. On the other hand - if I would be
forced to apply the European Union's GDPR regulation, all of us Europeans
would probably no longer be able to use APRS anyway. Talk about crazy
lawyers sending you cease-and-desist notifications just for using (user)
data that is freely available on the Internet.
- The bot is indeed intended to be run 24x7 (and has been running 24x7 for
the past 2 months or so). Similar to Martin's Wxbot, I do host it on my
local Raspberry Pi but ultimately, its hosting might be done by a dedicated
host. Traffic-wise, its internet usage should be much lower than WXBOT as I
use a dedicated call sign filter whereas -iirc- WXBOT polls APRS-IS for all
messages. Additionally, all tasks which require e.g. updating repeater
data, TLE files or cleaning up the program's email account run in an
automated manner. With the exception of e.g. program updates and/or updates
to the Pi itself, there shouldn't be downtimes.
- UTF-8: this is indeed a tricky issue. Every message that is sent to an
audience whose UTF-8 capabilities are not know has to be plain ASCII
content which is just one extra step in my program's APRS communication
core. My idea was that whenever I would respond to a user's request, I
would be able to send out UTF-8 content if that user's transceiver/program
give me an indication about its support status for UTF-8. Nevertheless, I
can totally live with sending out plain ASCII content.

Thank you
Joerg
DF1JSL

On Wed, Apr 21, 2021 at 10:18 PM Andrew Pavlin <spam8mybrain at yahoo.com>
wrote:

> Hmmm... interesting concept.
>
> I'm not sure if you really need to duplicate the functionality of the
> WXBOT, although other services you could provide might be useful. Are you
> connected in such a way that your bot will be on the APRS-IS network 24/7?
>
> Nice touch with the internationalizations. You might need to watch out on
> the "places of interest" feature; depending on the type of place, that
> might be considered "commercial traffic" (as in advertising a business),
> depending on jurisdiction-specific interpretations of amateur radio
> regulations. For example, a hospital would probably be OK (being public
> safety), but a bank or restaurant less so. You might want to look at the
> QRU service for examples of traffic likely to be allowable.
>
> Re: APRS-capable radios not handling UTF-8: get used to it. Those tiny
> embedded systems don't have enough flash memory room (or probably screen
> resolution) to handle all 65000+ characters/glyphs of the entire UTF-8
> character set. Notice even the Japanese manufacturers spell out their
> language words in ASCII characters (such as the voice synthesizer add-on to
> the Kenwood TM-D710). I have trouble getting all UTF-8 glyphs on my big
> Linux development server. It might be an interesting suggestion to Hessu to
> improve his JSON map restructuring of the TOCALL registry to add UTF-8
> capability as another attribute for each TOCALL, so you could use his
> database to figure out which character set the querying station handles
> (assuming it handles any; some TOCALLs are transmit-only beacons and don't
> listen to anything, such as transmit-only trackers like the TinyTrak3 and
> flood gauges, although you shouldn't get any requests from such stations).
>
> To get a TOCALL for your application, send an email to Bob Bruninga
> wb4apr at amsat.org and give him a suggestion that doesn't conflict with
> anything else presently on the list http://aprs.org/aprs11/tocalls.txt or
> https://github.com/hessu/aprs-deviceid/blob/master/generated/tocalls.pretty.json
> <https://github.com/hessu/aprs-deviceid/blob/master/generated/tocalls.dense.json>,
> but keep it tight (not too many varying characters) so as to not waste the
> rather small namespace of the TOCALL list; he'll either add it to his list
> and send it to Hessu, or tell you why it's not available. That's how I got
> APJYCn for my YAAC program (where 'n' is the version number). Note that you
> can make up a APZxxx tocall for experimenting until you get an official one
> registered.
>
> Andrew, KA2DDO
> author of YAAC ("Yet Another APRS Client"), which is UTF-8 capable, but
> doesn't have very many localizations yet
>
> On Wednesday, April 21, 2021, 2:40:52 PM EDT, Jörg Schultze-Lutter <
> joerg.schultze.lutter at gmail.com> wrote:
>
>
> 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
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20210422/55b6e4cf/attachment.html>