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

Wed Apr 21 17:09:00 EDT 2021

Hi,

An UTF-8 feature marker in the machine-readable APRS device index would 
not be a bad idea. It already has "messaging" and "item-in-msg" feature 
flags for some devices, so maybe "utf8" would make sense.

When dealing with UTF-8, remember that APRS packets overall must be 
handled as binary byte arrays. Only message contents (comment text, text 
message body, status message) should be decoded as UTF-8 for the purpose 
of displaying unicode text in a user interface. The APRS packet must not 
be UTF-8 decoded as a whole, it must be decoded from the binary byte 
array/buffer.

Some packets have NUL bytes in them, either intentionally or due to 
corruption. If the packets are UTF-8 decoded before forwarding, modified 
duplicates will be produced.

On Wed, 21 Apr 2021, Andrew Pavlin via aprssig 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, 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
> 
>

   - Hessu