tag:blogger.com,1999:blog-26314297762926422592024-03-14T07:10:54.742+02:00What's up on aprs.fiThe news of <a href="https://aprs.fi/">https://aprs.fi/</a> - new features and interesting attractions found in the APRS and AIS worlds.Hessuhttp://www.blogger.com/profile/12550787353137508264noreply@blogger.comBlogger267125tag:blogger.com,1999:blog-2631429776292642259.post-51219931999003094762023-06-29T00:41:00.006+03:002023-06-29T00:53:27.223+03:00CG Antenna GW-1000 APRS iGate has serious bugs<p>The CG Antenna GW-1000 APRS iGate gateway appliance contains faulty firmware which causes severe problems to APRS messaging worldwide. <b>The IS -> RF gateway feature must be disabled on all GW-1000 devices until the bug is fixed by CG Antenna, and firmware is updated on the devices.</b> Please <a href="http://www.cgantenna.be/contact.html" rel="nofollow" target="_blank">contact the vendor</a> for further instructions.</p><p>CG Antenna has asked me to publish this information so that owners of faulty iGates would more likely learn about the issue. They mentioned a special TTL level serial cable / adapter may be required for the update process.</p><h3 style="text-align: left;">Description of the issue</h3><p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjm4cRA2WFnLFPp4avDfo6a8LuKI9If_rUiROgJmG70rY7YQhneDxVLaFMWqaaksh_C53P0g9ZyAHDujAdbNEfkMC9d0NfMlf_wgVl6ka4cdnSfQb0oRCkbD4SIgvIuZq_amU29BnMKPYrEkAP-yjQvhNuQMiZ-61_UpCcs6wAzLMJ0vcFzXE0qlWbScyRO/s4032/IMG_1879.jpg" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" data-original-height="4032" data-original-width="3024" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjm4cRA2WFnLFPp4avDfo6a8LuKI9If_rUiROgJmG70rY7YQhneDxVLaFMWqaaksh_C53P0g9ZyAHDujAdbNEfkMC9d0NfMlf_wgVl6ka4cdnSfQb0oRCkbD4SIgvIuZq_amU29BnMKPYrEkAP-yjQvhNuQMiZ-61_UpCcs6wAzLMJ0vcFzXE0qlWbScyRO/w240-h320/IMG_1879.jpg" title="A power supply / driver of an airport beacon strobe" width="240" /></a></div>When enabled, the APRS-IS to RF (transmit) iGate transmits packets to the RF unmodified. It does not use the correct 3rd party packet format documented in the iGate specification. Because of this, other iGates near the faulty iGate assume all of those distant stations are active on the local RF channel, while in fact they may be on the other side of the world.<p></p><p>This causes the other local iGates to transmit APRS text messages destined to all of those remote stations to the local RF channel. They're operating correctly - the unmodified packets sent by the CG-1000 seem like they would have been transmitted locally on RF.</p><p>When a lot of messages are sent, such as during the APRS Thursday event, the local RF channel will be seriously congested. The CG Antenna GW-1000 device itself will transmit a high rate of packets, packets which are destined to remote stations and which should not be forwarded to RF. The other iGates confused by the GW-1000 cause additional unnecessary traffic.</p><p>Because of the congestion many packets are also delayed long enough to cause the 30-second duplicate packet filtering window to be exceeded. Packets sent to RF by the GW-1000 will be looped back to APRS-IS and redelivered everywhere in the world. A single GW-1000 gateway in Switzerland caused delayed duplicate APRS messages to be delivered worldwide.</p><p>There are currently GW-1000 gateways operating elsewhere, but it is difficult to track them down and get them disabled. They are hard to identify, because they send the packets to RF unmodified, without using their own callsign in the 3rd party packet frame like they should.</p><h3 style="text-align: left;">Timeline</h3><p>I have notified CG Antenna of the issue by email on January 14th, 2023, and they confirmed receiving the report on January 17th. On February 4th they confirmed that they have to make a firmware update. They have not published updated firmware on their <a href="http://www.cgantenna.be/gw1000.html" rel="nofollow" target="_blank">downloads page</a> yet as of June 29th, 2023. After 5 months, on June 21st, they <a href="http://www.cgantenna.be/product_gw1000APRS%20Total%20solution.html" rel="nofollow" target="_blank">updated their web site to note that the feature is faulty and needs to be disabled</a>.</p><p>The bug has been present in the firmware since the launch of the product, but only became apparent when the APRS Thursday event got people to send more APRS messages, and some of those messages were originated near GW-1000 iGate.</p><h3 style="text-align: left;">Learnings</h3><p>Yes, the APRS messaging feature is brittle and it's easy to cause a bit of a mess.</p><p>If you produce and deliver a product like this, make sure it is easy for customers to upgrade the firmware without special tools. Be prepared to ship updated firmware in a timely manner if there is a serious issue.</p><p>If you wish to implement an APRS iGate, be sure to fully read the <a href="https://aprs-is.net/IGating.aspx" target="_blank">APRS iGate spec</a>, and the <a href="https://aprs-is.net/IGateDetails.aspx" target="_blank">details page</a>, and fully understand it. If there's something that you don't understand, please don't do it before obtaining more information or help to understand it.</p><p>This is not the only current issue out there - there are other software causing similar issues. I'll make an update in the <a href="https://github.com/hessu/aprsc/blob/main/doc/IGATE-HINTS.md" target="_blank">APRS iGate implementation tips</a> document.</p><p>The issue was originally debugged and described in this <a href="https://groups.io/g/APRS/topic/packets_messages_looping_from/96251214?p=Created%2C%2C%2C20%2C1%2C80%2C0&jump=1" target="_blank">groups.io APRS group thread</a>.</p>Hessuhttp://www.blogger.com/profile/12550787353137508264noreply@blogger.com0tag:blogger.com,1999:blog-2631429776292642259.post-33582326868907131012022-03-01T02:21:00.008+02:002023-06-28T23:49:09.449+03:00Radiosonde iGates are quite a mess, and they seriously need some fixing<p><b>UPDATE: The radiosonde data feeds have almost completely been moved to <a href="http://sondehub.org">sondehub.org</a> and the APRS-IS is no longer involved or affected by it. Thank you!</b></p><p><span></span></p><a name='more'></a><p></p><p>I have today started to filter out radiosonde traffic coming to aprs.fi, because it's consuming quite a lot of resources, and the incoming data is quite a mess, and my log files are full of warnings about inconsistent balloon positions, just because the gateways all work differently, and they create a lot of duplicate data, at a very high rate.</p><p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEgotq1wNhaoP05MBAi3gvQtftJu5g-s7lXhKLs5v_StxNhB0jnzw7vwtfCnmqBvmB2TxK-boSjD1g4Hjweo89S5kGRYpmDniDwVwJG_8x2EkkXs0Iwgg92bS2jIabSjZYzE3y6bUDXjlcPrf3V4RPOAR1Fztu7VN2e1roNEfir5o2VFxi06uHBaKVBlOg" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img data-original-height="800" data-original-width="1266" height="202" src="https://blogger.googleusercontent.com/img/a/AVvXsEgotq1wNhaoP05MBAi3gvQtftJu5g-s7lXhKLs5v_StxNhB0jnzw7vwtfCnmqBvmB2TxK-boSjD1g4Hjweo89S5kGRYpmDniDwVwJG_8x2EkkXs0Iwgg92bS2jIabSjZYzE3y6bUDXjlcPrf3V4RPOAR1Fztu7VN2e1roNEfir5o2VFxi06uHBaKVBlOg=w320-h202" title="This is a single radiosonde ballloon." width="320" /></a></div>Various gateways convert the same received packets to slightly different APRS packets, and the same balloons show up as many tracks on aprs.fi, which consumes resources here, and it also looks silly on the map.<p></p><p>The packet rates are also wild - many gateways forward packets from a single balloon every few seconds, which is much more often than any well-behaving APRS stations do. Because different gateways customize the packets by using unique destination callsigns, inserting advertisement URLs and custom comment texts, <i>I'm getting a whole lot of packets here</i>, many of them modified duplicates of the same original frequent packets. It's quite silly indeed.</p><p>Please note that it has also been said and written many times that the APRS-IS is designed and built to only carry amateur radio traffic, and sonde data clearly are not amateur radio traffic. I might personally be ready to make an exception, but I can't speak for others, there might be strong opposition elsewhere. One perfectly good option that all of this traffic only goes to <a href="http://sondehub.org">sondehub.org</a> and/or <a href="http://radiosondy.info">radiosondy.info</a> in the future - but the improvements listed here should help that service just as well.<br /><br />I can re-enable intake of this data at aprs.fi (perhaps via a different set of APRS-IS-like servers, or the sondehub.org websocket feed), but I have two simple conditions that must be fulfilled first.</p><h2 style="text-align: left;">1. Receivers must forward data consistently, and maintain data integrity, so that APRS duplicate packet suppression works</h2><p>All gateways forwarding a single packet received from a sonde must all output the exact same APRS packet: Same source callsign, same destination callsign, and same packet contents. Similarly to APRS, the path may differ and the receiver callsign after the Q construct is naturally different.<br /><br />The packet must only contain data that was received from the sonde - it must not contain identifiers, text or data that is configured on the gateway, or is somehow dependent on the receiver software version, local time, signal level at receiver, or such.</p><p>This ensures that the APRS-IS duplicate packet filtering methods work. When all the gateways emit the same packet, duplicates can be removed and a single copy will land at aprs.fi.<br /><br />Yes, this requires a little co-operation and coordination by the gateway software authors. Once you sort it out, and document what the format is, and which gateways support the consistent format, let me know and I'll open it up!</p><p>The gateways may announce their own software and custom comment strings in the beacon comment text sent to indicate the position of the gateway itself. It must not go to the comment string of the balloon; the packet of the balloon must be standardised and harmonised.</p><h2 style="text-align: left;">2. The packet rate must be sane, and in line with APRS operations</h2><p>Typical APRS stations beacon once every 30 seconds, or much less often, when they're not making tight turns. Once per 10 or 20 minutes when they're not moving. It's not acceptable for balloons to transmit on the APRS-IS once every 3 seconds, even if their data rate on RF would allow such an interval.<br /><br />If you need a higher rate for the recovery / location, make it dynamic - every 20 seconds when the balloon is at low altitude and just about to fall down. When flying really high - every 40 or 60 seconds should do, it's plenty. When they're high up, the packets will be heard by many receivers, which also brings the packet rate up greatly.</p><p><br /><a href="https://blogger.googleusercontent.com/img/a/AVvXsEg8_PpLeXxTwlbIB1xS3JPhR46qmfciYwzr_K4OHIuqdJoAt7mHxVn-TB-gCsxff8IDlx5_oywNW43uJX5EYCrTYDWXI19-0AbYojRdvkg4skT-qWd1cp6Kq2xYijx1IOfqT4y8CEKVbxHWIjlc-ee6fICluPUciaWJ6zn0UTtu-jGtbjQccyO1yWt5bw" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="912" data-original-width="2182" height="168" src="https://blogger.googleusercontent.com/img/a/AVvXsEg8_PpLeXxTwlbIB1xS3JPhR46qmfciYwzr_K4OHIuqdJoAt7mHxVn-TB-gCsxff8IDlx5_oywNW43uJX5EYCrTYDWXI19-0AbYojRdvkg4skT-qWd1cp6Kq2xYijx1IOfqT4y8CEKVbxHWIjlc-ee6fICluPUciaWJ6zn0UTtu-jGtbjQccyO1yWt5bw=w400-h168" width="400" /></a></p><p><br />The discussion on fixing this for radiosonde_auto_rx is ongoing in <a href="https://github.com/projecthorus/radiosonde_auto_rx/issues/618" target="_blank">these</a> <a href="https://github.com/projecthorus/radiosonde_auto_rx/issues/619" target="_blank">two</a> tickets, but the point is that all gateways need to work the same way.</p><p>73, and happy hacking!</p>Hessuhttp://www.blogger.com/profile/12550787353137508264noreply@blogger.com0tag:blogger.com,1999:blog-2631429776292642259.post-31395260860449722362022-02-19T19:00:00.028+02:002022-02-20T22:36:52.338+02:00Baofeng & BTech APRS-K1 & iPhone problems<b>TL;DR: It seems like many Baofeng radio units (UV-5R, UV-82, etc) do not work with the aprs.fi iPhone app using the BTech APRS-K1 cable. They do not work with any </b><b>iPhone app - I tried all the other APRS apps I have, and other non-APRS apps recording or playing back Audio.</b><b> It seems a bit like a build quality issue as it does not depend on the radio model, but rather the individual unit. It works for some people, but for many it doesn't. Other radios I have work fine. The Android phone I have works with the UV-5R, so it must have something to do with the circuitry on that side as well.</b><div><b><br /></b><h3 style="text-align: left;">There's a 1-capacitor fix/workaround in the end!</h3><div><br /></div>Many users of the <a href="https://apps.apple.com/us/app/aprs-fi/id922155038" target="_blank">aprs.fi iPhone app</a> have purchased an affordable Baofeng radio, and the BTech APRS-K1 cable, and have then tried to use those for APRS. It has worked for some users, but for many it has failed miserably. This setup does not have a PTT line to key the transmitter – instead, VOX is enabled so that the radio will transmit whenever there's audio coming from the iPhone or iPad.<div><br /><div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEhyI5ffbbjApxmvM7B3E56lLXAnkYLNatwYNd6s44vSwSfSPjl3T1gQmIpI_nyBWHX087tRG4-vkrGB3_kg-zZVMNqI3YuIIejeJuCe6Tgb0V1vNh5rGAYIlQj31xXokqeEW2L3Bb2adiakgwNxw6TgavtFAv2Mirz0Ywli209ej1O0lqvvqxjuADJQbQ" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img alt="" data-original-height="1554" data-original-width="4030" height="123" src="https://blogger.googleusercontent.com/img/a/AVvXsEhyI5ffbbjApxmvM7B3E56lLXAnkYLNatwYNd6s44vSwSfSPjl3T1gQmIpI_nyBWHX087tRG4-vkrGB3_kg-zZVMNqI3YuIIejeJuCe6Tgb0V1vNh5rGAYIlQj31xXokqeEW2L3Bb2adiakgwNxw6TgavtFAv2Mirz0Ywli209ej1O0lqvvqxjuADJQbQ" width="320" /></a></div>Users have reported that as soon as the aprs.fi DSP modem is enabled ("Connect TNC" is pressed in the iPhone app), the Baofeng transmitter goes on, and never goes off. When "Disconnect TNC" is pressed in the app to stop the modem, the transmitter goes off a second or two later.</div><div><br /></div><div>Naturally, at that point, the first guess would be that the modem would be emitting some noise, which would trigger the VOX in the Baofeng. But it doesn't, if you attach earphones and listen, or if you look at the modem output with an oscilloscope.</div><div><br /><div><div class="separator" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEgI3juRnGuyurWqJPXPeDa2P3N1ECzsgC21lSxYy-uMt51j8XLXEaQOQU0YmfduCD8qShhmYj9h3t15W5rX5pb01PGvQlolzHDmUDdIQzgpFntBRPxHyAMk03x2gkvyTDPnTOVQUKTSoGxMPdFUIPfaG59yofNaope5H1YIkBtiYgaMv3az9E3aQmbHNQ" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="3863" data-original-width="2475" height="240" src="https://blogger.googleusercontent.com/img/a/AVvXsEgI3juRnGuyurWqJPXPeDa2P3N1ECzsgC21lSxYy-uMt51j8XLXEaQOQU0YmfduCD8qShhmYj9h3t15W5rX5pb01PGvQlolzHDmUDdIQzgpFntBRPxHyAMk03x2gkvyTDPnTOVQUKTSoGxMPdFUIPfaG59yofNaope5H1YIkBtiYgaMv3az9E3aQmbHNQ" width="154" /></a></div>It doesn't depend on the radio model - UV-5R or UV-82. Some units work, some don't. I had only tested the app with a Puxing PX-777, a Kenwood TH-D72 and a Kenwood TH-D74, all using the same BTech APRS-K1 cable, as they all are using the same mic/headphone connector ensemble. All of them work fine. Well, as well as a VOX-driven APRS transmitter can work, i.e. not great, as the transmitter keys up slowly and goes off <i>very slowly</i> due to the VOX delays.</div><div><br />So a few weeks ago I finally ordered an UV-5R so that I could figure out what exactly is going on. I have a Siglent digital storage oscilloscope which allows me to look at the three audio channels between the iPhone and the radio: left & right headphone outputs, and the microphone input.</div><div><br /></div><div>I also bought a 4-wire 1-meter TRRS extension cable from Ebay, cut it up and made a 10 cm extension cable with exposed wires where I could attach the oscilloscope. The JAMEGA Gmbh cable is awful - no shielding/braid at all on the cable, and they even sell a 10-meter version. Not good for low-level audio signals. But it'll work for 10 cm.<br /></div></div></div><div><br /></div><div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEg3OL9-IJBSLfz6QyjzVeeKNHl67KJXNj0lvFNujuPtJBSYePOgciTzuGWVJFJDoPxB9n0zquwhNdUe9K8-1irOeV9efpCI6p5RISA8QgpvCydY5ieaJhnOkQPQMbWjq_V27e5oKk4_4OKbE7s6evNhUWFIFWTDu9P-MzUzWHoWWHxEQt9-4r0wvqS2hw" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="3024" data-original-width="4032" height="300" src="https://blogger.googleusercontent.com/img/a/AVvXsEg3OL9-IJBSLfz6QyjzVeeKNHl67KJXNj0lvFNujuPtJBSYePOgciTzuGWVJFJDoPxB9n0zquwhNdUe9K8-1irOeV9efpCI6p5RISA8QgpvCydY5ieaJhnOkQPQMbWjq_V27e5oKk4_4OKbE7s6evNhUWFIFWTDu9P-MzUzWHoWWHxEQt9-4r0wvqS2hw=w400-h300" width="400" /></a></div><br />The first thing to test: plug in just the APRS-K1 cable, without a radio at the other end, and see that the inputs and outputs on the adapters and cables are fine, and the scope sees the right things. In this oscilloscope screen shot you see the L/R headphone outputs on the bottom, when a packet starts to go out. The blue line on top is the microphone line, which has a little high-frequency noise on it, as it is a low-level high-impedance wire which is not attached to anything on the other end.</div><div><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEgNF1URAD-Y49s42uOS7KsiAs25no3DkEuwbNd9XXxcn8Y644TWAXx_5FfVc6JeCVnEhbt5gUUhNufi5UneYEfizDr1JG5_6JBv5LEdc3e1Az7U03FAUsnWP6CA982vnkyTugzwDmoyvE99UcgNlFxE__d45aw1LbtkYX0PI0Fby10nzMo8SQIEgcij1g" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="600" data-original-width="1024" height="235" src="https://blogger.googleusercontent.com/img/a/AVvXsEgNF1URAD-Y49s42uOS7KsiAs25no3DkEuwbNd9XXxcn8Y644TWAXx_5FfVc6JeCVnEhbt5gUUhNufi5UneYEfizDr1JG5_6JBv5LEdc3e1Az7U03FAUsnWP6CA982vnkyTugzwDmoyvE99UcgNlFxE__d45aw1LbtkYX0PI0Fby10nzMo8SQIEgcij1g=w400-h235" width="400" /></a></div><br />Ok, that seems fine. The lines are quiet when the app is not transmitting a packet, and the waveform seems alright when it is transmitting. But what happens when I attach the APRS-K1 cable to a Baofeng without touching oscilloscope settings? This! All the time! It does not matter whether the Baofeng is powered on or off. Attach a Kenwood or a Puxing, this does not happen. There's a high-frequency signal on the cable, on all 3 pins.</div><div><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEhYBQc6DETZFSvPuMUPc429tVRYNo-nWpfk39lS80M9fqwwFIhk1UNJnZAoUB7s6chuuFwMrI9vcnNVSsRPwVQtwuBtocUdgPaEdl9Kcgkd3FPi0xAHbo45W429U7VFcb9XVUkzyio-B2qJ4WZZAKyS8o6sLCnKor5v7vEzH6_INIQGEhqKz4DuRuEhWw" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="600" data-original-width="1024" height="235" src="https://blogger.googleusercontent.com/img/a/AVvXsEhYBQc6DETZFSvPuMUPc429tVRYNo-nWpfk39lS80M9fqwwFIhk1UNJnZAoUB7s6chuuFwMrI9vcnNVSsRPwVQtwuBtocUdgPaEdl9Kcgkd3FPi0xAHbo45W429U7VFcb9XVUkzyio-B2qJ4WZZAKyS8o6sLCnKor5v7vEzH6_INIQGEhqKz4DuRuEhWw=w400-h235" width="400" /></a></div><br />If we zoom in to it on the frequency scale, we find a 473 kHz signal on all 3 wires. The frequency is drifting, so it's probably not sourced from a good oscillator / clock reference. Click on the image to see a higher-resolution screen shot - frequency counter is in the top right corner, level measurements on the panel below the plots. Pretty high-level, so if the Baofeng is powered on, VOX probably keys up the transmitter. The frequency is so high that you won't hear any audio being transmitted if you listen to the transmission with another radio. This is how it looks with the iPhone and a Belkin Lightning-3.5mm adapter.</div><div><br /></div><div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEhbhsFfyteSPWhCpMF2RGDgXW9FVvKY_G2wDBqG4fAJ7cC6rBfUbUH4Ikl29FlCrxOoGP7n5W_yjPH9f84P36jdqJQrICpeQUL9qK8bSlbMloAvDyc_Zkm8PwtBGpmmh_jWf2OKlbvQeUXZx-c0C_AiL4PTQItWtoWBXwDwioBVO4EWW4Hkz14T0PusgA" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="600" data-original-width="1024" height="235" src="https://blogger.googleusercontent.com/img/a/AVvXsEhbhsFfyteSPWhCpMF2RGDgXW9FVvKY_G2wDBqG4fAJ7cC6rBfUbUH4Ikl29FlCrxOoGP7n5W_yjPH9f84P36jdqJQrICpeQUL9qK8bSlbMloAvDyc_Zkm8PwtBGpmmh_jWf2OKlbvQeUXZx-c0C_AiL4PTQItWtoWBXwDwioBVO4EWW4Hkz14T0PusgA=w400-h235" width="400" /></a></div><div><br /></div></div><div>With the Belkin lightning-3.5mm adapter, levels are 150 & 330 mV L/R, frequency is about 470 kHz. </div><div><br />If I turn on the Baofeng, the VOX triggers, transmitter goes on, and on the oscilloscope the only difference is that there's some high-frequency noise on wires, which can be expected as there is a 5W transmitter on the table. Even though it's transmitting to a dummy load instead of an antenna, this is to be expected.</div><div><br /></div><div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEiNNJzbtXhB5CR_44anxBU0T2FLA_KnO7ivZrKzcUPLvx0tj9zb4Pmw1H3bUjiksyqCPn_KY7uxqVVgp2BCqRAL0uIT14cDT19dp8zciRgzyWRSmdcNBA6JUSA85iTD1-t8o6aRT-T86B3am5tsujOZeTiQg6zrsqBDLJ1wD3FyusoMnCDWOvfKrVGKBw" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="600" data-original-width="1024" height="235" src="https://blogger.googleusercontent.com/img/a/AVvXsEiNNJzbtXhB5CR_44anxBU0T2FLA_KnO7ivZrKzcUPLvx0tj9zb4Pmw1H3bUjiksyqCPn_KY7uxqVVgp2BCqRAL0uIT14cDT19dp8zciRgzyWRSmdcNBA6JUSA85iTD1-t8o6aRT-T86B3am5tsujOZeTiQg6zrsqBDLJ1wD3FyusoMnCDWOvfKrVGKBw=w400-h235" width="400" /></a></div><div><br /></div>This is the same thing, without the Belkin adapter, when attaching directly to the 3.5mm connector of my iPad - levels are lower at 20 & 110 mV L/R, frequency is 555 kHz. Baofeng is off, so no high-frequency noise from the transmitter.</div><div><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEihQ5CzC2Nu6Q2gRJfQWSZZxE4zRZmt818tHA-Qcn2q-l3nPW4erN462pUav9AAQP-vtauigYYjY0EoW4XgKrjiNbClrHtFCq_YUIPgqeo2jbys2-HduD2vJKV-gsNXDRTKMvD1zLiBpd4Tu52qgbgyjisEo5yvXpxT7p15P8SyARQnpISDYQxvTXWQww" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="600" data-original-width="1024" height="235" src="https://blogger.googleusercontent.com/img/a/AVvXsEihQ5CzC2Nu6Q2gRJfQWSZZxE4zRZmt818tHA-Qcn2q-l3nPW4erN462pUav9AAQP-vtauigYYjY0EoW4XgKrjiNbClrHtFCq_YUIPgqeo2jbys2-HduD2vJKV-gsNXDRTKMvD1zLiBpd4Tu52qgbgyjisEo5yvXpxT7p15P8SyARQnpISDYQxvTXWQww=w400-h235" width="400" /></a></div></div><div><br /></div><div>Now, the interesting detail is that this only happens when the iPhone audio interface (A/D and D/A converter chip & amplifiers) are powered on and capturing audio. Could it be a feedback loop of some kind, between the A/D D/A converters and the circuitry on the Baofeng, with the A/D/A converter leaking the 500 kHz signal back and amplifying it? Or an oscillator is formed together with the Baofeng?</div><div><br />The iPhone has a power management system, where unnecessary components are powered off to conserve battery power. If any application (Voice Memos, Camera app in video capture mode, or the aprs.fi app) starts to record audio from the microphone input, the electronics of the A/D and D/A converters are powered on. This explains why the transmitter goes on when you start recording audio on the iPhone, or when you turn on the modem in the aprs.fi app. If you're wearing headphones attached to the iPhone and start audio playback from any app, or start recording in one of those apps, you can even hear a small "pop" sound in the headphones - it's the D/A converter waking up! It looks like this on the oscilloscope:</div><div><br /></div><div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEguNtGoM1hqclCsputOABQSyVhpxPwqRAa81GRfNDy7HKYWDk91rxXHUhSq5Mv_Ek0QqZCIExhkJwruL63X6s-Ltm6I7M5xKKmybApOtcn5W3o4oIAnk5ZTBNIYPe655cnwKtbtt3ySy_pYXDqK4VpGxLDS84fUp0bn6qF1Vsm4lzw2nxRZR6BQFhH9tw" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="600" data-original-width="1024" height="235" src="https://blogger.googleusercontent.com/img/a/AVvXsEguNtGoM1hqclCsputOABQSyVhpxPwqRAa81GRfNDy7HKYWDk91rxXHUhSq5Mv_Ek0QqZCIExhkJwruL63X6s-Ltm6I7M5xKKmybApOtcn5W3o4oIAnk5ZTBNIYPe655cnwKtbtt3ySy_pYXDqK4VpGxLDS84fUp0bn6qF1Vsm4lzw2nxRZR6BQFhH9tw=w400-h235" width="400" /></a></div><br />Because someone reported the same Baofeng + APRS-K1 cable setup works with APRSDroid on an Android phone, I tried it with my Nokia here. Yes, it does work, so there must be some difference in the audio circuitry or how it is used!</div><div><br /></div><div>On Android, the A/D and D/A circuits seem to be powered separately. Georg DO1GL says that APRSDroid only outputs audio samples when it is transmitting a packet, and captures audio samples continuously for the receive to work. When looking at it on an oscilloscope, there is a 260 mV DC offset on one headphone audio channel when it's not transmitting. The DC offset goes away during transmit, and some time after the packet has ended, the DC offset comes back. There is also some additional noise on the output of the Android phone for some time after the packet has gone out, and the noise stops when the 260 mV DC offset appears. It would seem to me that the D/A is powered on only when audio goes out, and it can be powered off even when A/D conversion is taking place.</div><div><br />On the iPhone it seems to me that the D/A cannot be powered off independently. All audio-recording applications which I tried cause the D/A to be powered up and the strong 500 kHz signal to be generated if attached to the Baofeng. I tried all the APRS apps with DSP modems, and several other audio-capturing applications, and they all trigger the noise, if my Baofeng is attached.</div><div><br /><h3 style="text-align: left;">Oh well. If it's feedback or oscillation, can we fix it by adding capacitance? Turns out we can!</h3></div><div><br /></div><div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEitc_nFyaa3kYVmshjI3JQodfaw0kBh0L-EeJsGvy4vb3PVUzJjRr4us2pQ_88zKfa0T2YAVqpgYT7e1nr0isYPlH3klhzz6MI9oYg-2giIszGcIuuuxEIS0mibDpe6okSSf0EPMOl-l_jjlUrbiRBQh24FZBQErB-v7oelXXSjYkxBubG3M8takG8G6Q" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img alt="" data-original-height="1674" data-original-width="3661" height="146" src="https://blogger.googleusercontent.com/img/a/AVvXsEitc_nFyaa3kYVmshjI3JQodfaw0kBh0L-EeJsGvy4vb3PVUzJjRr4us2pQ_88zKfa0T2YAVqpgYT7e1nr0isYPlH3klhzz6MI9oYg-2giIszGcIuuuxEIS0mibDpe6okSSf0EPMOl-l_jjlUrbiRBQh24FZBQErB-v7oelXXSjYkxBubG3M8takG8G6Q" width="320" /></a></div><div>I'm not much of an electrical engineer, but sometimes you can work around issues like this by just adding a bit of inductance or capacitance somewhere in a very experimental fashion, without applying too much science or math.</div><div><br /></div><div>If you peel off the sticker on top of the APRS-K1 dongle, and open the two small Phillips screws, you'll find a small circuit board with a few capacitors and resistors. In this picture, the radio is attached to the left side, and the iPhone is attached to the right side. Red wire is the microphone wire on each side, white is the earphone wire, and black is ground. No isolation transformers.</div></div><div><br /></div><div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEjI5DU578oRuwT4iWvbXIeHabiE3yd2W9WtoI-PjZs9_MVp2MWMTel5v6QffhSs20ZTgWJEMwwfWJbG57Nm1sJyhwdm14ohOYLp4zm5AS1t921N2qy1XN0tLXD1JX1_Wn-2bzf93DUZyknOKkGw1EWOUM8T-j2A9sYQ5ClSDeXhQQL2hu1KJv5yQSB1iQ" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img alt="" data-original-height="1685" data-original-width="3204" height="168" src="https://blogger.googleusercontent.com/img/a/AVvXsEjI5DU578oRuwT4iWvbXIeHabiE3yd2W9WtoI-PjZs9_MVp2MWMTel5v6QffhSs20ZTgWJEMwwfWJbG57Nm1sJyhwdm14ohOYLp4zm5AS1t921N2qy1XN0tLXD1JX1_Wn-2bzf93DUZyknOKkGw1EWOUM8T-j2A9sYQ5ClSDeXhQQL2hu1KJv5yQSB1iQ" width="320" /></a></div>The iPhone-to-radio-mic connection has just a single 100 nF capacitor for blocking DC, on the bottom of the circuit board. The radio speaker -> iPhone mic path, on the upper side of the board, from left to right, has a series capacitor (10 nF), a 2-resistor voltage divider (10 kOhm top, 2.2 kOhm bottom half), a second series capacitor (guessing 10 nF but couldn't measure), and a 1.8 kOhm resistor to ground, which tells the iPhone that a microphone is connected.</div><div><br /></div><div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEhB_bC0EL7yytqON2j13omVwjJOKKRsKKEBni5xmMnRHoZNEbDex5Cqd51wtGvIehKakc1ClFiuXxvJFPFz3QFS2TGsWY0yZlRIWt5NBkZVw0MyLj76BXks8Xrm4h7lcTHMREGo_WAKvZ058RwfEf__zgK93vlb6DesFQFNVdI84z-GBoWt7lJ3F_mjaw" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img alt="" data-original-height="4032" data-original-width="3024" height="240" src="https://blogger.googleusercontent.com/img/a/AVvXsEhB_bC0EL7yytqON2j13omVwjJOKKRsKKEBni5xmMnRHoZNEbDex5Cqd51wtGvIehKakc1ClFiuXxvJFPFz3QFS2TGsWY0yZlRIWt5NBkZVw0MyLj76BXks8Xrm4h7lcTHMREGo_WAKvZ058RwfEf__zgK93vlb6DesFQFNVdI84z-GBoWt7lJ3F_mjaw" width="180" /></a></div>I checked with the oscilloscope that the 500 kHz signal was strongest on the bottom right corner, the wire labeled <b>Phone SP</b>, i.e. audio output from the phone. I grabbed a box of capacitors which were small enough to likely fit within the enclosure, tried the smallest and largest values (10 nF and 470 nF) by just pressing the capacitor wires on the SP and GND pins (black and white wire), and found that the largest one stopped the oscillation completely!</div><div><br />Most importantly, the Baofeng UV-5R is no longer stuck transmitting!<br /><br />I then tried different values, and found that when attached to the iPad, where the 500 kHz signal levels were lower, a smaller value of 220 nF was enough. With the iPhone and the Belkin 3.5 mm adapter, only 470 nF cured it.</div><div><br /></div><div>In hindsight, I could have tried putting the cap on the other pins as well - a lower value might have worked in another location. But this worked well enough and I didn't want to spend any more time on it, so I just soldered the capacitor in place, measured the results and closed the package!</div><div><br />This is how it looks with Baofeng UV-5R attached and powered on:<br /><br /></div><div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEgDfmyp_s6r2CveryQkYCS6zbgkRbIZnukjL5M2hVyqPCjOARsFkamRJgOEeymvB1Qjy1AUZ3yXqe304l4wUaJwqa80uIJnl2PrPNpjFM8-q3tq3wctcmPh1WiV9gbCgGSJYMJXnFP8Xsc0EgCxB6JHX-v37Nf829unIKcWQwdyvWkS-2IeEfsZMGV95A" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="600" data-original-width="1024" height="235" src="https://blogger.googleusercontent.com/img/a/AVvXsEgDfmyp_s6r2CveryQkYCS6zbgkRbIZnukjL5M2hVyqPCjOARsFkamRJgOEeymvB1Qjy1AUZ3yXqe304l4wUaJwqa80uIJnl2PrPNpjFM8-q3tq3wctcmPh1WiV9gbCgGSJYMJXnFP8Xsc0EgCxB6JHX-v37Nf829unIKcWQwdyvWkS-2IeEfsZMGV95A=w400-h235" width="400" /></a></div><div><br /></div>And this is how it looks when a packet is being transmitted. Note how the left and right audio output channels look the same, even though the parallel capacitance is present on one of those channels. Seems like it doesn't affect the transmitted audio too badly. Levels are different from the very first oscilloscope screen shot, because I've reduced the volume on the iPhone a bit.</div><div><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEiKohsdY4lew2vVeDzv8zhExTa-ddIGsLkjvcwjL8vVDwjCZCs9AqF4Blww1xvuTt49HYnvT4pTO8_KGiLa_lwPwACz31n7jxvLWxQhCgzM0jUqpID1B_SBqwSgIR_ub7kFJ7wwASQ3cGzQiHqC7OUBKdFLWBCWakPkjQI-0YQYk3PWW1D0ANwgqxCpKg" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="600" data-original-width="1024" height="235" src="https://blogger.googleusercontent.com/img/a/AVvXsEiKohsdY4lew2vVeDzv8zhExTa-ddIGsLkjvcwjL8vVDwjCZCs9AqF4Blww1xvuTt49HYnvT4pTO8_KGiLa_lwPwACz31n7jxvLWxQhCgzM0jUqpID1B_SBqwSgIR_ub7kFJ7wwASQ3cGzQiHqC7OUBKdFLWBCWakPkjQI-0YQYk3PWW1D0ANwgqxCpKg=w400-h235" width="400" /></a></div><br />Now, when I got it transmitting, I found out that the Baofeng is deaf. I have it attached to a 2*5/8 vertical antenna on the roof, which I use with other radios normally, and the transmissions go out just fine, but the squelch on the Baofeng does not open up when the nearby digipeaters transmit. On the other hand, squelch needs to be used, otherwise VOX will not key the transmitter at all, as VOX refuses to transmit when the squelch is open. I <i>will not </i>investigate that issue any further. :)</div></div>Hessuhttp://www.blogger.com/profile/12550787353137508264noreply@blogger.com0tag:blogger.com,1999:blog-2631429776292642259.post-6706040554112464562021-07-22T11:05:00.009+03:002021-07-22T11:16:25.106+03:00Manual stopping of the aprs.fi iPhone app is unnecessary<p>Quite often someone says the aprs.fi app is starting up with the map showing Helsinki instead of the previous map view and position, and requests for an improvement to the app to save the last location on the map. Well, it turns out that the app certainly does save the last location, and in fact a fairly complete state of many other views, <i>every time the app leaves the screen</i>. It is saved to a <b>state restoration file</b>. It will return to that view, based on the restoration file, even if the operating system needs to free up memory for other apps and removes the aprs.fi app from memory. Even after the whole iPhone is rebooted.</p><p></p><div class="separator" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em; text-align: center;"><a href="https://lh3.googleusercontent.com/-qO6gKElltr4/YPkXIH58zKI/AAAAAAAADfA/71Ei2NxLwkoznLB42-IWTxuvUpTEYIaegCLcBGAsYHQ/image.png" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="2048" data-original-width="1111" height="240" src="https://lh3.googleusercontent.com/-qO6gKElltr4/YPkXIH58zKI/AAAAAAAADfA/71Ei2NxLwkoznLB42-IWTxuvUpTEYIaegCLcBGAsYHQ/image.png" width="130" /></a></div>I invite you to make a quick test:<p></p><p></p><ol style="text-align: left;"><li>Position to your location (using the GPS centering button in the low right corner), or any other preferred position other than Helsinki.<br /><br /></li><li>Leave the app: Go to home screen by pressing the home button or swiping up on a device without a home button. <b>Do not</b> go to the most-recently-used apps list and swipe the aprs.fi app up to manually kill it. Just don't.<br /><br />When the app goes out of view the app saves the current view and state to a small <b>state restoration file</b>. Within some 5 to 20 seconds iOS will completely suspend the app from running, unless beaconing is enabled or the software TNC is running and streaming audio. It will not run in background, unless there is a necessary background task, and the iOS operating system <i>will not allow it to execute on the CPU</i>.<br /><br />iOS also takes a screen shot from the app on the screen at this point, and saves it on persistent storage along with the restoration file (SSD/flash memory).<br /><br /></li><li>Turn off the power of the iPhone (Settings -> General -> Shut down). Just to prove the point. This will, for sure, terminate all apps and remove them from memory.<br /><br /></li><li>Turn on phone, and open up the aprs.fi app. At this point it is started again, and it reads the state restoration file.<br /><br /></li><li>Observe the app magically returning to your last view. It can even return to most other views than map view after a complete reboot cycle. If you were tracking stations, it will continue to track the same stations at their current locations. If you were at the Help screen before the reboot, it'll go back to Help!<br /><br />To make the "cold start" of the app <i>look faster</i>, iOS will initially display the screen shot of the app it took in step 2, until the app is actually running and producing stuff on the screen. Even after a reboot, it looks very much like the app would have been running all the time. Sufficiently advanced technology looking like magic, again.<br /><br /></li><li>If you manually terminate the app by swiping it up from the recent apps list, <b>iOS will delete the state restoration file</b> and the screen shot, so that the next startup of the app will happen from a clean state. It will not be able to go back to the previous view. On the next cold start the app will show a splash screen with the aprs.fi logo instead of the screen shot.</li></ol><div>Quite a few people have a habit of killing apps and removing the state files by swiping them up from the recent apps list. This is probably because the misconception that those apps would be running on the CPU and consuming memory, and killing them would free up resources and save energy. This would be quite logical and is rooted in the history of traditional computers. The Internet has a thousand sites describing this procedure and claiming it'd do something good. Unfortunately not everything written on the Internet is true.<br /><br />In fact the iPhone/iPad iOS operating system is already doing all that needs to be done! When an app goes out of view, iOS normally <b>suspends</b> all execution of the app after about 5 seconds. The <b>suspended</b> app will remain in RAM memory, though, until that memory is needed for something else. If there's enough memory and you return to that app soon without using a lot of memory in other apps, iOS can simply wake the app up from memory and it will resume running very quickly. It may remain <b>suspended</b> in memory for a very long time if you use it frequently without using a lot of memory in other apps. The power usage of that memory is very small, and the amount of power used does not change based on how much stuff is currently stored.</div><div><br /></div><div><div class="separator" style="clear: both; text-align: center;"><a href="https://lh3.googleusercontent.com/-mTsBYvIyJ1k/YPkRJekdQFI/AAAAAAAADe4/EEjn0ml93NMoHJmWpS66a8eqosVLv7KgACLcBGAsYHQ/image.png" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img alt="" data-original-height="905" data-original-width="784" height="400" src="https://lh3.googleusercontent.com/-mTsBYvIyJ1k/YPkRJekdQFI/AAAAAAAADe4/EEjn0ml93NMoHJmWpS66a8eqosVLv7KgACLcBGAsYHQ/w346-h400/image.png" width="346" /></a></div>When the <b>active</b> app currently running in <b>foreground</b> (i.e. displayed on screen) needs more memory and there isn't any memory available, iOS will quietly free up memory by fully terminating some of the other apps which are currently suspended. When a terminated app is started again, it will need to initialise itself and read all resource files from the permanent flash storage. All of this takes much more CPU, wall-clock time and electrical energy than waking up from RAM memory.</div><div><br /></div><div>If apps are unnecessarily terminated manually, they will use more energy when they are used again, as opposed to the situation where they are simply woken up from suspended state.</div><div><br /></div><div>The attached image is from the <a href="https://developer.apple.com/documentation/uikit/app_and_environment/managing_your_app_s_life_cycle?language=objc" target="_blank">Apple developer documentation</a>. The app transitions through the Inactive states very quickly when moving between the Active state and other states.</div><div><br /></div><div>That said, some apps can also run in the background, but only while performing one of a few specific tasks: playing music, VoIP calls (skype, whatsapp calls, other telephony), receiving GPS location updates for navigation, and a few other things. Each of these <b>Background Modes</b> need to be specifically permitted by an Apple employee during the app review process. For example, an app without actual user-visible mapping, navigation or location-related features are not allowed not obtain GPS positions in the background.</div><div><br /></div><div><div class="separator" style="clear: both; text-align: center;"><a href="https://lh3.googleusercontent.com/-D0NUt9oeo8A/YPkZ0iXZT4I/AAAAAAAADfI/wZL0T6WDUBAchMY-idC-kwXvXvtxgLBlwCLcBGAsYHQ/image.png" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img alt="" data-original-height="721" data-original-width="1170" height="123" src="https://lh3.googleusercontent.com/-D0NUt9oeo8A/YPkZ0iXZT4I/AAAAAAAADfI/wZL0T6WDUBAchMY-idC-kwXvXvtxgLBlwCLcBGAsYHQ/w200-h123/image.png" width="200" /></a></div>The aprs.fi app plays and records audio in the background when the software DSP modem is running. A red "recording" symbol will show up in the top of the screen whenever this happens in the background, and tapping that symbol will pop up the app doing it.<br /></div><div><br /></div><div><div class="separator" style="clear: both; text-align: center;"><a href="https://lh3.googleusercontent.com/-FIq5cJ0_u0c/YPknrZYwQ0I/AAAAAAAADfw/ubdynFn7w0gQo7GyleN-PN6rYqmX4Em9ACLcBGAsYHQ/image.png" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img alt="" data-original-height="1528" data-original-width="1170" height="240" src="https://lh3.googleusercontent.com/-FIq5cJ0_u0c/YPknrZYwQ0I/AAAAAAAADfw/ubdynFn7w0gQo7GyleN-PN6rYqmX4Em9ACLcBGAsYHQ/image.png" width="184" /></a></div>The aprs.fi app can also receive GPS location updates when beaconing is enabled and the app is given permission to obtain location data in the background. The "Allow location access" setting in iOS Privacy settings must be set to "Always". "While Using the App" setting only gives location data when the application is in the <b>Active</b> state, i.e. in the foreground, displayed on the screen. The app will naturally only request and receive location updates in the background when beaconing is enabled - requesting the frequent location updates uses a significant amount of energy since it powers up the GPS circuitry. The battery drains much faster if beaconing is enabled! If the software modem is not running, and beaconing is off, the app will be properly suspended within seconds after it leaves the screen.</div><div><br /></div><div>After saying all of this: There are a few cases where manual termination of the app may be necessary. If the state restoration file is corrupted, and the app crashes on startup while reading it, manual termination will delete the file and work around the issue.</div><div><br /></div><div>Once I had a bug in the app, where the user could navigate to a view which had no working "go back" button, and no way to switch tabs. The app was running but the user was stuck there on that single screen. To make things worse, state restoration worked perfectly, so even after a full iPhone reboot the user would be automatically brought back to this view! Again, a manual termination of the app removed the state restoration file and the app would again start up in the map view, and all was fine as long as the user did not go to that same view again.</div><div><br />A buggy app could accidentally also continue recording audio, or receiving GPS location coordinates, after it no longer needs them. But iOS will tell you if they do this, and you can then terminate them if necessary.</div><div><br /></div><div>A former Apple Genius Bar technician, Scotty Loveless, <a href="https://lifehacker.com/quitting-apps-in-ios-actually-worsens-battery-life-1560086834" target="_blank">wrote</a>:</div><div></div><blockquote><div>"By closing the app, you take the app out of the phone's RAM . While you think this may be what you want to do, it's not. When you open that same app again the next time you need it, your device has to load it back into memory all over again. All of that loading and unloading puts more stress on your device than just leaving it alone. Plus, iOS closes apps automatically as it needs more memory, so you're doing something your device is already doing for you. You are meant to be the user of your device, not the janitor.</div><div><br /></div><div>The truth is, those apps in your multitasking menu are not running in the background at all: iOS freezes them where you last left the app so that it's ready to go if you go back. Unless you have enabled Background App Refresh, your apps are not allowed to run in the background unless they are playing music, using location services, recording audio, or the sneakiest of them all: checking for incoming VOIP calls , like Skype. All of these exceptions, besides the latter, will put an icon next to your battery icon to alert you it is running in the background."</div><div></div></blockquote><div>In 2016, an <a href="https://9to5mac.com/2016/03/10/should-you-quit-ios-apps-answer/" target="_blank">iPhone user decided to email Apple CEO</a>, Tim Cook, and ask whether manual killing of apps would extend battery life. The reply came from Apple's senior VP of Software Engineering, Craig Federighi:</div><div><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://lh3.googleusercontent.com/-zvvmT1n5-eM/YPkeP5wDdXI/AAAAAAAADfQ/PeCBEM8eCC8ajKQpmZSBfzn3RE9hFw7CQCLcBGAsYHQ/image.png" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="269" data-original-width="411" src="https://lh3.googleusercontent.com/-zvvmT1n5-eM/YPkeP5wDdXI/AAAAAAAADfQ/PeCBEM8eCC8ajKQpmZSBfzn3RE9hFw7CQCLcBGAsYHQ/s16000/image.png" /></a></div><br />The <a href="https://medium.com/@kendallbaker/stop-force-quitting-your-iphone-apps-eb13d86caaa5" target="_blank">recommendation of Kendall Baker</a> is golden:<br /><blockquote>"As for the multitasking menu, think of that as a “Recently Used” section, as opposed to a “Currently Open” one."</blockquote></div><p></p>Hessuhttp://www.blogger.com/profile/12550787353137508264noreply@blogger.com0tag:blogger.com,1999:blog-2631429776292642259.post-5521441004909468452020-05-13T22:08:00.000+03:002020-05-13T22:23:51.107+03:00aprs.fi iPhone / iPad 2.0 with Messaging, APRS-IS TX and DSP modemVersion 2.0 of the aprs.fi iPhone & iPad app is now out! A new major version is well deserved, since it comes with the following new major features:<br />
<ul>
<li>APRS text messaging</li>
<li>APRS-IS position beaconing</li>
<li>A high-performance software DSP modem/TNC (1200 bit/s only at this time)</li>
<li>Longer time ranges in map and graph views, arbitrary date/time ranges on map</li>
<li>Up to 10 station profiles in Beacon</li>
</ul>
<div>
The features listed above are enabled by purchasing the Extra Features subscription with an in-app payment.<br />
<span class="s1" style="background-color: white; font-variant-ligatures: no-common-ligatures;"><span style="font-family: inherit;"><br /></span></span>
<span class="s1" style="background-color: white; font-variant-ligatures: no-common-ligatures;"><span style="font-family: inherit;">There's a 1-week free trial included in the</span></span><span style="background-color: white; font-family: inherit;">1-year subscription, but remember to cancel at least 24 hours before the </span><span style="background-color: white; font-family: inherit;">end of the trial, as Apple will charge the next period up to 24 hours before </span><span style="background-color: white; font-family: inherit;">each subscription term ends! They do this to ensure continuous service when the period ends and switches to the next one.</span></div>
<div>
<div class="p1" style="font-stretch: normal; font-variant-east-asian: normal; font-variant-numeric: normal; line-height: normal;">
<span style="background-color: white; font-family: inherit;"><br /></span></div>
<div class="p1" style="font-stretch: normal; font-variant-east-asian: normal; font-variant-numeric: normal; line-height: normal;">
<span style="background-color: white; font-family: inherit;">This is a big release for me, since I have <i>literally</i> worked on these features for a few years. It's been a bit slow, but I finally managed to put together a set of major features which should be well worth the </span>subscription price. <a href="http://blog.aprs.fi/2018/12/subscription-for-extra-features-ios.html" target="_blank">The story and reasoning behind the subscription model is throughly described in a previous blog</a> post so I won't dive into it now.</div>
</div>
<br />
In addition to the Extra Features, there are a few new things which are available to all users:<br />
<ul>
<li>Beaconing now has a slider control to adjust the maximum interval between beacon transmissions between 5 minutes and 60 minutes. Previous versions had this fixed to 25 minutes. If the minimum and maximum sliders are set to the same value, it will beacon with quite exactly that interval. If they're set to different intervals, the app will use an algorithm similar to smart beaconing, as before - move faster, it will transmit more often. If you don't move, the maximum interval is used.</li>
<li>The map view now has a button to adjust the time range.</li>
</ul>
<div>
And, of course, a few bug fixes here and there.</div>
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen="" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/6i022oJ0-ko/0.jpg" frameborder="0" height="266" src="https://www.youtube.com/embed/6i022oJ0-ko?feature=player_embedded" width="320"></iframe></div>
<br />
Messaging is implemented in a very iPhone-like way. Received ACKs are shown as a delivery status for each sent message. Transmitting works either via a TNC (Mobilinkd TNC3 or the new built-in DSP modem), or via the Internet (aprs.fi / APRS-IS). Received messages come in via both paths transparently, and it indicates whether each message got in via TNC or Net, or both. Messages received from the APRS-IS are delivered to the iPhone using a Push Notification, so you'll get a notification just like you'd get from an SMS or iMessage, even if the app would not be running at the time. If you have an iWatch it'll also show the notification with message contents!<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen="" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/tgKylmFlTOE/0.jpg" frameborder="0" height="266" src="https://www.youtube.com/embed/tgKylmFlTOE?feature=player_embedded" width="320"></iframe></div>
<br />
The demodulator of the TNC is based on the excellent Direwolf modem by John Langner, who kindly permitted me to redistribute his code under the BSD license. I've just reorganised the code quite a lot, and optimised it for less CPU consumption when compiled for the iPhone. It decodes really well - I've benchmarked it with the WA8LMF TNC Test CD and it's in the top category by the number of decoded packets, when compared to the benchmark results published for other TNCs by John in the Direwolf documentation. I'll leave comparative tests and public benchmarking to other neutral parties!<br />
<br />
The modulator of the TNC is partially derived from javAX25 by Sivan Toledo, and its C port by Alejandro Santos, who have also kindly permitted me to redistribute under the BSD license.<br />
<br />
I still do recommend the Mobilinkd TNC3, since it has an actual PTT circuit to key the transmitter, and it talks with the iDevice over BLE - no wires needed to attach the iPhone. With an audio / DSP modem you'll have to use VOX to key the transmitter, and the transmitter will start up slowly (requiring a large TX delay setting) and will turn off slowly as well (eating precious channel time).<br />
<br />
Here's a little video showing packets being decoded <a href="https://twitter.com/aprsfi/status/1256151993099399169" target="_blank">right off the speaker</a>. Once I get an iGate implemented I'll have to run the iGate for a few days like this, just for the silliness value.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://1.bp.blogspot.com/-GkXycluXeJ4/XrxEmcj785I/AAAAAAAADSw/nWVDj6EGlw8h0SBnWPl8_StM9Ry-OsyUACLcBGAsYHQ/s1600/aprsfi-msg-iwatch.jpeg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1200" data-original-width="1600" height="300" src="https://1.bp.blogspot.com/-GkXycluXeJ4/XrxEmcj785I/AAAAAAAADSw/nWVDj6EGlw8h0SBnWPl8_StM9Ry-OsyUACLcBGAsYHQ/s400/aprsfi-msg-iwatch.jpeg" width="400" /></a></div>
Hessuhttp://www.blogger.com/profile/12550787353137508264noreply@blogger.com0tag:blogger.com,1999:blog-2631429776292642259.post-47584717542966833362020-03-22T12:36:00.000+02:002020-05-13T22:08:51.690+03:00aprs.fi supports Kenneth's Proposed Telemetry Format<blockquote class="tr_bq">
<span style="font-family: "times" , "times new roman" , serif;"><i><b>Telemetry</b> is the collection of measurements or other data at remote or inaccessible points and their automatic transmission to receiving equipment for monitoring. The word is derived from the Greek roots tele, "remote", and metron, "measure".</i> (Wikipedia)</span></blockquote>
APRS telemetry can be used to transmit things like <a href="https://aprs.fi/telemetry/?call=KK5CM-1" target="_blank">voltages</a>, <a href="https://aprs.fi/telemetry/a/OH7RDA?range=week" target="_blank">temperatures</a>, and <a href="https://aprs.fi/telemetry/a/OH2RCH" target="_blank">channel traffic status</a> from anywhere to everyone on the APRS network.<br />
<br />
<b>Today I've changed how aprs.fi deals with telemetry values.</b> The change is backwards compatible, but if you start to play with this on the transmitting side, strict classic implementations may not accept your data any more. Please read the whole article if you're going to make use of this.<br />
<div>
<br /></div>
The APRS protocol is documented in <a href="http://www.aprs.org/doc/APRS101.PDF" target="_blank">APRS101.PDF</a>. Chapter 13 specifies how telemetry can be transmitted. Analog values are defined to be 8-bit integers:<br />
<blockquote class="tr_bq">
<i><span style="font-family: "timesnewromanpsmt";">There are five 8-bit unsigned analog data values (expressed as 3-digit
decimal numbers in the range 000–255), followed by a single 8-bit digital
data value (expressed as 8 bytes, each containing </span><span style="font-family: "courier";">1</span><span style="font-family: "timesnewromanpsmt";"> or </span><span style="font-family: "courier";">0</span><span style="font-family: "timesnewromanpsmt";">).</span></i></blockquote>
In year 2020 you may find this a little bit restrictive, as a lot of measurements are done at slightly higher resolution these days. Even the popular <a href="https://datasheets.maximintegrated.com/en/ds/DS18B20.pdf" target="_blank">DS18B20</a> temperature sensor does 12 bits. Oh, and it can do negative temperatures too.<br />
<br />
Values that are negative, or larger than 255, or decimal values which fit within 8 bits, are supposed to be scaled to fit within the 0...255 range. A separate EQNS Equation Coefficients packet should be sent to provide coefficients <i>a</i>, <i>b</i> and <i>c</i>, which are used to scale the transmitted value <i>v</i> back to the original measured value <i>X </i>using the formula:<br />
<blockquote class="tr_bq">
<span style="font-family: "timesnewromanpsmt"; font-size: 11pt;">X = a *</span><span style="font-family: "arialmt"; font-size: 8pt;"> </span><span style="font-family: "timesnewromanpsmt"; font-size: 11pt;">v</span><span style="font-family: "timesnewromanpsmt"; font-size: 7pt; vertical-align: 5pt;">2 </span><span style="font-family: "timesnewromanpsmt"; font-size: 11pt;">+ b *</span><span style="font-family: "arialmt"; font-size: 8pt;"> </span><span style="font-family: "timesnewromanpsmt"; font-size: 11pt;">v + c</span></blockquote>
So, you could scale temperatures between -40 and +60 Celsius to a range of 0..100 by adding 40, and then transmit an EQNS packet saying a = 0, b = 1, c = -40, and the recipient could then figure that a transmitted value of 60 would be 0*60^2 + 1*60 + -40 = 2<span style="font-family: "times" , "times new roman" , serif;">0<span style="background-color: white;">°</span>C</span>.<br />
<br />
But if you follow the spec, there's no way to transmit a 80-degree temperature range (-40°C to +40°C) with a 0.1°C resolution. It could be scaled to 0..800 range, but it'd overflow the 8-bit upper limit of 255.<br />
<div>
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://1.bp.blogspot.com/-_-G1V89OEes/XnKbSJw62tI/AAAAAAAADN0/YuN5Eoilz3wv4rO4_f2GwTeJYzvo6DzYACLcBGAsYHQ/s1600/aprs-tlm-temp-sensor-1.jpg" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" data-original-height="1067" data-original-width="1600" height="213" src="https://1.bp.blogspot.com/-_-G1V89OEes/XnKbSJw62tI/AAAAAAAADN0/YuN5Eoilz3wv4rO4_f2GwTeJYzvo6DzYACLcBGAsYHQ/s320/aprs-tlm-temp-sensor-1.jpg" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">One of my in-house temperature & humidity sensors.<br />
ESP8266 on wifi + DHT22 compatible AM2302 sensor.<br />
Not APRS though, MQTT to Graphite & Grafana.</td></tr>
</tbody></table>
Needless to say, a lot of people found this unnecessarily complicated and limited, and figured they could just ignore the slightly archaic specification and simply transmit and accept values larger than 255, decimal values, and negative values. When I originally implemented telemetry decoding for aprs.fi in 2008, I already found a lot of this happening.<br />
<br />
I figured there must be other implementations that are more relaxed than APRS101.PDF and just went along, picking a backwards compatible but slightly more relaxed schema using the <a href="https://www.urbandictionary.com/define.php?term=Stetson-Harrison%20method" target="_blank">Stetson-Harrison</a> method, without really documenting the situation. So, until today, aprs.fi has been storing an unsigned fixed-point decimal number which can represent values between 0 and 999999,99. Two decimals. No negative values. It has been stored as a 32-bit data unit in the database. I admit it's been a bit silly - I didn't go all in and accept negative values, and the fixed point is a bit... fixed.<br />
<br />
Kenneth Finnegan (<a href="https://digitalcommons.calpoly.edu/theses/1341/" target="_blank">MS in APRS</a>, the highest academic degree anyone has on the subject) has written a some good notes on how APRS telemetry is actually formatted in the wild here:<br />
<br />
<a href="https://github.com/PhirePhly/aprs_notes/blob/master/telemetry_format.md">https://github.com/PhirePhly/aprs_notes/blob/master/telemetry_format.md</a><br />
<br />
Kenneth also outlines a <b>Proposed Telemetry Format</b>, where a telemetry packet can be made shorter if there's less than 5 values to be transmitted, and where large, negative or floating-point values can be transmitted as-is without scaling them to the classic nintendo 8-bit 0...255 range specified in APRS101.PDF. I think the proposal is good, and it also matches the reality of what is already being done widely by many telemetry transmitters.<br />
<br />
The proposed format is backwards compatible in a way that allows decoders accepting the new format to also accept the old format without special handling. Old and pedantic decoders can not accept the new format when either the shorter format (with less values) or decimal/negative/large values are sent. Luckily it's easy to upgrade the old decoders to accept the new format, and even the smallest microcontrollers today are easily programmed to handle floating point values like this.<br />
<br />
<h3>
As of today, aprs.fi implements Kenneth's Proposed Telemetry Format.</h3>
<br />
<ul>
<li>Analog values are stored in signed <a href="https://en.wikipedia.org/wiki/Single-precision_floating-point_format">IEEE single precision (32-bit) base-2 floating point format</a>. Kenneth does not specify a resolution or maximum value, so I just picked the single precision format, since it doesn't actually increase my disk storage requirements. As the wikipedia article says, the single precision float can store a maximum value of 3.4028235 × 1038. <i>"All integers with 7 or fewer decimal digits, and any 2n for a whole number −149 ≤ n ≤ 127, can be converted exactly into an IEEE 754 single-precision floating-point value."</i></li>
<li>The decoder only accepts values between -2147483648 and 2147483647.</li>
<li>Since it is a floating point value, if you send <i>very large</i> values, the resolution starts to show up in the less significant digits. But it is still exactly precise in the -9999999 to 9999999 range, and certainly in the 0...255 range too.</li>
<li>Only three decimals are printed on the telemetry pages for now - if you transmit 0.0005 it'll be rounded up to 0.001. This is because the values calculated with EQNS coefficients often have a <b>lot</b> of decimals, and for most data it does not make sense to print it out with more than 1, 2 or 3 decimals. But I'm guessing there isn't much data that would have meaningful 4 decimals.</li>
</ul>
<div>
<br /></div>
<h3>
A few examples of packets that can now be accepted</h3>
Short telemetry, just one value of 42:<br />
<blockquote class="tr_bq">
<span style="font-family: "courier new" , "courier" , monospace;">T#001,42</span></blockquote>
Slightly longer, with three values, first one being negative, second one being large, third one having decimals:<br />
<blockquote class="tr_bq">
<span style="font-family: "courier new" , "courier" , monospace;">T#042,-1,10000000,142.4242424</span></blockquote>
Just four bits of digital telemetry:<br />
<blockquote class="tr_bq">
<span style="font-family: "courier new" , "courier" , monospace;">T#999,,,,,,1101</span></blockquote>
<br />
<h3>
Caveats</h3>
Older decoders which read APRS101.PDF to the letter will not accept these packets. I'm hoping they will be relaxed to accept the proposed format in the future. At this point you'll need to test if your intended recipients parse them.<br />
<br />
<b>javAPRSSrvr</b> will pass these packets through, but if a client sets up a "t/t" filter to request all packets of the Telemetry type, it will currently only accept packets which strictly match the APRS101.PDF format. If there is a decimal point in a value, a negative sign, or an analog integer value exceeding 255, the client will not get the packet. I'm hoping Pete will relax this requirement in the future.<br />
<br />
<b>aprsc</b> packet type filters (like "t/t") only look at the packet type (first few bytes usually). It does not care if the remaining packet matches some format or not, and it allows upgrading the format without changes in server code.<br />
<br />
<h3>
Final note to people writing APRS decoders</h3>
If you implement the Proposed Format, please let me or Kenneth know, or make a github pull request to Kenneth's document, so that we can have a list of software supporting the new format. Thanks!<br />
<br /></div>
Hessuhttp://www.blogger.com/profile/12550787353137508264noreply@blogger.com0tag:blogger.com,1999:blog-2631429776292642259.post-45808246663825379332020-02-01T14:53:00.002+02:002020-02-01T15:56:36.498+02:00How APRS paths workThe APRS packet path is used to control the distribution and retransmission of a packet in the APRS network.<br />
<br />
Every now and then someone asks how paths actually work. Having spent quite some time staring at packets that have been digipeated, and decoding them at my little aprs.fi web site, I suspect I might have begun to understand it, so here goes. I'll explain it the long way and begin with a packet without a path, continue with the traditional AX.25 digipeating path, and then go to the APRS world.<br />
<div>
<br />
<h3>
</h3>
<h3>
No path</h3>
<div>
<br /></div>
<div>
Let's assume my call is <span style="color: blue;">N0CALL</span>, and I have a generic APRS device which uses the generic APRS tocall (destination callsign) of <span style="background-color: white; color: orange;">APRS</span>. The packet, without any digipeaters or path, in the usual text format, as used on the APRS-IS, would look like:</div>
<div>
<br /></div>
<div>
<span style="color: blue;">N0CALL</span>><span style="background-color: white; color: orange;">APRS</span>:<span style="background-color: white; font-family: "verdana" , "arial" , "helvetica" , sans-serif; white-space: nowrap;"><span style="color: magenta;">!1234.56ND01037.50E&</span></span><br />
<div>
<br /></div>
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="http://1.bp.blogspot.com/-O-dwkILiPSc/XjVn2xZS_xI/AAAAAAAADM8/B4zDhDIS9S0UqOvDt5FOJh73ayaCunVeQCK4BGAYYCw/s1600/aprs-gear-202001-3.jpg" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="212" src="https://1.bp.blogspot.com/-O-dwkILiPSc/XjVn2xZS_xI/AAAAAAAADM8/B4zDhDIS9S0UqOvDt5FOJh73ayaCunVeQCK4BGAYYCw/s320/aprs-gear-202001-3.jpg" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Some of my APRS gear on top of my old bass gear, from left:<br />
Mobilinkd TNC3 for iPhone (prototype unit), Kenwood<br />
TH-D72 (digipeats), an unassembled TNC-X (can digipeat with<br />
a daughtercard added), Argent Data Systems Tracker2 OT2m<br />
(digipeats), Coastal Chipworks TNC-pi on top of a Raspberry<br />
Pi (digipeats with aprx), Byonics TinTrak4 (digipeats),<br />
Kenwood TH-D74 (can digipeat). Moomin for size reference<br />
only. Hartke Kickback 15" 120W. If your APRS hardware<br />
is not shown here yet, my address is on qrz.com. :)</td></tr>
</tbody></table>
<div>
There are two separating characters: the '>' separates the <span style="color: blue;">source</span> and <span style="color: orange;">destination</span> callsigns, and the ':' separates the packet header from the <span style="color: magenta;">actual data being transmitted</span> (the APRS formatted position, in this case). A packet like this would not be repeated through any digipeaters, but it could still be directly heard, picked up by an iGate and passed to the APRS-IS on the Internet. Sometimes you might want to do this and configure your transmitter with an empty path.</div>
<div>
<br /></div>
<h3>
Classic AX.25 digipeating</h3>
<div>
<br /></div>
<div>
The digipeater path may then optionally appear after the destination callsign. Here's a packet that I might transmit, which requests digipeating via two specific digipeaters, in a particular, specified order:</div>
<div>
<br /></div>
<div>
<span style="color: blue;">N0CALL</span>><span style="background-color: white; color: orange;">APRS</span><span style="background-color: white;">,<span style="color: red;">OH7RDA,OH7RDB</span></span>:<span style="background-color: white; font-family: "verdana" , "arial" , "helvetica" , sans-serif; white-space: nowrap;"><span style="color: magenta;">!1234.56ND01037.50E&</span></span><br />
<div>
<br /></div>
</div>
<div>
Here, the <span style="color: red;">digipeater path</span> is <span style="background-color: white; color: red;">OH7RDA,OH7RDB</span><span style="background-color: white;"> - the packet should be digipeated by OH7RDA and <i>then</i> OH7RDB. This is how classic AX.25 packet radio digipeating works. </span>APRS is transmitted using AX.25 packet radio packets, so they will follow the old AX.25 rules too. You can certainly do this and most APRS digipeaters will digipeat your packet if you just put the callsign in the path.</div>
</div>
<div>
<br /></div>
<div>
When OH7RDA retransmits the packet, it will flip the "has been repeated" bit on for that callsign. It really is a single bit called the "H bit". The packet, in text format, will look like this – note the '*' which indicates the "has been repeated by this digipeater" bit:</div>
<div>
<br /></div>
<div>
<span style="color: blue;">N0CALL</span>><span style="background-color: white; color: orange;">APRS</span><span style="background-color: white;">,<span style="color: red;">OH7RDA*,OH7RDB</span></span>:<span style="background-color: white; font-family: "verdana" , "arial" , "helvetica" , sans-serif; white-space: nowrap;"><span style="color: magenta;">!1234.56ND01037.50E&</span></span><br />
<div>
<br /></div>
</div>
<div>
Each digipeater will look for the first digipeater callsign in the path which has not been used yet (i.e. the "has been repeated" bit is not on - there's no "*" in there), and then figure out based on that if it should be retransmitted. So, after OH7RDA has retransmitted the packet, and OH7RDB has heard the above packet with <span style="color: red;">OH7RDA*,OH7RDB</span> in it, it will go "oh that's my callsign, I'll retransmit". The resulting packet transmitted by OH7RDB will have <span style="color: red;">OH7RDA*,OH7RDB*</span> as the path! Note that OH7RDB <i>will not </i>retransmit the original packet before OH7RDA has done his part.</div>
<div>
<br /></div>
<div>
To add confusion, and to save a few bytes, usually only the last "*" is usually printed, although the "has been repeated" bit is set on all previous digipeater calls. <span style="background-color: white;"><span style="color: red;">OH7RDA,OH7RDB,OH7RDC*</span> actually means<span style="color: red;"> </span></span><span style="background-color: white;"><span style="color: red;">OH7RDA*,OH7RDB*,OH7RDC* </span>!</span></div>
<div>
<span style="background-color: white;"><br /></span></div>
<h3>
Aliases of digipeaters, classic AX.25 packet approach</h3>
<div>
<br /></div>
<div>
Digipeaters can be also configured to respond to alias callsigns in addition to their own call. For example, OH7RDA could be configured to repeat a packet which requests digipeating by <span style="color: red;">ALIAS</span>. It may then do one of two things: It can either substitute <span style="color: red;">ALIAS</span> with it's own callsign, or prepend it's own callsign before <span style="color: red;">ALIAS</span>. This varies by digipeater software and its configuration.</div>
<div>
<br /></div>
<div>
<span style="color: blue;">N0CALL</span>><span style="background-color: white; color: orange;">APRS</span><span style="background-color: white;">,<span style="color: red;">ALIAS</span></span>:data</div>
<div>
<br /></div>
<div>
When retransmitted by OH7RDA, will become one of:</div>
<div>
<br /></div>
<div>
<div>
<span style="color: blue;">N0CALL</span>><span style="background-color: white; color: orange;">APRS</span><span style="background-color: white;">,<span style="color: red;">OH7RDA*</span></span>:data</div>
<div>
<div>
<span style="color: blue;">N0CALL</span>><span style="background-color: white; color: orange;">APRS</span><span style="background-color: white;">,<span style="color: red;">OH7RDA,ALIAS*</span></span>:data</div>
<div>
<br /></div>
<div>
The benefit of the second format (digi call prepended) is that, upon receiving such a packet, we know that the originator used <span style="color: red;">ALIAS</span> as the path.</div>
<div>
<br />
In the classic/old APRS digipeating world, people used aliases like WIDE to ask for any digipeaters to digipeat. Currently, this method is used to digipeat through satellites and the ISS - just use a simple alias of <span style="color: red;">ARISS</span> as the path and it will be digipeated through the <span style="color: red;">RS0ISS</span> digipeater on the ISS or any of the other APRS-supporting satellites on 145.825 MHz! Yes, this means the PATH setting should be just "<span style="color: red;">ARISS</span>". Do not put any of the WIDE or RS0ISS stuff in there, it won't help.</div>
</div>
</div>
<div>
<br /></div>
<h3>
WIDEn-N paths on APRS</h3>
<div>
<br /></div>
<div>
This is where it gets interesting and more specific to APRS, as these paths only work on APRS digipeaters. A WIDEn-N path has two integers, n and N. <span style="color: red;">WIDE3-1</span> would have n of 3, and N of 1. The first integer theoretically means "I'd like to have this packet to be digipeated by this many digipeater hops" (3 in the example of <span style="color: red;">WIDE3-1</span>). The second integer means "there's this many hops left before digipeating stops". When it becomes 0, it won't be digipeated any more, and the "has been repeated" bit will be set (a "*" will appear).</div>
<div>
<br /></div>
<div>
A packet with a path of <span style="color: red;">WIDE3-3</span>, after first retransmission will become <span style="color: red;">WIDE3-2</span>, and then <span style="color: red;">WIDE3-1</span>, and after the third retransmission it'll be <span style="color: red;">WIDE3*</span>. The SSID of 0 is not printed – it's really WIDE3-0 under the hood of the packet but the -0 will not be shown.</div>
<div>
<br /></div>
<div>
The digipeaters supporting this kind of alias usually also prepend their callsigns (all the good ones do, the bad ones don't). And the packet will be often picked up by many digipeaters! So you may see something like this, when both OH7RDA and OH7RDB hear N0CALL, and OH7RDC hears OH7RDB:</div>
<div>
<br /></div>
<div>
<div>
<span style="color: blue;">N0CALL</span>><span style="background-color: white; color: orange;">APRS</span><span style="background-color: white;">,<span style="color: red;">WIDE2-2</span></span>:data</div>
<div>
<span style="color: blue;">N0CALL</span>><span style="background-color: white; color: orange;">APRS</span><span style="background-color: white;">,<span style="color: red;">OH7RDA*,WIDE2-1</span></span>:data</div>
</div>
<div>
<span style="color: blue;">N0CALL</span>><span style="background-color: white; color: orange;">APRS</span><span style="background-color: white;">,<span style="color: red;">OH7RDB*,WIDE2-1</span></span>:data</div>
<div>
<span style="color: blue;">N0CALL</span>><span style="background-color: white; color: orange;">APRS</span><span style="background-color: white;">,<span style="color: red;">OH7RDB,OH7RDC,WIDE2*</span></span>:data</div>
<div>
<br /></div>
<div>
You can also send a packet which originally has a path of WIDE2-1, and it'll be digipeated by digipeaters which are configured to respond to the WIDE2 alias - but only once, since the "remaining hops" number is 1 to begin with. If three digipeaters can hear you, this would result in:<br />
<br /></div>
<div>
<div>
<div>
<span style="color: blue;">N0CALL</span>><span style="background-color: white; color: orange;">APRS</span><span style="background-color: white;">,<span style="color: red;">WIDE2-1</span></span>:data</div>
<div>
<span style="color: blue;">N0CALL</span>><span style="background-color: white; color: orange;">APRS</span><span style="background-color: white;">,<span style="color: red;">OH7RDA,WIDE2*</span></span>:data</div>
</div>
<div>
<span style="color: blue;">N0CALL</span>><span style="background-color: white; color: orange;">APRS</span><span style="background-color: white;">,<span style="color: red;">OH7RDB,WIDE2*</span></span>:data</div>
</div>
<div>
<div>
<span style="color: blue;">N0CALL</span>><span style="background-color: white; color: orange;">APRS</span><span style="background-color: white;">,<span style="color: red;">OH7RDC,WIDE2*</span></span>:data</div>
</div>
<div>
<br /></div>
<div>
A packet of WIDE2-2 is often retransmitted by much more than than 2 digipeaters, since it will be digipeated <b>twice to each direction</b>. Each high-level digipeater in a tower will be often heard by a few digipeaters which are actually quite far away. This is how a WIDE3-3 path might be distributed through a whole country, and a bit to the neighbouring countries as well (rough example but not far from the truth):</div>
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://3.bp.blogspot.com/-Y5wpGWD2HYg/XjVTelY5YPI/AAAAAAAADMw/Qc8YdgqIUgwSImNyGh770FeJVDgcRiBxwCK4BGAYYCw/s1600/APRS-path-WIDE3.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="400" src="https://3.bp.blogspot.com/-Y5wpGWD2HYg/XjVTelY5YPI/AAAAAAAADMw/Qc8YdgqIUgwSImNyGh770FeJVDgcRiBxwCK4BGAYYCw/s400/APRS-path-WIDE3.png" width="390" /></a></div>
<div>
<br /></div>
<div>
This is why we don't usually use paths with more than 2 hops on APRS, and practically never more than 3 (except in some specific cases in rural areas with quiet channels having little traffic). A packet like this can light up the whole APRS network in almost the whole country (or a few states, for you in the larger nations). If a lot of people did this, the channel would become too congested and APRS would stop working as everyone would be transmitting on top of each other. It has happened and we've learned it the hard way.</div>
<div>
<br /></div>
<h3>
Fill-in digipeaters</h3>
<div>
<br /></div>
<div>
In some areas people set up low-level "fill-in" digipeaters at their homes. They are only configured to respond to the <span style="color: red;">WIDE1</span> alias, but not <span style="color: red;">WIDE2</span>. Digipeaters higher up at towers and such, serving a wide area, are configured to respond to both <span style="color: red;">WIDE1</span> and <span style="color: red;">WIDE2</span> aliases.</div>
<div>
<br /></div>
<div>
The idea is that the fill-in WIDE1 digipeater may well hear packets from nearby transmitters, which might be missed by the higher-up digipeater – due to distance, or because it hears a lot of stations and gets a lot of collisions, or because there are "urban canyon" obstructions. The wide-area-coverage WIDE2 digipeater will be heard by everyone, and there's no need for the fill-in WIDE1 digipeaters to retransmit packets which have already been transmitted by it!</div>
<div>
<br /></div>
<div>
This is accomplished by transmitting a packet with a <span style="color: red;">WIDE1-1,WIDE2-1</span> path. This is the usual recommended default APRS path, as you might have noticed. It would be first digipeated by any digipeater (fill-in or wide-area), and then by a wide-area WIDE2 digipeater. But only for a total range of 2 hops! This is how it might look, if you could receive the original packet and all the digipeated packets - <span style="color: #0b5394;">N1FILL</span> is the fill-in home digipeater, OH7RDA and OH7RDB are higher-up digipeaters which can hear <span style="color: #0b5394;">N1FILL</span> but not <span style="color: blue;">N0CALL</span>:</div>
<div>
<br /></div>
<div>
<div>
<div>
<div>
<span style="color: blue;">N0CALL</span>><span style="background-color: white; color: orange;">APRS</span><span style="background-color: white;">,<span style="color: red;">WIDE1-1,WIDE2-1</span></span>:data</div>
<div>
<span style="color: blue;">N0CALL</span>><span style="background-color: white; color: orange;">APRS</span><span style="background-color: white;">,<span style="color: #0b5394;">N1FILL</span><span style="color: red;">,WIDE1*,WIDE2-1</span></span>:data</div>
</div>
<div>
<div>
<span style="color: blue;">N0CALL</span>><span style="background-color: white; color: orange;">APRS</span><span style="background-color: white;">,<span style="color: #0b5394;">N1FILL</span><span style="color: red;">,WIDE1,OH7RDA,WIDE2*</span></span>:data</div>
<div>
<div>
<span style="color: blue;">N0CALL</span>><span style="background-color: white; color: orange;">APRS</span><span style="background-color: white;">,<span style="color: #0b5394;">N1FILL</span><span style="color: red;">,WIDE1,OH7RDB,WIDE2*</span></span>:data</div>
<div>
<br /></div>
</div>
</div>
</div>
</div>
<div>
<div>
In reality, many of these fill-in digipeaters are <i>old and dumb TNCs</i>, and can not do callsign prepending. Instead, they just do callsign substitution and replace WIDE1-1 with their own callsign, like this:</div>
<div>
<br /></div>
</div>
<div>
<div>
<div>
<span style="color: blue;">N0CALL</span>><span style="background-color: white; color: orange;">APRS</span><span style="background-color: white;">,<span style="color: red;">WIDE1-1,WIDE2-1</span></span>:data</div>
<div>
<span style="color: blue;">N0CALL</span>><span style="background-color: white; color: orange;">APRS</span><span style="background-color: white;">,<span style="color: #0b5394;">N1FILL*</span><span style="color: red;">,WIDE2-1</span></span>:data</div>
</div>
<div>
</div>
</div>
<div>
<br /></div>
<div>
Alternatively, if <span style="color: #073763;">N1FILL</span> would not receive this packet, but just the higher-up digipeaters directly, then it might go a bit further. OH7RDA heard <span style="color: blue;">N0CALL</span>, and subsequently OH6RDA and OH8RDA hear OH7RDA:</div>
<div>
<br /></div>
<div>
<div>
<div>
<span style="color: blue;">N0CALL</span>><span style="background-color: white; color: orange;">APRS</span><span style="background-color: white;">,<span style="color: red;">WIDE1-1,WIDE2-1</span></span>:data</div>
<div>
<span style="color: blue;">N0CALL</span>><span style="background-color: white; color: orange;">APRS</span><span style="background-color: white;">,</span><span style="background-color: white; color: red;">OH7RDA</span><span style="background-color: white;"><span style="color: red;">,WIDE1*,WIDE2-1</span></span>:data</div>
</div>
<div>
<div>
<span style="color: blue;">N0CALL</span>><span style="background-color: white; color: orange;">APRS</span><span style="background-color: white;">,<span style="color: red;">OH7RDB</span><span style="color: red;">,WIDE1,OH6RDA,WIDE2*</span></span>:data</div>
<div>
<div>
<span style="color: blue;">N0CALL</span>><span style="background-color: white; color: orange;">APRS</span><span style="background-color: white;">,<span style="color: red;">OH7RDB</span><span style="color: red;">,WIDE1,OH8RDA,WIDE2*</span></span>:data</div>
<div>
<br /></div>
<div>
To send a packet for one hop of digipeating you can choose to use either WIDE1-1 or WIDE2-1. With WIDE1-1 you may have it digipeated through fill-ins and wide-area digis, a WIDE2-1 should only trigger the wide-area ones.<br />
<br />
There are also some buggy digipeaters out there which do not add their callsign at all - they just retransmit, and decrement the hop counter of a path element (WIDE2-2 to WIDE2-1 and so on). These are particularly annoying when trying to figure out what happened to a packet.<br />
<br />
<h3>
What about the ,qAR,IGATECALL stuff happening on the APRS-IS?</h3>
<br />
The APRS-IS servers on the Internet, or alternatively, the iGate itself, append something called the <b>q construct</b> to the packet. After the q construct you'll find the callsign of the iGate which received the packet from a radio and passed it to the Internet:<br />
<div style="-webkit-text-stroke-width: 0px; color: black; font-family: Times; font-size: medium; font-style: normal; font-variant-caps: normal; font-variant-ligatures: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-decoration-color: initial; text-decoration-style: initial; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;">
</div>
<br />
<div style="-webkit-text-stroke-width: 0px; color: black; font-family: Times; font-size: medium; font-style: normal; font-variant-caps: normal; font-variant-ligatures: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-decoration-color: initial; text-decoration-style: initial; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;">
<div style="margin: 0px;">
<span style="color: blue;">N0CALL</span>><span style="background-color: white; color: orange;">APRS</span><span style="background-color: white;">,</span><span style="color: red;"><span style="background-color: white;">WIDE1-1,WIDE2-1,</span><span style="background-color: cyan;">qAR,IGATECALL</span></span>:data<br />
<br />
The q construct does not appear on the radio side - it is only used for tagging additional information to it on the Internet.<br />
<br /></div>
</div>
</div>
<h3>
Limits and policies</h3>
<div>
<br /></div>
<div>
Digipeaters often have policies or filters configured, to prevent digipeating of outright silly paths like <span style="color: red;">WIDE6-6</span>, or paths with a big combined hop length ("<span style="color: red;">WIDE1-1,WIDE2-2,WIDE3-3,WIDE3-3</span>" for a total of 9 hops), or paths where the second integer is larger than the first one (<span style="color: red;">WIDE1-7</span>). Paths like this are considered abusive and cause excess congestion to the APRS network.</div>
<div>
<br /></div>
<div>
Having said that, I think it's alright to have some fun sometimes!</div>
<div>
<br /></div>
<div>
One fun trick is to send a packet, manually, by hand, towards the west, have it travel around the country and then come back to you from the east. You can accomplish this by drawing a map of live digipeaters (aprs.fi can do this for you), and then putting in the callsigns of the digipeaters in the path (up to 8 digis may work): <span style="color: red;">DIGI1,DIGI2,DIGI3,DIGI4,DIGI5</span>. Even though they are many elements in the path, it won't consume much more radio channel time than what a WIDE1-1,WIDE2-2 packet would. Just don't do this with the regularly-beaconing APRS tracker in your car, it'd be silly.</div>
<div>
</div>
</div>
</div>
</div>
</div>
Hessuhttp://www.blogger.com/profile/12550787353137508264noreply@blogger.com1tag:blogger.com,1999:blog-2631429776292642259.post-3863464831890259112019-08-15T00:21:00.000+03:002019-08-15T00:21:10.771+03:00RX-only igates considered beneficial to the networkAs probably most of you know by now, besides running the aprs.fi web site, I'm also one of the two main authors of the aprsc server software. aprsc <a href="http://status.aprs2.net/" target="_blank">runs on most of the APRS-IS servers</a> where iGates usually connect.<br />
<br />
There have been recent and strong claims saying that receive-only (rx-only) iGates destroy the two-way messaging feature of APRS. This has been claimed in <a href="https://www.f4fxl.org/why-are-aprs-rx-only-igates-bad/" rel="nofollow" target="_blank">blog posts</a> and facebook threads. Some people ask me if this is true.<br />
<br />
<b>No, it is not true. Receive-only iGates do not break messaging if there are transmit-capable igates nearby, and those transmit-capable iGates are connected to an APRS-IS server which has a full APRS feed. All aprs.net and aprs2.net servers, where iGates normally connect, do have a full feed. No problem!</b><br />
<b><br /></b>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://1.bp.blogspot.com/-uK3eKXzgFEg/XVR4ygEGBUI/AAAAAAAADIM/yjHqDds60UIK-FLHrsyW8qAaSnrWxpKEACLcBGAs/s1600/2019-07-27-gliding-height.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="1200" data-original-width="1600" height="300" src="https://1.bp.blogspot.com/-uK3eKXzgFEg/XVR4ygEGBUI/AAAAAAAADIM/yjHqDds60UIK-FLHrsyW8qAaSnrWxpKEACLcBGAs/s400/2019-07-27-gliding-height.jpg" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Messaging would work from 1650m / 5400 ft above Vihti, even in the presence of<br />RX-only iGates, as long as there is at least one TX-capable iGate.</td></tr>
</tbody></table>
<br />
If there are no transmit-capable (TX) iGates around, two-way messaging will not work, of course. Having a transmit-capable iGate would therefore be better, but receive-only iGates are easier to set up technically, they are cheaper (receivers are practically free now), and licensing for automatic transmitters is difficult in many countries. Where transmit-capable (TX) iGates are present, receive-only iGates do not break the TX iGates, they just improve reception coverage. For messages, too.<br />
<br />
Just to make it perfectly clear: <b>If there are TX iGates present, additional RX-only iGates improve messaging performance.</b> For the RF-to-IS direction (and ACKs for the IS-to-RF messages).<br />
<br />
The common incorrect claim is that the APRS-IS server sends the message only to the latest iGate which heard a station. In fact, the APRS-IS servers (both javaprssrvr and aprsc) send the messages to <i>all iGates which heard the station recently. </i>In aprsc, "recently" means "within 3 hours", and I believe javaprssrvr uses something similar.<br />
<br />
The server maintains a list of recently heard callsigns <i>independently for each iGate client</i>. There's a separate list of heard stations for each iGate client. When the server has a packet to pass on, it will look at all connected clients, and for each client, if the recipient of the message is found from the list of recently heard stations, the message will be sent. The scanning will not stop; the message will be given to all clients which heard the station.<br />
<br />
I can confirm that we have written the software to do it like this, and since it is open source, <a href="https://github.com/hessu/aprsc/blob/master/src/filter.c#L2467" target="_blank">you can see the code yourself</a>. The <a href="https://github.com/hessu/aprsc/blob/master/tests/t/40messaging.t#L192" target="_blank">automatic test case</a> also validates that the server keeps working that way, so that there won't be a bug creeping in the future to break it accidentally. I've also tested that javaprssrvr behaves like this – I've run the test cases against it to confirm compatibility.<br />
<br />
There may be problems when there is a server with a filtered feed involved (possibly a server software running at the "client" without having a full feed), but those are rare and known to be problematic. All Tier2 servers have a full feed (aprs2.net ones), and so do the core servers.<br />
<br />
<b>The real problem is that a user, seeing one-way beaconing to the APRS-IS works, may well expect two-way messaging to work too. And when it doesn't work, there's only a timeout, no immediate feedback saying "sorry, this won't work now", which is what a sensible system would do today.</b><br />
<br />
<b>Even in that case, an rx-only igate is better than nothing!</b> I wouldn't be so harsh against them, since the step from RX-only to TX-capable may be a bit difficult for many.<br />
<div>
<br /></div>
<div>
Bottom line:<br />
<br />
In each area, there should be one TX igate, maybe two. More may create QRM as the same messages will be transmitted from APRS-IS to RF many times. RX igates will not break messaging if there are TX igates around – they just improve RX coverage.</div>
<div>
<br /></div>
<div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://1.bp.blogspot.com/-1NFAeNGd-yE/XVR4yfJXTRI/AAAAAAAADIQ/aaMQwxjAwUoBl8pGCctHEKCd2gfKZj1kQCLcBGAs/s1600/2019-07-27-gliding-view.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="1200" data-original-width="1600" height="300" src="https://1.bp.blogspot.com/-1NFAeNGd-yE/XVR4yfJXTRI/AAAAAAAADIQ/aaMQwxjAwUoBl8pGCctHEKCd2gfKZj1kQCLcBGAs/s400/2019-07-27-gliding-view.jpg" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">This picture may at first seem irrelevant, but it does show me working VHF in AM (122.825 MHz),<br />and Flarm on 868 MHz to OGN (which runs aprsc). Flarm antenna visible in top left corner.</td></tr>
</tbody></table>
</div>
Hessuhttp://www.blogger.com/profile/12550787353137508264noreply@blogger.com5tag:blogger.com,1999:blog-2631429776292642259.post-39441626867768789822019-04-21T16:13:00.000+03:002019-04-21T16:14:38.919+03:00Server upgrades, and raw packets UI abuse<div class="separator" style="clear: both; text-align: center;">
<a href="https://3.bp.blogspot.com/-AiTOJ6Mq90M/XLxoilJqPPI/AAAAAAAADG8/iRfGEi-HZSI7HHLn9hTchAAlH8jFBbY2gCLcBGAs/s1600/aprsfi-poweredge1.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" data-original-height="1200" data-original-width="1600" height="240" src="https://3.bp.blogspot.com/-AiTOJ6Mq90M/XLxoilJqPPI/AAAAAAAADG8/iRfGEi-HZSI7HHLn9hTchAAlH8jFBbY2gCLcBGAs/s320/aprsfi-poweredge1.jpg" width="320" /></a></div>
<span style="font-family: inherit;">This month I'm upgrading the <a href="http://aprs.fi/">aprs.fi</a> servers quite a bit. The old blade server hardware chassis is getting shut down and replaced with a brand new pre-owned and dumpster-dived blade server chassis. The new second-hand blades have 8 CPU cores and 192 GB memory each, which is quite sweet! I suspect the web site & database will be doing very little disk reads with this much cache around.</span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;">The downside is that we're not going to run the fibre channel SAN network, and the associated disk racks, since they're a bit power-hungry. So, internal disks only it is. To get relatively good disk IO performance I installed 1 TB SSD disks in the blades – two SSDs in each for RAID1 (~170€ with 24% VAT each, 3 blades, total 6 SSDs). The blades have CERC 6/i raid controllers, which are </span>SATA2 and <span style="font-family: inherit;">quite slow. The Samsung SSDs are capable of some 500+ Mbytes/sec reads, but the hardware controller in RAID1 config only gives out 130 Mbytes/sec. With Linux software RAID1 it can balance reads across the SSDs and give out 2*140 Mbytes/sec, which is alright.</span><br />
<span style="font-family: inherit;"><br /></span>
<a href="https://4.bp.blogspot.com/-PWlWxY8iLlE/XLxokqc51KI/AAAAAAAADHA/XyrxkLtZ8ZcLc7QmtOaUNfe12qbsSr68ACLcBGAs/s1600/aprsfi-poweredge2.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" data-original-height="1200" data-original-width="1600" height="240" src="https://4.bp.blogspot.com/-PWlWxY8iLlE/XLxokqc51KI/AAAAAAAADHA/XyrxkLtZ8ZcLc7QmtOaUNfe12qbsSr68ACLcBGAs/s320/aprsfi-poweredge2.jpg" width="320" /></a><span style="font-family: inherit;">aprs.fi being a database application, especially with the huge cache memory, it'll be mostly random-access write heavy, so the streaming read benchmark above is not too relevant. The random-access speed of the SSD gives a nice boost, and the memory will help an awful lot.</span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;">The new servers are already running a live replica of the database, but the web service is still running on the old ones. Hoping to get the move done soon. The operating system is also getting a bump to the next major release, and some adjustments are needed to support that.</span><br />
<span style="font-family: inherit;"><br /></span>
<b><span style="font-family: inherit;">In less happy news: A few</span><span style="background-color: white; color: #222222; font-family: inherit;"> smart folks have, again, figured that it would </span></b><b style="color: #222222; font-family: inherit;">be a great idea to download raw APRS-IS packets programmatically</b><span style="background-color: white; color: #222222; font-family: inherit;"> (using</span><span style="background-color: white; color: #222222; font-family: inherit;"> </span><span style="background-color: white; color: #222222; font-family: inherit;">software they've written) from the </span><a href="http://aprs.fi/" rel="nofollow" style="background-color: white; border: 0px; color: #6611cc; cursor: pointer; font-family: inherit; margin: 0px; padding: 0px; text-decoration-line: none;" target="_blank">aprs.fi</a><span style="background-color: white; color: #222222; font-family: inherit;"> user interface, the raw packets </span><span style="background-color: white; color: #222222; font-family: inherit;">view. This is forbidden by the TOS (</span><a href="https://aprs.fi/page/tos" rel="nofollow" style="background-color: white; border: 0px; color: #6611cc; cursor: pointer; font-family: inherit; margin: 0px; padding: 0px; text-decoration-line: none;" target="_blank">https://aprs.fi/page/tos</a><span style="background-color: white; color: #222222; font-family: inherit;">) and a </span><span style="background-color: white; color: #222222; font-family: inherit;">longer reasoning can be found in the FAQ (</span><a href="https://aprs.fi/page/faq" rel="nofollow" style="background-color: white; border: 0px; color: #6611cc; cursor: pointer; font-family: inherit; margin: 0px; padding: 0px; text-decoration-line: none;" target="_blank">https://aprs.fi/page/faq</a><span style="background-color: white; color: #222222; font-family: inherit;">): </span><br />
<blockquote class="tr_bq">
<span style="font-family: inherit;"><span style="background-color: white; color: #222222;">Downloading data for application use using the user interface (for </span></span><span style="font-family: inherit;"><span style="background-color: white; color: #222222;">example, fetching the /info/ page just to get the current coordinates of a </span></span><span style="font-family: inherit;"><span style="background-color: white; color: #222222;">station) wastes both human and computer resources. </span></span> </blockquote>
<blockquote class="tr_bq">
<span style="font-family: inherit;"><span style="background-color: white; color: #222222;"></span></span><span style="font-family: inherit;"><span style="background-color: white; color: #222222;">First, you need to write a parser to extract the data from the HTML (and </span></span><span style="font-family: inherit;"><span style="background-color: white; color: #222222;">then fix your parser every time I change my HTML layout). Second, </span><a href="http://aprs.fi/" rel="nofollow" style="background-color: white; border: 0px; color: #6611cc; cursor: pointer; margin: 0px; padding: 0px; text-decoration-line: none;" target="_blank">aprs.fi</a><span style="background-color: white; color: #222222;"> </span></span><span style="font-family: inherit;"><span style="background-color: white; color: #222222;">needs to do the user interface magic (language and timezone selection, </span></span><span style="font-family: inherit;"><span style="background-color: white; color: #222222;">user-friendly template formatting, session set-up) for every request, all </span></span><span style="font-family: inherit;"><span style="background-color: white; color: #222222;">of which is unnecessary. </span></span> </blockquote>
<blockquote class="tr_bq">
<span style="font-family: inherit;"><span style="background-color: white; color: #222222;">[...] All of this </span></span><span style="font-family: inherit;"><span style="background-color: white; color: #222222;">extra overhead consumes CPU time, which in turn heats up the computer </span></span><span style="font-family: inherit;"><span style="background-color: white; color: #222222;">room, consumes electricity, destroys tropical rain forests, accelerates </span></span><span style="font-family: inherit;"><span style="background-color: white; color: #222222;">global warming, and kills kittens. And baby seals.</span></span></blockquote>
<span style="font-family: inherit;"><span style="background-color: white; color: #222222;">The correct way to obtain a raw APRS-IS feed is to connect to the APRS-IS </span></span><span style="font-family: inherit;"><span style="background-color: white; color: #222222;">(</span><a href="http://aprs-is.net/Connecting.aspx" rel="nofollow" style="background-color: white; border: 0px; color: #6611cc; cursor: pointer; margin: 0px; padding: 0px; text-decoration-line: none;" target="_blank">http://aprs-is.net/<wbr></wbr>Connecting.aspx</a><span style="background-color: white; color: #222222;">) - you'll get a lightweight TCP </span></span><span style="font-family: inherit;"><span style="background-color: white; color: #222222;">session with all the packets in real time. As clean CRLF-delimited rows with none of my HTML encoding to mess it up. For free, from the very same </span></span><span style="font-family: inherit;"><span style="background-color: white; color: #222222;">place where I get them from, and much faster! </span></span><br />
<span style="font-family: inherit;"><span style="background-color: white; color: #222222;"><br /></span></span><span style="font-family: inherit;"><span style="background-color: white; color: #222222;">If one chooses to fetch the packets by hammering on my <i>user interface</i>, as </span></span><span style="font-family: inherit;"><span style="background-color: white; color: #222222;">opposed to an API, it'll create unnecessary extra load on my servers, and </span></span><span style="font-family: inherit;"><span style="background-color: white; color: #222222;">make me a little bit upset. Especially when someone fetches 1000 packets every time, via the Tor network, repeatedly every few seconds, and ends up fetching the same packets over and over again. That is not a great way to make use of this free service.</span></span><br />
<br />
<span style="color: #222222;"><span style="background-color: white;"><b>To make this sort of abuse harder, you'll now need to log in to view the raw packets.</b> It's a little bit more clumsy if you're not logged in already, but the login cookies have a long lifetime so you don't need to do it that often.</span></span>Hessuhttp://www.blogger.com/profile/12550787353137508264noreply@blogger.com2tag:blogger.com,1999:blog-2631429776292642259.post-56428943552416796592018-12-10T01:00:00.000+02:002018-12-10T16:54:41.452+02:00Subscription for extra features within aprs.fi iOS app<div class="separator" style="clear: both; text-align: left;">
<a href="https://4.bp.blogspot.com/-phs3vIJRQEQ/V9SDVuT6KNI/AAAAAAAAC9w/wWAwZ2JXqfk47tSOLGU7CVDnEKRZIEnbACLcB/s1600/aprsfi-help-inapp-warning.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="246" src="https://4.bp.blogspot.com/-phs3vIJRQEQ/V9SDVuT6KNI/AAAAAAAAC9w/wWAwZ2JXqfk47tSOLGU7CVDnEKRZIEnbACLcB/s320/aprsfi-help-inapp-warning.png" width="320" /></a>This little warning has been in the aprs.fi iOS help text from the first version of the app - my plan from the beginning has been that some functions will require an additional paid subscription. The time for this is coming soon, and I've lately been spending some time implementing those features. This is likely going to upset some people (<i>"what, I already paid for this app, I need to pay more?!?"</i>) so it's probably good to go through the reasons once more.</div>
<br />
There is a fairly small number of amateur radio APRS users which are using iPhones or iPads. Androids are quite a bit more popular amongst hams. It will only take a short while until everyone, who ever will buy the app, has done it. After that nobody will pay for the application any more.<br />
<br />
The work will not stop there: the application and the backend servers supporting it need to be maintained, upgraded and improved over time – if the application does not get some love and care from its creators at regular intervals, it will soon decay and eventually stop working. This has happened to a few ham and APRS apps already, and I'm not at all surprised about that. Even if the application does not get any new features, someone must keep it going, add support for new iOS versions and iPhone models, fix backend servers, and so on.<br />
<br />
This maintenance burden may be difficult to appreciate if you haven't tried doing it yourself. When there's a new iOS version, you need new Xcode to build the app for it, new Xcode requires new OS X version on the laptop, and the app's code will need modifications to compile on the new Xcode due to changes in the programming language and APIs (programming interfaces provided by the operating system). And then there are the backend servers (don't get me started about "serverless").<br />
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://3.bp.blogspot.com/--kklEimimUc/V9SYqkzjO9I/AAAAAAAAC-M/LZBU6PF7zEI-TgkcRKDZMBNnEv2sfOn3wCLcB/s1600/20160626-sappion-luomu-wm-3.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="266" src="https://3.bp.blogspot.com/--kklEimimUc/V9SYqkzjO9I/AAAAAAAAC-M/LZBU6PF7zEI-TgkcRKDZMBNnEv2sfOn3wCLcB/s400/20160626-sappion-luomu-wm-3.jpg" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><span style="font-size: 12.8px;"><i>"What? We need to pay more?!? Greedy bastards!"</i></span><br />
<span style="font-size: 12.8px;">Photo of Finnish native "kyyttö" breed of cows (c) myself<br />2016-06-16 </span>at <a href="https://www.facebook.com/sappionluomu/" target="_blank">Sappion luomutila</a></td></tr>
</tbody></table>
I do quite some volunteer work as a hobby to support the APRS system (in the form of running aprs.fi itself, contributing free open source software such as <a href="http://he.fi/aprsc/" target="_blank">aprsc</a> and the <a href="http://status.aprs2.net/" target="_blank">aprs2.net backend software</a>, open source <a href="https://github.com/hessu/aprs-symbols" target="_blank">APRS symbol graphics</a>, <a href="https://github.com/hessu/aprs-deviceid" target="_blank">machine-readable APRS device identification database</a>, and a few other bits). I'm already quite busy with everything, and the family, so I decided to make a little bit of money from the iOS app. Due to the relatively small amount of users, it'll probably never pay for all the effort needed (pay-off not really comparable to the daytime job), but at least something. And, to keep the motivation there in the future, it would be nice to have something that is called a <i>sustainable business model -</i> in other words, <i>a little bit of money keeps flowing in the future, too</i>. That's where a subscription payment model comes in handy!<br />
<br />
<h3>
How will it work?</h3>
<br />
The model will be very simple: There's only a single subscription option, which will enable a set of extra features. Whenever a new feature is added, it may go to the "base" set of features, which are available to all users which have purchased the app. Or, it may go to the "extra" set of features, which are available with the "extra" subscription. If you have the "extra" subscription, you'll have all the features added in the future – there won't be another "pro", "enterprise", or "super" subscription required for those. No per-feature pricing, just the "base" set and the full "extra" set.<br />
<br />
Some features going to the "extra" set will seem fairly basic to some, and they will be features that most users hopefully want to have: Messaging, beaconing to APRS-IS, iGate, long and arbitrary time range lookups, soundcard modem, etc. On the other hand, the pricing will be fairly cheap, in my opinion, when compared to the price of an iPhone or any piece of APRS hardware: less than the app purchase price per year, resulting in roughly 50 cents / month price ($0.50 USD / € 0.50). About the same price as a Panini at Starbucks, a bit more than large Caffe Mocha! Subscription period will be 6 or 12 months, and there will be a <b>free trial period</b> in the beginning so that you can try before you pay. I may adjust the price later to one direction, or the other, depending on how it sells.<br />
<br />
I hope most users will want the extra set, so that even with this low subscription price I'll still get something. Apple grabs 30% of that for the first year of subscription (like it does for app purchases), and then the taxman grabs another 30-40% of what's left. You pay $6, I get less than $3, and I can buy a couple litres of milk for example. After two years I'd have enough to buy a beer in the pub. Yay.<br />
<br />
Some folks will likely ask for a lump sum "lifetime" option for the extra features. It's not good for the <i>sustainable business model</i> – the purchases would end soon, at which point there is no income. Also, it's difficult for anyone to promise that it will actually work for a "lifetime", due to the need for regular maintenance and support from the developer.<br />
<br />
<b>When comparing prices of applications one should remember the size of the target audience.</b> Creating and maintaining an application takes roughly as much time for 10, 1000 or 100000 users. This is why some really nice and big apps for the general public can be really cheap, or financed by in-app advertisements: 1€ per user for 100000 users would already make 100000€. This makes apps for smaller audiences (hams with iPhones <i>and</i> interest in APRS) relatively more expensive.<br />
<br />
<h3>
To re-iterate:</h3>
<ul>
<li>The subscription price will be small (roughly around 50 cents / month), paid through in-app payment.</li>
<li>There will be a free trial period in the beginning of the subscription, so you'll know what you'll get. Just remember to cancel it before the end of the trial; this is how Apple's subscription trials work.</li>
<li>It will enable all new features in the future.</li>
<li><b>Current features will NOT stop working or require subscription payment</b> – the subscription is optional and you get to keep what you paid for earlier.</li>
<li>Some future new features will also be included the base feature set, not requiring subscription.</li>
</ul>
<div class="separator" style="clear: both; text-align: center;">
</div>
Hessuhttp://www.blogger.com/profile/12550787353137508264noreply@blogger.com1tag:blogger.com,1999:blog-2631429776292642259.post-8541595695959837862017-05-09T08:07:00.000+03:002017-05-09T10:17:50.570+03:00Important Hints to iGate developers<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://4.bp.blogspot.com/--oFHoDBzAeg/WRFjG1_AFQI/AAAAAAAADBE/HesEIDzikRwxtsbgOnyMw_K9At3EqqQcACLcB/s1600/ESP8266_mounted_on_adapter.jpg" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="200" src="https://4.bp.blogspot.com/--oFHoDBzAeg/WRFjG1_AFQI/AAAAAAAADBE/HesEIDzikRwxtsbgOnyMw_K9At3EqqQcACLcB/s200/ESP8266_mounted_on_adapter.jpg" width="150" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><a href="https://commons.wikimedia.org/w/index.php?curid=54458803" target="_blank">By connorgoodwolf</a> - Own work, CC BY-SA 4.0</td></tr>
</tbody></table>
There are a lot of APRS iGate implementations out there, and new ones are popping up every few months these days. A lot of the new ones are made for various microcontroller chips and development boards (Arduino, ESP8266 and friends). Some are made for SDR sticks, some are built in mobile phone applications. Many of them reduce the amount of hardware needed to run an iGate by fully removing the need for a TNC, a full-blown computer, or an actual amateur radio transceiver.<br />
<br />
Very cool stuff!<br />
<br />
<br />
It would seem like writing an iGate would be very easy: receive packets off the air, put them in TNC2 format, and pass them to the APRS-IS servers over TCP (specifications: <a href="http://aprs-is.net/Connecting.aspx" target="_blank">connecting</a>, <a href="http://aprs-is.net/IGating.aspx" target="_blank">design</a>, <a href="http://aprs-is.net/IGateDetails.aspx" target="_blank">details</a>). But it turns out that there are quite a few things that can go wrong in the implementation, and in fact, some things seem to be going wrong the same way fairly often. Some bugs are fairly common and some seem to pop up in multiple different iGates, old and new.<br />
<br />
<a href="https://2.bp.blogspot.com/-OKdEssurI7E/WRFfKi0tiqI/AAAAAAAADAs/gPbcU3l8w5Yn8Eo4G-GBmiLBgTesVM-2QCLcB/s1600/disaster-girl-worked-fine-in-dev-ops-problem-now.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="239" src="https://2.bp.blogspot.com/-OKdEssurI7E/WRFfKi0tiqI/AAAAAAAADAs/gPbcU3l8w5Yn8Eo4G-GBmiLBgTesVM-2QCLcB/s320/disaster-girl-worked-fine-in-dev-ops-problem-now.jpg" width="320" /></a>Currently the most popular ones are due to the false assumption that all packets are either plain 7-bit English ASCII text with no NUL bytes or other binary stuff, or some specific Unicode encoding such as UTF-8. These assumptions lead to the packets getting truncated at the first NUL (binary 0) byte, or otherwise modified in a way that scändic and <span style="background-color: white; color: #222222;">ø</span>thér ïnternáti<span style="background-color: white; color: #222222;">ønal characters get mutilated if they don't happen to use the same encoding. Sometimes a truncation of a packet at the first NUL may lead to the packet being concatenated together with the next packet.</span><br />
<br />
I get to decode the corrupted packets on <a href="https://aprs.fi/" target="_blank">aprs.fi</a>, and I also get to process the corrupted ones in the aprsc APRS-IS server software which is <a href="http://status.aprs2.net/" target="_blank">fairly common</a> these days. If the bugged packets are not detected and handled, there usually are some folks complaining to me about the odd results, since they are often received from aprsc and viewed on aprs.fi.<br />
<br />
I can't blame the authors of the new applications – I have to admit that APRS documentation is <i>not great</i>, and it's easy to stumble across the same bugs if you haven't fixed them once before.<br />
<br />
<a href="https://1.bp.blogspot.com/-PhKCvxlYMDM/WRFhN7hkpRI/AAAAAAAADA4/Cue3CU8yvKUtDaQZKL6nGpHj2yZZRipdACLcB/s1600/code-staring.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="200" src="https://1.bp.blogspot.com/-PhKCvxlYMDM/WRFhN7hkpRI/AAAAAAAADA4/Cue3CU8yvKUtDaQZKL6nGpHj2yZZRipdACLcB/s200/code-staring.jpg" width="176" /></a>Every now and then I spend an evening trying to identify some of these bugs in the APRS-IS client applications and file bug tickets to the software authors. Last night I filed 3 packet corruption bug reports on Github for 3 different iGate applications. These are not the first ones, I've probably filed 30 in the past. It's not hard to spot these once you know what to look for.<br />
<b><br /></b>
<b>I'd like to take this chance to thank to all the authors who fix the bugs in a timely manner and release the fixed versions!</b><br />
<br />
Based on this experience I wrote a little <b>document listing common iGate bugs: <a href="https://github.com/hessu/aprsc/blob/master/doc/IGATE-HINTS.md" target="_blank">IGATE-HINTS.md</a></b>. It'd be great if all APRS software authors could glance through it and make sure these bugs are not present in their own software. If you spot someone writing a new iGate, please pass on the link to the new author – hopefully these bugs will then be avoided right from the beginning.<br />
<br />
Unfortunately some buggy iGate applications are orphaned and no longer developed. A few of those applications are fairly popular, too. It'd be great for the network if iGate operators could gradually upgrade to applications which still get updates, and don't exhibit any of the packet-corrupting bugs.<br />
<br />
A lot of iGates are also not getting updated, even though they run software which would have updates available. Some iGate operators feel that the iGates work, sort of, since most packets go through them just fine, most of the time. I think I'll try to make aprs.fi highlight some of the more common issues on the station info page in the future.<br />
<br />
If you know a little Python or C, and you've got a little extra time, <a href="https://twitter.com/aprsfi" target="_blank">let me know</a> – there are some bugs out there in the Open Source Land which could use a helping hand.<br />
<style type="text/css">
p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 15.0px Menlo; color: #ffffff; background-color: #000000; background-color: rgba(0, 0, 0, 0.94)}
span.s1 {font-variant-ligatures: no-common-ligatures}
</style>Hessuhttp://www.blogger.com/profile/12550787353137508264noreply@blogger.com1tag:blogger.com,1999:blog-2631429776292642259.post-87771569648211069122017-03-25T20:18:00.002+02:002017-03-25T20:18:40.867+02:00New version of aprs.fi's APRS packet parser released: Ham::APRS::FAP v1.21<div class="p1">
<a href="https://2.bp.blogspot.com/-JWkYtM4dwD8/WNazozVo6VI/AAAAAAAADAY/x6B63ULs56sLLg3F1pqAz1E3xnbHb-Z_ACLcB/s1600/powered_by_perl.gif" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://2.bp.blogspot.com/-JWkYtM4dwD8/WNazozVo6VI/AAAAAAAADAY/x6B63ULs56sLLg3F1pqAz1E3xnbHb-Z_ACLcB/s1600/powered_by_perl.gif" /></a></div>
<div>
Yesterday I uploaded a new version of the APRS packet parser used by aprs.fi, <a href="http://search.cpan.org/~hessu/Ham-APRS-FAP/" target="_blank">Ham::APRS::FAP</a>, to the CPAN. It's open source, so if you're a little bit weird like me and enjoy programming in Perl, this might be useful. Here's a full list of changes:</div>
<ul>
<li><span class="s1">Improve make_position() to support HMS UTC timestamp. </span>make_position() now returns the packet type character so that it can signal the presence of a timestamp.</li>
<li>Improve make_position() to support comment string, !DAO! extension, altitude encoding. Fix rounding errors in lat/lon/speed. Support generating packets with no speed or course. Take optional parameters in a hash parameter. Implement unit tests for make_position().</li>
<li><a href="https://travis-ci.org/hessu/perl-aprs-fap" target="_blank">Set up Travis automatic running of the (existing) unit test runs</a>.</li>
<li><span class="s1">Additional character escaping in regular expressions to deal</span> with deprecated functionality in Perl 5.22.</li>
</ul>
<div>
The packet parser is one of the more complete APRS decoders, although I'm not sure if any of the parsers deal with <i>all</i> of the APRS features and packet variants yet.</div>
Hessuhttp://www.blogger.com/profile/12550787353137508264noreply@blogger.com4tag:blogger.com,1999:blog-2631429776292642259.post-89323013738530356782016-12-12T22:00:00.000+02:002016-12-13T10:58:52.218+02:00aprs.fi moving to TLSIn an effort to increase security on the web at large scale, web browser vendors and other organisations such as Google are making changes which encourage web sites to move to TLS/SSL encryption. Even web sites which previously did not seem to need it – ones with static content only, and ones without any login / password functionality. This is good and fine – even if it's not a banking web site, it's good that third parties along the network can not observe or modify the content being downloaded. The Chrome web browser has started to label non-encrypted sites with an informative '(i)' symbol which warns the user that "Your connection to this site is not private", and <a href="https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html" target="_blank">will eventually make those warnings stronger</a>. Google gives <a href="https://webmasters.googleblog.com/2014/08/https-as-ranking-signal.html" target="_blank">better ranking</a> in the search results for https sites.<br />
<br />
A real, practical issue right now is that the <a href="https://developers.google.com/web/updates/2016/04/geolocation-on-secure-contexts-only" target="_blank">geolocation Javascript API is no longer available on non-HTTPS sites in recent Android and Chrome versions</a>. This actually broke map center and tracking functionality on the aprs.fi web site.<br />
<br />
I wholeheartedly support this movement, it will make the Internet a better place!<br />
<br />
These days, with performance-improving developments such as <a href="https://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html" target="_blank">ECDHE</a>, <a href="https://en.wikipedia.org/wiki/Galois/Counter_Mode" target="_blank">GCM mode AES</a> and <a href="https://en.wikipedia.org/wiki/AES_instruction_set" target="_blank">hardware accelerated AES</a>, running TLS on a web server is <a href="https://www.maxcdn.com/blog/ssl-performance-myth/" target="_blank">not much</a> of a <a href="https://istlsfastyet.com/" target="_blank">performance issue</a> any more. Most of the CPU time will be spent on application logic, anyway.<br />
<br />
The fun part is that <a href="https://en.wikipedia.org/wiki/HTTP/2" target="_blank">HTTP/2</a>, a new protocol used by modern web browser to access web sites, is only used over TLS/HTTPS – it is not available over plaintext connections. HTTP/2 is faster than older HTTP versions, and a surprising side effect is that a web site <i><a href="https://www.httpvshttps.com/" target="_blank">may well open up faster</a></i> over HTTP/2 + TLS than over HTTP 1.1 <i>without</i> the encryption!<br />
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://3.bp.blogspot.com/-VFGEosj0g00/WE-qa0oqrUI/AAAAAAAAC_s/wGDO7TtVnvQyL6IXhSGr9BSHCcIR96SewCLcB/s1600/20160626-sappion-luomu-3.jpg" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="266" src="https://3.bp.blogspot.com/-VFGEosj0g00/WE-qa0oqrUI/AAAAAAAAC_s/wGDO7TtVnvQyL6IXhSGr9BSHCcIR96SewCLcB/s400/20160626-sappion-luomu-3.jpg" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Picture not related. I just took it last summer. Kyyttö cows <span style="background-color: white; color: #252525; font-family: sans-serif; font-size: 14px;">©</span> <a href="https://www.instagram.com/sappionluomutila/" target="_blank">Sappion luomu</a>.</td></tr>
</tbody></table>
Before now, aprs.fi has only used TLS/HTTPS for its login and user account management pages. Fairly soon I will have a maintenance break on the aprs.fi servers, upgrade the operating system to the next major release, and install a new version of the aprs.fi software which supports access over both HTTP and HTTPS. To reduce duplicate content (same stuff being available over both HTTP and HTTPS) it will prefer HTTPS and nudge clients that way every now and then, but initially plaintext access should be possible, too. Later on, if there are no surprises, the nudges will gradually become stronger.<br />
<br />
There are a few issues which need to be addressed. There are possibly a few Amprnet users accessing this site over amateur radio frequencies. On the other hand, they're then practically surfing the Internet over radio, and probably doing a few requests to other encrypted sites now and then, too, so maybe it's not a big problem for them.<br />
<br />
Another thing is that apparently users in China can't access the Google Maps API over HTTPS, so those users would still need the plaintext access for now. I might make the <a href="http://zh.aprs.fi/">zh.aprs.fi</a> site plaintext only, and bump those users that way, or something along that way. Maybe the Amprnet users can use that, too?Hessuhttp://www.blogger.com/profile/12550787353137508264noreply@blogger.com2tag:blogger.com,1999:blog-2631429776292642259.post-67228300321669865162016-10-09T20:47:00.000+03:002016-10-09T20:56:52.712+03:00aprs.fi iPhone/iPad app update: v1.6.2Version 1.6.2 of the <a href="http://aprs.fi%20iphone/iPad%20app" target="_blank">aprs.fi iPhone/iPad app</a> went out yesterday evening. I've been adding a few features and fixes here and there on the weekends, but most of the larger changes in the code are actually under the hood and not yet visible for the users. I've also spent a good amount of time upgrading the <a href="http://aprs.fi/">aprs.fi</a> web site backend and fixing a few bugs here and there.<br />
<br />
<span style="font-family: inherit;">Here are the visible changes in 1.6.2, all of them were recently requested by users of the app:</span><br />
<a href="https://4.bp.blogspot.com/-Ezx4yHJVYAY/V_qELeCQ05I/AAAAAAAAC_A/s6cSMu4CW1MxEYvb85gOoBRQgWt7sUQPgCLcB/s1600/aprsfi-app-shot-settings.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="400" src="https://4.bp.blogspot.com/-Ezx4yHJVYAY/V_qELeCQ05I/AAAAAAAAC_A/s6cSMu4CW1MxEYvb85gOoBRQgWt7sUQPgCLcB/s400/aprsfi-app-shot-settings.png" width="223" /></a><span style="font-family: inherit;"></span><br />
<ul>
<li><span style="font-family: inherit;">Tapping a station on the map multiple times switches the track line colour for that station.</span></li>
<li><span style="font-family: inherit;">Track line width can be adjusted in Settings. The default size is slightly thicker than the previous default.</span></li>
<li><span style="font-family: inherit;">The maximum tracked station tail/track length is now 6 hours.</span></li>
<li><span style="font-family: inherit;">Previously selected stations and addresses can be deleted by swiping the respective table row to the left.</span></li>
<li><span style="font-family: inherit;">Previously selected address search results are retained even if the application is killed manually by the user.</span></li>
<li><span style="font-family: inherit;">Some small visual adjustments (more space between "Beacon now!" and "Delete station" buttons, etc).</span></li>
</ul>
<br />
<span style="font-family: inherit;">Some folks are also asking for a feature to track multiple stations at the same time, but that can already be done, since version 1.0 – just tap the '+' button on the additional stations info view to add them in tracking. <a href="https://youtu.be/EjysllVZqVE?t=55s" target="_blank">This video demonstrates tracking many stations in the iOS app</a>.</span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;">Here are some of the new features added in previous versions this summer:</span><br />
<br />
<ul>
<li><span style="font-family: inherit;"><span style="background-color: white;">Setting to hide/show station callsign labels on the map</span></span></li>
<li>Setting to disable (accidental) map pinch rotation</li>
<li>Latest packets of an APRS station can be viewed by clicking a new button in the station information view. Tap a packet to decode it using the aprs.fi packet decoder.</li>
<li>Filtering feature to control what is shown on the map, for hiding weather and AIS stations, for example. Complex custom filtering will be available in the future.</li>
<li>A feature to display road traffic information (traffic jams). The information can be hidden in Settings.</li>
</ul>
<br />
I'm also currently working on APRS-IS beaconing and messaging features, and arbitrary date/time range selection (with long time ranges), but they're not complete yet. Larger features take more time.<br />
<br />
The app is already getting quite happy reviews, but it still needs a few features to really make it complete. The 5-star average rating and these reviews are for version 1.6.1, from users from the USA:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://3.bp.blogspot.com/-_4qgXfT5dD0/V_oNsnNAitI/AAAAAAAAC-s/AX8Wlts3RyMW5m3T6gZT-7pDTlx0kvB0gCLcB/s1600/aprsfi-app-reviews-usa1.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="640" src="https://3.bp.blogspot.com/-_4qgXfT5dD0/V_oNsnNAitI/AAAAAAAAC-s/AX8Wlts3RyMW5m3T6gZT-7pDTlx0kvB0gCLcB/s640/aprsfi-app-reviews-usa1.png" width="359" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://2.bp.blogspot.com/-r1V65wSH5ck/V_oNtvWTmcI/AAAAAAAAC-w/WCAj4Ap_M80kE9qZyh5AGNg1sQpGHpDTgCLcB/s1600/aprsfi-app-reviews-usa2.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="640" src="https://2.bp.blogspot.com/-r1V65wSH5ck/V_oNtvWTmcI/AAAAAAAAC-w/WCAj4Ap_M80kE9qZyh5AGNg1sQpGHpDTgCLcB/s640/aprsfi-app-reviews-usa2.png" width="358" /></a></div>
<br />
<br />Hessuhttp://www.blogger.com/profile/12550787353137508264noreply@blogger.com0tag:blogger.com,1999:blog-2631429776292642259.post-6200342292399834632015-12-13T20:10:00.000+02:002015-12-13T20:39:52.473+02:00aprs.fi iOS app for iPhone and iPad!<a href="http://2.bp.blogspot.com/-V1AeRGUpHY4/Vm1259ITwzI/AAAAAAAAC8I/dsIBsT8CbfM/s1600/aprsfi-logo-social-blog.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="143" src="http://2.bp.blogspot.com/-V1AeRGUpHY4/Vm1259ITwzI/AAAAAAAAC8I/dsIBsT8CbfM/s200/aprsfi-logo-social-blog.png" width="200" /></a>The new, official <a href="https://geo.itunes.apple.com/app/aprs.fi/id922155038?mt=8&at=1000la28&ct=blog" target="_blank">aprs.fi iOS application</a> went live on the App Store a week back. It runs on the iPhone and iPad, and currently supports iOS 7 to iOS 9. Purchase once – run on up to 10 devices associated to the same iTunes accounts!<br />
<br />
It provides <b>immediate</b>, near-real-time visibility to APRS traffic around you, and has quick search-as-you-type station and address search functions. Zoom around the world as easily as on aprs.fi, or look up stations by their callsign. Multiple stations can be tracked at the same time.<br />
<br />
Telemetry, weather, and APRS station statistics can be viewed as graphs.<br />
<br />
The new <a href="http://blog.aprs.fi/2015/11/new-symbol-graphics-and-better-support.html">high-resolution symbol graphics</a> look crisp on Retina displays. iOS 9 Split-Screen multitasking is supported on applicable devices (iPad Air 2, iPad Pro, iPad mini 4, and newer). Landscape and portrait modes work too, of course.<br />
<br />
Position beaconing to aprs.fi works great, although, as usual, GPS use in the background reduces battery life noticeably. The <b>minimum transmit interval</b> slider can be used to reduce transmission rate, allowing the GPS to turn off for longer periods of time. The app does not require location information, but it can be helpful for automatic map centering and calculating distances.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen="" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/EjysllVZqVE/0.jpg" frameborder="0" height="266" src="https://www.youtube.com/embed/EjysllVZqVE?feature=player_embedded" width="320"></iframe></div>
<br />
A little expectation management needs to be done at this point: Some future features will only be available for a small additional yearly price, through an in-app purchase. That price will be lower than the purchase price of the app. The rationale behind this is simple: There's only a rather small number of APRS iOS users around the world, and once most of them have bought the app once, there will be no more income from the app, ever. Having a small, steady income nicely keeps up the motivation in maintaining and improving the application in the future. A few APRS apps have already been practically abandoned on the app store, with no updates in one, two or three years. The original app, simply named "APRS" recently got deleted and replaced with something completely unrelated.<br />
<br />
Some new features, and all bug fixes of course, will be free updates. The current version does not even include any support for in-app purchasing yet – it'll maybe come up some time next year, after the base features are ready.<br />
<br />
<a href="https://geo.itunes.apple.com/app/aprs.fi/id922155038?mt=8&at=1000la28&ct=blog" target="_blank">Purchase the app now</a>, and you'll get a nice APRS web site for free!<br />
<br />
<a href="https://geo.itunes.apple.com/app/aprs.fi/id922155038?mt=8&at=1000la28&ct=blog" style="background: url(http://linkmaker.itunes.apple.com/images/badges/en-us/badge_appstore-lrg.svg) no-repeat; display: inline-block; height: 40px; overflow: hidden; width: 165px;"></a>
<br />
<h3>
<br /></h3>
<h3>
Frequently Asked Questions</h3>
<div>
<br /></div>
<h4>
What about Android?</h4>
<div>
Yes, maybe later. It takes a lot of time to produce these things. I concentrated on iOS mostly because all my devices happen to be iOS, I have some previous experience on iOS development, and <a href="https://aprsdroid.org/" target="_blank">APRSDroid</a> is already so good.<br />
<br /></div>
<div>
<h4>
</h4>
<h4>
Filtering, I wish to hide AIS vessels and/or weather stations?</h4>
Yes, that's on the top of my list of things to do, I can't live without them either.<br />
<br /></div>
<div>
<h4>
</h4>
<h4>
Can not beacon to APRS-IS?</h4>
Not yet! This is the <b>aprs.fi app</b>, not an APRS-IS app, so it talks primarily to the aprs.fi service, not other services. Beaconing to APRS-IS will come later, stay tuned.<br />
<br />
Connecting to the aprs.fi database makes the immediate real-time view happen, so that there's no need to wait 30 minutes for everyone to transmit their position once after opening the app. On the downside, if aprs.fi happens to be down, the app doesn't do much either. Luckily aprs.fi has proven to be very stable during its operation since 2007.<br />
<br /></div>
<div>
<h4>
</h4>
<h4>
Messaging?</h4>
Yes, of course, later.<br />
<ul>
</ul>
</div>
Hessuhttp://www.blogger.com/profile/12550787353137508264noreply@blogger.com9tag:blogger.com,1999:blog-2631429776292642259.post-47392583527422657002015-11-03T13:15:00.000+02:002015-12-03T09:25:21.435+02:00New symbol graphics and better support for mobile devices<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="http://4.bp.blogspot.com/-28I6jfI6hBo/VjiT44T3FkI/AAAAAAAAC7g/QeVN7tNLdH8/s1600/aprs-symbols-demo2.png" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="200" src="http://4.bp.blogspot.com/-28I6jfI6hBo/VjiT44T3FkI/AAAAAAAAC7g/QeVN7tNLdH8/s400/aprs-symbols-demo2.png" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Old symbols, scaled up, pixels obvious</td></tr>
</tbody></table>
[updated 2015-11-03: the set is now available on github.]<br /><br />I've just upgraded <a href="http://aprs.fi/">aprs.fi</a> to use my new APRS symbol graphics set. The new symbols are <a href="https://en.wikipedia.org/wiki/Vector_graphics" target="_blank">drawn in vector format</a> (as opposed to a <a href="https://en.wikipedia.org/wiki/Raster_graphics" target="_blank">raster format</a> at a fixed resolution), allowing them to be rendered at larger and smaller sizes without distortion or blurriness. The new symbols are slightly larger than the old ones, making them easier to recognise on modern displays having smaller pixels than the old ones. They're also available in double resolution so that they're properly sharp on the 4K/retina displays found on many modern tablets, phones and computers!<br />
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="http://1.bp.blogspot.com/-iuuDFmqZKXs/VjiCwEG7NgI/AAAAAAAAC7Q/uf0KFlYj4K0/s1600/aprs-symbols-demo.png" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="200" src="http://1.bp.blogspot.com/-iuuDFmqZKXs/VjiCwEG7NgI/AAAAAAAAC7Q/uf0KFlYj4K0/s400/aprs-symbols-demo.png" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">New symbols, scaled up - no pixelation!</td></tr>
</tbody></table>
One downside is that they are just a little bit bigger than the old ones, taking up more space on the screen. On the other hand, the old ones were a bit too small on modern displays, and the very small resolution did make it hard to understand what the symbol tried to mimic.<br />
<br />
<a href="https://github.com/hessu/aprs-symbols" target="_blank">The new aprs.fi symbol set is available as open source on GitHub</a>, in both vector (Adobe Illustrator/PDF) and raster (PNG) formats. Other APRS applications may then use them, too, at no cost. Raster renderings are available in 24x24, 48x48, 64x64 and 128x128 pixel resolutions - drawing from raster sprites in apps is usually quicker and easier than working with the vector source material. Having the vector sources makes it possible to improve them and and replace individual symbols easily. If you need to render other resolutions or make some other fine tuning, you can run <a href="http://www.adobe.com/products/illustrator.html">Illustrator for free for 30 days</a>. The symbol set release even comes with a little piece of javascript which crunches out the 3 PNG files (primary, secondary, overlay characters) at the 4 resolutions in a few seconds.<br />
<br />
Naturally I did not draw all of the symbols myself. Many are loosely or strongly based on the original symbol graphics, primarily to keep the familiar and consistent look. Some symbols I obtained from other sources, such as Wikipedia. In those cases I picked SVG versions which allow commercial reuse (source known, and the work is placed on public domain, or with a CC license which allows adaptation and commercial reuse). In any case, the source and copyright information is documented separately for each symbol.<br />
<br />
The aprs.fi symbol graphics set <b>does not contain additional symbols for overlays yet</b>, mostly because it takes lots and lots of time to draw them, and the effort it took to create this set was pretty high already. Maybe later!<br />
<br />
There is one obvious difference in the new symbol set: the "ham store" symbol has been replaced with a more generic "store" shopping cart, reflecting the <a href="http://www.aprs.org/symbols/symbolsX.txt" target="_blank">current \h symbol definition</a> in the master index. Please use the 'H' overlay character to specify an amateur radio shop.<br />
<br />
To complement the symbol graphics, I've previously published a <a href="https://github.com/hessu/aprs-symbol-index" target="_blank">machine-readable (CSV/JSON/XML/YAML) APRS symbol description index</a>, which is easier to integrate in applications than Bob's master list.<br />
<b><br /></b>
<b>Improved mobile device support</b><br />
<br />
aprs.fi will now work better than before on mobile devices. I fixed the signup/login flow and most of the text and data table views to scale more nicely on small devices, allowing horizontal scrolling of tables. It'll need some more work to make it very nice, but this is a good start.Hessuhttp://www.blogger.com/profile/12550787353137508264noreply@blogger.com7tag:blogger.com,1999:blog-2631429776292642259.post-13749460459954620302015-10-09T08:46:00.000+03:002015-10-09T08:46:37.125+03:00OpenStreetMap available again<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-mW-GBKWUNMU/VhdT3fuYQ4I/AAAAAAAAC6s/iu_ZhVE-JMQ/s1600/blog-osm.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="227" src="http://4.bp.blogspot.com/-mW-GBKWUNMU/VhdT3fuYQ4I/AAAAAAAAC6s/iu_ZhVE-JMQ/s400/blog-osm.png" width="400" /></a></div>
<br />
Earlier this year aprs.fi <a href="http://blog.aprs.fi/2015/04/google-maps-disabled-on-aprsfi.html">was unavailable</a> for a short while after Google disabled Maps API access due to mixed OSM/Google content being visible on the site.<br />
<br />
I now spent a couple evenings setting up OSM again in a way that would not interfere with Google's policy of not allowing Google content such as Street View or address search results to be shown on top of non-Google maps. The result of that work is now live on aprs.fi.<br />
<br />
OpenStreetMap maps are again visible, but Street View buttons and controls are hidden while in OSM mode.<br />
<br />
While using OSM, address searches are done by using the GeoNames database. City lookups work quite well, but address searches do not seem to work, at least not for Finland. City/country lookups do not return information on how large the found place is, so zoom level does not adjust automatically to cover the place.Hessuhttp://www.blogger.com/profile/12550787353137508264noreply@blogger.com2tag:blogger.com,1999:blog-2631429776292642259.post-79328621784685800742015-10-07T00:40:00.001+03:002015-10-07T00:40:54.209+03:00Beware: Cookies.<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="http://1.bp.blogspot.com/-1LWr7F2g-_k/VhQ4c-3O7aI/AAAAAAAAC6Q/oIKxOwytMs8/s1600/cookies.jpg" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="211" src="http://1.bp.blogspot.com/-1LWr7F2g-_k/VhQ4c-3O7aI/AAAAAAAAC6Q/oIKxOwytMs8/s320/cookies.jpg" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Credit: star5112 / Flickr Creative Commons</td></tr>
</tbody></table>
This is not the feature I actually wanted to implement next, but here goes.<br />
<br />
aprs.fi now displays one of those oh-so-common warnings saying "This site uses cookies". There is some code in there to try to show the warning only to visitors from the European Union, but due to the inherent inaccuracy of GeoIP-type lookups, it may fail either way for some users.<br />
<br />
aprs.fi has used <a href="https://en.wikipedia.org/wiki/HTTP_cookie" target="_blank">cookies</a> from the beginning, just like roughly all the other web sites in the world. Nothing in the use of cookies has changed (they're used everywhere and by everyone), but new regulations set by the European Union, and requirements set by Google, require aprs.fi to display this warning.<br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;">Once you click the '✖' button in the corner of the warning, a cookie will be set, so that your selection is remembered, preventing the warning box from appearing again. It'd be annoying if the box appeared every time. If you have disabled cookies, the warning will appear every time, since the web site cannot know if you have dismissed the box before or not, since that information would be stored in a cookie.</span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;">More information:</span><br />
<br />
<ul>
<li><a href="http://www.google.com/about/company/user-consent-policy.html" target="_blank">Google EU user consent policy</a></li>
<li><a href="https://support.google.com/adsense/answer/6245892?hl=en" target="_blank">Google EU consent policy FAQ</a></li>
<li><a href="https://www.cookiechoices.org/" target="_blank">Google helping publishers with cookie consent</a></li>
<li><a href="http://aprs.fi/page/privacy" target="_blank">Privacy policy of aprs.fi</a></li>
</ul>
<br />
<form action="http://mapt.he.fi/" method="get" style="background-color: white; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 12px; margin: 0px; padding: 0px;">
</form>
Hessuhttp://www.blogger.com/profile/12550787353137508264noreply@blogger.com0tag:blogger.com,1999:blog-2631429776292642259.post-51381853391062345402015-06-21T16:44:00.001+03:002015-06-21T16:44:22.548+03:00DKIM, SPF and assorted tricks to get through spam filtersToday I've set up <a href="http://www.dkim.org/" target="_blank">DKIM</a> (<a href="https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail" target="_blank">DomainKeys Identified Mail</a>) on the aprs.fi servers and within the aprs.fi DNS zone. A week back I already set up the <a href="https://en.wikipedia.org/wiki/Sender_Policy_Framework" target="_blank">SPF (Sender Policy Framework)</a> records in the DNS, and fixed the reverse DNS information for the IPv6 addresses used by aprs.fi to send out email.<div>
<br /><table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="http://3.bp.blogspot.com/-c_w1AW1saaA/VYa-5pGhs7I/AAAAAAAAC5A/cMlUM5tN0b8/s1600/spam.jpg" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="239" src="http://3.bp.blogspot.com/-c_w1AW1saaA/VYa-5pGhs7I/AAAAAAAAC5A/cMlUM5tN0b8/s320/spam.jpg" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><span style="background-color: white; color: #999999; font-family: 'Proxima Nova', Helvetica, sans-serif; font-size: 12px; font-style: italic; text-align: start;">Mike Mozart / Creative Commons / Via </span><a href="https://www.flickr.com/photos/jeepersmedia/14010924432/in/photolist-7xTgcM-92GYYS-MWDXK-4YquSL-5CdVgj-P2Vxe-9ivgoD-b4ThXT-dAPegg-63Qv8E-pahwM-eKfYX-3amv6c-4rj2st-nSQoB-nm6DGC-8TvbJW-517Dag-8QJsR1-9XaKCf-94FQuX-4UmTaY-9Ye3sC-eJm1Gs-pZJFZa-9PVUjk-6UH1aU-4jp" style="background-color: white; color: #999999; font-family: 'Proxima Nova', Helvetica, sans-serif; font-size: 12px; font-style: italic; padding: 3px 0px 20px; text-align: start; text-decoration: none;" target="_blank">Flickr: jeepersmedia</a></td></tr>
</tbody></table>
<div>
In non-technical terms, this should help GMail and other services to figure out cases of others sending email (spam?) on behalf of aprs.fi, and correctly classify those as junk. It also might help GMail figure out that the registration confirmation and password reset emails sent out by aprs.fi are actually not spam.</div>
<div>
<br /></div>
<div>
It has been a rather persistent problem - GMail has consistently labeled the registration emails as spam, and people have been asking why they're not getting the emails. In all cases the mails have been found in the spam folder. We'll see if this helps!</div>
</div>
<div>
<br /></div>
<div>
Thank you to postfix and opendkim for making this a rather easy thing to get going.</div>
Hessuhttp://www.blogger.com/profile/12550787353137508264noreply@blogger.com0tag:blogger.com,1999:blog-2631429776292642259.post-90658176823119563552015-04-02T11:30:00.000+03:002015-04-03T14:10:11.387+03:00Google Maps disabled on aprs.fi temporarily due to a TOS accident<br />
I woke up today to find out that Google Maps are disabled on aprs.fi, and the site is slightly crippled.<br />
<br />
Google had noticed that aprs.fi has integrated support for OpenStreetMap map tiles *and* Street View. I hadn't noticed that the combination of Street View on top of anything else than Google Maps is forbidden according to the Maps API Terms Of Service document. Or I had just forgotten about it when implementing OSM or Street View (there was probably a year or two of time between the two, and probably another year or two since I actually read the lengthy TOS).<br />
<br />
Google had nicely sent me a few emails to warn about the unapproved combination, first one already on 5th of March. I had moved away from reading emails regularly in Gmail a long while back, but forgotten to arrange for these emails from Google APIs to go to my primary email address. Silly me. Since I didn't respond or do anything about the situation, for almost a full month, they disabled Maps API, which certainly got my attention.<br />
<br />
Oh well. OSM support is disabled for now, and I notified Google that aprs.fi is again compliant with the terms. Should be back soonish.<br />
<br />
I might put OSM support back later, and remove Street View instead, as OSM is probably more useful in practice at some areas (although admittedly less visual and "cool"). Or maybe make some sort of arrangement where Street View only works if you have Google Maps selected instead of OSM. Have to check with the Google folks if that's OK, there are a few variations we can try. The first thing is to get the main functionality back up, no matter which maps they are.<br />
<br />
I'll post updates on Twitter (<a href="https://twitter.com/aprsfi">https://twitter.com/aprsfi</a>) and Facebook (<a href="https://www.facebook.com/aprs.fi">https://www.facebook.com/aprs.fi</a>). Stay tuned.<br />
<br />
My mistake entirely, although quite a human one. When did you last read the full text of the license agreement of your new application or mobile phone? :)Hessuhttp://www.blogger.com/profile/12550787353137508264noreply@blogger.com30tag:blogger.com,1999:blog-2631429776292642259.post-17423928074207287142015-03-13T20:52:00.000+02:002015-03-13T21:12:09.775+02:00Device identification database updated, available for other appsMost APRS devices and applications transmit an unique AX.25 destination callsign in all their packets, so that receiving stations can figure out which application or device is transmitting each packet. Bob Bruninga maintains a <a href="http://aprs.org/aprs11/tocalls.txt" target="_blank">tocalls.txt</a> index file, which lists all the assigned destination callsigns.<br />
<div>
<br /></div>
<div>
Those devices which use the Mic-E encoding to transmit position packets encode the latitude and a little bit of the longitude within the destination callsign, in which case something else has to be done for device identification. Mic-E device IDs are encoded around the comment text, with one character in the beginning of the comment text and zero to two characters in the end of the comment. The Mic-E type codes are indexed in <a href="http://www.aprs.org/aprs12/mic-e-types.txt" target="_blank">mic-e-types.txt</a>.</div>
<div>
<br /></div>
<div>
Now, when an application such as aprs.fi wishes to automatically decode the destination callsigns and type codes to readable application names, <a href="http://aprs.fi/info/a/OH7LZB-7" target="_blank">as seen on the aprs.fi station information page</a>, the author of that application needs to collect all the device identifiers from those two files, and somehow convert them to application source code, or a configuration file that can be read by the application. The master files are written with human interpretation in mind, and it's rather hard to make an application automatically parse out the identifiers from them. It needs to be done manually, and whenever new devices or applications are published, all the applications wishing to detect the new ones need to get an update. All softwares authors need to get notified that there are some new devices, and then somehow add the devices in their respective configs. That's quite a lot of extra work that would be better spent writing some fancy new features instead.</div>
<div>
<br /></div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://2.bp.blogspot.com/-XOVltzdBc1U/VQMvKiZ--3I/AAAAAAAAC3w/gXcHF0j3isU/s1600/20150312-ohsrh-efmi.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://2.bp.blogspot.com/-XOVltzdBc1U/VQMvKiZ--3I/AAAAAAAAC3w/gXcHF0j3isU/s1600/20150312-ohsrh-efmi.jpg" height="241" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">OH7LZB-7, correctly identified as a Kenwood TH-D72,<br />
at Mikkeli International yesterday afternoon.<br />
Aircraft and training provided by <a href="http://www.mik.fi/" target="_blank">MIK</a> at Helsinki-Malmi.</td></tr>
</tbody></table>
<div>
<br /></div>
<div>
For aprs.fi, I initially made a Perl module, <a href="http://search.cpan.org/dist/Ham-APRS-DeviceID/" target="_blank">Ham::APRS::DeviceID</a>, and published it as open source, so that other software authors could use the index too, and skip the manual labour-intensive part of parsing the master text files. For some obscure reasons a number of programmers have chosen to use other programming languages than Perl, and the module was of limited usefulness for them.</div>
<div>
<br /></div>
<div>
To improve the situation, I converted the device index in <a href="http://en.wikipedia.org/wiki/YAML" target="_blank">YAML</a> (Yet Another Markup Language), which is easy to read and edit by humans, and also easy to read and edit by computer programs. I also wrote a little converter program which parses the <a href="https://github.com/hessu/aprs-deviceid/blob/master/tocalls.yaml" target="_blank">tocalls.yaml</a> file and outputs the same data in <a href="http://en.wikipedia.org/wiki/JSON" target="_blank">JSON</a> and <a href="http://en.wikipedia.org/wiki/XML" target="_blank">XML</a> formats, which are popular file formats for passing data between computer systems.</div>
<div>
<br /></div>
<div>
I then updated the original Perl module to read the YAML file, and removed the old database that was embedded in the code. DeviceID.pm 2.00 and later use tocalls.yaml. I also updated aprs.fi to use the new version of the Perl module, and tocalls.yaml. The update brought a number of new devices to aprs.fi, including the newer Yaesu radios.</div>
<div>
<br /></div>
<div>
Other programmers who wish to do device identification are welcome to <a href="https://github.com/hessu/aprs-deviceid">download the YAML</a>, <a href="https://github.com/hessu/aprs-deviceid/tree/master/generated">JSON or XML</a> files and use those. It should be straightforward to automatically update the device index during an application build, or even automatically update the index directly in the application.</div>
<div>
<br /></div>
<div>
New devices should still be first added to Bob's files, and only then to tocalls.yaml. If you have a new device which has already been added to Bob's index, please make a pull request or an <a href="https://github.com/hessu/aprs-deviceid/issues">issue ticket</a> to update tocalls.yaml accordingly.</div>
Hessuhttp://www.blogger.com/profile/12550787353137508264noreply@blogger.com0Helsinki-Malmin lentoasema, Helsinki-Malmi Airport (HEM), 00700 Helsinki, Finland60.251646 25.04211199999997560.23589 25.001771499999975 60.267402000000004 25.082452499999974tag:blogger.com,1999:blog-2631429776292642259.post-23041541240767008822014-02-17T00:42:00.000+02:002014-02-17T00:45:57.474+02:00Mic-E mangled packet parsing improvements<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="http://3.bp.blogspot.com/-cmwxq7EZFCo/UwE7hlJZJ6I/AAAAAAAACwk/Wwwc6hTZKJU/s1600/oh7lzb-kenwood-thd72-0001.JPG" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="http://3.bp.blogspot.com/-cmwxq7EZFCo/UwE7hlJZJ6I/AAAAAAAACwk/Wwwc6hTZKJU/s1600/oh7lzb-kenwood-thd72-0001.JPG" height="320" width="181" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">One of my APRS transmitters<br />
using the Mic-E packet format.<br />
Fresh photo for the blog.</td></tr>
</tbody></table>
Mic-E encoded packets, as commonly transmitted by Kenwood & Yaesu radios, Byonics trackers and others, are often corrupted by broken APRS igates. The speed/course bytes in these packets, which often have binary values in the 0x1C - 0x1F range (unprintable control codes in the ASCII table), or the 0x7F DEL "character", are commonly removed or replaced with spaces (0x20, space bar) by certain iGate setups.<br />
<br />
Mangling packets in transit is wrong, and by default it would make these position packets, which are completely valid according the protocol specification, fail to decode, and fail to plot on aprs.fi. To get around this aprs.fi and many other decoders try to detect these broken packets and extract whatever information is left in them after the broken igate.<br />
<br />
Yesterday evening I fixed a few bugs in the Mic-E packet decoder used by aprs.fi. This improves the handling of mangled packets a bit further.<br />
<ul>
<li>The correct symbol table identifier (primary or secondary) is now successfully decoded from mangled Mic-E packets. The table identifier byte was incorrectly extracted before the demangling trick - from the wrong offset due to the mangling. Thanks to KD0KZE for the bug report.
</li>
<li>Speed and course information is no longer decoded from Mic-E packet if demangling was applied. That information has been lost in transit when the packet got mangled by the igate.</li>
<li>Mangled Mic-E packets are now indicated with a <b>mice_mangled</b> flag in the decoded raw packets. Switch from Normal to Decoded mode in the <a href="http://aprs.fi/?c=raw" target="_blank">raw packets list</a> to see it in action. Expect to see broken igates highlighted on aprs.fi later on.</li>
</ul>
Today I released version 1.20 of the <a href="http://search.cpan.org/dist/Ham-APRS-FAP/" target="_blank">open source APRS packet parser</a>, which contains the above improvements. There are a few other fixes in there, which were already installed on aprs.fi earlier last year.<br />
<pre style="white-space: pre-wrap; word-wrap: break-word;"></pre>
Hessuhttp://www.blogger.com/profile/12550787353137508264noreply@blogger.com2tag:blogger.com,1999:blog-2631429776292642259.post-73884155129116771432013-12-02T09:38:00.000+02:002013-12-02T09:38:06.041+02:00Back button should now work!<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="http://3.bp.blogspot.com/-_TQYooiiTFA/Upwz3K66SVI/AAAAAAAACV4/3urcFi_TeH4/s1600/20131201-joulukissoja-0006.JPG" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="200" src="http://3.bp.blogspot.com/-_TQYooiiTFA/Upwz3K66SVI/AAAAAAAACV4/3urcFi_TeH4/s320/20131201-joulukissoja-0006.JPG" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Ocicat kitten, 5 weeks, (c) Heikki Hannikainen</td></tr>
</tbody></table>
Last night I spent a couple hours trying to improve URL navigation on the aprs.fi real-time map. The <b>back </b>and<b> forward </b>buttons have behaved quite weirdly for some time, and that simply needed to be fixed. The upgrade went in just a few minutes ago.<br />
<br />
With the help of the <a href="http://diveintohtml5.info/history.html" target="_blank">HTML5 history API</a> I think I <b>mostly</b> got it right now. It is of course likely that I missed some corners, so keep the feedback coming - either in blog comments or posts on the discussion group.<br />
<br />
Basically, the browser history now only gets a new entry when the user initiates a "major change" in the map status: a new callsign or a new address is searched. Those new history entries can be navigated using the web browser's <b>back</b> and <b>forward</b> buttons.<br />
<br />
Minor state changes, such as changing the time range / tail length parameters, and any changes <i>not initiated by the user</i>, should only <b>update</b> the current browser history entry. After first looking up station A, then looking up station B, and then changing time range, clicking <b>back</b> will take you to station A. Clicking <b>forward</b> will then take you to station B - with the changed time range! Try it out, you'll see what I mean.<br />
<br />
Naturally this won't work so nicely with steam-powered web browsers, or the oldest boat anchors out there.<br />
<br />
Christmas is coming, and postcards need to be printed, so I was required to take some kitten photos with seasonal props yesterday.Hessuhttp://www.blogger.com/profile/12550787353137508264noreply@blogger.com2tag:blogger.com,1999:blog-2631429776292642259.post-81105101932745217412013-11-06T09:32:00.000+02:002013-11-06T09:32:52.481+02:00Amateur Radio Questions and Answers<a href="http://ham.stackexchange.com/" target="_blank">Amateur Radio Stack Exchange</a> is a question and answer site for amateur radio enthusiasts. It's currently in public beta, and a lot of good questions already have great answers.<br />
<br />
The Stack Exchange Q&A site format is very popular in programmer circles - take a look at <a href="http://stackoverflow.com/questions" target="_blank">Stack Overflow</a> for example - good questions and answers get voted up, and the best answers are prominently displayed, unlike in traditional discussion groups and mailing list archives where the good bits are often buried in the middle of a lot of uninformed answers and chatter that is only slightly related to the original question.<br />
<br />
If you've got an amateur radio related question, please post it there. If not, try answering one of the <a href="http://ham.stackexchange.com/unanswered" target="_blank">unanswered questions</a>. It's actually a lot of fun!<br />
<br />
The site is currently in a beta, and needs a little push (questions, answers, votes) to keep going.<br />
<br />
Start with the instructions on the <a href="http://ham.stackexchange.com/about" target="_blank">About page</a>.Hessuhttp://www.blogger.com/profile/12550787353137508264noreply@blogger.com0tag:blogger.com,1999:blog-2631429776292642259.post-24558336206080208492013-10-20T14:32:00.004+03:002013-10-20T14:32:42.809+03:00aprs.fi upgraded on 2013-10-20<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="http://4.bp.blogspot.com/-8MLTn-gHN3M/UmO-7PaWYlI/AAAAAAAAB3E/joe3JkD-ivg/s1600/IMG_2258.JPG" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="240" src="http://4.bp.blogspot.com/-8MLTn-gHN3M/UmO-7PaWYlI/AAAAAAAAB3E/joe3JkD-ivg/s320/IMG_2258.JPG" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Photo unrelated to upgrade! Some floppies we found at the<br />OH2K club station while cleaning and discarding old stuff.<br />Quite nostalgic stuff for me.</td></tr>
</tbody></table>
I just finished upgrading aprs.fi. It's been a while since the last full upgrade (a few small patches have been applied in the meanwhile). Here's a summary of the changes:<br />
<br />
A fix for Internet Explorer 11. The real-time map view now loads and works on IE11, which has just become available to the general public.<br />
<br />
When running on a mobile device (ipad, android tablets, etc), the callsign input form field no longer gets focus automatically during the map load process. It tends to pop up the on-screen keyboard, which is quite annoying. On non-mobile devices the automatic focus still happens, so that you can start typing in a callsign right after opening up the site.<br />
<br />
Google Maps API code upgraded to version 3.13. I somehow suddenly get flashbacks from Donald Duck comics. Odd.<br />
<br />
Some internal code refactoring was done in the API and authentication code. If all went well, no visible changes to anyone.Hessuhttp://www.blogger.com/profile/12550787353137508264noreply@blogger.com4