[aprssig] Generic Smartphone APRS aps!

[Gregg Wonderly]

On 1/24/2011 9:13 PM, Bob Bruninga wrote:
> To all aspiring smart-phone authors  I offer the following thoughts:
>
> 1) Hopefully someone has already written a standard APRS web page that will
> show any map of local activity as needed on any device.  So no one needs to
> develop map stuff for each new toy.  If such a web source does not exist
> then we need one person writing the killer site.

The vast majority of applications could not make any use of mapping that is not 
integrated to the application.  There is really no form of integration that an 
application can do as a client of a web page without the web page being a 
complete APRS application itself.  It also would vastly include the total 
bandwidth needed to the device quite dramatically to provide updates as station 
traffic caused changes on the map.

The map is essential to the "view" of what is happening and what is available 
around APRS mobile participants.

> 2) Instead, for each new wireless toy, concentrate on APRS in the following
> priority order.  Every electronic device  that might be in the hand of a ham
> radio operator should be able to do these things in this order of priority.
>
> a) TXing current status (&  position if the device knows it)
> b) Includes monitoring FREQuency if available
> c) Receiving any APRS messages
> d) Sending APRS messages
> e) Sending OBJECTS (based on current position)
> f) Text Display of other nearby APRS-IS stations:
>     * Their STATUS text (or position text)
>     * Their contact frequency
>     * Their symbol
>     * Their direction and distance
>     * Their PHG, or WX or CSE/SPD
>     * Their Path

Most of this what APRS applications have historically done as a "minimum".  The 
frequency business is possible, but requires manual entry by the user if the 
device is not connected to a smart radio that provides this information through 
a serial port or other connectivity.

There is some use of bluetooth going on for serial access, but I really think 
there is a lot more flexibility in solutions such as the "WiSnap SMD Module 
131C" which provides a "terminal server" kind of solution in a small board that 
can be integrated into existing cases to allow smart devices, in multiplicity, 
access to a TNC and radio duly attached.

For many support applications, having a portable iGate in place on an alternate 
frequency would be a great help to improving communications, and doing APRS 
mostly over WIFI would mean that there would be no traffic dropped to the smart 
devices.  There are things we can do to help increase the viability of APRS in 
heavily used areas by moving stuff to alternate frequencies or "transports". 
The iGate server mechanisms really allow a more complete and robust APRS service 
to exist.  The 1.2kbps network works okay, but because of the pricing of the 
equipment and the limits on participants (except on highly optimized networks), 
more and more people will be finding ways to use existing smart devices, big and 
small, to participate.

WIFI just provides so much more distance, bandwidth and multiplexing that 
bluetooth can't provide to an iGate environment.

> Notice, that NO map is required.  The path may or may not show much of
> value, since only the shortest path to the nearest IGate is captured by the
> APRS-IS, but it is a start.

I know you say this, but for me, the map is a pretty essential piece of data. 
Everything else that is not the map, is readable information, but the spacial 
information on the map is something that you can't quickly evaluate just from 
the "data" in the packets.  You have to do a lot more work than it makes sense 
for a mobile operator to have to deal with.

> All of the above to me is how APRS fulfills its primary objective of
> facilitating ham radio communications.  For the purpose of communications,
> the map is just not that important, yet is the biggest 95% of most APRS
> clients.  Authors can waste a few years of their life on developing a new
> mapping interface, or they can just settle for the above and be done in a
> week.

Mapping features vary, and many people do spend a lot of time on "mapping". The 
iPhone mapping support on the device is very easy to use, even though it does 
require a couple of layers of data to manage all aspects of its use.  But some 
people don't want to use it because it requires over the air services to 
download and use the map data provided by Google.  Your request for the 
"awesome" web page map has the same requirements of over the air download, so it 
might not be what some developers need for the audience and use they are targeting.

The other, non-map features of APRS are very fragile from a protocol and a 
"handling" perspective because of how we've glued stuff on over the years.

I and other developers I am sure are never excited by all the "details" that 
come out of how hard it is to decode APRS packets.  Every decoder must include a 
"bad packet" handling implementation because people send malformed packets 
because of how easy it is to "mistype" the contents of status and other often 
hand crafted packets.  The variations on good vs bad packets are often very 
subtle and difficult to keep up with.  So, we go through these long, drawn out 
development processes trying to work through the subtleties of compatibility and 
correctness.

Gregg Wonderly
W5GGW