[aprssig] Generic Smartphone APRS aps!

[Lynn W. Deffenbaugh (Mr)]

First, there is no such thing as a "Generic SmartPhone" platform.  Every 
phone O/S has a different development environment, language, licensing, 
and distribution model.  Even a "web application" may or may not work on 
any given SmartPhone browser...

And these recommendations ignore the RF aspect of APRS!  Just because 
it's a SmartPhone, doesn't mean that Internet access will always be 
available.

APRSISCE/32 already runs on Windows Mobile SmartPhones (as well as 
Windows desktops)

Includes an offline-capable mapping interface using cached 
OpenStreetMap.org maps

Supports connections to numerous TNCs the most handy method of which is 
via a Bluetooth to serial link attached to your TNC/radio so that your 
phone can connect on demand.

And when you DO happen to have mobile Internet, you can be a mobile 
IGate, bi-directional if you know you won't be interfering in the local 
infrastructure.

So, your advice is well intentioned, and focuses on one set of 
priorities and necessities (like messaging IMHO), but let's not leave 
the RF out of Ham radio, even if it is running on a phone.

Bob Bruninga wrote:
> 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.
>   

APRSISCE/32 doesn't do web.  It connects directly to the APRS-IS stream 
just like any other APRS client.  It is a full member of the APRS-IS 
network.

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

Done

> b) Includes monitoring FREQuency if available
>   

If the operator puts it in the comment text, done.  I'd love to have an 
interface directly to the radio, but that's just not feasible (yet).

> c) Receiving any APRS messages
>   

Done, including all messages for a callsign (-SSID independant), the 
standard "group" messages (ALL, QST, CQ), custom message groups, RF 
channel "Eavesdropping", and even full-up global Eavesdropping if you 
can handle the traffic!  These are the hard ones (IMHO) if you don't 
handle the APRS-IS stream realtime...  Accurately acking only those 
messages actually received and displayed is also a neat trick without 
the stream.

> d) Sending APRS messages
>   

Done.  With user-friend chat interface per QSO/conversation.

> e) Sending OBJECTS (based on current position)
>   

Done.  Including Items, intervals, timestamps, and even custom 
per-object RF paths.  And in the latest version, Weather objects if you 
have a WxNow.txt-compatible station.

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

Done, done (if they're transmitting it), done, done, done, and done.  
And something that's not very easy to do with a web interface on a Smart 
Phone?  Dead Reckoning stations with a 1 second refresh rate.

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

No one with a Smart Phone is going to be happy with a non-graphical 
application.  You might not need a map, but at least a graphical 
depiction of range and bearing to the stations can be done without a lot 
of work.

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

Well, maybe a full-time week, but how many of us have that kind of time 
to dedicate to a program that will only get nit-picked and 
feature-demanded more than could possibly be coded in a week?  I'd also 
encourage anyone willing to take on this task to read G4ILO's very 
accurate Advice to Amateur Programmers at http://tinyurl.com/G4ILO-Advice

> Good luck!
>   

You'll need it!

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

> Bob, Wb4APR
>