[aprssig] APRS Message Idea

[Robert Bruninga]

>>> vk4tec at tech-software.net 3/3/05 2:05:12 PM >>>
>What has happened to you guys are you too scared 
>to try anything new

Not really.  But in a forum for the technical exchange of
ideas, any down-sides to an idea should be as welcome
as the upside...  Bob

On Thu, 2005-03-03 at 10:19 -0500, A.J. Farmer (AJ3U) wrote:
> >From: Robert Bruninga
> >No that is only the simplistic way some new "aprs" software
> >works.  The original design tries on a decaying algoirthm
> >for rapid initial delivery, but less network load after a few
> >minutes.  But then it decays down to one retry every 30
> >minutes until the station eventually comes on the air.
> 
> The Kenwood radios do not work this way.  They have actually been the
source
> of my frustration with sending APRS messages.  They do not decay and
they
> completely give up after 5 tries.
> 
> >It works for rapid 
> >10 second message turnaround over good channels, and 
> >multiple retries over bad ones, and eventual delivery over long
> >periods of time.  ANd users cannot screw it up, or overload
> >the netowrk by chaning any settings.  Its automatic, its
> >fundamental and it is what APRS was designed to do.
> 
> >Its just that too many other programs just took the simplistic
> >and very channel innefficient apprach of retry N times and
> >stop.
> 
> Again, while mobile with my Kenwood, I want to send the message once
and
> forget it knowing it will keep trying until delivered or until I kill
it.
> Instead, I have to re-send the message over and over until my other
mobile
> buddy gets back in range of me or a digi.  I wish Kenwood had
implemented
> this part of the APRS spec correctly...
> 
> Thanks for the input.
> 
> A.J.
> 
> -----Original Message-----
> From: Robert Bruninga [mailto:bruninga at usna.edu] 
> Sent: Thursday, March 03, 2005 9:22 AM
> To: aprssig at lists.tapr.org; ajfarmer at spenet.com 
> Subject: Re: [aprssig] APRS Message Idea
> 
> >>> ajfarmer at spenet.com 3/2/05 11:43:36 PM >>>
> >With APRS, when you send a message ... the software ...
> >tries a number of times..., then gives up if the receiving 
> >station does not ACK...
> 
> No that is only the simplistic way some new "aprs" software
> works.  The original design tries on a decaying algoirthm
> for rapid initial delivery, but less network load after a few
> minutes.  But then it decays down to one retry every 30
> minutes until the station eventually comes on the air.
> 
> >The problem is, if you are messaging a far away station, 
> >you don't know if they are actually active on APRS [at] 
> >the particular moment that you send the message.
> 
> With APRSdos the message will always eventually get
> delivered.  Also some programs (WinAPRS etc) added
> "retry-on-heard" so that the message will still be there 
> until the station eventually comes on the air, and then
> retries will continue...
> 
> > With cellular, the message gets delivered as soon as the 
> >person gets back in range, with APRS, sorry, you missed 
> >the guy by a few minutes...
> 
> No, just with simplistic "aprs" clones that never properly
> implemented the full APRS decaying algorithm packet 
> delivery system.  Original APRS software's work fine.
> 
> >I know this was not the original design or intent of APRS, 
> 
> Yes it was.  Justs some follow on softare clones took
> too many shortcuts in the protocol and overall functional
> features of APRS while being focused only on maps..
> 
> >but what do you all think of enabling this type of store 
> >and forward capability? 
> 
> It should have been in all code.  But everyone tires of me
> ranting  on these kinds of omissions in some present programs...
> 
> > This system could be separate from the standard "tactical" 
> >"type of messaging currently used. 
> 
> Not needed to be separate...  The Decay algoirhtm covers 
> ALL cases and requires NO user settings.  It works for rapid 
> 10 second message turnaround over good channels, and 
> multiple retries over bad ones, and eventual delivery over long
> periods of time.  ANd users cannot screw it up, or overload
> the netowrk by chaning any settings.  Its automatic, its
> fundamental and it is what APRS was designed to do.
> 
> Its just that too many other programs just took the simplistic
> and very channel innefficient apprach of retry N times and
> stop.
> 
> >What do you all think?   Already available somehow?
> 
> Yep, always been there, but only implemented in APRSdos,
> WinAPRS (retry on heard), APRS+SA, APRscs and
> maybe some I dont remember.
> 
> de Wb4APR, Bob
> 
> 
> 
> _______________________________________________
> 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