[aprssig] APRS rates (and decay)
Robert Bruninga bruninga at usna.eduMon Jan 14 22:13:32 UTC 2008
- Previous message: [aprssig] info for TM-D710E in car
- Next message: [aprssig] Com port sharing utility
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> > There are two specified beacon rates for APRS, > > 10 minutes at events or DIRECT or ONE-HOP local > > use, and 30 minutes for 2 hops or more wider > > area use. So a parked car, if not turned off > > altogether, should decay to 30 minutes. These > > standard final rates are there so that APRS has a > > consistent expectation of latency for operating stations. > Are you saying that stations should ONLY transmit > every 10 minutes (direct - no path) or every 30 > minutes (2 hop path) and nothing other than > that? No, not at all. You have to remember that the original APRS applied the decay rate to everything. Positions, messages, status, everything. If it was new, it was refresehed starting at a high 8 second rate but then always decaying down until it reached the bottom-line final rates of 10 or 30. And these also were NOT user settable! If the user was using a path of DIRECT or 1 hop, then he decayed to a 10 min rate. If he was uwing 2 hops or more, then he decayed to 30 minutes. That was the fundamental principle of APRS sharing a channel. The number one advantage of this original APRS design, was that there were no user settable rates to screw up! It was all transparent to the user. Any new bit of information that he entered into APRS was refresehd at an initial rate of 8 seconds, and then on down. The 10 and 30 minute FIXED rates are the END of that decay process if the data -has-not-changed. And again this was not a user setting. It depended on the length of his path. That alone could tell us if this was a local event (final 10m rate), or a regional event (final 30m rate). Now of course, for a mobile with GPS, then there was a user selectible rate since 8 seconds would be too high for that. That was then the only user settable rate. Say 1 minute for a special event, 2 minutes for routine. BUT it also got the same DECAY algorithm applied to it as well. As long as the GPS data was changing (beyond 100 feet), it stayed at that 1 minute rate. But if the vehicle stopped, and the position did not change, then it would automatically decay., but it would pick back up immediatelly if it changed again. Again, no user intervention required, and also randome GPS gitter was also ignored. > I stand by my statement that I think Kenwood > would have included it if you would have asked > them to. I have asked them to. >> Proportional pathing makes sure that locally, >> a vehicle is reported more often than at distance. >> Hence it reduces channel QRM by an order of magnitude. > However, it still sounds lie the D710's going out > with a 2 hop path every 4 minutes. However, is > that "no matter what" or does it reduce then to > every 30 minutes if it's stationary? Yes and no. Both Proportional Pathing and Decay are independent options that can be enabled or disabled. They both apply. If you have them both on, and pull into work but leave your system running, then it will slowly decay to a lower rate AND will also not use the longer path except for every 4th packet, etc.. If after an hour, the rate has decayed to 30 minutes, then you will hear the car every 30m locally, once an hour via the local digi, and once every 2 hours throughout the state (east coast state). > If I look around me, most stations are not moving. > Home stations, weather stations, digipeaters etc... In the original APRS, WX station data is treated like all other data, if it is changing, then it is transmitted at the initial rate. If it is not changing then it is decayed. If there is a change, then the decay is canceled and it is transmitted at the high rate again. The idea always is that NEW informaiton in APRS is desired FAST and old data is desired slow, and we should not depend on the user or the operator to be constantly changing. It was supposed to be fully automatic and transparent to the user. > The operator at the home station can set > responsible paths and set it at a low beacon rate. No, such simplistic reasoning and dependency on correct settings by users for each situation completely undermines the design of APRS. APRS was not supposed to have to have trained operators always having to manipulate every path, every timing, every rate depending on what he was doing! It is this simplistic approach taken in most follow-on clones that is ruining the concept and making APRS less useful as the real-time situational awareness and communication system. > To be useful, the weather stations should probably > beacon more often... every 5 or 10 minutes. Yes, but if they were done like the original APRS, then they would be proportional to what was happening, and no one would have to change them. As soon as we have operators having to change to high rate for some situatinos and low rate to minimize QRM, we are setting ourselves up for all the exact problems we have today. Forgotten parameters beaconing too often, too far, or not enough when needed. > The digipeaters we have sorted out with most > of their own beacons going out direct with > no path, but with a one hop path once an hour > and a two hop path once an hour. Yes, that is proportional pathing... > The DR-135T has a NICE setting where it > will skip the next X beacons if it hears > itself having been digipeated, the idea > being that it can beacon at a faster > rate in areas with poor coverage, but hold > off on the next several beacons if > it hears itself coming back. I sure hope there is more to it. Because that also is a good definition of a nuclear melt down. The term "in areas with poor coverage" is completely indistinguishible from an "area with total overload" if all you are using to measure it is -own-packet-heard. Neither one of them are hearing their packets. In the one case transmitting again makes sense. In the other, it is the worst thing to do. The ONLY WAY, I can agree to such a potnential melt-down algorithm is if it has an external squelch connection or runs OPEN squelch and it can also detect channel BUSY (not just packets detected. There is a catastrophic difference).. There really was a lot of effort put into this that was ignored when APRS became to be viewed as only a vehicle tracking system (with simplistic fixed rates)... Bob, WB4APR
- Previous message: [aprssig] info for TM-D710E in car
- Next message: [aprssig] Com port sharing utility
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the aprssig mailing list
