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

RE: Problem with sending message via RF

Expand Messages
  • g.isringhaus
    Yeah, it still seems to get stuck. I kind of still wanted to view IS stations and only broadcast on RF, but seems like APRSIS has no way on doing this
    Message 1 of 28 , Sep 21, 2013

       Yeah, it still seems to get stuck.  I kind of still wanted to view IS stations and only broadcast on RF, but seems like APRSIS has no way on doing this reliably.  I of course could hit RF Only each time I try to send a message out to somebody, but would be nice if the program was intelligent enough to determine that the IS has been disabled on TX and to send all packet via RF.  Guess for now, I'll just check the RF Only each time. 



      --- In aprsisce@yahoogroups.com, <g.isringhaus@...> wrote:

      The SSID is K0GDI-1, I was wanting to keep the IS from TX because of my own preference.  This is just for the SSID of -1, I keep it open both TX and RX for my main SSID.  It seems to be working fine for now.  Just seems like either it takes about 10 minutes or so for the program to know that the TX is turned of on the IS, or because it recently heard that station on RF and knows to send via RF.  I'll keep an eye on it.



      --- In aprsisce@yahoogroups.com, <ve7gdh@...> wrote:

      Greg (callsign?) wrote...

      > I am having problems with sending messages via RF...

      What is the callsign-SSID of the station sending the messages?

      73 es cul - Keith VE7GDH
      www.ui-view.org
      --
      "I may be lost, but I know exactly where I am!"
    • Rob Giuliano
      James, I think you are reading more into this than the intent.  It is NOT inaccurate. ... There was NO mention of a definite loss of communication, but
      Message 2 of 28 , Sep 21, 2013
        James,
        I think you are reading more into this than the intent.  It is NOT inaccurate.

        > You really should use the "RF Only" option on the Chat dialog to force
        > it to RF and keep APRS-IS Messages enabled. This allows lots of capability
        > including continuing an APRS QSO with a station that might have left
        > your range but is still within range of another message-gating IGate.
        > If you have APRS-IS Messages disabled, you'll simply lose the QSO.

        There was NO mention of a definite loss of communication, but increasing the probability by keeping both paths open - if the other path is lost - not saying it WOULD BE LOST, but it could be lost.  Included in that is the IGATE messaging gating.

         
        Robert Giuliano
        KB8RCO


        ---------------------------------------------


        From: James Ewen <ve6srv@...>
        To: aprsisce@yahoogroups.com
        Sent: Saturday, September 21, 2013 12:41 AM
        Subject: Re: [aprsisce] RE: Problem with sending message via RF

         
        On Fri, Sep 20, 2013 at 10:01 PM, Lynn W Deffenbaugh (Mr)
        <kj4erj@...> wrote:

        > You really should use the "RF Only" option on the Chat dialog to force it to RF and
        > keep APRS-IS Messages enabled. This allows lots of capability including continuing
        > an APRS QSO with a station that might have left your range but is still within range
        > of another message-gating IGate. If you have APRS-IS Messages disabled, you'll
        > simply lose the QSO.

        The above is an inaccurate observation. Hundreds of stations with RF
        only access successfully send and receive APRS messages with stations
        outside of their local RF network by having their messages injected
        into the APRS-IS by other i-gates in the area.

        The messaging source station does not have to directly inject a
        message into the APRS-IS to be able to have their message gated into
        another area.

        --
        James
        VE6SRV


      • James Ewen
        ... Nope, I didn t add extra words like you have... ... The statement was you ll simply lose the QSO , you are adding in definite and increasing
        Message 3 of 28 , Sep 21, 2013
          On Sat, Sep 21, 2013 at 12:54 PM, Rob Giuliano <kb8rco@...> wrote:

          > James,
          > I think you are reading more into this than the intent. It is NOT
          > inaccurate.

          Nope, I didn't add extra words like you have...


          >> If you have APRS-IS Messages disabled, you'll simply lose the QSO.
          >
          > There was NO mention of a definite loss of communication, but increasing the
          > probability by keeping both paths open - if the other path is lost - not
          > saying it WOULD BE LOST, but it could be lost. Included in that is the
          > IGATE messaging gating.

          The statement was "you'll simply lose the QSO", you are adding in
          "definite" and "increasing probability" into the statement.

          Lynn and I butt heads a lot about how APRSISCE/32 works because we
          come from opposite sides of the concept of APRS.

          Lynn built the program based on 100% internet connectivity, and added
          in RF connectivity after the fact. A lot of the thought process he
          uses, and concepts built into APRSISCE/32 are rooted in being tethered
          to the internet.

          I come at APRS from an RF based implementation, where I use APRS with
          RF as the primary connection, and occasionally have access to the
          internet.

          So, keeping that in mind, let's look at the concept above.

          I am sitting at home, with the ability to send APRS packets out via RF
          and IS simultaneously. I am sending APRS messages to you (you are on
          RF only), and you are located well beyond the reach of the local RF
          network. Therefore, to be able to get messages to you, my messages
          have to enter the APRS-IS, then get gated back out to RF for delivery
          to you.

          Obviously if I can inject directly to the APRS-IS, my message will
          travel across the internet, and then get gated to you. With my message
          also being sent via RF, it will be heard locally as well. Should the
          internet connectivity drop out, then that RF packet could be heard by
          another i-gate, and enter the APRS-IS that way. I will not simply lose
          the QSO, the messages will automatically find an alternate route.

          If however the software being used to send those messages makes
          assumptions about the "best" path to use, and shuts off alternate
          routes, then it could disrupt the QSO.

          This isn't about starting a war... I'm just offering different
          observations about the assumptions being made.

          When you work very close to a project, you can get locked into a
          specific mindset, and it is helpful to have differing points of view
          brought out.

          I enjoy discussions like this because I too end up with a narrow focus
          on different ideas and concepts, and by listening to what others have
          to say, I can gain more insight into the concept, learn more than I
          new before, and possibly change my conceptualization of the whole
          idea.

          --
          James
          VE6SRV
        • g.isringhaus
          ... Nope, I didn t add extra words like you have... ... The statement was you ll simply lose the QSO , you are adding in definite and increasing
          Message 4 of 28 , Sep 21, 2013

             Well said James.  I try not to rely too much on the internet for this particular SSID because I want to make sure that it is 100% running on RF when a disaster strikes.  Everybody has preferences and different ways of doing things.  That is what makes the hobby fun!



            --- In aprsisce@yahoogroups.com, <ve6srv@...> wrote:

            On Sat, Sep 21, 2013 at 12:54 PM, Rob Giuliano <kb8rco@...> wrote:

            > James,
            > I think you are reading more into this than the intent. It is NOT
            > inaccurate.

            Nope, I didn't add extra words like you have...


            >> If you have APRS-IS Messages disabled, you'll simply lose the QSO.
            >
            > There was NO mention of a definite loss of communication, but increasing the
            > probability by keeping both paths open - if the other path is lost - not
            > saying it WOULD BE LOST, but it could be lost. Included in that is the
            > IGATE messaging gating.

            The statement was "you'll simply lose the QSO", you are adding in
            "definite" and "increasing probability" into the statement.

            Lynn and I butt heads a lot about how APRSISCE/32 works because we
            come from opposite sides of the concept of APRS.

            Lynn built the program based on 100% internet connectivity, and added
            in RF connectivity after the fact. A lot of the thought process he
            uses, and concepts built into APRSISCE/32 are rooted in being tethered
            to the internet.

            I come at APRS from an RF based implementation, where I use APRS with
            RF as the primary connection, and occasionally have access to the
            internet.

            So, keeping that in mind, let's look at the concept above.

            I am sitting at home, with the ability to send APRS packets out via RF
            and IS simultaneously. I am sending APRS messages to you (you are on
            RF only), and you are located well beyond the reach of the local RF
            network. Therefore, to be able to get messages to you, my messages
            have to enter the APRS-IS, then get gated back out to RF for delivery
            to you.

            Obviously if I can inject directly to the APRS-IS, my message will
            travel across the internet, and then get gated to you. With my message
            also being sent via RF, it will be heard locally as well. Should the
            internet connectivity drop out, then that RF packet could be heard by
            another i-gate, and enter the APRS-IS that way. I will not simply lose
            the QSO, the messages will automatically find an alternate route.

            If however the software being used to send those messages makes
            assumptions about the "best" path to use, and shuts off alternate
            routes, then it could disrupt the QSO.

            This isn't about starting a war... I'm just offering different
            observations about the assumptions being made.

            When you work very close to a project, you can get locked into a
            specific mindset, and it is helpful to have differing points of view
            brought out.

            I enjoy discussions like this because I too end up with a narrow focus
            on different ideas and concepts, and by listening to what others have
            to say, I can gain more insight into the concept, learn more than I
            new before, and possibly change my conceptualization of the whole
            idea.

            --
            James
            VE6SRV
          • Steve Daniels
            What James says is true about APRSISCE/32 being a bit internet relient, but to be fair the original software was designed as a IS stream viewing client. The RF
            Message 5 of 28 , Sep 21, 2013

              What James says is true about APRSISCE/32 being a bit internet relient, but to be fair the original software was designed as a IS stream viewing client.

              The RF was added on. That’s admittedly a simplistic view.

              Lynn has stated that he intends to do a redesign of APRSIS32. I know he has had thoughts on how to change things. Obviously a lot has been learnt over the time APRSIS32 has been going.

               

              And of course someone keeps distracting him, with other projects. Sorry

               

              Steve Daniels

              Amateur Radio Callsign G6UIM

              Torbay Freecycle  Owner

              http://uk.groups.yahoo.com/group/torbay_freecycle

              APRSISCE/32 Beta tester and WIKI editor http://aprsisce.wikidot.com

               


              From: aprsisce@yahoogroups.com [mailto: aprsisce@yahoogroups.com ] On Behalf Of g.isringhaus@...
              Sent: 21 September 2013 23:16
              To: aprsisce@yahoogroups.com
              Subject: [aprsisce] RE: Problem with sending message via RF

               

               

               Well said James.  I try not to rely too much on the internet for this particular SSID because I want to make sure that it is 100% running on RF when a disaster strikes.  Everybody has preferences and different ways of doing things.  That is what makes the hobby fun!



              --- In aprsisce@yahoogroups.com , <ve6srv@...> wrote:

              On Sat, Sep 21, 2013 at 12:54 PM, Rob Giuliano <kb8rco@...> wrote:

              > James,

              > I think you are reading more into this than the intent. It is NOT
              > inaccurate.


              Nope, I didn't add extra words like you have...

              >> If you have APRS-IS Messages disabled, you'll simply lose the QSO.

              >
              > There was NO mention of a definite loss of communication, but increasing
              the
              > probability by keeping both paths open - if the other path is lost - not
              > saying it WOULD BE LOST, but it could be lost. Included in that is the
              > IGATE messaging gating.


              The statement was "you'll simply lose the QSO", you are adding in
              "definite" and "increasing probability" into the statement.

              Lynn and I butt heads a lot about how APRSISCE/32 works because we
              come from opposite sides of the concept of APRS.

              Lynn built the program based on 100% internet connectivity, and added
              in RF connectivity after the fact. A lot of the thought process he
              uses, and concepts built into APRSISCE/32 are rooted in being tethered
              to the internet.

              I come at APRS from an RF based implementation, where I use APRS with
              RF as the primary connection, and occasionally have access to the
              internet.

              So, keeping that in mind, let's look at the concept above.

              I am sitting at home, with the ability to send APRS packets out via RF
              and IS simultaneously. I am sending APRS messages to you (you are on
              RF only), and you are located well beyond the reach of the local RF
              network. Therefore, to be able to get messages to you, my messages
              have to enter the APRS-IS, then get gated back out to RF for delivery
              to you.

              Obviously if I can inject directly to the APRS-IS, my message will
              travel across the internet, and then get gated to you. With my message
              also being sent via RF, it will be heard locally as well. Should the
              internet connectivity drop out, then that RF packet could be heard by
              another i-gate, and enter the APRS-IS that way. I will not simply lose
              the QSO, the messages will automatically find an alternate route.

              If however the software being used to send those messages makes
              assumptions about the "best" path to use, and shuts off alternate
              routes, then it could disrupt the QSO.

              This isn't about starting a war... I'm just offering different
              observations about the assumptions being made.

              When you work very close to a project, you can get locked into a
              specific mindset, and it is helpful to have differing points of view
              brought out.

              I enjoy discussions like this because I too end up with a narrow focus
              on different ideas and concepts, and by listening to what others have
              to say, I can gain more insight into the concept, learn more than I
              new before, and possibly change my conceptualization of the whole
              idea.

              --
              James
              VE6SRV

            • Rob Giuliano
              I do agree that APRSISce/32 is APRS-IS centered, but I think your comments take out of context, the point of the original discussion.  I may have read read
              Message 6 of 28 , Sep 22, 2013
                I do agree that APRSISce/32 is APRS-IS centered, but I think your comments take out of context, the point of the original discussion.  I may have read read some things into it, but followed (IMO) the point he was trying to make from the original discussion.

                > You really should use the "RF Only" option on the Chat dialog to force
                > it to RF and keep APRS-IS Messages enabled. This allows lots of capability
                > including continuing an APRS QSO with a station that might have left
                > your range but is still within range of another message-gating IGate.
                > If you have APRS-IS Messages disabled, you'll simply lose the QSO.

                I don't have full original message, but the point (as I read it) was EVEN WITH "force RF" enabled, a user "should" keep APRS-IS messages enabled (don't disable it) because "if you lose the RF by the other station leaving your range", you still have the IS system (or IS-> RF from another I-Gate.

                That is STILL good advice so the message gets to them.
                Disabling APRS-IS messages when forced RF is check reduces your options, especially if IGATE access is limited in the area.
                 
                Robert Giuliano
                KB8RCO


                ---------------------------------------------


                From: James Ewen <ve6srv@...>
                To: aprsisce@yahoogroups.com
                Sent: Saturday, September 21, 2013 4:15 PM
                Subject: Re: [aprsisce] RE: Problem with sending message via RF

                 
                On Sat, Sep 21, 2013 at 12:54 PM, Rob Giuliano <kb8rco@...> wrote:

                > James,
                > I think you are reading more into this than the intent. It is NOT
                > inaccurate.

                Nope, I didn't add extra words like you have...

                >> If you have APRS-IS Messages disabled, you'll simply lose the QSO.
                >
                > There was NO mention of a definite loss of communication, but increasing the
                > probability by keeping both paths open - if the other path is lost - not
                > saying it WOULD BE LOST, but it could be lost. Included in that is the
                > IGATE messaging gating.

                The statement was "you'll simply lose the QSO", you are adding in
                "definite" and "increasing probability" into the statement.

                Lynn and I butt heads a lot about how APRSISCE/32 works because we
                come from opposite sides of the concept of APRS.

                Lynn built the program based on 100% internet connectivity, and added
                in RF connectivity after the fact. A lot of the thought process he
                uses, and concepts built into APRSISCE/32 are rooted in being tethered
                to the internet.

                I come at APRS from an RF based implementation, where I use APRS with
                RF as the primary connection, and occasionally have access to the
                internet.

                So, keeping that in mind, let's look at the concept above.

                I am sitting at home, with the ability to send APRS packets out via RF
                and IS simultaneously. I am sending APRS messages to you (you are on
                RF only), and you are located well beyond the reach of the local RF
                network. Therefore, to be able to get messages to you, my messages
                have to enter the APRS-IS, then get gated back out to RF for delivery
                to you.

                Obviously if I can inject directly to the APRS-IS, my message will
                travel across the internet, and then get gated to you. With my message
                also being sent via RF, it will be heard locally as well. Should the
                internet connectivity drop out, then that RF packet could be heard by
                another i-gate, and enter the APRS-IS that way. I will not simply lose
                the QSO, the messages will automatically find an alternate route.

                If however the software being used to send those messages makes
                assumptions about the "best" path to use, and shuts off alternate
                routes, then it could disrupt the QSO.

                This isn't about starting a war... I'm just offering different
                observations about the assumptions being made.

                When you work very close to a project, you can get locked into a
                specific mindset, and it is helpful to have differing points of view
                brought out.

                I enjoy discussions like this because I too end up with a narrow focus
                on different ideas and concepts, and by listening to what others have
                to say, I can gain more insight into the concept, learn more than I
                new before, and possibly change my conceptualization of the whole
                idea.

                --
                James
                VE6SRV


              • James Ewen
                ... Yes, your options are reduced IF you have internet access. If you are where there are no i-gates, and you have internet connectivity turned off, then you
                Message 7 of 28 , Sep 22, 2013
                  On Sun, Sep 22, 2013 at 1:48 PM, Rob Giuliano <kb8rco@...> wrote:

                  > I don't have full original message, but the point (as I read it) was EVEN WITH "force RF"
                  > enabled, a user "should" keep APRS-IS messages enabled (don't disable it) because
                  > "if you lose the RF by the other station leaving your range", you still have the IS system
                  > (or IS-> RF from another I-Gate.
                  >
                  > That is STILL good advice so the message gets to them.
                  > Disabling APRS-IS messages when forced RF is check reduces your options,
                  > especially if IGATE access is limited in the area.

                  Yes, your options are reduced IF you have internet access. If you are
                  where there are no i-gates, and you have internet connectivity turned
                  off, then you would simply lose the QSO when the other station moves
                  out of RF range.

                  The point was that there were assumptions being made with the original
                  statement... it was assumed that there were no i-gates in the area,
                  and that the user HAD access to the internet. To "simply lose the QSO"
                  when a station moves out of local RF range requires all internet
                  access (both internal and provided by others) to be non-existent.

                  BTW, "local RF range" includes the whole area which an RF signal can
                  be heard, not only directly, but through ALL accessed digipeaters.

                  If you have internet access, and RF access, then allowing both methods
                  to be used to deliver a message is good advice, but losing
                  connectivity via one port does not necessarily cause the loss of
                  communications capability.

                  --
                  James
                  VE6SRV
                • Rob Giuliano
                  But the MAIN POINT of the group MUST BE to provide CLARITY - SPECIFICALLY with respect to the answer to the question posed - without confusion. When I read
                  Message 8 of 28 , Sep 22, 2013
                    But the MAIN POINT of the group MUST BE to provide CLARITY - SPECIFICALLY with respect to the answer to the question posed - without confusion.

                    When I read your response to Lynn, had I been the person who posed the question, I could have been confused - SPECIFICALLY because the statement directly said the answer was "inaccurate", while quoting pretty much the whole answer.

                    >> You really should use the "RF Only" option on the Chat dialog
                    >> to force it to RF and keep APRS-IS Messages enabled. This allows
                    >> lots of capability including continuing an APRS QSO with a station
                    >> that might have left your range but is still within range of another
                    >> message-gating IGate. If you have APRS-IS Messages disabled, you'll
                    >> simply lose the QSO.
                    >
                    > The above is an inaccurate observation. Hundreds of stations with RF
                    > only access successfully send and receive APRS messages with stations
                    > outside of their local RF network by having their messages injected
                    > into the APRS-IS by other i-gates in the area.

                    The assumptions were to make a point about settings, not to "bash or imply inability" of the system.  Countering them "could have been done" in a method that was less aggressive to the point being made (and therefore less confusion to the person LOOKING FOR ANSWERS".  

                    Don't get me wrong, the banter and comments all have value and are opportunity to learn more about APRS in general and APRSISce/32 specifically.  I know I have learned more from those points.

                    BUT the points need to be made without confusion about the original message's question or request for assistance.

                    Robert Giuliano
                    KB8RCO


                    ---------------------------------------------


                    From: James Ewen <ve6srv@...>
                    To: aprsisce@yahoogroups.com
                    Sent: Sunday, September 22, 2013 4:12 PM
                    Subject: Re: [aprsisce] RE: Problem with sending message via RF

                     
                    On Sun, Sep 22, 2013 at 1:48 PM, Rob Giuliano <kb8rco@...> wrote:

                    > I don't have full original message, but the point (as I read it) was EVEN WITH "force RF"
                    > enabled, a user "should" keep APRS-IS messages enabled (don't disable it) because
                    > "if you lose the RF by the other station leaving your range", you still have the IS system
                    > (or IS-> RF from another I-Gate.
                    >
                    > That is STILL good advice so the message gets to them.
                    > Disabling APRS-IS messages when forced RF is check reduces your options,
                    > especially if IGATE access is limited in the area.

                    Yes, your options are reduced IF you have internet access. If you are
                    where there are no i-gates, and you have internet connectivity turned
                    off, then you would simply lose the QSO when the other station moves
                    out of RF range.

                    The point was that there were assumptions being made with the original
                    statement... it was assumed that there were no i-gates in the area,
                    and that the user HAD access to the internet. To "simply lose the QSO"
                    when a station moves out of local RF range requires all internet
                    access (both internal and provided by others) to be non-existent.

                    BTW, "local RF range" includes the whole area which an RF signal can
                    be heard, not only directly, but through ALL accessed digipeaters.

                    If you have internet access, and RF access, then allowing both methods
                    to be used to deliver a message is good advice, but losing
                    connectivity via one port does not necessarily cause the loss of
                    communications capability.

                    --
                    James
                    VE6SRV


                  • James Ewen
                    ... Correct, and making a statement that a QSO would be lost because internet connectivity was shut down was inaccurate. ... That was because there was a need
                    Message 9 of 28 , Sep 22, 2013
                      On Sun, Sep 22, 2013 at 2:36 PM, Rob Giuliano <kb8rco@...> wrote:

                      > But the MAIN POINT of the group MUST BE to provide CLARITY - SPECIFICALLY
                      > with respect to the answer to the question posed - without confusion.

                      Correct, and making a statement that a QSO would be lost because
                      internet connectivity was shut down was inaccurate.

                      > When I read your response to Lynn, had I been the person who posed the question,
                      > I could have been confused - SPECIFICALLY because the statement directly said the
                      > answer was "inaccurate", while quoting pretty much the whole answer.

                      That was because there was a need to provide context. Lynn had a
                      prescribed condition that was defined in the paragraph.

                      > Don't get me wrong, the banter and comments all have value and are
                      > opportunity to learn more about APRS in general and APRSISce/32
                      > specifically. I know I have learned more from those points.
                      >
                      > BUT the points need to be made without confusion about the original
                      > message's question or request for assistance.

                      Which I attempted to do by providing context, and pointing out that
                      the suggestion that one would "simply lose the QSO" was an inaccurate
                      observation.

                      Greg was having difficulty getting APRSISCE/32 to work in the manner
                      in which he wanted. If he could get APRSISCE/32 to use RF only, then
                      the status of his internet connectivity would not weigh on the ability
                      to be able to send and receive messages.

                      --
                      James
                      VE6SRV
                    • Bob Harris
                      I have vague recollection that somewhere someone passed on an app that would reset KPC-3 out of KISS mode (without diddling with control codes using the like
                      Message 10 of 28 , Sep 24, 2013
                        I have vague recollection that somewhere someone passed on an app that would reset KPC-3 out of KISS mode (without diddling with control codes using the like of Tera Term). Does anyone know about it? I may have to make a house call on Friday and get a KPC-3 back to some degree of normalcy. Since it is currently in KISS mode, getting it back to terminal mode will be the first step.

                        (I thought it might have been on Steven's website, but when I looked there this morning I couldn't find it)
                        --

                        BobHarris (K9UDX)
                        Can MOTCH Katmai Henry David Thoreau UDX Bda UD (1992-2005)
                        Longmeadow Bradford Torrey CD
                        Bath, NH

                      • Steve Daniels
                        At the bottom of the following link is software called online kiss+ which should do what you want http://www.dk3wn.info/software.shtml Not used it myself, just
                        Message 11 of 28 , Sep 24, 2013

                          At the bottom of the following link is software called online kiss+ which should do what you want

                           

                          http://www.dk3wn.info/software.shtml

                           

                          Not used it myself, just saw it the other day

                           

                          Steve Daniels

                          Amateur Radio Callsign G6UIM

                          Torbay Freecycle  Owner

                          http://uk.groups.yahoo.com/group/torbay_freecycle

                          APRSISCE/32 Beta tester and WIKI editor http://aprsisce.wikidot.com

                           


                          From: aprsisce@yahoogroups.com [mailto: aprsisce@yahoogroups.com ] On Behalf Of Bob Harris
                          Sent: 24 September 2013 15:08
                          To: aprsisce@yahoogroups.com
                          Subject: [aprsisce] Resetting KPC-3 TNCs

                           

                          I have vague recollection that somewhere someone passed on an app that would reset KPC-3 out of KISS mode (without diddling with control codes using the like of Tera Term). Does anyone know about it? I may have to make a house call on Friday and get a KPC-3 back to some degree of normalcy. Since it is currently in KISS mode, getting it back to terminal mode will be the first step.

                          (I thought it might have been on Steven's website, but when I looked there this morning I couldn't find it)

                          --

                          Bob Harris (K9UDX)
                          Can MOTCH Katmai Henry David Thoreau UDX Bda UD (1992-2005)
                          Longmeadow Bradford Torrey CD
                          Bath , NH

                        • Lee D Bengston
                          Last year I posted a link to download some perl scripts converted to binaries for Windows that can take a KPC-3 plus (or a KPC-9612 plus) in and out of KISS
                          Message 12 of 28 , Sep 24, 2013
                            Last year I posted a link to download some perl scripts converted to binaries for Windows that can take a KPC-3 plus (or a KPC-9612 plus) in and out of KISS mode, but I'm not sure if the commands are the same for a KPC-3.


                            Regards,
                            Lee - K5DAT



                            On Tue, Sep 24, 2013 at 10:08 AM, Bob Harris <knineudx@...> wrote:
                            I have vague recollection that somewhere someone passed on an app that would reset KPC-3 out of KISS mode (without diddling with control codes using the like of Tera Term). Does anyone know about it? I may have to make a house call on Friday and get a KPC-3 back to some degree of normalcy. Since it is currently in KISS mode, getting it back to terminal mode will be the first step.

                            (I thought it might have been on Steven's website, but when I looked there this morning I couldn't find it)
                            --

                            BobHarris (K9UDX)
                            Can MOTCH Katmai Henry David Thoreau UDX Bda UD (1992-2005)
                            Longmeadow Bradford Torrey CD
                            Bath, NH


                          • Steve
                            I think this may be what everyone is looking for and it is on Stephens web site http://wa8lmf.net/miscinfo/ and scroll down to this! TNC KISS_OFF.EXE
                            Message 13 of 28 , Sep 24, 2013
                              I think this may be what everyone is "looking" for and it is on Stephens web site


                              and scroll down to this!


                              73
                              Steve, kf6wax





                              On Tue, Sep 24, 2013 at 5:53 PM, Lee D Bengston <kilo5dat@...> wrote:
                               

                              Last year I posted a link to download some perl scripts converted to binaries for Windows that can take a KPC-3 plus (or a KPC-9612 plus) in and out of KISS mode, but I'm not sure if the commands are the same for a KPC-3.


                              Regards,
                              Lee - K5DAT



                              On Tue, Sep 24, 2013 at 10:08 AM, Bob Harris <knineudx@...> wrote:
                              I have vague recollection that somewhere someone passed on an app that would reset KPC-3 out of KISS mode (without diddling with control codes using the like of Tera Term). Does anyone know about it? I may have to make a house call on Friday and get a KPC-3 back to some degree of normalcy. Since it is currently in KISS mode, getting it back to terminal mode will be the first step.

                              (I thought it might have been on Steven's website, but when I looked there this morning I couldn't find it)
                              --

                              BobHarris (K9UDX)
                              Can MOTCH Katmai Henry David Thoreau UDX Bda UD (1992-2005)
                              Longmeadow Bradford Torrey CD
                              Bath, NH



                            • Bob Harris
                              Steve, That s it! I couldn t find it this morning when I looked (before putting my query on the list). Thanks everybody. ... -- Bob Harris (K9UDX) Bath, NH
                              Message 14 of 28 , Sep 24, 2013
                                Steve,

                                That's it! I couldn't find it this morning when I looked (before putting my query on the list).
                                Thanks everybody.

                                On 9/24/2013 9:00 PM, Steve wrote:
                                 
                                I think this may be what everyone is "looking" for and it is on Stephens web site


                                and scroll down to this!


                                73
                                Steve, kf6wax





                                On Tue, Sep 24, 2013 at 5:53 PM, Lee D Bengston <kilo5dat@...> wrote:
                                 
                                Last year I posted a link to download some perl scripts converted to binaries for Windows that can take a KPC-3 plus (or a KPC-9612 plus) in and out of KISS mode, but I'm not sure if the commands are the same for a KPC-3.


                                Regards,
                                Lee - K5DAT



                                On Tue, Sep 24, 2013 at 10:08 AM, Bob Harris <knineudx@...> wrote:
                                I have vague recollection that somewhere someone passed on an app that would reset KPC-3 out of KISS mode (without diddling with control codes using the like of Tera Term). Does anyone know about it? I may have to make a house call on Friday and get a KPC-3 back to some degree of normalcy. Since it is currently in KISS mode, getting it back to terminal mode will be the first step.

                                (I thought it might have been on Steven's website, but when I looked there this morning I couldn't find it)
                                --

                                Bob Harris (K9UDX)
                                Can MOTCH Katmai Henry David Thoreau UDX Bda UD (1992-2005)
                                Longmeadow Bradford Torrey CD
                                Bath, NH




                                --

                                Bob Harris (K9UDX)
                                Bath, NH

                              • Lee D Bengston
                                TNC KISS_OFF.EXE Compiled Quick Basic program to reset TNCs from KISS to normal command line mode. Because this is a
                                Message 15 of 28 , Sep 24, 2013

                                  TNC KISS_OFF.EXE

                                  Compiled Quick Basic program to reset TNCs from KISS to normal command line mode. Because this is a compiled DOS program, it is a 16-bit application.  It will run in versions of Windows up to WinXP SP3 but not later. (Vista and higher will not run programs that contain 16-bit code) Because this app is a legacy DOS program, it is limited to the first 4 com ports (COM1 to COM4).

                                  There's a kpc-kiss-off.exe file in the zip package below that doesn't have the limitations above.  There's a little setup program to run first just to tell it which com port (up to COM12) and what baud rate to use.  If you are using XP, the program above should be fine, however.


                                  Regards,
                                  Lee - K5DAT



                                  On Tue, Sep 24, 2013 at 9:00 PM, Steve <kf6wax@...> wrote:
                                   

                                  I think this may be what everyone is "looking" for and it is on Stephens web site


                                  and scroll down to this!


                                  73
                                  Steve, kf6wax





                                  On Tue, Sep 24, 2013 at 5:53 PM, Lee D Bengston <kilo5dat@...> wrote:
                                   

                                  Last year I posted a link to download some perl scripts converted to binaries for Windows that can take a KPC-3 plus (or a KPC-9612 plus) in and out of KISS mode, but I'm not sure if the commands are the same for a KPC-3.


                                  Regards,
                                  Lee - K5DAT



                                  On Tue, Sep 24, 2013 at 10:08 AM, Bob Harris <knineudx@...> wrote:
                                  I have vague recollection that somewhere someone passed on an app that would reset KPC-3 out of KISS mode (without diddling with control codes using the like of Tera Term). Does anyone know about it? I may have to make a house call on Friday and get a KPC-3 back to some degree of normalcy. Since it is currently in KISS mode, getting it back to terminal mode will be the first step.

                                  (I thought it might have been on Steven's website, but when I looked there this morning I couldn't find it)
                                  --

                                  BobHarris (K9UDX)
                                  Can MOTCH Katmai Henry David Thoreau UDX Bda UD (1992-2005)
                                  Longmeadow Bradford Torrey CD
                                  Bath, NH




                                • Bob Harris
                                  Thanks Lee. Perfect for my needs. Going into my toolbox. ... -- Bob Harris (K9UDX) Can MOTCH Katmai Henry David Thoreau UDX Bda UD (1992-2005) Longmeadow
                                  Message 16 of 28 , Sep 25, 2013
                                    Thanks Lee. Perfect for my needs. Going into my toolbox.

                                    On 9/24/2013 8:53 PM, Lee D Bengston wrote:
                                     
                                    Last year I posted a link to download some perl scripts converted to binaries for Windows that can take a KPC-3 plus (or a KPC-9612 plus) in and out of KISS mode, but I'm not sure if the commands are the same for a KPC-3.


                                    Regards,
                                    Lee - K5DAT



                                    On Tue, Sep 24, 2013 at 10:08 AM, Bob Harris <knineudx@...> wrote:
                                    I have vague recollection that somewhere someone passed on an app that would reset KPC-3 out of KISS mode (without diddling with control codes using the like of Tera Term). Does anyone know about it? I may have to make a house call on Friday and get a KPC-3 back to some degree of normalcy. Since it is currently in KISS mode, getting it back to terminal mode will be the first step.

                                    (I thought it might have been on Steven's website, but when I looked there this morning I couldn't find it)
                                    --

                                    Bob Harris (K9UDX)
                                    Can MOTCH Katmai Henry David Thoreau UDX Bda UD (1992-2005)
                                    Longmeadow Bradford Torrey CD
                                    Bath, NH



                                    --

                                    BobHarris (K9UDX)
                                    Can MOTCH Katmai Henry David Thoreau UDX Bda UD (1992-2005)
                                    Longmeadow Bradford Torrey CD
                                    Bath, NH

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