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

Re: T2-135 Message ACK

Expand Messages
  • ke7kus
    In addition, the issue of the APRS message ID automatically incrementing (evident in the case of an Outbox hangup ) needs to be corrected. I m having a hard
    Message 1 of 29 , Dec 27, 2008
    • 0 Attachment
      In addition, the issue of the APRS message ID automatically
      incrementing (evident in the case of an "Outbox hangup") needs to be
      corrected. I'm having a hard time figuring out any rhyme or reason to
      the incrementing message ID logic during a "hangup". Many digis and
      -IS backend daemons have good duplicate filtering methods; however,
      these are almost all based on message ID, and are thus trumped if the
      message ID increments, since the digi/daemon/etc. sees the message as
      a new message. This really gums things up--dupe messages getting
      routed, dupe responses getting returned...lots of bandwidth badness.

      At some point Scott's going to bump up against firmware sizes that
      will exceed chip capacity if we keep adding fixes to the current
      firmware. It might be time to consider forking the current firmware
      into a "dedicated digipeater" version, a "weather station" version, a
      "mobile version", etc. This would allow more dedicated capacity for a
      given application depending on the desired usage, and function could
      be changed out with a simple firmware swap.

      Also might be good to move these types of issues onto their own
      "Bugfix" and "Requested Features" threads here on the group. Might
      make it easier to compile inputs for future firmware upgrades.

      Kurt
      KE7KUS

      > > IMO, the OT2 should probably send a Garmin ACK to the NUVI in either
      > > one of the following cases:
      > >
      > > #1 if it gets an APRS MSG ACK (that works already, cool!!!)
      > > #2 after the RETRIES count reached its limit
      > > #3 right away if the Nuvi keeps sending the message to the OT2 at a
      > > faster pace than the OT2's RETRYTIME value.
      >
      > I also suggest:
      > #4 when the OT2 is powered on. That way you clear the outbox by
      performing
      > a power cycle on the OT2.
    • Scott Miller
      ... The problem there is that (aside from complicating maintenance) there s no way to satisfy everyone with a finite number of combinations of features -
      Message 2 of 29 , Dec 29, 2008
      • 0 Attachment
        > At some point Scott's going to bump up against firmware sizes that
        > will exceed chip capacity if we keep adding fixes to the current
        > firmware. It might be time to consider forking the current firmware
        > into a "dedicated digipeater" version, a "weather station" version, a
        > "mobile version", etc. This would allow more dedicated capacity for a
        > given application depending on the desired usage, and function could
        > be changed out with a simple firmware swap.

        The problem there is that (aside from complicating maintenance) there's
        no way to satisfy everyone with a finite number of combinations of
        features - they'll always want some combination that's not available.
        I'm trying to hold off on splitting the code as long as possible.

        Some of the rewrites I'm doing now *might* free up some space. Or make
        it worse, but at least make things easier to work with and add some new
        options. I went poking around and figured out that I can recompile the
        ANSI C libraries with some (poorly documented) options to help trim the
        size of the functions, at the expense of features and standards
        compliance. That might free up enough space to clean up some ugly kludges.

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