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

Tue Sep 30 08:12:11 EDT 2008

Have you tried the Emergency service approach with Apple? Perhaps if they
knew that the IPHONE can be used as another tool in the HAMS toolbox for
helping to provide emergency services, and it your app was free, they might
listen.

Do you have a contact you are dealing with at APPLE? Maybe we could all
write them.  I love my IPHONE and anything that can use the GPS for position
reporting especially in an emergency would be usefull.

Fran, W1FJM

-----Original Message-----
From: aprssig-bounces at lists.tapr.org [mailto:aprssig-bounces at lists.tapr.org]
On Behalf Of Steve Dimse
Sent: Monday, September 29, 2008 8:16 PM
To: TAPR APRS Mailing List
Subject: Re: [aprssig] OpenAPRS Direct Client Connection Interface
(gogogadget smart phones)

findU uses http, once you have an account you can enter your position  
by just sending a URL like

http://www.findu.com/cgi-bin/inputpos.cgi?call=k4hg-8&passwd=xxx&lat=24.7727
6&lon=-80.94058

I wrote a client for the iPhone that reads the GPS and sends it to  
findU, unfortunately Apple does not feel that it has a wide enough  
audience to justify making it available through the App store. Unless  
tApple lowers the bar it will never see the light of day. Keep that in  
mind if someone chooses to do a client for your API. You need to lie  
to Apple about the audience, mention ham radio and the answer is no.

Steve K4HG

On Sep 29, 2008, at 7:23 PM, Gregory A. Carter wrote:

> 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
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig

_______________________________________________
aprssig mailing list
aprssig at lists.tapr.org
https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig