Re: [tracker2] OT2m temperature report way off...
- I went through a similar thought process.
In my case, I am trying to prototype how we would track several red cross feeding vehicles in a county the size of several small states.
I came up with the idea that I'm not really trying to figure out their route, I'm more concerned about where they are within a few miles. That meant that packets can be sent less often, and only when the position has changed more than a few miles (which works out to about 20 minutes or so.)
In any case, I can poll the tracker to find out where it is at any one time now :)
-Dan N7NMDOn 10/3/07, mark.rice@... <mark.rice@...> wrote:
Thanks James. I'd like to implement some of your comments.
Our town of 25,000 people has very little aprs activity, but Dallas
isn't far away (45 miles) so I need to be careful with the settings as
it can impact metro rf (which is why I don't use Wide3 out here).
The slow speed I can change to 5 or even 10mph. If I'm at 10 or below,
I'm either coming to a traffic stop or in a parking lot. If it's the
latter, I don't leave my aprs on. If it's the former, my speed will
resume in less than 2 minutes. The speed of 40mph was selected because
of the mostly small-town driving that I do, but I might increase that.
Regarding the time setting, I will bump that up a bit as well. It can't
hurt and it very like will help with rf sharing.
Thanks again, James. I'm grateful for your assistance.
From: email@example.com [mailto: firstname.lastname@example.org] On
Behalf Of James Ewen
Sent: Wednesday, October 03, 2007 11:24 AM
Subject: Re: [tracker2] OT2m temperature report way off...
On 10/3/07, mark.rice@... < mark.rice@...> wrote:Yahoo! Groups Links
> At speeds between 0 and 40 MPH
> Use transmit rate from 300 to 120 Sec
> Transmit when turning more than 24 degrees But not more than once
> every 3 seconds
Okay, let's look at this to see what's happening.
First the speed section. Generally you will want to have your low speed
threshold set up a little above zero. Before SA was turned off, it was
necessary. We usually have the low end set around 5 mph.
Really, when you are moving that slow, you will be kicking out packets
due to turns more than distance.
Your high end speed is lower than usual, but it is valid. Normally this
is set at top highway speed, but there's no hard fast rule on that. Any
time you are traveling at or above the high speed setting, you will be
beaconing at the high speed rate.
Now, the rate settings... You are asking the unit to beacon every 5
minutes when it is sitting still. Do you need to tell everyone that your
vehicle is parked and doing nothing every 5 minutes? The general
recommendation is to set your low speed rate to 30 minutes. That's 1800
seconds. This keeps your position updated on most screens, without
causing excessive QRM on the channel. Your fast rate has you reporting
every 2 minutes when you are travelling 40 MPH or better.
This is a reasonable rate. The general baseline is 3 minutes, but 2 is
okay. It depends on the network load in your area. If there are a lot of
stations vying for airtime, you might want to slow the rate down to make
room for everyone. That's also why you would want to have a slow rate
when stopped, as it allows those who are actually doing something active
more room to play.
Your minimum turn angle is good. This value is the base for the
CornerPegging routine, when you are traveling slow, the turn angle
required to force a beacon is much larger, based on speed/slope (a value
Scott has hard coded in the OT line). This is designed so that you don't
beacon for minor course deviations at slow speeds (lane
changes) but will catch significant corners on the highway.
The real source of those rapid beacons is the very small minimum turn
time you have set. If you are travelling at 5 mph for example, and turn
a 90 degree corner, you will probably beacon 2 times. This is because at
that speed, you probably need something like 40 degrees to make
CornerPegging want to report your course change. In a 90 degree corner,
you'll find CornerPegging firing off two beacons. The minimum turn time
is designed to keep that from happening. If you set the minimum turn
time to 30 seconds, you will definitely be around that corner (unless
traffic is really bad). This also makes sure you don't send a flurry of
beacons when winding your way through a parking lot, or getting dizzy in
a traffic circle.
So, in summary, I would suggest setting your minimum speed a little
higher, your slow rate longer, and your minimum turn time longer.
You need to strike a compromise between reporting rates and sharing the
channel with others. SmartBeaconing was designed to do just that, but
you can also set it up to be a network hog. Setting a static beacon rate
in your D700 of 1 minute and leaving it on all day does the same, but
Bob doesn't see it that way. At least the D710 drops from it's 1 minute
rate using a decay algorithm now, back down to 32 minutes when
Hope that helps, and makes sense to you.
- James VE6SRV wrote...
> Bob Bruninga is dead set against SmartBeaconing because he feels thatYou must be mistaken there - hi! He just said over on the APRS SIG...
> SmartBeacon enabled trackers cause extra QRM.
> I have no problem with smart beaconing if somehow it can be setOf course, we all know that SmartBeaconing does a lot more than allow you to
> to AVERAGE no more than about one packet per minute or less like
> everyone else...
have it beacon every minute. It is precisely to prevent something like that
happening that SmartBeaconing exists.
Also, see a message from Steve KA9MVA from nearly a year ago...
and a reply from Bob WB4APR...
where he said "I agree completely with all you said."
I also suggested that if Kenwood has designed the D710 to allow updates
(they released a couple of minor updates the other day) then they could also
do an update to add SmartBeaconing. I could have missed it, but I don't
think I have seen a reply on that yet.
73 es cul - Keith VE7GDH
"I may be lost, but I know exactly where I am!"
- On 10/4/07, Keith VE7GDH <ve7gdh@...> wrote:
> > I have no problem with smart beaconing if somehow it can be setThat just goes to show that he still hasn't even looked at the concept
> > to AVERAGE no more than about one packet per minute or less like
> > everyone else...
of SmartBeaconing. If he did, he would know that it can easily do just
I can make the same uninformed statement about every other APRS
application out there. The Kenwood units have the capability to set
them up to beacon every 12 seconds. I don't know of any lower limits
in any software APRS program. I can set UI-View up to beacon every
second. I bet I can set APRSdos to beacon at less than a 1 minute
Because an implementation can be configured at a rate of less than one
packet per minute does not mean that it will AVERAGE more than that. I
can run SmartBeaconing configured to beacon once every 10 seconds,
drive for 1 hour, and then park for 6 hours beaconing once per hour.
Does this fulfill Bob's 1 minute average criteria?
> Of course, we all know that SmartBeaconing does a lot more than allow you toWe do indeed, and I sure am glad that developers like Scott take the
> have it beacon every minute. It is precisely to prevent something like that
> happening that SmartBeaconing exists.
time to understand a concept to the point where they add it to their
> I also suggested that if Kenwood has designed the D710 to allow updatesI'm working on that... the bug is in Kenwood's ear if I can believe
> (they released a couple of minor updates the other day) then they could also
> do an update to add SmartBeaconing. I could have missed it, but I don't
> think I have seen a reply on that yet.
the reports from DCC. If Bob is as happy with SmartBeaconing as he
suggests in the messages you point out, then there should be little
reason for not implementing the best network airtime conservation