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

Re: [tracker2] DAO digits?

Expand Messages
  • Scott Miller
    ... Ah... the problem is that in Garmin mode it s not extracting the extra decimal places. It s converting from radians (IEEE double-precision floating point)
    Message 1 of 4 , Mar 12, 2010
    • 0 Attachment
      > That !W! is supposed to have 2 more characters in there that are either
      > the raw additional digits (as implied by the T2-135 manual, "an extra
      > digit of precision") or a base-91-encoded pair of digits for each of the
      > lat and lon (per http://www.aprs.org/aprs12/datum.txt
      > <http://www.aprs.org/aprs12/datum.txt>).

      Ah... the problem is that in Garmin mode it's not extracting the extra
      decimal places. It's converting from radians (IEEE double-precision
      floating point) to semicircles (32-bit integer) and decoding that to
      decimal minutes. The same function is used to handle received Base91
      compressed positions, so it's not going to be a quick fix.

      Scott
    • Lynn W. Deffenbaugh (Mr)
      ... Oh well, at least it s been identified and I m not losing my mind! I ll watch for some future firmware revision to mention it and that will FINALLY be the
      Message 2 of 4 , Mar 12, 2010
      • 0 Attachment
        Scott Miller wrote:
        >> That !W! is supposed to have 2 more characters in there that are either
        >> the raw additional digits (as implied by the T2-135 manual, "an extra
        >> digit of precision") or a base-91-encoded pair of digits for each of the
        >> lat and lon (per http://www.aprs.org/aprs12/datum.txt
        >> <http://www.aprs.org/aprs12/datum.txt>).
        >>
        >
        > Ah... the problem is that in Garmin mode it's not extracting the extra
        > decimal places. It's converting from radians (IEEE double-precision
        > floating point) to semicircles (32-bit integer) and decoding that to
        > decimal minutes. The same function is used to handle received Base91
        > compressed positions, so it's not going to be a quick fix.
        >

        Oh well, at least it's been identified and I'm not losing my mind! I'll
        watch for some future firmware revision to mention it and that will
        FINALLY be the fix to get me to pull my mobiles and get the T2s
        upgraded! While you're at it and assuming there's code space, how about
        2 digits as well as the 1 that the documentation currently implies is
        supported?

        Any chance it might be done before mid-June? I'm hoping/planning to
        take a T2/Alinco/Nuvi setup to Spain for a vacation then. Not that an
        additional digit of accuracy will help anything, it'd just be nice to be
        running the latest for the trip!

        Lynn (D) - KJ4ERJ


        > Scott
        >
        >
      • Scott Miller
        I d suggest using compressed mode if you need the precision - it should get full precision in Garmin mode. Scott
        Message 3 of 4 , Mar 13, 2010
        • 0 Attachment
          I'd suggest using compressed mode if you need the precision - it should
          get full precision in Garmin mode.

          Scott

          Lynn W. Deffenbaugh (Mr) wrote:
          >
          >
          > Scott Miller wrote:
          > >> That !W! is supposed to have 2 more characters in there that are either
          > >> the raw additional digits (as implied by the T2-135 manual, "an extra
          > >> digit of precision") or a base-91-encoded pair of digits for each of the
          > >> lat and lon (per http://www.aprs.org/aprs12/datum.txt
          > <http://www.aprs.org/aprs12/datum.txt>
          > >> <http://www.aprs.org/aprs12/datum.txt
          > <http://www.aprs.org/aprs12/datum.txt>>).
          > >>
          > >
          > > Ah... the problem is that in Garmin mode it's not extracting the extra
          > > decimal places. It's converting from radians (IEEE double-precision
          > > floating point) to semicircles (32-bit integer) and decoding that to
          > > decimal minutes. The same function is used to handle received Base91
          > > compressed positions, so it's not going to be a quick fix.
          > >
          >
          > Oh well, at least it's been identified and I'm not losing my mind! I'll
          > watch for some future firmware revision to mention it and that will
          > FINALLY be the fix to get me to pull my mobiles and get the T2s
          > upgraded! While you're at it and assuming there's code space, how about
          > 2 digits as well as the 1 that the documentation currently implies is
          > supported?
          >
          > Any chance it might be done before mid-June? I'm hoping/planning to
          > take a T2/Alinco/Nuvi setup to Spain for a vacation then. Not that an
          > additional digit of accuracy will help anything, it'd just be nice to be
          > running the latest for the trip!
          >
          > Lynn (D) - KJ4ERJ
          >
          > > Scott
          > >
          > >
          >
          >
        Your message has been successfully submitted and would be delivered to recipients shortly.