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

T2-135 Message ACK

Expand Messages
  • ke7kus
    Hello all, I m the proud new owner of a T2-135/Nuvi 350 and I must say the setup is absolutely fantastic. For the price, there s not a better way to get into
    Message 1 of 29 , Nov 6, 2008
    • 0 Attachment
      Hello all,

      I'm the proud new owner of a T2-135/Nuvi 350 and I must say the setup
      is absolutely fantastic. For the price, there's not a better way to
      get into APRS. Install and setup was relatively painless, and it took
      no time at all to get on the air.

      The only issue I've had is with messaging. It seems I have an issue
      with APRS messages getting ACK'ed when I send them from the T2. Below
      is an excerpt from findu.com:

      KE7KUS-1>APOT2A,HAYDEN,N7ZEV-3,WIDE2*,qAR,K7FED-10::KE7KUS :test mobile{ab
      KE7KUS-1>APOT2A,HAYDEN,N7ZEV-3,WIDE2*,qAR,K7FED-10::KE7KUS :test mobile{ac

      Rest of packets here:
      http://www.findu.com/cgi-bin/raw.cgi?call=KE7KUS-1

      Symptoms:

      1) Message (when sent via the Nuvi) goes into the Outbox, but the
      "sending..." mnemonic never goes away.
      2) The radio will continue to retransmit the message, well past the
      RETRIES parameter (3) I have set in the T2.
      3) I'm not super-sure, but in the above packets, {ab and {ac should
      be numbers for the ACK to return for the sent message. If I'm wrong
      on this, someone please set me straight...
      4) I've had about a 25% success rate in getting incoming messages via
      RF. Not sure if it's tied into the seemingly mindless outgoing
      transmission - maybe a local I-Gate function?

      Questions:

      1) Why would the T2 send the outgoing message more times than the
      RETRIES parameter?

      2) Why doesn't the message get ACK'ed?

      3) What causes the reduced success rate for received messages?

      Any help or suggestions would be greatly appreciated.

      Thanks,
      Kurt
    • ke7kus
      ... Follow-on troubleshooting: Seems I m having the similar issues as Bob, KA9FLX: http://groups.yahoo.com/group/tracker2/message/4932 Except I m using a Nuvi
      Message 2 of 29 , Nov 8, 2008
      • 0 Attachment
        > The only issue I've had is with messaging. It seems I have an issue
        > with APRS messages getting ACK'ed when I send them from the T2.

        Follow-on troubleshooting:

        Seems I'm having the similar issues as Bob, KA9FLX:
        http://groups.yahoo.com/group/tracker2/message/4932

        Except I'm using a Nuvi 350, not a 760.

        >
        > Symptoms:
        >
        > 1) Message (when sent via the Nuvi) goes into the Outbox, but the
        > "sending..." mnemonic never goes away.

        This is only true for messages sent to RF (i.e. messages starting with
        "-"). Config messages sent to the T2 from the Nuvi (i.e messages
        starting with "--") are processed correctly...no issues.

        > 2) The radio will continue to retransmit the message, well past the
        > RETRIES parameter

        It seems that the radio continues to retransmit the message because
        each time it transmits, it assigns a new message ID number to the
        message. Based on Scott's inputs here, the RETRIES parameter in the
        T2 config only applies to messages with the same ID number. Checking
        places like findu.com shows that I get an ack for each message sent
        out. But still doesn't explain why the message ID gets incremented
        with each transmission.

        > 3) I'm not super-sure, but in the above packets, {ab and {ac should
        > be numbers for the ACK to return for the sent message. If I'm wrong
        > on this, someone please set me straight...

        How about I set myself straight here. Chapter 14 of the APRS Protocol
        1.0.1 says:

        "A message may also have an optional message identifier, which is
        appendedto the message text. The message identifier consists of the
        character '{' followed by a message number (up to 5 alphanumeric
        characters, no spaces) to identify the message."

        As such, the "alpha" letters in my message ID's are completely
        acceptable.

        > 4) I've had about a 25% success rate in getting incoming messages
        >via RF. Not sure if it's tied into the seemingly mindless outgoing
        > transmission - maybe a local I-Gate function?

        This issue still exists. This makes me think there's a possibility it
        may be an RX gains issue. I've got the DR-135 set to "Narrow" FM,
        and when I listen to the TX audio on an HT, it sounds fine. Must work
        OK to, because sent packets make it into APRS-IS and are decoded OK.
        RX audio may be a culprit. Any suggestions on places to look for
        tweaks, or suggestions for better troubleshooting?

        Kurt
        KE7KUS
      • ke7kus
        ... After further troubleshooting, RX audio seems unlikely, since the T2 receives and decodes position packets from RF just fine. The Favorites menu fills
        Message 3 of 29 , Nov 8, 2008
        • 0 Attachment
          > > 4) I've had about a 25% success rate in getting incoming messages
          > >via RF. Not sure if it's tied into the seemingly mindless outgoing
          > > transmission - maybe a local I-Gate function?

          > RX audio may be a culprit.

          After further troubleshooting, RX audio seems unlikely, since the T2
          receives and decodes position packets from RF just fine. The
          "Favorites" menu fills up nicely with received stations. Seems to
          only be an issue, then, with RX of messaging via RF. Could be an
          IGate issue, however, the result is not consistent. When I send out a
          packet to WHO-IS, I get returns via RF. When I send a message from
          Xastir to station, I get no message into the Nuvi/T2. I'm not
          familiar enough with IGate from -IS to RF. Could that be causing the
          problem?

          Kurt
          KE7KUS
        • kb9lgs
          ... I am a bit new at this so may be full of it or completely off base. Reasonable comments to this effect gladly accepted as educational, but one of the
          Message 4 of 29 , Nov 9, 2008
          • 0 Attachment
            --- In tracker2@yahoogroups.com, "ke7kus" <ke7kus@...> wrote:
            >
            > > The only issue I've had is with messaging. It seems I have an issue
            > > with APRS messages getting ACK'ed when I send them from the T2.
            >
            > Follow-on troubleshooting:
            >
            > Seems I'm having the similar issues as Bob, KA9FLX:
            > http://groups.yahoo.com/group/tracker2/message/4932
            >
            > Except I'm using a Nuvi 350, not a 760.

            I am a bit new at this so may be "full of it" or completely off base.
            Reasonable comments to this effect gladly accepted as educational,
            but one of the issues I think may be an issue with the APRS protocol.

            I have had this issue, and many people I have sent messages to can
            attest to my system continually sending them messages. Obviously we
            need to deal with this retry thing, but actually being able to get the
            ACK is also important and seems to be my issue. I have done some
            limited tracking of the issue, and it seems from what I can tell if
            the ACK gets to my radio I am indeed fine. But that is the issue,
            getting it there.

            If I am where the packet is heard by the actual wide coverage (level
            2) digi when the other station receives the message, then everything
            is hunky doory. But if I have to go through a low profile digi
            (level 1) to get to the actual real wide area ones when the other
            station receives the message then there is a problem. When it comes
            down to it, it appears that our local digi managers are doing their
            job well and following the general principle that a repeater should be
            able to only hear what it can send to and only send to what it can
            hear. (No alligators.) So if I need to use a wide 1 to get to the
            wide 2 then that wide 2 would need the help of the wide 1 to get back
            to me. But the path seems to assume that the wide 2 is the end of
            the line. So the stations that can hear the wide 2 digi directly get
            the ACK, but since I can't directly receive it I am sunk.

            Are we going to need something like a path of wide1-1,wide2-1,wide1-1
            for message handling?
          • ke7kus
            ... Additional troubleshooting results: 1) Sporadic Rx of messages led me to believe that successful reception might be path dependent. Sure enough, after
            Message 5 of 29 , Nov 9, 2008
            • 0 Attachment
              > > > 4) I've had about a 25% success rate in getting incoming messages
              > > >via RF.
              >
              > > RX audio may be a culprit.
              >
              > After further troubleshooting, RX audio seems unlikely, since the T2
              > receives and decodes position packets from RF just fine. Could be an
              > IGate issue, however, the result is not consistent. When I send out a
              > packet to WHO-IS, I get returns via RF. When I send a message from
              > Xastir to station, I get no message into the Nuvi/T2.

              Additional troubleshooting results:

              1) Sporadic Rx of messages led me to believe that successful
              reception might be path dependent. Sure enough, after trying several
              IGates in the local area, I found one which would consistently pass
              messages through to the T2/Nuvi. As such, I'm ruling out Rx audio setup.

              2) I did note, however, that although the message gets through to the
              T2/Nuvi, the sent message never gets an ACK from the T2 and Xastir
              keeps attempting to resend the message until it times out. I only get
              one copy of the message in the Nuvi Inbox. The radio never attempts
              to transmit an ACK when a message is received.

              Based on all of this, the two issues I need to resolve are: A) why
              sending a message from the Nuvi is not working, and B) why no ACK is
              sent when a message is received.

              Plan tomorrow is to take the radio back out of the truck and hook it
              up to a terminal to take the Nuvi out of the loop. Hopefully that
              will help isolate whether the issue is in the Garmin FMI interface, or
              in the T2 side of the software. More to follow...

              Kurt
              KE7KUS
            • Cap
              ... ... 1 ... You have correctly analyzed the problem. FB. The solution is not simple _unless_ the low-powered mobile station _can_ directly _hear_
              Message 6 of 29 , Nov 10, 2008
              • 0 Attachment
                --- In tracker2@yahoogroups.com, "kb9lgs" <raytodd@...> wrote:
                <snip>
                > So the stations that can hear the wide 2 digi directly get
                > the ACK, but since I can't directly receive it I am sunk.
                >
                > Are we going to need something like a path of wide1-1,wide2-1,wide1-
                1
                > for message handling?
                >

                You have correctly analyzed the problem. FB. The solution is not
                simple _unless_ the low-powered mobile station _can_ directly _hear_
                the high-level ("WIDE2-N") digi that transmits the packet containing
                the message ACK.
                Still, WIDE1-1 should never be other than first in order (left-most)
                in any station's digipath setting.
                73, Cap KE6AFE
              • ke7kus
                ... Troubleshot tonight by removing the Nuvi and connecting the T2-135/DR-135 to my desktop via a serial cable (BTW, I m running firmware v.54680): 1) Sending
                Message 7 of 29 , Nov 10, 2008
                • 0 Attachment
                  > Plan tomorrow is to take the radio back out of the truck and hook it
                  > up to a terminal to take the Nuvi out of the loop. Hopefully that
                  > will help isolate whether the issue is in the Garmin FMI interface, or
                  > in the T2 side of the software. More to follow...

                  Troubleshot tonight by removing the Nuvi and connecting the
                  T2-135/DR-135 to my desktop via a serial cable (BTW, I'm running
                  firmware v.54680):

                  1) Sending messages via a terminal program (minicom) worked as it
                  should. The APRS message was sent in accordance with the RETRIES
                  parameter, and the message ID remained the same for each retry. When
                  the RETRIES limit was reached, the T2 stopped attempting to send the
                  message. Worked as advertised without the Nuvi in the loop.

                  This leads me to believe that the problem I'm having with sending the
                  message from the Nuvi and it getting stuck in the Outbox with an
                  auto-incrementing message ID for each send attempt is a function of
                  something in the software related to the Garmin FMI code. I've been
                  looking at the source code from the Argent website (specifically the
                  garmin.c file) to see if I can decipher the issue. Scott's
                  documentation in the code is commendable, however, reading C to me is
                  like reading Greek. Lines 506-544 deal with FMI and messaging and if
                  there were an issue, I suspect it would be in there somewhere, but I'm
                  not "C-familiar" enough to make good sense of it. If Scott, or anyone
                  else out there with some C programming knowledge could briefly walk
                  through it, check it, and explain it to me, I'd be very grateful.

                  2) Rx of messages without the Nuvi was about the same as with the
                  Nuvi, but the more I experiment with it, I'm convinced that it's more
                  a routing function gating from IS back to RF, rather than a function
                  of the Nuvi/T2 itself. I'll do some more experimenting with the local
                  digis here and see if I can't make some more sense of it, but the
                  results aren't consistent enough, or I haven't isolated the fail point
                  well enough to comment further.

                  The one thing I haven't tried is sending a message from the Nuvi using
                  the "--SEND <CALLSIGN> <TEXT>" format for sending. Might be
                  worthwhile, since I get proper functionality out of the "--" set of
                  commands.

                  Kurt
                  KE7KUS
                • ke7kus
                  ... Using the above format for sending a message via the Nuvi, the message goes into the Outbox, and does NOT have the sending... mnemonic beside it (i.e. it
                  Message 8 of 29 , Nov 11, 2008
                  • 0 Attachment
                    > The one thing I haven't tried is sending a message from the Nuvi using
                    > the "--SEND <CALLSIGN> <TEXT>" format for sending. Might be
                    > worthwhile, since I get proper functionality out of the "--" set of
                    > commands.

                    Using the above format for sending a message via the Nuvi, the message
                    goes into the Outbox, and does NOT have the "sending..." mnemonic
                    beside it (i.e. it looks as if it has been sent), however, the message
                    is never transmitted over RF.

                    Since message sending using the above format worked fine when the
                    radio/T2 was used via a terminal & serial cable, it increases my
                    confidence that the issue is in the FMI interface programming.

                    Am I the only one here having this issue? Doesn't seem like many
                    others are having trouble with messaging via their Nuvi 350's, or else
                    they're all very quiet about it...

                    Kurt
                    KE7KUS
                  • ve7pke1
                    ... Several weeks ago I started a thread about messaging with the Nuvi 350 and T2. In that I discovered and other confirmed that there are a few mistakes in
                    Message 9 of 29 , Nov 11, 2008
                    • 0 Attachment
                      --- In tracker2@yahoogroups.com, "ke7kus" <ke7kus@...> wrote:
                      >Kurt
                      Several weeks ago I started a thread about messaging with the Nuvi 350
                      and T2.
                      In that I discovered and other confirmed that there are a few mistakes
                      in some of the information out there.
                      -callsign text works. --send does not.
                      Check out the discussion.
                      I have had mixed results with getting acks back. I have not tried with
                      my -135 version yet only with Nuvi 350 T2 hooked to handheld.
                      Dave

                      > > The one thing I haven't tried is sending a message from the Nuvi using
                      > > the "--SEND <CALLSIGN> <TEXT>" format for sending. Might be
                      > > worthwhile, since I get proper functionality out of the "--" set of
                      > > commands.
                      >
                      > Using the above format for sending a message via the Nuvi, the message
                      > goes into the Outbox, and does NOT have the "sending..." mnemonic
                      > beside it (i.e. it looks as if it has been sent), however, the message
                      > is never transmitted over RF.
                      >
                      > Since message sending using the above format worked fine when the
                      > radio/T2 was used via a terminal & serial cable, it increases my
                      > confidence that the issue is in the FMI interface programming.
                      >
                      > Am I the only one here having this issue? Doesn't seem like many
                      > others are having trouble with messaging via their Nuvi 350's, or else
                      > they're all very quiet about it...
                      >
                      > Kurt
                      > KE7KUS
                      >
                    • rschultz82
                      I too have the same problem, messages send and pass the retrytime and keep going. It is stuck in the Outbox as Sending. You are seeing this on the Nuvi 350, I
                      Message 10 of 29 , Nov 11, 2008
                      • 0 Attachment
                        I too have the same problem, messages send and pass the retrytime and
                        keep going. It is stuck in the Outbox as Sending. You are seeing this
                        on the Nuvi 350, I am actually using a Nuvi 360, but I doubt there is
                        much difference. I look forward to more of your troubleshooting, but
                        right now I don't really have any time to do any of my own.

                        Thanks,

                        Ryan
                        W9UEY
                      • Bjornung
                        ... I have the same problem as far as I can understand. I do not have experience in sending APRS messages so have not been able to contribute, but have
                        Message 11 of 29 , Nov 11, 2008
                        • 0 Attachment
                          --- In tracker2@yahoogroups.com, "ke7kus" <ke7kus@...> wrote:
                          >..........
                          > Am I the only one here having this issue? Doesn't seem like many
                          > others are having trouble with messaging via their Nuvi 350's, or else
                          > they're all very quiet about it...
                          >
                          > Kurt
                          > KE7KUS
                          >

                          I have the same problem as far as I can understand. I do not have
                          experience in sending APRS messages so have not been able to
                          contribute, but have followed your testing with intereset. I am using
                          OT2 and Nuvi 350 with a VX-5 HT. One thing I noticed today was that i
                          could not even get a message to the OT2 (--VERSION) untill after I had
                          cleared all remaining (not more than 6-7)meassages in the outbox. Note
                          that I have not yet comfirmed that this is always so.

                          Regards
                          Bjornung
                          LA9ULA
                        • ke7kus
                          Dave, ... I had the same issue with my Nuvi 350 and T2-135 that you had with your configuration. The SEND command worked fine when I connected to the
                          Message 12 of 29 , Nov 11, 2008
                          • 0 Attachment
                            Dave,

                            > Several weeks ago I started a thread about messaging with the Nuvi 350
                            > and T2.
                            > In that I discovered and other confirmed that there are a few mistakes
                            > in some of the information out there.
                            > -callsign text works. --send does not.

                            I had the same issue with my Nuvi 350 and T2-135 that you had with
                            your configuration. The SEND command worked fine when I connected to
                            the T2/DR-135 with a serial cable into the back of the radio, using a
                            terminal program on my desktop, but I could not get it to work using
                            the Nuvi 350.

                            As such, I'm pretty convinced that the issue is in the part of the
                            software that handles the FMI interface. The fact that you're seeing
                            the same thing with a Tracker2 further reinforces my thinking, since
                            the only things in common between your setup and mine are the Tracker
                            software and the Nuvi GPS.

                            Kurt
                            KE7KUS
                          • Scott Miller
                            Sorry for being so far behind on some of these threads. I took advantage of the holiday today and spent the whole day away from the computer, catching up on
                            Message 13 of 29 , Nov 11, 2008
                            • 0 Attachment
                              Sorry for being so far behind on some of these threads. I took
                              advantage of the holiday today and spent the whole day away from the
                              computer, catching up on other stuff in the shop.

                              I'm going to be working on setting up a lab where I can leave a bunch of
                              stuff set up - should make it easier to recreate stuff like this without
                              having to tear down the one or two test units I've usually got on the
                              bench and totally reconfigure everything.

                              As for the nuvi messaging thing, first make sure you've got the latest
                              nuvi firmware. They fixed a message queue bug not long ago. Also,
                              check that your RETRIES setting is not 0.

                              Scott

                              ke7kus wrote:
                              >
                              >
                              > > The one thing I haven't tried is sending a message from the Nuvi using
                              > > the "--SEND <CALLSIGN> <TEXT>" format for sending. Might be
                              > > worthwhile, since I get proper functionality out of the "--" set of
                              > > commands.
                              >
                              > Using the above format for sending a message via the Nuvi, the message
                              > goes into the Outbox, and does NOT have the "sending..." mnemonic
                              > beside it (i.e. it looks as if it has been sent), however, the message
                              > is never transmitted over RF.
                              >
                              > Since message sending using the above format worked fine when the
                              > radio/T2 was used via a terminal & serial cable, it increases my
                              > confidence that the issue is in the FMI interface programming.
                              >
                              > Am I the only one here having this issue? Doesn't seem like many
                              > others are having trouble with messaging via their Nuvi 350's, or else
                              > they're all very quiet about it...
                              >
                              > Kurt
                              > KE7KUS
                              >
                              >
                            • Rudolf Benner
                              You need to clone yourself or grow a couple of extra arms. ... the ... bunch of ... without ... the ... latest ... Nuvi using ... set of ... message ...
                              Message 14 of 29 , Nov 11, 2008
                              • 0 Attachment
                                You need to clone yourself or grow a couple of extra arms.


                                --- In tracker2@yahoogroups.com, Scott Miller <scott@...> wrote:
                                >
                                > Sorry for being so far behind on some of these threads. I took
                                > advantage of the holiday today and spent the whole day away from
                                the
                                > computer, catching up on other stuff in the shop.
                                >
                                > I'm going to be working on setting up a lab where I can leave a
                                bunch of
                                > stuff set up - should make it easier to recreate stuff like this
                                without
                                > having to tear down the one or two test units I've usually got on
                                the
                                > bench and totally reconfigure everything.
                                >
                                > As for the nuvi messaging thing, first make sure you've got the
                                latest
                                > nuvi firmware. They fixed a message queue bug not long ago. Also,
                                > check that your RETRIES setting is not 0.
                                >
                                > Scott
                                >
                                > ke7kus wrote:
                                > >
                                > >
                                > > > The one thing I haven't tried is sending a message from the
                                Nuvi using
                                > > > the "--SEND <CALLSIGN> <TEXT>" format for sending. Might be
                                > > > worthwhile, since I get proper functionality out of the "--"
                                set of
                                > > > commands.
                                > >
                                > > Using the above format for sending a message via the Nuvi, the
                                message
                                > > goes into the Outbox, and does NOT have the "sending..." mnemonic
                                > > beside it (i.e. it looks as if it has been sent), however, the
                                message
                                > > is never transmitted over RF.
                                > >
                                > > Since message sending using the above format worked fine when the
                                > > radio/T2 was used via a terminal & serial cable, it increases my
                                > > confidence that the issue is in the FMI interface programming.
                                > >
                                > > Am I the only one here having this issue? Doesn't seem like many
                                > > others are having trouble with messaging via their Nuvi 350's, or
                                else
                                > > they're all very quiet about it...
                                > >
                                > > Kurt
                                > > KE7KUS
                                > >
                                > >
                                >
                              • Scott Miller
                                Well, Charlie had the day off from school, so I put him to work restocking parts and packing kits. He s the closest I ve got to a clone so far, I guess. =]
                                Message 15 of 29 , Nov 11, 2008
                                • 0 Attachment
                                  Well, Charlie had the day off from school, so I put him to work
                                  restocking parts and packing kits. He's the closest I've got to a clone
                                  so far, I guess. =]

                                  Scott

                                  Rudolf Benner wrote:
                                  >
                                  >
                                  > You need to clone yourself or grow a couple of extra arms.
                                  >
                                  > --- In tracker2@yahoogroups.com <mailto:tracker2%40yahoogroups.com>,
                                  > Scott Miller <scott@...> wrote:
                                  > >
                                  > > Sorry for being so far behind on some of these threads. I took
                                  > > advantage of the holiday today and spent the whole day away from
                                  > the
                                  > > computer, catching up on other stuff in the shop.
                                  > >
                                  > > I'm going to be working on setting up a lab where I can leave a
                                  > bunch of
                                  > > stuff set up - should make it easier to recreate stuff like this
                                  > without
                                  > > having to tear down the one or two test units I've usually got on
                                  > the
                                  > > bench and totally reconfigure everything.
                                  > >
                                  > > As for the nuvi messaging thing, first make sure you've got the
                                  > latest
                                  > > nuvi firmware. They fixed a message queue bug not long ago. Also,
                                  > > check that your RETRIES setting is not 0.
                                  > >
                                  > > Scott
                                  > >
                                  > > ke7kus wrote:
                                  > > >
                                  > > >
                                  > > > > The one thing I haven't tried is sending a message from the
                                  > Nuvi using
                                  > > > > the "--SEND <CALLSIGN> <TEXT>" format for sending. Might be
                                  > > > > worthwhile, since I get proper functionality out of the "--"
                                  > set of
                                  > > > > commands.
                                  > > >
                                  > > > Using the above format for sending a message via the Nuvi, the
                                  > message
                                  > > > goes into the Outbox, and does NOT have the "sending..." mnemonic
                                  > > > beside it (i.e. it looks as if it has been sent), however, the
                                  > message
                                  > > > is never transmitted over RF.
                                  > > >
                                  > > > Since message sending using the above format worked fine when the
                                  > > > radio/T2 was used via a terminal & serial cable, it increases my
                                  > > > confidence that the issue is in the FMI interface programming.
                                  > > >
                                  > > > Am I the only one here having this issue? Doesn't seem like many
                                  > > > others are having trouble with messaging via their Nuvi 350's, or
                                  > else
                                  > > > they're all very quiet about it...
                                  > > >
                                  > > > Kurt
                                  > > > KE7KUS
                                  > > >
                                  > > >
                                  > >
                                  >
                                  >
                                • ke7kus
                                  Scott, ... I ve got latest and greatest for everything involved: Nuvi 350 w/ firmware v 6.00 T2-135 Build 54680 DR-135MkIII RETRIES has been set to everything
                                  Message 16 of 29 , Nov 11, 2008
                                  • 0 Attachment
                                    Scott,
                                    > As for the nuvi messaging thing, first make sure you've got the latest
                                    > nuvi firmware. They fixed a message queue bug not long ago. Also,
                                    > check that your RETRIES setting is not 0.

                                    I've got latest and greatest for everything involved:

                                    Nuvi 350 w/ firmware v 6.00
                                    T2-135 Build 54680
                                    DR-135MkIII

                                    RETRIES has been set to everything from 2 to 6, but never 0. With
                                    messaging, I'm getting consistent results, so you should be able to
                                    dupe it in the lab. Let me know if you need more info.

                                    Kurt
                                    KE7KUS
                                  • Scott Miller
                                    ... You might see different behavior, because the logic is a little different. For FMI-originated message, it s currently set up so that it doesn t ACK the
                                    Message 17 of 29 , Nov 12, 2008
                                    • 0 Attachment
                                      > The one thing I haven't tried is sending a message from the Nuvi using
                                      > the "--SEND <CALLSIGN> <TEXT>" format for sending. Might be
                                      > worthwhile, since I get proper functionality out of the "--" set of
                                      > commands.

                                      You might see different behavior, because the logic is a little
                                      different. For FMI-originated message, it's currently set up so that it
                                      doesn't ACK the message to the nuvi until it gets an ack from the recipient.

                                      The intent here is to make it clear if the message has gone through or
                                      not. The problem is that there's no NAK for FMI messages - it never
                                      occurred to Garmin that there might be a situation where a particular
                                      message couldn't get through, so the only way to clear it from the queue
                                      and get the next one to be sent is to ACK it after it runs out of retries.

                                      Around line 350 in parse_aprs.c is where it handles incoming ACKs. If
                                      it sees that it's an ACK for the current message, it'll tell the nuvi.

                                      Further complicating things is the fact that the T2 has to keep checking
                                      with the nuvi to see if it missed a message. If it rebooted or
                                      something and missed the original message, the only way to get it is to
                                      ask for a retry on message ID 0xffffffff. If there's a message in the
                                      queue, it'll send it again - but the stupid thing (if I remember this
                                      right) is that it sends it with message ID 0xffffffff, so you don't know
                                      what the original ID is.

                                      The bug Garmin fixed recently was related to this, but I can't recall
                                      the exact fix. I've got to make sure my test units are all up to date
                                      and run through a bunch of test scenarios.

                                      As long as people are looking at code and trying to debug by themselves,
                                      I should probably post the linker map files along with the firmware.
                                      That way, if you're curious what's going on internally, you can use the
                                      DUMP command to see the contents of RAM and find specific variables by
                                      looking them up in the map file.

                                      Scott
                                    • ke7kus
                                      ... queue ... retries. Seems like Garmin could be sitting on a real gold-mine here with FMI if they d spend a little time and effort on it. With the marked
                                      Message 18 of 29 , Nov 13, 2008
                                      • 0 Attachment
                                        > The intent here is to make it clear if the message has gone through or
                                        > not. The problem is that there's no NAK for FMI messages - it never
                                        > occurred to Garmin that there might be a situation where a particular
                                        > message couldn't get through, so the only way to clear it from the
                                        queue
                                        > and get the next one to be sent is to ACK it after it runs out of
                                        retries.

                                        Seems like Garmin could be sitting on a real gold-mine here with FMI
                                        if they'd spend a little time and effort on it. With the marked
                                        increase in interest in interactive geolocation, APRS is not the only
                                        application that would benefit from a competent 2-way serial interface
                                        between a Garmin GPS and (insert name of hardware/software application
                                        here.) I don't know of any other manufacturer who even implements a
                                        2-way interface with their units. Could be a real breakout feature in
                                        a competitive market. (Garmin...I hope you're reading this, as well
                                        as the recent observations regarding FMI 2.0...)

                                        > Around line 350 in parse_aprs.c is where it handles incoming ACKs. If
                                        > it sees that it's an ACK for the current message, it'll tell the nuvi.

                                        This may be part of my problem. Here in Phoenix, I've seen a really
                                        low success rate on getting message ACK's back through the IGates to
                                        RF. It's not just ACK's either...I'm batting about 25% getting
                                        anything back to the radio from APRS-IS. The messages from my T2 show
                                        in findu/openaprs/aprs.fi; however, when I check the raw traffic for
                                        the local digi's, they're not putting out the return info to RF in
                                        many cases. I definitely need to do some more troubleshooting in this
                                        area to see if particular IGates are running restrictive traffic
                                        rulesets, or if there's something else causing the packets to not get
                                        through. Although APRS was designed to be as simple as possible with
                                        packet routing, in a congested urban area, some attention might need
                                        to be paid depending on the local IGate setups.

                                        If I understand correctly what you've said here, the lack of NAK in
                                        the FMI interface could be the root cause of my issue. Without it,
                                        the T2 relies on incoming ACK from RF for a given message to let nuvi
                                        know that it can stop trying to send the message from the Outbox.
                                        Absent that ACK, nuvi's going to do exactly what mine is
                                        doing...continue to try to send the message. I'll work on
                                        troubleshooting the RF ACK issue from this end.

                                        > As long as people are looking at code and trying to debug by
                                        themselves,
                                        > I should probably post the linker map files along with the firmware.
                                        > That way, if you're curious what's going on internally, you can use the
                                        > DUMP command to see the contents of RAM and find specific variables by
                                        > looking them up in the map file.

                                        This would be great - slightly over my head, but I'm learning more and
                                        more each day, and that's what I really love about ham radio.

                                        Kurt
                                        KE7KUS
                                      • Steve
                                        Your problem in Phoenix is not restrictive IGATES!! The problems in Phoenix are purely extremely high packet levels that get worse in the winter with the
                                        Message 19 of 29 , Nov 13, 2008
                                        • 0 Attachment
                                          Your problem in Phoenix is not restrictive IGATES!!
                                          The problems in Phoenix are purely extremely high packet levels that get worse in the winter with the arrival of the "snow birds".
                                           
                                          I used to be the sysop for the Phoenix Igate and it was a thankless task with people using packet paths far too wide for a metropolitan area and compounded by a large number of very high digi's in the mountains around the valley of the sun.
                                           
                                          No amount of "education or advice" to users could get the packet numbers down!
                                           
                                          Just the other day I noticed that KB7KFC-1 was showing a traffic load in excess of 235 packets in the "Quiet" part of the day outside of the commute hours.
                                           
                                          No one in Phoenix is more than 1 HOP from an Igate....yet some choose a path like TEMP2-2,WIDE1-1,WIDE2-2  (the nearest static station to kb7kfc) and seen using a beacon rate of that of a mobile!!
                                           
                                          Get used to packet collisions in Phoenix as the problem will not go away anytime soon!
                                           
                                          73
                                          Steve, kf6wax,  Charlotte NC area Igate sysop
                                           
                                           


                                           
                                          On Thu, Nov 13, 2008 at 9:33 AM, ke7kus <ke7kus@...> wrote:

                                          > The intent here is to make it clear if the message has gone through or
                                          > not. The problem is that there's no NAK for FMI messages - it never
                                          > occurred to Garmin that there might be a situation where a particular
                                          > message couldn't get through, so the only way to clear it from the
                                          queue
                                          > and get the next one to be sent is to ACK it after it runs out of
                                          retries.

                                          Seems like Garmin could be sitting on a real gold-mine here with FMI
                                          if they'd spend a little time and effort on it. With the marked
                                          increase in interest in interactive geolocation, APRS is not the only
                                          application that would benefit from a competent 2-way serial interface
                                          between a Garmin GPS and (insert name of hardware/software application
                                          here.) I don't know of any other manufacturer who even implements a
                                          2-way interface with their units. Could be a real breakout feature in
                                          a competitive market. (Garmin...I hope you're reading this, as well
                                          as the recent observations regarding FMI 2.0...)

                                          > Around line 350 in parse_aprs.c is where it handles incoming ACKs. If
                                          > it sees that it's an ACK for the current message, it'll tell the nuvi.

                                          This may be part of my problem. Here in Phoenix, I've seen a really
                                          low success rate on getting message ACK's back through the IGates to
                                          RF. It's not just ACK's either...I'm batting about 25% getting
                                          anything back to the radio from APRS-IS. The messages from my T2 show
                                          in findu/openaprs/aprs.fi; however, when I check the raw traffic for
                                          the local digi's, they're not putting out the return info to RF in
                                          many cases. I definitely need to do some more troubleshooting in this
                                          area to see if particular IGates are running restrictive traffic
                                          rulesets, or if there's something else causing the packets to not get
                                          through. Although APRS was designed to be as simple as possible with
                                          packet routing, in a congested urban area, some attention might need
                                          to be paid depending on the local IGate setups.

                                          If I understand correctly what you've said here, the lack of NAK in
                                          the FMI interface could be the root cause of my issue. Without it,
                                          the T2 relies on incoming ACK from RF for a given message to let nuvi
                                          know that it can stop trying to send the message from the Outbox.
                                          Absent that ACK, nuvi's going to do exactly what mine is
                                          doing...continue to try to send the message. I'll work on
                                          troubleshooting the RF ACK issue from this end.

                                          > As long as people are looking at code and trying to debug by
                                          themselves,
                                          > I should probably post the linker map files along with the firmware.
                                          > That way, if you're curious what's going on internally, you can use the
                                          > DUMP command to see the contents of RAM and find specific variables by
                                          > looking them up in the map file.

                                          This would be great - slightly over my head, but I'm learning more and
                                          more each day, and that's what I really love about ham radio.

                                          Kurt
                                          KE7KUS


                                        • ke7kus
                                          ... Thanks for the info, Steve. I drove around the valley tonight for about 2 hours running errands and doing some tests enroute. For the first time I was
                                          Message 20 of 29 , Nov 13, 2008
                                          • 0 Attachment
                                            > Your problem in Phoenix is not restrictive IGATES!!
                                            > The problems in Phoenix are purely extremely high packet levels that get
                                            > worse in the winter with the arrival of the "snow birds".

                                            > Get used to packet collisions in Phoenix as the problem will not go away
                                            > anytime soon!

                                            Thanks for the info, Steve. I drove around the valley tonight for
                                            about 2 hours running errands and doing some tests enroute. For the
                                            first time I was able to get several messages out to "EMAIL" via the
                                            Nuvi, the way they should work. No hangups in the Outbox and messages
                                            received on the other end with no problem.

                                            Packet collisions would certainly explain the problem given Scott's
                                            info on the lack of NAK in the FMI spec. If an ACK gets broadcast
                                            once or twice by a digi and gets stepped on by other stations, the
                                            Nuvi keeps attempting to send, the ACK sending station stops sending
                                            and the great "do-loop" begins.

                                            For Scott and the rest, this seems to rule out a software issue other
                                            than the inherent limits of both the APRS and FMI protocols. A
                                            software error would generate consistent hangups in the Outbox, and
                                            that was certainly not the case tonight. Packet collisions would also
                                            explain the issues with Rx of messages that I have had to this point
                                            and been unable to isolate...unable to isolate because the issue isn't
                                            an isolated issue, but a widespread local problem.

                                            Kurt
                                            KE7KUS
                                          • Mark Cheavens
                                            Kurt, Also keep in mind that the longer the message is, the less likely it is of getting through. 1. Mobile Flutter 2. The odds of another station transmitting
                                            Message 21 of 29 , Nov 14, 2008
                                            • 0 Attachment
                                              Kurt,
                                              Also keep in mind that the longer the message is, the less likely it is of getting through.
                                              1. Mobile Flutter
                                              2. The odds of another station transmitting and clobbering you at the digi site the longer you are transmitting.

                                              I am NOT promoting the use of "big smoke" transmitters, BUT, if you were to run a gain antenna and a 100W transmitter, I'll bet most of you messages would get through!

                                              I live in a metro area (Houston) and my tracker always works MUCH better on 50W than on 5W. It has 2-3 times as many position reports make it through the digi.

                                              Mark
                                              KC5EVE
                                              At 12:32 AM 11/14/2008, you wrote:

                                              > Your problem in Phoenix is not restrictive IGATES!!
                                              > The problems in Phoenix are purely extremely high packet levels that get
                                              > worse in the winter with the arrival of the "snow birds".

                                              > Get used to packet collisions in Phoenix as the problem will not go away
                                              > anytime soon!

                                              Thanks for the info, Steve. I drove around the valley tonight for
                                              about 2 hours running errands and doing some tests enroute. For the
                                              first time I was able to get several messages out to "EMAIL" via the
                                              Nuvi, the way they should work. No hangups in the Outbox and messages
                                              received on the other end with no problem.

                                              Packet collisions would certainly explain the problem given Scott's
                                              info on the lack of NAK in the FMI spec. If an ACK gets broadcast
                                              once or twice by a digi and gets stepped on by other stations, the
                                              Nuvi keeps attempting to send, the ACK sending station stops sending
                                              and the great "do-loop" begins.

                                              For Scott and the rest, this seems to rule out a software issue other
                                              than the inherent limits of both the APRS and FMI protocols. A
                                              software error would generate consistent hangups in the Outbox, and
                                              that was certainly not the case tonight. Packet collisions would also
                                              explain the issues with Rx of messages that I have had to this point
                                              and been unable to isolate...unable to isolate because the issue isn't
                                              an isolated issue, but a widespread local problem.

                                              Kurt
                                              KE7KUS

                                            • ke7kus
                                              Mark, ... I ve been running around at 5W and getting stepped on quite a bit at the digi s. I bumped up the power to 25W and that s when I started to see a
                                              Message 22 of 29 , Nov 14, 2008
                                              • 0 Attachment
                                                Mark,

                                                > Also keep in mind that the longer the message is, the less likely it
                                                > is of getting through.

                                                > I am NOT promoting the use of "big smoke" transmitters, BUT, if you
                                                > were to run a gain antenna and a 100W transmitter, I'll bet most of
                                                > you messages would get through!
                                                >
                                                > I live in a metro area (Houston) and my tracker always works MUCH
                                                > better on 50W than on 5W. It has 2-3 times as many position reports
                                                > make it through the digi.
                                                >
                                                > Mark
                                                > KC5EVE

                                                I've been running around at 5W and getting stepped on quite a bit at
                                                the digi's. I bumped up the power to 25W and that's when I started to
                                                see a noticeable increase in the success rate of the message traffic
                                                getting through. Not 100%, but it made a noticeable difference. I'm
                                                batting about 80-85% over the last few days, which is a night-and-day
                                                difference from running 5W at before. It just never occurred to me
                                                that at 9 miles and direct line-of-sight to a digi at 3000' above
                                                surrounding terrain that I'd need any more than 5W to get into the
                                                game. Great lesson learned, and thanks to those who provided the
                                                education.

                                                Kurt
                                                KE7KUS
                                              • James Ewen
                                                ... Just wondering... what lesson did you learn? I d be interested in hearing your interpretation! James VE6SRV
                                                Message 23 of 29 , Nov 18, 2008
                                                • 0 Attachment
                                                  On Fri, Nov 14, 2008 at 10:45 PM, ke7kus <ke7kus@...> wrote:

                                                  > I've been running around at 5W and getting stepped on quite a bit at
                                                  > the digi's. I bumped up the power to 25W and that's when I started to
                                                  > see a noticeable increase in the success rate of the message traffic
                                                  > getting through. Not 100%, but it made a noticeable difference. I'm
                                                  > batting about 80-85% over the last few days, which is a night-and-day
                                                  > difference from running 5W at before. It just never occurred to me
                                                  > that at 9 miles and direct line-of-sight to a digi at 3000' above
                                                  > surrounding terrain that I'd need any more than 5W to get into the
                                                  > game. Great lesson learned, and thanks to those who provided the
                                                  > education.

                                                  Just wondering... what lesson did you learn? I'd be interested in
                                                  hearing your interpretation!

                                                  James
                                                  VE6SRV
                                                • ke7kus
                                                  ... 1) Packet congestion in a major metro area like Phoenix is a much bigger problem than I had originally thought. Here at ground level, 144.39 doesn t
                                                  Message 24 of 29 , Nov 19, 2008
                                                  • 0 Attachment
                                                    > Just wondering... what lesson did you learn? I'd be interested in
                                                    > hearing your interpretation!

                                                    1) Packet congestion in a major metro area like Phoenix is a much
                                                    bigger problem than I had originally thought. Here at ground level,
                                                    144.39 doesn't really sound that congested; however, at 4500' above
                                                    the average terrain, the local digis get saturated with all kinds of
                                                    traffic from local area users, as well as from high digis 100+ miles
                                                    away. At ground level, you never hear that distant traffic; however,
                                                    at the digi it creates packet collisions which prevent traffic getting
                                                    through. Being new to APRS, I had read a bit on high density packet
                                                    situations and problems with channel saturation, but this was a great
                                                    example of the problem in action. I now understand the ALOHA circle
                                                    concept and its importance much better.

                                                    2) T2's interface with the nuvi works fine; however, limitations of
                                                    the Garmin FMI interface can inhibit smooth functioning when packet
                                                    collisions are involved. If a return ACK from a sent message gets
                                                    corrupted because of a packet collision, the sent message will hang in
                                                    the nuvi Outbox with the "Sending..." mnemonic. Not a problem with
                                                    the T2, but rather a limitation in the FMI interface itself.

                                                    I'm still quite happy with the whole setup, and Scott's done a
                                                    fantastic job bringing mobile graphical APRS to those who may not
                                                    necessarily have the $1200+ to throw at a D710 & AvMap G5. It's
                                                    prompted me to get to writing some APRS-related software as a side
                                                    project (much to the XYL's chagrin), and I'm really enjoying
                                                    experimenting with it.

                                                    Kurt
                                                    KE7KUS
                                                  • Steve
                                                    kb7kfc-1 has a traffic object (VHF LOAD) near his location in Chandler, a quick look and it shows or reports a packet count of 250 EVERY 10 minutes and that
                                                    Message 25 of 29 , Nov 19, 2008
                                                    • 0 Attachment
                                                      kb7kfc-1 has a traffic object (VHF LOAD) near his location in Chandler, a quick look and it shows or reports a packet count of 250 EVERY 10 minutes and that was at 8.30am local PHX time. WED 19th.
                                                       
                                                      collisions will occur with that kind of packet rate in your area
                                                       
                                                      73
                                                      Steve, kf6wax former PHX Igate sysop
                                                       


                                                       
                                                      On Wed, Nov 19, 2008 at 9:35 AM, ke7kus <ke7kus@...> wrote:

                                                      > Just wondering... what lesson did you learn? I'd be interested in
                                                      > hearing your interpretation!

                                                      1) Packet congestion in a major metro area like Phoenix is a much
                                                      bigger problem than I had originally thought. Here at ground level,
                                                      144.39 doesn't really sound that congested; however, at 4500' above
                                                      the average terrain, the local digis get saturated with all kinds of
                                                      traffic from local area users, as well as from high digis 100+ miles
                                                      away. At ground level, you never hear that distant traffic; however,
                                                      at the digi it creates packet collisions which prevent traffic getting
                                                      through. Being new to APRS, I had read a bit on high density packet
                                                      situations and problems with channel saturation, but this was a great
                                                      example of the problem in action. I now understand the ALOHA circle
                                                      concept and its importance much better.

                                                      2) T2's interface with the nuvi works fine; however, limitations of
                                                      the Garmin FMI interface can inhibit smooth functioning when packet
                                                      collisions are involved. If a return ACK from a sent message gets
                                                      corrupted because of a packet collision, the sent message will hang in
                                                      the nuvi Outbox with the "Sending..." mnemonic. Not a problem with
                                                      the T2, but rather a limitation in the FMI interface itself.

                                                      I'm still quite happy with the whole setup, and Scott's done a
                                                      fantastic job bringing mobile graphical APRS to those who may not
                                                      necessarily have the $1200+ to throw at a D710 & AvMap G5. It's
                                                      prompted me to get to writing some APRS-related software as a side
                                                      project (much to the XYL's chagrin), and I'm really enjoying
                                                      experimenting with it.

                                                      Kurt
                                                      KE7KUS


                                                    • ki6tsf
                                                      Hello, ... in ... I agree. Of course, the problem also appears if no APRS MSG ACK was ever sent by the recipient.. the OT2/Nuvi combo will keep sending the
                                                      Message 26 of 29 , Dec 26, 2008
                                                      • 0 Attachment
                                                        Hello,

                                                        --- In tracker2@yahoogroups.com, "ke7kus" <ke7kus@...> wrote:
                                                        > 2) T2's interface with the nuvi works fine; however, limitations of
                                                        > the Garmin FMI interface can inhibit smooth functioning when packet
                                                        > collisions are involved. If a return ACK from a sent message gets
                                                        > corrupted because of a packet collision, the sent message will hang
                                                        in
                                                        > the nuvi Outbox with the "Sending..." mnemonic. Not a problem with
                                                        > the T2, but rather a limitation in the FMI interface itself.
                                                        >

                                                        I agree.

                                                        Of course, the problem also appears if no APRS MSG ACK was ever sent
                                                        by the recipient.. the OT2/Nuvi combo will keep sending the message
                                                        and have its Outbox queue blocked. There needs to be a global timeout
                                                        concept that is reliable in every situation.

                                                        When no APRS MSG ACK is ever received, it seems that the OT2 does stop
                                                        retrying to send the message after reaching the RETRIES parameter
                                                        value ONLY when the Nuvi is powered off. The message will remain in
                                                        the Outbox queue and prevent other messages to be sent after the Nuvi
                                                        is powered back on, but won't be retried for ever anymore.

                                                        As I understand, the Nuvi keeps sending the message to the OT2 until
                                                        it gets a Garmin ACK from it.

                                                        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.

                                                        That would definitely fix the problem of having APRS messages being
                                                        sent forever by the Nuvi when the OT2 gets no APRS MSG ACK (whatever
                                                        the reason for not getting an ack).

                                                        A small extra would be that the OT2 sends a failure notification to
                                                        the Nuvi in the form of a Inbox message in cases #2 and #3 so the user
                                                        knows there was a problem.

                                                        Hope this makes sense and is feasible... comments welcome.

                                                        73 and Merry X-mas holidays to all!!!

                                                        Bernard KI6TSF
                                                      • Bob Poortinga
                                                        ... I also suggest: #4 when the OT2 is powered on. That way you clear the outbox by performing a power cycle on the OT2. 73 de -- Bob Poortinga K9SQL
                                                        Message 27 of 29 , Dec 27, 2008
                                                        • 0 Attachment
                                                          "ki6tsf" <ki6tsf@...> writes:

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

                                                          73 de
                                                          --
                                                          Bob Poortinga K9SQL <http://www.linkedin.com/in/bobpoortinga>
                                                          Bloomington, Indiana US
                                                        • 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 28 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 29 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.