Re: [Xastir] Position rate possibility....
> 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 ___ Xastir mailing list Xas
Re: [Xastir] Position rate possibility....
Richard Polivka, N6NKO wrote: 1) Fixed position. If the vehicle drops below a certain threshold speed, call it STOP SPEED, we send out a quick burst of packets, say three to five , to show the speed coming to zero for at least two packets. I'm not sure we would want to do this, because every time you come to a red light, you'd be going through this procedure. Some parts of the country can't take that. Maybe ONE packet would be OK. 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. 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. 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. Now if I have covered old ground, forgive me. These are just thoughts. When I first got started with the HamHUD, I tried and tried to do perfect corner pegging, but I was never succesful. The problem being that, in a 90-degree turn at an intersection, you need one set of parameters, but in a 90-degree sweeper at 70 MPH, you need an entirely different set of parameters. I don't think slope is enough to get it right. I used to get 2 or 3 position packets sent out in the sweepers, and while I could make adjustments to reduce that, it generally messed up the intersections. The other problem that I though I was seeing, but no one else agreed, was if I came to, say, a 20-degree bend in the road and I was travelling 65 MPH, I did NOT get a position packet sent out. I think I was told that, at those speeds, almost all the beacons are done by timing and not by turning. In the end, I just set everything to the default values and forgot about it. 7 3 Earl -- Earl Needham KD5XB Clovis, New Mexico DM84jk ZUT ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
[Xastir] Position rate possibility....
Alright, now I have a bug on the brain. That is good. Keeps me from thinking about spending money. Plus, XM Classics is on - no wine yet - way too early. But I am wired to the neck in caffeine and the pot is empty. Let me make a proposal. Now I will run it up the flagpole so make sure your sights are lined up to shoot at it... 1) Fixed position. If the vehicle drops below a certain threshold speed, call it STOP SPEED, we send out a quick burst of packets, say three to five , to show the speed coming to zero for at least two packets. In STOP MODE, we send out packets at some set rate. We do not leave this mode until we have a net positive speed above START SPEED and a change in position defined by START POSITION CHANGE. This should allow for compensating for "wild positions" and not allowing them to cause the unit to do massive transmissions. 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. 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. Now if I have covered old ground, forgive me. These are just thoughts. 73 from 807, Richard, N6NKO ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
