<div dir="ltr">Andrew - thank you for your feedback.<div><br></div><div>- 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.</div><div>- 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.</div><div>- 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.</div><div>- 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.</div><div><br></div><div>Thank you</div><div>Joerg</div><div>DF1JSL</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 21, 2021 at 10:18 PM Andrew Pavlin <<a href="mailto:spam8mybrain@yahoo.com" target="_blank">spam8mybrain@yahoo.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:13px"><div></div>
<div dir="ltr">Hmmm... interesting concept.</div><div dir="ltr"><br></div><div dir="ltr">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"><br></div><div dir="ltr">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"><br></div><div dir="ltr">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"><br></div><div dir="ltr">To get a TOCALL for your application, send an email to Bob Bruninga <a href="mailto:wb4apr@amsat.org" target="_blank">wb4apr@amsat.org</a> 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"><br></div><div dir="ltr">Andrew, KA2DDO</div><div dir="ltr">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="gmail-m_1066706185453098941gmail-m_6873171912243003048gmail-m_6531006974632594464gmail-m_64165076247318466gmail-m_5235925111072112493ydp4edb404fyahoo_quoted_9266149335">
<div style="font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:13px;color:rgb(38,40,42)">
<div>
On Wednesday, April 21, 2021, 2:40:52 PM EDT, Jörg Schultze-Lutter <<a href="mailto:joerg.schultze.lutter@gmail.com" target="_blank">joerg.schultze.lutter@gmail.com</a>> wrote:
</div>
<div><br></div>
<div><br></div>
<div><div id="gmail-m_1066706185453098941gmail-m_6873171912243003048gmail-m_6531006974632594464gmail-m_64165076247318466gmail-m_5235925111072112493ydp4edb404fyiv7713242620"><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></div></blockquote></div>