Loading ...
Sorry, an error occurred while loading the content.
 

Re: [tracker2] OT2m temperature report way off...

Expand Messages
  • Dan
    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
    Message 1 of 24 , Oct 3, 2007
      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 N7NMD


      On 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.

      - Mark
      N4CMB-11

      -----Original Message-----
      From: tracker2@yahoogroups.com [mailto: tracker2@yahoogroups.com] On
      Behalf Of James Ewen
      Sent: Wednesday, October 03, 2007 11:24 AM
      To: tracker2@yahoogroups.com
      Subject: Re: [tracker2] OT2m temperature report way off...

      On 10/3/07, mark.rice@... < mark.rice@...> wrote:

      > 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
      stationary.

      Hope that helps, and makes sense to you.

      James
      VE6SRV

      Yahoo! Groups Links


    • Keith VE7GDH
      James VE6SRV wrote... ... You must be mistaken there - hi! He just said over on the APRS SIG... ... Of course, we all know that SmartBeaconing does a lot more
      Message 2 of 24 , Oct 4, 2007
        James VE6SRV wrote...

        > Bob Bruninga is dead set against SmartBeaconing because he feels that
        > SmartBeacon enabled trackers cause extra QRM.

        You must be mistaken there - hi! He just said over on the APRS SIG...

        > I have no problem with smart beaconing if somehow it can be set
        > to AVERAGE no more than about one packet per minute or less like
        > everyone else...

        Of course, we all know that SmartBeaconing does a lot more than allow you to
        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...
        www.tapr.org/pipermail/aprssig/2006-November/016924.html
        and a reply from Bob WB4APR...
        www.tapr.org/pipermail/aprssig/2006-November/016925.html
        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!"
      • James Ewen
        ... That just goes to show that he still hasn t even looked at the concept of SmartBeaconing. If he did, he would know that it can easily do just that. I can
        Message 3 of 24 , Oct 4, 2007
          On 10/4/07, Keith VE7GDH <ve7gdh@...> wrote:

          > > I have no problem with smart beaconing if somehow it can be set
          > > to AVERAGE no more than about one packet per minute or less like
          > > everyone else...

          That just goes to show that he still hasn't even looked at the concept
          of SmartBeaconing. If he did, he would know that it can easily do just
          that.

          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
          interval.

          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 to
          > have it beacon every minute. It is precisely to prevent something like that
          > happening that SmartBeaconing exists.

          We do indeed, and I sure am glad that developers like Scott take the
          time to understand a concept to the point where they add it to their
          own hardware.

          > 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.

          I'm working on that... the bug is in Kenwood's ear if I can believe
          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
          routine around.

          James
          VE6SRV
        Your message has been successfully submitted and would be delivered to recipients shortly.