<html><head></head><body><div class="ydpade7b093yahoo-style-wrap" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px;"><div></div>
<div dir="ltr" data-setdir="false">Hmmm... interesting concept.</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">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?</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">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.<br></div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">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).</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">To get a TOCALL for your application, send an email to Bob Bruninga wb4apr@amsat.org and give him a suggestion that doesn't conflict with anything else presently on the list <a href="http://aprs.org/aprs11/tocalls.txt" rel="nofollow" target="_blank">http://aprs.org/aprs11/tocalls.txt</a> or <a href="https://github.com/hessu/aprs-deviceid/blob/master/generated/tocalls.dense.json" rel="nofollow" target="_blank">https://github.com/hessu/aprs-deviceid/blob/master/generated/tocalls.pretty.json</a>, 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.</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">Andrew, KA2DDO</div><div dir="ltr" data-setdir="false">author of YAAC ("Yet Another APRS Client"), which is UTF-8 capable, but doesn't have very many localizations yet<br></div><div><br></div>
</div><div id="ydp4edb404fyahoo_quoted_9266149335" class="ydp4edb404fyahoo_quoted">
<div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">
<div>
On Wednesday, April 21, 2021, 2:40:52 PM EDT, Jörg Schultze-Lutter <joerg.schultze.lutter@gmail.com> wrote:
</div>
<div><br></div>
<div><br></div>
<div><div id="ydp4edb404fyiv7713242620"><div dir="ltr">Greetings from Germany<br><br>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. <br><br>My bot in a nutshell:<br><br>- runs on a Raspberry 4 along with a local Pi-Hole server and some Telegram bots: <a href="https://aprs.fi/#!call=a%2FMPAD&timerange=3600&tail=3600" rel="nofollow" target="_blank">https://aprs.fi/#!call=a%2FMPAD&timerange=3600&tail=3600</a><br>- Features, keywords, source code, instructions, technical details,known issues, caveats and examples: <a href="https://github.com/joergschultzelutter/mpad" rel="nofollow" target="_blank">https://github.com/joergschultzelutter/mpad</a>. <div><br></div><div>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..<br></div><div><br></div><div>Thanks to: Hessu (<a href="http://aprs.fi" rel="nofollow" target="_blank">aprs.fi</a>), Steve Dimse (<a href="http://findu.com" rel="nofollow" target="_blank">findu.com</a>), 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.<br><br>There remain two questions for which I have been unable to identify any information:<br><div>---<br>1) Similar to Martin's WxBot, my bot uses the generic "APRS" TOCALL identifier (<a href="http://www.aprs.org/aprs11/tocalls.txt" rel="nofollow" target="_blank">http://www.aprs.org/aprs11/tocalls.txt</a>). Is it mandatory/recommended/... to use a unique ID for my bot? If yes, how do I apply for one?<br><br>2) Thanks to the power of Python 3, my bot is fully UTF-8 capable for both incoming and outgoing content. Based on <a href="http://www.aprs.org/aprs12/utf-8.txt" rel="nofollow" target="_blank">http://www.aprs.org/aprs12/utf-8.txt</a> (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.</div><br><div>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. </div><div>---<br></div><div><br></div><div>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" :-)</div><div><br></div><div>Kind regards<br>Joerg<br>DF1JSL</div></div></div>
</div>_______________________________________________<br>aprssig mailing list<br><a href="mailto:aprssig@lists.tapr.org" rel="nofollow" target="_blank">aprssig@lists.tapr.org</a><br><a href="http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org" rel="nofollow" target="_blank">http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</a><br></div>
</div>
</div></body></html>