<div dir="ltr">Hello all,<br><br>I'm very excited to announce a new concept feature from OpenAPRS.  As everyone already knows, cell phones are here to stay and most of the smart phones have GPS support built into them and a nifty little SDK to develop applications for them.  So why not develop applications that will make use of these features in a way that only HAMs can appreciate?<br>
<br>I'm beta testing a new server "protocol" that would allow smart phones (Blackberry's, iPhones, etc) to connect to OpenAPRS through a TCP connection very similar to the way APRS software connects to the APRS-IS servers.  Obviously there is a high complexity to the modern APRS packet and that complexity limits smaller embeded devices from being able to easily and quickly access a broad range of APRS information that is out on APRS-IS.  There are so many different ways to send a position report these days that it hurts the head.  So why force smaller embeded devices to do all the work when there are databases out there like OpenAPRS that already have and are just waiting to give that information out in a simple standard format?<br>
<br>Another issue to contribute to the embded device delima is memory, sure a smart phone can connect to APRS-IS but would quickly be overrun by packets and clog both the memory and the processing power of the device, thereby limiting it's ability to find stations, send APRS messages or get the latest weather and telemetry reports.  Sure there are web pages that a phone can go to like OpenAPRS and though you can get information from there and see maps there is one important thing that you can't do, turn on the GPS and start sending your position reports on a beacon and have them gated to APRS-IS, set it and forget it.<br>
<br>Enter OpenAPRS's Direct Client Connection (DCC).<br><br>With DCC smart phones, people and APRS software that have support for it don't have to store position reports in memory or try and parse the multitude of different distinct APRS packets being shifted around APRS-IS all day long at 30 per second.  The basic concept is this:<br>
<br>1) Signup for an OpenAPRS Account (verify your license if you want to create objects, position reports or messages).<br>2) Connect up to DCC, I'll use telnet as an example but any device or program that can open a socket can do this. (commands prefixed with '.' are sent to server by me)<br>
<br>Example getting a weather report:<br><br>telnet <a href="http://dcc.openaprs.net">dcc.openaprs.net</a> 2620<br>Trying dcc.openaprs.net...<br>Connected to <a href="http://dcc.openaprs.net">dcc.openaprs.net</a>.<br>Escape character is '^]'.<br>
001 MS:I am a OpenAPRS v1.01.02.<br>002 MS:Please login by typing ``.LN <email> <password> [client]''<br>.LN <a href="mailto:user@domain.com">user@domain.com</a> password<br>100 MS:Login successful.<br>
.WX CL:AA6AV-10<br>500 MS:OK!<br>308 BA:1012.10|HU:49|LA:38.329166|LN:-122.319000|RM:0|RD:0|RH:0|SR:AA6AV-10|TM:24|WD:148|WS:9<br>309 RS:1|MH:1|SW:0.0000|MS:1 of 1 matches returned (0.0000 seconds).<br>.QU<br>108 MS:Goodbye.<br>
<br>(the report is encoded by escapable field, BA=barometer, HU=humidity, etc...)<br><br>Example sending an APRS message:<br><br>[login portion just as above]<br>.CM TO:N6NAR|MS:Hello how are you today?<br>500 MS:OK!<br>.QU<br>
108 MS:Goodbye.<br><br>3) Disconnect or stay connected and get your APRS messages:<br><br>.CK<br>500 MS:OK!<br>300 CT:1222712020|SR:NV6G-2|MS:Hello!<br>300 CT:1222711876|SR:NV6G-2|MS:Hello!1<br>300 CT:1222711877|SR:NV6G-2|MS:Hello!2<br>
300 CT:1222711796|SR:NV6G-2|MS:Hello!<br>301 RS:4|MS:4 messages returned.<br><br>(CT=creation timestamp, SR=source callsign, MS=message)<br><br>Of course while connected any messages sent to the callsign you signed up with will actually go to your client realtime and automatically be REPLY-ACKed once you've checked messages for the first time, this removes the need to keep using the .CK command to check over and over again.<br>
<br>So what's the point of announcing this to APRSSIG?<br><br>The point is this:<br><br>1) I'd love to find developers who can assist in witing programs for Blackberry and iPhone to use this protocol and allow these phones to live up to their Amateur Radio potential.<br>
2) I'd love to get support for this protocol in APRS software that is out on the market today like Xastir and UIView.<br><br>Why get it added to APRS software?<br><br>Simply put, wouldn't it be nice not to need to leave your client connected to APRS-IS for 30 minutes to get a good picture of the network?  One of the commands supported on OpenAPRS DCC will dispaly all stations within a given latitude/longitude window.  This means that you launch your APRS software, center the screen where you'd like to see APRS traffic, the software connects up to OpenAPRS DCC asks for stations in that window (including each stations tracks) and updates your view very much like APRS sites do that have Google Maps/AJAX support.  Having to leave a client connected to APRS-IS wastes bandwidth when all the clients wants is a clear picture of who is within the current display.  The DCC protocol also supports this for weather stations, weather data and telemetry data (including support for displaying EQNS, UNITS  and BITS).<br>
<br>To read more about the DCC protocol check out it's documentation page at <a href="http://dcc.openaprs.net/">http://dcc.openaprs.net/</a><br><br>Of course I'd love to hear any feedback, bug reports, etc that anyone has on this subject, drop me an email on list or off either way.  I don't expect that this concept will catch on fast but I'm very enthusiastic about the possibilities...  Now if only I could find some phone programmers...<br>
<br>Greg<br><br>NV6G<br>OpenAPRS.Net<br></div>