[Xastir] Position rate possibility....

[James Ewen]

> > 2) Moving mode. Me sees three possibilities here: A) fixed time
> > beaconing; B) Fixed distance beaconing; C) Speed based beaconing.  I
> > would prefer speed based beaconing. Instead of having threshold points,
> > I would make the time change linear. Have an X-Y formula: X being speed;
> > Y being distance. Both end points on both axes are settable. At slower
> > speeds, you usually are working city streets. This would require more
> > transmissions because of the Urban Canyon issue and there are more
> > opportunities to radically change course. This would avoid the big
> > position jump on a track where you look at a map and see someone halfway
> > across the county changing directions.


Beaconing faster at slower speeds is diametrically opposite to the
SmartBeaconing concept, as well as your fixed distance concept.

With a fixed distance concept, you beacon slower at slow speeds due to
the time required to cover the set distance. At slow speeds you beacon
at a slower rate because the amount of error in your distance
accumulates at a slower rate. The idea is to be able to have a circle
of ambiguity that you will find the station within. The faster the
station is travelling the faster you have to beacon to be able to keep
the circle of ambiguity the same size.

Because we send speed and course information with our packets, we can
reduce that circle of ambiguity down to an arc. We can dead reckon a
station's position until the next beacon is heard. This works great
unless the station makes course changes before the next beacon is
scheduled. The sooner the station makes that course change after a
beacon, the more ambiguity there can be.

CornerPegging is what make sure that we are informed of any course
changes that happen between the time/distance based beacons. We set a
minimum course deviation that we want to report called minimum turn
angle. If we choose to only report course deviations of 45 degrees or
more, so that we don't beacon a whole lot in town when making lane
changes and such, then we can still get well out of that ambiguity arc
when cruising down the highway, and make a moderate bend in the road.
Using turn slope divided by the speed allows us to set a minimum turn
angle for the highway speed, yet still requires a much larger course
deviation at slow speeds so we don't go crazy in town.


>        The HamHUD used to send extra beacons in the event it didn't receive a
> digi repeating it's own signal.  It was taken out, I think because of
> other people complaining about channel congestion, but I'm not 100% sure
> of that -- it's been several years.


The HamHUD used to listen for a digipeat to come back, and if it
didn't hear that, it would beacon again. We got flack about that.
Because of the nature of mobile packet radio propagation, and the need
for packets to be copied 100%, it is possible for the packet sent to
be copied properly at the digipeater, digipeated, and then not heard
at the mobile that originated the packet.

APRS is a send and forget protocol... You can not be guaranteed that
others hear your packet. You can not be guaranteed that you will hear
every packet. You need to send your packets when you should, and
continue along your way.


> > 3) Dealing with turns. This seems to be a sore spot - corner pegging. We
> > only have a max data rate of 1 secoud out of most GPS units. So what I
> > would do is modify the sending rate based on the degrees turned and
> > instead of using a lookup table, I would use maybe cos^2 or cos^3 of the
> > angle change as the modfier. Modify from the current beaconing rate down
> > to 1 sec beaconing at >= 90 degrees. Here in Wisconsin, U-turns are
> > legal so those would have to be covered.


No sore spot with CornerPegging... It works great. It's interesting
now that you want GPS updates faster than every second. It used to
confound the problem... There is no lookup table for CornerPegging. It
is simple math. We compare the heading change since beacon to the turn
threshold. If it is greater, and it has been longer than the minimum
turn time, we send another beacon. In the math limited
microprocessors, it is difficult to do squares and cubes of a cosine
of an angle if not impossible. Why you would want to increase
beaconing to every second while turning is a little confusing. The
"problem" that you are trying to solve is excessive beaconing, and
your solution increases the beacon rate.


> > Now if I have covered old ground, forgive me. These are just thoughts.


Look at the descriptions of SmartBeaconing and CornerPegging on the Wiki.
http://info.aprs.net/wikka.php?wakka=SmartBeaconing
http://info.aprs.net/wikka.php?wakka=CornerPegging

Look at the description of the SmartBeaconing and CornerPegging
concepts and implementation on the HamHUD site.
http://www.hamhud.net/hh2/smartbeacon.html

It is always better to try modifying or reinventing something by first
understanding how it works.


James
VE6SRV