[aprssig] OpenAPRS Direct Client Connection Interface (gogo gadget smart phones)

[Gregory A. Carter]

Hello all,

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?

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?

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.

Enter OpenAPRS's Direct Client Connection (DCC).

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:

1) Signup for an OpenAPRS Account (verify your license if you want to create
objects, position reports or messages).
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)

Example getting a weather report:

telnet dcc.openaprs.net 2620
Trying dcc.openaprs.net...
Connected to dcc.openaprs.net.
Escape character is '^]'.
001 MS:I am a OpenAPRS v1.01.02.
002 MS:Please login by typing ``.LN <email> <password> [client]''
.LN user at domain.com password
100 MS:Login successful.
.WX CL:AA6AV-10
500 MS:OK!
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
309 RS:1|MH:1|SW:0.0000|MS:1 of 1 matches returned (0.0000 seconds).
.QU
108 MS:Goodbye.

(the report is encoded by escapable field, BA=barometer, HU=humidity,
etc...)

Example sending an APRS message:

[login portion just as above]
.CM TO:N6NAR|MS:Hello how are you today?
500 MS:OK!
.QU
108 MS:Goodbye.

3) Disconnect or stay connected and get your APRS messages:

.CK
500 MS:OK!
300 CT:1222712020|SR:NV6G-2|MS:Hello!
300 CT:1222711876|SR:NV6G-2|MS:Hello!1
300 CT:1222711877|SR:NV6G-2|MS:Hello!2
300 CT:1222711796|SR:NV6G-2|MS:Hello!
301 RS:4|MS:4 messages returned.

(CT=creation timestamp, SR=source callsign, MS=message)

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.

So what's the point of announcing this to APRSSIG?

The point is this:

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.
2) I'd love to get support for this protocol in APRS software that is out on
the market today like Xastir and UIView.

Why get it added to APRS software?

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).

To read more about the DCC protocol check out it's documentation page at
http://dcc.openaprs.net/

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...

Greg

NV6G
OpenAPRS.Net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20080929/05b7a94d/attachment.html>