[htaprs] VC-H1 APRN network

[Robert Bruninga]

> Then why use APRS-IS at all?  Why not send this, 
> as Scott recommended, directly to the APRN server(s). 

With this recent idea, I do not envision the need for an "APRN
Server", but rather simple local "APRN Nodes".  These nodes
monitor the local SSTV uplink channels and collect images and
save them for recall.  The images may eitehr be recalled over
the air on the same RF network, or, since they are stored and
are connected to the internet, then each local image has a local
URL.

The identification of the picture and the URL to point to it,
then, are the only things injected into the APRS-IS.

> The information does no good on APRS and would 
> require a more complex "IGate" configuration 
> requiring the APRN IGate to connect to both 
> APRS-IS and to the APRN servers.  Keep it
> simple.

Yes, that is why the idea has evolved this way.  That is, do not
re-invent a new server system.  Just use the APRS-IS as the
distribution system for the information (a single packet).  This
lets the APRN "node" be autonomous and hold its own images for
access over the web by anyone with a browser and the URL to the
image held on that machine.

I guess you would call that a "server", since it is serving up
web pages of images, but I am calling it a "node" to distinguish
it from an "APRS server" which is serving real-time packets.  So
in this case, then the APRN node just launches an APRS packet
into the APRS-IS just like anyother user data source.

This keeps it simple by not inventing anything new.  And since
John KB2SCS has already written the APRN node software, it seems
like this approach would be viable.

The APRS-IS does not do anything unusual with these APRN
packets.  But applications, such as FINDU, can then collect the
APRN packets and have pointers to the images on demand.

Something like that....  Oh, and I am abandoning the idea of
having the APRN node append info onto the originators Mic-E
packet.  Lets keep the image uplink identifier packet (usually
Mic-E) separate from the APRN node's packet that it injects into
the APRS-IS.  This avoids any appearance of the APRN-node acting
as an Igate.  It is  not.  It receives an image identification
packet, parses it, stores it, does whatever it needs to do with
it, but then it generates a single packet in an exact format
that it then originated into the APRS-IS.  I have a suggested
format on my web page:

http://web.usna.navy.mil/~bruninga/aprntxt.html

Bob, WB4APR
> 73,
> 
> Pete Loveall AE5PL
> pete at ae5pl dot net
> 
> > -----Original Message-----
> > From: Robert Bruninga
> > Posted At: Wednesday, February 27, 2008 2:57 PM
> > Subject: RE: [htaprs] VC-H1 APRN network
> > 
> > We are not sending an "image packet".  What we would be
sending
> > on the APRS-IS network is a single Mic-E position packet
> > whenever a new image is uploaded to an APRN node.  That
packet
> > is a standard Mic-E packet generated by the handheld D7 HT
with
> > these existing standard fields:
> > 
> > CALL, LAT/LONG/CSE/SPD and STATUS TEXT.  The only thing
unique
> > to this application is that the "status text" contains a URL
> > that points to where the image can be viewed.
> > 
> > It is no different from any other position packet from any
other
> > D7, except for the length of the URL on the end.
> 
> _______________________________________________
> htaprs mailing list
> htaprs at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/htaprs
>