[aprssig] APRS Speed Spec? (plan B)

Heikki Hannikainen hessu at hes.iki.fi
Thu Oct 12 16:39:03 CDT 2017


Hi,

I agree with Jason and Kenneth. This is not really needed, and it's yet 
another special case kludge which doesn't work too well.

The velocity of an orbital object is not of much importance to anyone. 
It's not even going to change much for the same satellite over time. You 
just want to know what is the footprint the satellite sees, and when 
you're going to be in range, and maybe, if you want to calculate the 
doppler, the speed it's approaching yourself. And to get those you'll need 
to have the keps and do the math locally.

For jets flying fast, just calculate the speed it took to go from 
position A to position B - they also don't change speed very fast.


On Wed, 11 Oct 2017, Kenneth Finnegan wrote:

> On Wed, Oct 11, 2017 at 1:20 PM, Jason KG4WSV <kg4wsv at gmail.com> wrote:
>       999 - speed is 999 or greater.
>
>       done.
> 
> 
> I'm going to agree with Jason on this one. 
> 
> What is the purpose of encoding very coarse higher velocities? If something has a satellite or jet symbol and
> an altitude of "really high" I don't think we need to have the ability to encode exactly how bloody fast it's
> going. It's going to be over the horizon before you finish looking up what range of speeds 997 is anyways.
> 
> If anyone really cares more than "greater than 999" they probably care more than "1,600-15,000 knots" and will
> want to add "/VEL=XXXXXknots" in their status text.
> 
> There's also all the speed differences between LEO, space station, GPS, GEO orbits for various orbit configs,
> but it's not like I think we should try and support all of those anyways. At some point encoding the keps makes
> more sense than heading and velocity...
> 
> --
> Kenneth Finnegan
> http://blog.thelifeofkenneth.com/
> 
> On Wed, Oct 11, 2017 at 1:20 PM, Jason KG4WSV <kg4wsv at gmail.com> wrote:
>       how about:
>
>       999 - speed is 999 or greater.
>
>       done.
>
>       if you need better resolution, switch to hex (max 4095 in decimal) or
>       base92 (~779000), which is no more nuts than what you propose. Since
>       you're forcing the app developers to code, maximize the usefulness of
>       the kludge.
>
>       or add a /S=N extension, where N is one or more digits representing
>       speed followed by whitespace or end of packet.  That way your max
>       speed is bounded by the length of the packet.  or c.
>
>       -Jason
>       kg4wsv
>       _______________________________________________
>       aprssig mailing list
>       aprssig at tapr.org
>       http://www.tapr.org/mailman/listinfo/aprssig
> 
> 
> 
>

   - Hessu


More information about the aprssig mailing list