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

Problem with sending message via RF

Expand Messages
  • g.isringhaus
    I am having problems with sending messages via RF. I can send someone one message at it triggers the radio and sends it just fine. I check on aprs.fi and I am
    Message 1 of 28 , Sep 20, 2013
    • 0 Attachment

      I am having problems with sending messages via RF.  I can send someone one message at it triggers the radio and sends it just fine.  I check on aprs.fi and I am getting an ack.  I get a "2" for tries and seems to be like normal.  But when I try to send another message after that it seems to not go out at all.  It will show like it is trying, but it is not triggering my radio at all.  I am using AGWPE with APRSIS32.  Everything else seems fine, beacons and the such.  I have my APRS-IS configuration set to where everything is unchecked except for "Enabled" and "Xmit Enable".  I don't really want to send any packets out via the IS, RF only.  For my port to AGW I have everything checked except for "RF to IS" "IS to RF" "Me not 3rd" and "GPS/NMEA".  RF Baud is set at 1200 and Quiet Time is set to "0".  Any ideas why it would send the first packet out and seem to get an ack and not send out any others to that person?  I have tried this with two APRS callsings and same result. 

       

      Thanks in advance.

       

      Greg..

    • James Ewen
      Some APRS applications will hold onto your multiline messages until an ACK is seen for each line in turn. If you send: Message Line 1 Message Line 2 and
      Message 2 of 28 , Sep 20, 2013
      • 0 Attachment
        Some APRS applications will hold onto your multiline messages until an ACK is seen for each line in turn.

        If you send:

        Message Line 1
        Message Line 2

        and APRSISCE/32 doesn't see the ACK for line 1, it will never attempt to send line 2. You can go into the queue and delete line 1, and then line 2 will go out. Or, you can uncheck the ACK checkbox, and APRSISCE/32 will send line after line without needing to see and ACK back.

        When connected to the APRS-IS directly, ACKs are pretty much guaranteed, but via RF only, it can take a bit to get a successful ACK back, especially in a less that reliable network that most heavily populated areas have.

        When I am working with messaging to my digipeaters via RF, I have to uncheck the ACK box to be able to work without having to delete messages manually. You don't always get ACKS gated back, but I see the response from the digipeater, so I know that I got through.




        On Fri, Sep 20, 2013 at 8:24 PM, <g.isringhaus@...> wrote:


        I am having problems with sending messages via RF.  I can send someone one message at it triggers the radio and sends it just fine.  I check on aprs.fi and I am getting an ack.  I get a "2" for tries and seems to be like normal.  But when I try to send another message after that it seems to not go out at all.  It will show like it is trying, but it is not triggering my radio at all.  I am using AGWPE with APRSIS32.  Everything else seems fine, beacons and the such.  I have my APRS-IS configuration set to where everything is unchecked except for "Enabled" and "Xmit Enable".  I don't really want to send any packets out via the IS, RF only.  For my port to AGW I have everything checked except for "RF to IS" "IS to RF" "Me not 3rd" and "GPS/NMEA".  RF Baud is set at 1200 and Quiet Time is set to "0".  Any ideas why it would send the first packet out and seem to get an ack and not send out any others to that person?  I have tried this with two APRS callsings and same result. 

         

        Thanks in advance.

         

        Greg..






        --
        James
        VE6SRV
      • g.isringhaus
        I am still connected to the IS, but just on receive only. So I can either get acks back via RF or IS. Also I am about 100% positive that I am getting an ack
        Message 3 of 28 , Sep 20, 2013
        • 0 Attachment

           I am still connected to the IS, but just on receive only.  So I can either get acks back via RF or IS.  Also I am about 100% positive that I am getting an ack back because it makes it on the first attempt and then moves to the next line, but a packet never goes out.  And then the number goes 2,3,4,5,6 attempts but it is not triggering RF.



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

          Some APRS applications will hold onto your multiline messages until an ACK is seen for each line in turn.

          If you send:

          Message Line 1
          Message Line 2

          and APRSISCE/32 doesn't see the ACK for line 1, it will never attempt to send line 2. You can go into the queue and delete line 1, and then line 2 will go out. Or, you can uncheck the ACK checkbox, and APRSISCE/32 will send line after line without needing to see and ACK back.

          When connected to the APRS-IS directly, ACKs are pretty much guaranteed, but via RF only, it can take a bit to get a successful ACK back, especially in a less that reliable network that most heavily populated areas have.

          When I am working with messaging to my digipeaters via RF, I have to uncheck the ACK box to be able to work without having to delete messages manually. You don't always get ACKS gated back, but I see the response from the digipeater, so I know that I got through.




          On Fri, Sep 20, 2013 at 8:24 PM, <g.isringhaus@...> wrote:


          I am having problems with sending messages via RF.  I can send someone one message at it triggers the radio and sends it just fine.  I check on aprs.fi and I am getting an ack.  I get a "2" for tries and seems to be like normal.  But when I try to send another message after that it seems to not go out at all.  It will show like it is trying, but it is not triggering my radio at all.  I am using AGWPE with APRSIS32.  Everything else seems fine, beacons and the such.  I have my APRS-IS configuration set to where everything is unchecked except for "Enabled" and "Xmit Enable".  I don't really want to send any packets out via the IS, RF only.  For my port to AGW I have everything checked except for "RF to IS" "IS to RF" "Me not 3rd" and "GPS/NMEA".  RF Baud is set at 1200 and Quiet Time is set to "0".  Any ideas why it would send the first packet out and seem to get an ack and not send out any others to that person?  I have tried this with two APRS callsings and same result. 

           

          Thanks in advance.

           

          Greg..






          --
          James
          VE6SRV
        • Greg Depew
          Greg KB3KBR Sent from my Verizon Wireless BlackBerry ... From: goatherder_4891@hotmail.com Date: Sat, 21 Sep 2013 02:59:51 To:
          Message 4 of 28 , Sep 20, 2013
          • 0 Attachment
            Greg KB3KBR Sent from my Verizon Wireless BlackBerry

            -----Original Message-----
            From: goatherder_4891@...
            Date: Sat, 21 Sep 2013 02:59:51
            To: <g.isringhaus@...>
            Reply-To: goatherder_4891@...
            Subject: Re: [aprsisce] RE: Problem with sending message via RF

            I'm pretty sure that if you have Best checked it will xmit both RF and IS unless you have IS disabled. But if it rx's an ack by IS it will try the next msg via IS and if its disabled it won't go out.
            Greg KB3KBR Sent from my Verizon Wireless BlackBerry

            -----Original Message-----
            From: g.isringhaus@...
            Date: Sat, 21 Sep 2013 02:55:17
            To: <aprsisce@yahoogroups.com>
            Subject: [aprsisce] RE: Problem with sending message via RF

             




             I am still connected to the IS, but just on receive only.  So I can either get acks back via RF or IS.  Also I am about 100% positive that I am getting an ack back because it makes it on the first attempt and then moves to the next line, but a packet never goes out.  And then the number goes 2,3,4,5,6 attempts but it is not triggering RF.


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



            Some APRS applications will hold onto your multiline messages until an ACK is seen for each line in turn.


            If you send:


            Message Line 1
            Message Line 2


            and APRSISCE/32 doesn't see the ACK for line 1, it will never attempt to send line 2. You can go into the queue and delete line 1, and then line 2 will go out. Or, you can uncheck the ACK checkbox, and APRSISCE/32 will send line after line without needing to see and ACK back.


            When connected to the APRS-IS directly, ACKs are pretty much guaranteed, but via RF only, it can take a bit to get a successful ACK back, especially in a less that reliable network that most heavily populated areas have.


            When I am working with messaging to my digipeaters via RF, I have to uncheck the ACK box to be able to work without having to delete messages manually. You don't always get ACKS gated back, but I see the response from the digipeater, so I know that I got through.







            On Fri, Sep 20, 2013 at 8:24 PM, <g.isringhaus@... <mailto:g.isringhaus@...> > wrote:




            I am having problems with sending messages via RF.  I can send someone one message at it triggers the radio and sends it just fine.  I check on aprs.fi <http://aprs.fi> and I am getting an ack.  I get a "2" for tries and seems to be like normal.  But when I try to send another message after that it seems to not go out at all.  It will show like it is trying, but it is not triggering my radio at all.  I am using AGWPE with APRSIS32.  Everything else seems fine, beacons and the such.  I have my APRS-IS configuration set to where everything is unchecked except for "Enabled" and "Xmit Enable".  I don't really want to send any packets out via the IS, RF only.  For my port to AGW I have everything checked except for "RF to IS" "IS to RF" "Me not 3rd" and "GPS/NMEA".  RF Baud is set at 1200 and Quiet Time is set to "0".  Any ideas why it would send the first packet out and seem to get an ack and not send out any others to that person?  I have tried this with two APRS callsings and same result. 
             
            Thanks in advance.
             
            Greg..






            --
            James
            VE6SRV
          • g.isringhaus
            I just tried to send another message after the last one failed at 9 attempts. Appears that APRSISCE is trying to send it out, as it goes 1,2,3,4,5,6 attempts
            Message 5 of 28 , Sep 20, 2013
            • 0 Attachment

                I just tried to send another message after the last one failed at 9 attempts.  Appears that APRSISCE is trying to send it out, as it goes 1,2,3,4,5,6 attempts and not triggering the RF port.



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

               I am still connected to the IS, but just on receive only.  So I can either get acks back via RF or IS.  Also I am about 100% positive that I am getting an ack back because it makes it on the first attempt and then moves to the next line, but a packet never goes out.  And then the number goes 2,3,4,5,6 attempts but it is not triggering RF.



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

              Some APRS applications will hold onto your multiline messages until an ACK is seen for each line in turn.

              If you send:

              Message Line 1
              Message Line 2

              and APRSISCE/32 doesn't see the ACK for line 1, it will never attempt to send line 2. You can go into the queue and delete line 1, and then line 2 will go out. Or, you can uncheck the ACK checkbox, and APRSISCE/32 will send line after line without needing to see and ACK back.

              When connected to the APRS-IS directly, ACKs are pretty much guaranteed, but via RF only, it can take a bit to get a successful ACK back, especially in a less that reliable network that most heavily populated areas have.

              When I am working with messaging to my digipeaters via RF, I have to uncheck the ACK box to be able to work without having to delete messages manually. You don't always get ACKS gated back, but I see the response from the digipeater, so I know that I got through.




              On Fri, Sep 20, 2013 at 8:24 PM, <g.isringhaus@...> wrote:


              I am having problems with sending messages via RF.  I can send someone one message at it triggers the radio and sends it just fine.  I check on aprs.fi and I am getting an ack.  I get a "2" for tries and seems to be like normal.  But when I try to send another message after that it seems to not go out at all.  It will show like it is trying, but it is not triggering my radio at all.  I am using AGWPE with APRSIS32.  Everything else seems fine, beacons and the such.  I have my APRS-IS configuration set to where everything is unchecked except for "Enabled" and "Xmit Enable".  I don't really want to send any packets out via the IS, RF only.  For my port to AGW I have everything checked except for "RF to IS" "IS to RF" "Me not 3rd" and "GPS/NMEA".  RF Baud is set at 1200 and Quiet Time is set to "0".  Any ideas why it would send the first packet out and seem to get an ack and not send out any others to that person?  I have tried this with two APRS callsings and same result. 

               

              Thanks in advance.

               

              Greg..






              --
              James
              VE6SRV
            • g.isringhaus
              Lynn can you confirm? QUOTE: I m pretty sure that if you have Best checked it will xmit both RF and IS unless you have IS disabled. But if it rx s an ack by IS
              Message 6 of 28 , Sep 20, 2013
              • 0 Attachment

                 Lynn can you confirm?

                 

                QUOTE:  I'm pretty sure that if you have Best checked it will xmit both RF and IS unless you have IS disabled. But if it rx's an ack by IS it will try the next msg via IS and if its disabled it won't go out.
                Greg KB3KBR Sent from my Verizon Wireless BlackBerry

                 

                Is there a fix on your end that you can do so that I don't have to select RF only each time I want to send a message.  Seems like "Best" method is getting confused and should know that my I have the IS disabled for messaging.



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

                Greg KB3KBR Sent from my Verizon Wireless BlackBerry

                -----Original Message-----
                From: goatherder_4891@...
                Date: Sat, 21 Sep 2013 02:59:51
                To: <g.isringhaus@...>
                Reply-To: goatherder_4891@...
                Subject: Re: [aprsisce] RE: Problem with sending message via RF

                I'm pretty sure that if you have Best checked it will xmit both RF and IS unless you have IS disabled. But if it rx's an ack by IS it will try the next msg via IS and if its disabled it won't go out.
                Greg KB3KBR Sent from my Verizon Wireless BlackBerry

                -----Original Message-----
                From: g.isringhaus@...
                Date: Sat, 21 Sep 2013 02:55:17
                To: <aprsisce@yahoogroups.com>
                Subject: [aprsisce] RE: Problem with sending message via RF

                 




                 I am still connected to the IS, but just on receive only.  So I can either get acks back via RF or IS.  Also I am about 100% positive that I am getting an ack back because it makes it on the first attempt and then moves to the next line, but a packet never goes out.  And then the number goes 2,3,4,5,6 attempts but it is not triggering RF.


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



                Some APRS applications will hold onto your multiline messages until an ACK is seen for each line in turn.


                If you send:


                Message Line 1
                Message Line 2


                and APRSISCE/32 doesn't see the ACK for line 1, it will never attempt to send line 2. You can go into the queue and delete line 1, and then line 2 will go out. Or, you can uncheck the ACK checkbox, and APRSISCE/32 will send line after line without needing to see and ACK back.


                When connected to the APRS-IS directly, ACKs are pretty much guaranteed, but via RF only, it can take a bit to get a successful ACK back, especially in a less that reliable network that most heavily populated areas have.


                When I am working with messaging to my digipeaters via RF, I have to uncheck the ACK box to be able to work without having to delete messages manually. You don't always get ACKS gated back, but I see the response from the digipeater, so I know that I got through.







                On Fri, Sep 20, 2013 at 8:24 PM, <g.isringhaus@... <mailto:g.isringhaus@...> > wrote:




                I am having problems with sending messages via RF.  I can send someone one message at it triggers the radio and sends it just fine.  I check on aprs.fi <http://aprs.fi> and I am getting an ack.  I get a "2" for tries and seems to be like normal.  But when I try to send another message after that it seems to not go out at all.  It will show like it is trying, but it is not triggering my radio at all.  I am using AGWPE with APRSIS32.  Everything else seems fine, beacons and the such.  I have my APRS-IS configuration set to where everything is unchecked except for "Enabled" and "Xmit Enable".  I don't really want to send any packets out via the IS, RF only.  For my port to AGW I have everything checked except for "RF to IS" "IS to RF" "Me not 3rd" and "GPS/NMEA".  RF Baud is set at 1200 and Quiet Time is set to "0".  Any ideas why it would send the first packet out and seem to get an ack and not send out any others to that person?  I have tried this with two APRS callsings and same result. 
                 
                Thanks in advance.
                 
                Greg..






                --
                James
                VE6SRV
              • g.isringhaus
                Or is is maybe that it takes a little bit for APRSISCE to learn that the transmit is disabled on the IS. Because now it seems to be working. I think it is a
                Message 7 of 28 , Sep 20, 2013
                • 0 Attachment

                  Or is is maybe that it takes a little bit for APRSISCE to learn that the transmit is disabled on the IS.  Because now it seems to be working.  I think it is a slow learner.  Anyway, I'll let you know if it acts up again.



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

                   Lynn can you confirm?

                   

                  QUOTE:  I'm pretty sure that if you have Best checked it will xmit both RF and IS unless you have IS disabled. But if it rx's an ack by IS it will try the next msg via IS and if its disabled it won't go out.
                  Greg KB3KBR Sent from my Verizon Wireless BlackBerry

                   

                  Is there a fix on your end that you can do so that I don't have to select RF only each time I want to send a message.  Seems like "Best" method is getting confused and should know that my I have the IS disabled for messaging.



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

                  Greg KB3KBR Sent from my Verizon Wireless BlackBerry

                  -----Original Message-----
                  From: goatherder_4891@...
                  Date: Sat, 21 Sep 2013 02:59:51
                  To: <g.isringhaus@...>
                  Reply-To: goatherder_4891@...
                  Subject: Re: [aprsisce] RE: Problem with sending message via RF

                  I'm pretty sure that if you have Best checked it will xmit both RF and IS unless you have IS disabled. But if it rx's an ack by IS it will try the next msg via IS and if its disabled it won't go out.
                  Greg KB3KBR Sent from my Verizon Wireless BlackBerry

                  -----Original Message-----
                  From: g.isringhaus@...
                  Date: Sat, 21 Sep 2013 02:55:17
                  To: <aprsisce@yahoogroups.com>
                  Subject: [aprsisce] RE: Problem with sending message via RF

                   




                   I am still connected to the IS, but just on receive only.  So I can either get acks back via RF or IS.  Also I am about 100% positive that I am getting an ack back because it makes it on the first attempt and then moves to the next line, but a packet never goes out.  And then the number goes 2,3,4,5,6 attempts but it is not triggering RF.


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



                  Some APRS applications will hold onto your multiline messages until an ACK is seen for each line in turn.


                  If you send:


                  Message Line 1
                  Message Line 2


                  and APRSISCE/32 doesn't see the ACK for line 1, it will never attempt to send line 2. You can go into the queue and delete line 1, and then line 2 will go out. Or, you can uncheck the ACK checkbox, and APRSISCE/32 will send line after line without needing to see and ACK back.


                  When connected to the APRS-IS directly, ACKs are pretty much guaranteed, but via RF only, it can take a bit to get a successful ACK back, especially in a less that reliable network that most heavily populated areas have.


                  When I am working with messaging to my digipeaters via RF, I have to uncheck the ACK box to be able to work without having to delete messages manually. You don't always get ACKS gated back, but I see the response from the digipeater, so I know that I got through.







                  On Fri, Sep 20, 2013 at 8:24 PM, <g.isringhaus@... <mailto:g.isringhaus@...> > wrote:




                  I am having problems with sending messages via RF.  I can send someone one message at it triggers the radio and sends it just fine.  I check on aprs.fi <http://aprs.fi> and I am getting an ack.  I get a "2" for tries and seems to be like normal.  But when I try to send another message after that it seems to not go out at all.  It will show like it is trying, but it is not triggering my radio at all.  I am using AGWPE with APRSIS32.  Everything else seems fine, beacons and the such.  I have my APRS-IS configuration set to where everything is unchecked except for "Enabled" and "Xmit Enable".  I don't really want to send any packets out via the IS, RF only.  For my port to AGW I have everything checked except for "RF to IS" "IS to RF" "Me not 3rd" and "GPS/NMEA".  RF Baud is set at 1200 and Quiet Time is set to "0".  Any ideas why it would send the first packet out and seem to get an ack and not send out any others to that person?  I have tried this with two APRS callsings and same result. 
                   
                  Thanks in advance.
                   
                  Greg..






                  --
                  James
                  VE6SRV
                • Lynn W Deffenbaugh (Mr)
                  Are you sure that the ack is getting to APRSISCE/32? Or is your message pane (upper left of map) staying Yellow or Orange? Check Messages / Pending Messages
                  Message 8 of 28 , Sep 20, 2013
                  • 0 Attachment
                    Are you sure that the ack is getting to APRSISCE/32?  Or is your message pane (upper left of map) staying Yellow or Orange?  Check Messages / Pending Messages and I suspect you'll see that the first message is still waiting for an ack.  That should be the only thing that causes subsequent messages to wait because they're sent FIFO with an ack required before the next one will transmit.

                    Any hint as to why you don't have everything enabled on the APRS-IS port?  Especially Messages?  APRSISCE/32 is (semi-) intelligent about whether or not a message will be sent to RF, -IS, or both.  And you can still force it to RF Only directly in the Chat dialog.

                    Just because you see an ack in aprs.fi doesn't mean that ack got to your APRSISCE/32 instance.

                    Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

                    On 9/20/2013 10:24 PM, g.isringhaus@... wrote:

                    I am having problems with sending messages via RF.  I can send someone one message at it triggers the radio and sends it just fine.  I check on aprs.fi and I am getting an ack.  I get a "2" for tries and seems to be like normal.  But when I try to send another message after that it seems to not go out at all.  It will show like it is trying, but it is not triggering my radio at all.  I am using AGWPE with APRSIS32.  Everything else seems fine, beacons and the such.  I have my APRS-IS configuration set to where everything is unchecked except for "Enabled" and "Xmit Enable".  I don't really want to send any packets out via the IS, RF only.  For my port to AGW I have everything checked except for "RF to IS" "IS to RF" "Me not 3rd" and "GPS/NMEA".  RF Baud is set at 1200 and Quiet Time is set to "0".  Any ideas why it would send the first packet out and seem to get an ack and not send out any others to that person?  I have tried this with two APRS callsings and same result. 

                     

                    Thanks in advance.

                     

                    Greg..


                  • Lynn W Deffenbaugh (Mr)
                    You threatened it by asking the question so it decided to behave. Best means that if APRSISCE/32 has recently heard the station on RF, it will send to RF.
                    Message 9 of 28 , Sep 20, 2013
                    • 0 Attachment
                      You threatened it by asking the question so it decided to behave.

                      "Best" means that if APRSISCE/32 has "recently" heard the station on RF, it will send to RF.  It will ALWAYS send it to the APRS-IS (assuming you have Messages enabled, which you really should have).  If the station you're sending a message to is completely unknown, "Best" will send it out all available ports because it has no idea where the station is.

                      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.

                      Lynn (D) - KJ4ERJ -Author of APRSISCE for Windows Mobile and Win32

                      PS.  Another reason that the radio might not key up is that the TNC believes the channel is "busy".  APRSISCE/32 can only deliver packets to the TNC.  There's no handshaking to know if they were actually transmitted or not.  An enabled trace log on Port(<YourName>) can help you know if APRSISCE/32 is sending the data out that port or not.

                      On 9/20/2013 11:10 PM, g.isringhaus@... wrote:

                      Or is is maybe that it takes a little bit for APRSISCE to learn that the transmit is disabled on the IS.  Because now it seems to be working.  I think it is a slow learner.  Anyway, I'll let you know if it acts up again.



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

                       Lynn can you confirm?

                       

                      QUOTE:  I'm pretty sure that if you have Best checked it will xmit both RF and IS unless you have IS disabled. But if it rx's an ack by IS it will try the next msg via IS and if its disabled it won't go out.
                      Greg KB3KBR Sent from my Verizon Wireless BlackBerry

                       

                      Is there a fix on your end that you can do so that I don't have to select RF only each time I want to send a message.  Seems like "Best" method is getting confused and should know that my I have the IS disabled for messaging.



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

                      Greg KB3KBR Sent from my Verizon Wireless BlackBerry

                      -----Original Message-----
                      From: goatherder_4891@...
                      Date: Sat, 21 Sep 2013 02:59:51
                      To: <g.isringhaus@...>
                      Reply-To: goatherder_4891@...
                      Subject: Re: [aprsisce] RE: Problem with sending message via RF

                      I'm pretty sure that if you have Best checked it will xmit both RF and IS unless you have IS disabled. But if it rx's an ack by IS it will try the next msg via IS and if its disabled it won't go out.
                      Greg KB3KBR Sent from my Verizon Wireless BlackBerry

                      -----Original Message-----
                      From: g.isringhaus@...
                      Date: Sat, 21 Sep 2013 02:55:17
                      To: <aprsisce@yahoogroups.com>
                      Subject: [aprsisce] RE: Problem with sending message via RF

                       




                       I am still connected to the IS, but just on receive only.  So I can either get acks back via RF or IS.  Also I am about 100% positive that I am getting an ack back because it makes it on the first attempt and then moves to the next line, but a packet never goes out.  And then the number goes 2,3,4,5,6 attempts but it is not triggering RF.


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



                      Some APRS applications will hold onto your multiline messages until an ACK is seen for each line in turn.


                      If you send:


                      Message Line 1
                      Message Line 2


                      and APRSISCE/32 doesn't see the ACK for line 1, it will never attempt to send line 2. You can go into the queue and delete line 1, and then line 2 will go out. Or, you can uncheck the ACK checkbox, and APRSISCE/32 will send line after line without needing to see and ACK back.


                      When connected to the APRS-IS directly, ACKs are pretty much guaranteed, but via RF only, it can take a bit to get a successful ACK back, especially in a less that reliable network that most heavily populated areas have.


                      When I am working with messaging to my digipeaters via RF, I have to uncheck the ACK box to be able to work without having to delete messages manually. You don't always get ACKS gated back, but I see the response from the digipeater, so I know that I got through.







                      On Fri, Sep 20, 2013 at 8:24 PM, <g.isringhaus@... <mailto:g.isringhaus@...> > wrote:




                      I am having problems with sending messages via RF.  I can send someone one message at it triggers the radio and sends it just fine.  I check on aprs.fi <http://aprs.fi> and I am getting an ack.  I get a "2" for tries and seems to be like normal.  But when I try to send another message after that it seems to not go out at all.  It will show like it is trying, but it is not triggering my radio at all.  I am using AGWPE with APRSIS32.  Everything else seems fine, beacons and the such.  I have my APRS-IS configuration set to where everything is unchecked except for "Enabled" and "Xmit Enable".  I don't really want to send any packets out via the IS, RF only.  For my port to AGW I have everything checked except for "RF to IS" "IS to RF" "Me not 3rd" and "GPS/NMEA".  RF Baud is set at 1200 and Quiet Time is set to "0".  Any ideas why it would send the first packet out and seem to get an ack and not send out any others to that person?  I have tried this with two APRS callsings and same result. 
                       
                      Thanks in advance.
                       
                      Greg..






                      --
                      James
                      VE6SRV

                    • James Ewen
                      On Fri, Sep 20, 2013 at 10:01 PM, Lynn W Deffenbaugh (Mr) ... The above is an inaccurate observation. Hundreds of stations with RF only access successfully
                      Message 10 of 28 , Sep 20, 2013
                      • 0 Attachment
                        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
                      • Keith VE7GDH
                        Greg (callsign?) wrote... ... 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
                        Message 11 of 28 , Sep 21, 2013
                        • 0 Attachment
                          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!"
                        • g.isringhaus
                          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
                          Message 12 of 28 , Sep 21, 2013
                          • 0 Attachment

                            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!"
                          • 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 13 of 28 , Sep 21, 2013
                            • 0 Attachment

                               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 14 of 28 , Sep 21, 2013
                              • 0 Attachment
                                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 15 of 28 , Sep 21, 2013
                                • 0 Attachment
                                  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 16 of 28 , Sep 21, 2013
                                  • 0 Attachment

                                     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 17 of 28 , Sep 21, 2013
                                    • 0 Attachment

                                      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 18 of 28 , Sep 22, 2013
                                      • 0 Attachment
                                        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 19 of 28 , Sep 22, 2013
                                        • 0 Attachment
                                          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 20 of 28 , Sep 22, 2013
                                          • 0 Attachment
                                            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 21 of 28 , Sep 22, 2013
                                            • 0 Attachment
                                              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 22 of 28 , Sep 24, 2013
                                              • 0 Attachment
                                                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 23 of 28 , Sep 24, 2013
                                                • 0 Attachment

                                                  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 24 of 28 , Sep 24, 2013
                                                  • 0 Attachment
                                                    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 25 of 28 , Sep 24, 2013
                                                    • 0 Attachment
                                                      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 26 of 28 , Sep 24, 2013
                                                      • 0 Attachment
                                                        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 27 of 28 , Sep 24, 2013
                                                        • 0 Attachment

                                                          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 28 of 28 , Sep 25, 2013
                                                          • 0 Attachment
                                                            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.