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

Re: Delayed digipeats

Expand Messages
  • asbjorn.hauge
    ... Oops and I m sorry. Just got the impression that more people were involved in this while reading messages in this group. ... Then I have to make a video or
    Message 1 of 14 , Mar 11, 2013
    • 0 Attachment
      --- In aprsisce@yahoogroups.com, James Ewen <ve6srv@...> wrote:

      > Remove the "s" from developers... it's just little old Lynn that developed
      > this program.

      Oops and I'm sorry. Just got the impression that more people were involved in this while reading messages in this group.


      > Can you provide some evidence of the 3 to 15 second delayed packet
      > digipeating?

      Then I have to make a video or something showing when the TNC is transmitting the packet. What is shown in the log does not correspond to what/when it puts out on the serial port.


      > > Port(PK-232):2013-03-10T23:09:47.796 Sent[55]:<C0 00 AC A0 A0 A0>ll<E0 98
      > 82>b<90 A6 82>r<98 82>b<90 A6 82 E4 AE 92 88 8A>b@<E0 AE 92 88 8A>d@e<03

      [snipped code]

      > > You see that I receive a beacon from my -9 station. My computer then
      > > generates a new packet for this some 600ms later (and that in a strange
      > > format).
      >
      > So that's a 600 millisecond delay. That's much less than the 3 to 15 second
      > delay that you say happens on "everything I digipeat". This is a normal
      > function of how a fill-in digipeater SHOULD work. Fill-in digipeaters are
      > supposed to be set up so that low powered HTs and other low powered devices
      > get a boost into a main digipeater. The area where the fill-in digipeater
      > is located should have good RX from the main digipeaters, and the only
      > reason one should be asking for help from it is that they can not be heard
      > by the main digipeater.
      >
      > Main digipeaters by design should key up immediately upon reception of a
      > packet. There should be no delays according to the APRS specification. All
      > other stations (including fill-in digipeaters) should listen for the
      > channel to be clear, and then wait a random amount of time (for collision
      > avoidance) before keying up. This delay allow the main digipeaters to have
      > priority access to the channel, moving packets heard quickly around the
      > network before loading up more packets.

      Yes and that is what I thought was the case here, but the problem is that the channel is clear for several seconds before my fill-in responds.
      If I set my radios to 144.825 where there's no traffic, my fill-in will digipeat my handheld's beacon after 3-6 seconds, but the logs will show immediate processing.

      This makes me think that the program does everything right, but the problem lies in the communication to the TNC. The same serial setup works perfectly with UI-View, so I don't think that's the problem, but could the transmit string to the TNC be a problem? If you look at it, it contains a combination of hex codes and ASCII. The TNC is in KISS-mode at 9600 baud, direct serial connection.

      > The interesting thing that is happening is that LD1OG and LD2RK are
      > handling the packet twice. If they are running proper configurations
      > according to the APRS specification, you should not see them handling the
      > packets that were digipeated by your station since they have already
      > handled the packetsonce each previously.

      I can try to inform the sysops about that, they are indeed very transmit-happy.


      > From the information provided, it is working properly. If you can provide
      > other information that shows the 3 to 15 second delays, then we can look at
      > those packets to see if there are any reasons for the delays.

      Thank you for a proper and thourough answer! I will try to provide more info and perhaps a video to show the problem visually.
      To wrap it up: When the program logs a send-command, it doesn't actually send it before some seconds later.

      --
      LA1HSA
      Asbjørn
    • James Ewen
      ... Hmm, that s a different can of worms... We can t see that happening from the raw packets. ... That s wierd... ... It shouldn t affect it, but something
      Message 2 of 14 , Mar 11, 2013
      • 0 Attachment
        On Mon, Mar 11, 2013 at 2:34 AM, asbjorn.hauge <asbjorn.hauge@...> wrote:

        >> Can you provide some evidence of the 3 to 15 second delayed packet
        >> digipeating?
        >
        > Then I have to make a video or something showing when the TNC is transmitting
        > the packet. What is shown in the log does not correspond to what/when it puts out on the serial port.

        Hmm, that's a different can of worms...

        We can't see that happening from the raw packets.

        > If I set my radios to 144.825 where there's no traffic, my fill-in will digipeat my
        > handheld's beacon after 3-6 seconds, but the logs will show immediate processing.

        That's wierd...

        > This makes me think that the program does everything right, but the problem lies
        > in the communication to the TNC. The same serial setup works perfectly with UI-View,
        > so I don't think that's the problem, but could the transmit string to the TNC be a problem?

        It shouldn't affect it, but something different is happening.

        > If you look at it, it contains a combination of hex codes and ASCII. The TNC is
        > in KISS-mode at 9600 baud, direct serial connection.

        I don't play in KISS mode a whole lot, perhaps Lynn can tell us if
        that looks right.

        --
        James
        VE6SRV
      • asbjorn.hauge
        ... I ll see if I can arrange a video of it. Will be tricky showing the TNC and the program at the same time. ... Lynn, do you have any ideas or suggestions to
        Message 3 of 14 , Mar 18, 2013
        • 0 Attachment
          --- In aprsisce@yahoogroups.com, James Ewen <ve6srv@...> wrote:
          >
          > On Mon, Mar 11, 2013 at 2:34 AM, asbjorn.hauge <asbjorn.hauge@...> wrote:
          >
          > >> Can you provide some evidence of the 3 to 15 second delayed packet
          > >> digipeating?
          > >
          > > Then I have to make a video or something showing when the TNC is transmitting
          > > the packet. What is shown in the log does not correspond to what/when it puts out on the serial port.
          >
          > Hmm, that's a different can of worms...
          >
          > We can't see that happening from the raw packets.

          I'll see if I can arrange a video of it. Will be tricky showing the TNC and the program at the same time.

          > > If you look at it, it contains a combination of hex codes and ASCII. The TNC is
          > > in KISS-mode at 9600 baud, direct serial connection.
          >
          > I don't play in KISS mode a whole lot, perhaps Lynn can tell us if
          > that looks right.

          Lynn, do you have any ideas or suggestions to this problem?

          My station had digipeater-duty during an event this weekend (on alternative frequency) and I was the only digi. Incoming packets were delayed a few seconds (on a clear frequency). My own beacons or objects are sent instantly, so it only affects digipeating. Trace logs show instant digipeating, but it delays before sending it to the RS232 port.

          I am out of clues right now and any help will be appreciated.

          --
          Asbjørn
          LA1HSA
        • Rob Giuliano
          Are you sure this is not related to your SlotTime and Persist settings? Since it seems to be better when transmitting directly (vs digi), this may ave some
          Message 4 of 14 , Mar 18, 2013
          • 0 Attachment
            Are you sure this is not related to your "SlotTime" and "Persist" settings?
             
            Since it seems to be better when transmitting directly (vs digi), this may ave some impact.
             
            Beacon -> channel may have been "free" for some time and the transmit "just happens".
             
            DIGI -> channel "WAS" just active with the data you received
               SlotTime and Persist are used to improve the chances of a clear transmission. 
              
             
            Try changing these for the TNC in use and see if that changes your delay.
             
            Robert Giuliano
            KB8RCO


            ---------------------------------------------
            From: asbjorn.hauge <asbjorn.hauge@...>
            To: aprsisce@yahoogroups.com
            Sent: Monday, March 18, 2013 5:48 AM
            Subject: [aprsisce] Re: Delayed digipeats
             


            --- In mailto:aprsisce%40yahoogroups.com, James Ewen <ve6srv@...> wrote:
            >
            > On Mon, Mar 11, 2013 at 2:34 AM, asbjorn.hauge <asbjorn.hauge@...> wrote:
            >
            > >> Can you provide some evidence of the 3 to 15 second delayed packet
            > >> digipeating?
            > >
            > > Then I have to make a video or something showing when the TNC is transmitting
            > > the packet. What is shown in the log does not correspond to what/when it puts out on the serial port.
            >
            > Hmm, that's a different can of worms...
            >
            > We can't see that happening from the raw packets.

            I'll see if I can arrange a video of it. Will be tricky showing the TNC and the program at the same time.

            > > If you look at it, it contains a combination of hex codes and ASCII. The TNC is
            > > in KISS-mode at 9600 baud, direct serial connection.
            >
            > I don't play in KISS mode a whole lot, perhaps Lynn can tell us if
            > that looks right.

            Lynn, do you have any ideas or suggestions to this problem?

            My station had digipeater-duty during an event this weekend (on alternative frequency) and I was the only digi. Incoming packets were delayed a few seconds (on a clear frequency). My own beacons or objects are sent instantly, so it only affects digipeating. Trace logs show instant digipeating, but it delays before sending it to the RS232 port.

            I am out of clues right now and any help will be appreciated.

            --
            Asbjørn
            LA1HSA

          • asbjorn.hauge
            ... That may just be the answer! I will check that when I get home. I didn t think those parameters were affected when the TNC is in KISS-mode, but apparently
            Message 5 of 14 , Mar 18, 2013
            • 0 Attachment
              --- In aprsisce@yahoogroups.com, Rob Giuliano <kb8rco@...> wrote:
              >
              > Are you sure this is not related to your "SlotTime" and "Persist" settings?

              That may just be the answer! I will check that when I get home. I didn't think those parameters were affected when the TNC is in KISS-mode, but apparently they are.
              I will see what it's set at and try changing the KISS initialization in APRSIS32.


              > Since it seems to be better when transmitting directly (vs digi), this may ave some impact.
              >
              > Beacon -> channel may have been "free" for some time and the transmit "just happens".
              >
              > DIGI -> channel "WAS" just active with the data you received
              >    SlotTime and Persist are used to improve the chances of a clear transmission. 
              >   
              >
              > Try changing these for the TNC in use and see if that changes your delay.

              I will do. Thanks for the tip :) Will report back when I have a result.

              --
              Asbjoern
              LA1HSA
            • James Ewen
              ... 3 to 15 seconds seems awfully long for slottime and persist. If persist were set very low, then the odds of it being hit are pretty slim, and if slottime
              Message 6 of 14 , Mar 18, 2013
              • 0 Attachment
                On Mon, Mar 18, 2013 at 8:52 AM, asbjorn.hauge <asbjorn.hauge@...> wrote:

                > --- In aprsisce@yahoogroups.com, Rob Giuliano <kb8rco@...> wrote:
                >>
                >> Are you sure this is not related to your "SlotTime" and "Persist" settings?
                >
                > That may just be the answer! I will check that when I get home.

                3 to 15 seconds seems awfully long for slottime and persist.

                If persist were set very low, then the odds of it being hit are pretty
                slim, and if slottime were very high you could wait a long time
                between random checks.... I suppose it is possible.

                --
                James
                VE6SRV
              • asbjorn.hauge
                ... I checked and reconfigured the TNC, but didn t solve any problems. Slottime set to 0 (was 300ms) Persist set to 0 (just to be sure. It was 63) PPersist set
                Message 7 of 14 , Mar 18, 2013
                • 0 Attachment
                  --- In aprsisce@yahoogroups.com, James Ewen <ve6srv@...> wrote:

                  > 3 to 15 seconds seems awfully long for slottime and persist.
                  >
                  > If persist were set very low, then the odds of it being hit are pretty
                  > slim, and if slottime were very high you could wait a long time
                  > between random checks.... I suppose it is possible.

                  I checked and reconfigured the TNC, but didn't solve any problems.
                  Slottime set to 0 (was 300ms)
                  Persist set to 0 (just to be sure. It was 63)
                  PPersist set to off
                  DWait set to 0
                  Ackprior is off (not sure if it matters)

                  I installed a serial port sniffer to see what and when data was sent and received. APRSIS32 responds quickly and the packet is verified sent over RS232 about 600ms after it was received. So, the problem lies within the TNC.

                  Does anyone have a known working init script for PK-232? Seems like mine is not quite perfect, but it's adopted from UI-View which doesn't have this problem.

                  --
                  Asbjoern
                  LA1HSA
                • Lynn W Deffenbaugh (Mr)
                  ... UI-View may send some additional timing parameters in the KISS protocol during port initialization. APRSISCE/32 assumes these have all been done by
                  Message 8 of 14 , Mar 18, 2013
                  • 0 Attachment
                    On 3/18/2013 6:09 PM, asbjorn.hauge wrote:
                    > Does anyone have a known working init script for PK-232? Seems like mine is not quite perfect, but it's adopted from UI-View which doesn't have this problem.

                    UI-View may send some additional timing parameters in the KISS protocol
                    during port initialization. APRSISCE/32 assumes these have all been
                    done by configuration commands and not via the KISS set commands.

                    Does anyone know this detail about UI-View? Or can someone capture the
                    actual KISS packets from an RS-232 sniffer during both UI-View and
                    APRSISCE/32 KISS port startup? The packets of interest would be the
                    first set of packets wrapped in <C0>...<C0> KISS delimiters, not the
                    ASCII port commands just prior to commanding KISS mode to start.

                    Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
                  • asbjorn.hauge
                    ... Thank you for the response, Lynn. I can t see any other controls before it enters KISS-mode, at least not in my captures. ... I have made captures from
                    Message 9 of 14 , Mar 18, 2013
                    • 0 Attachment
                      --- In aprsisce@yahoogroups.com, "Lynn W Deffenbaugh (Mr)" <kj4erj@...> wrote:
                      >
                      > On 3/18/2013 6:09 PM, asbjorn.hauge wrote:
                      > > Does anyone have a known working init script for PK-232? Seems like mine is not quite perfect, but it's adopted from UI-View which doesn't have this problem.
                      >
                      > UI-View may send some additional timing parameters in the KISS protocol
                      > during port initialization. APRSISCE/32 assumes these have all been
                      > done by configuration commands and not via the KISS set commands.

                      Thank you for the response, Lynn.

                      I can't see any other controls before it enters KISS-mode, at least not in my captures.

                      > Does anyone know this detail about UI-View? Or can someone capture the
                      > actual KISS packets from an RS-232 sniffer during both UI-View and
                      > APRSISCE/32 KISS port startup? The packets of interest would be the
                      > first set of packets wrapped in <C0>...<C0> KISS delimiters, not the
                      > ASCII port commands just prior to commanding KISS mode to start.

                      I have made captures from both UI-VIew and APRSISCE/32. Capture is running while I start the program and all inits are done. The result would be cluttered in a post here, so I'm posting links to both text files (hope those links are allowed here).

                      UI-View init: http://la1hsa.com/digi/UI-View_init.txt
                      APRSISCE/32 init: http://la1hsa.com/digi/APRSIS32_init.txt

                      There are some overhead in those files, but removing the header would mess up the formatting.
                      From what I see in the APRSISCE/32-file, I have a constant data flow, but that is "control parameters" and warnings from the capture program. The logs should be colour-coded to show TX/RX (and they are here). If you want, I can post them in RTF to make you able to see the difference.

                      If there is any other way you want me to capture data, just tell me and I'll do my best.


                      --
                      Asbjoern
                      LA1HSA
                    • James Ewen
                      On Mon, Mar 18, 2013 at 4:09 PM, asbjorn.hauge wrote: Do you have a user manual for your TNC? I only have the KPC-3 manual which
                      Message 10 of 14 , Mar 18, 2013
                      • 0 Attachment
                        On Mon, Mar 18, 2013 at 4:09 PM, asbjorn.hauge <asbjorn.hauge@...> wrote:

                        Do you have a user manual for your TNC? I only have the KPC-3 manual
                        which describes the settings as it pertains to that device, but they
                        should be similar.

                        > I checked and reconfigured the TNC, but didn't solve any problems.

                        > Slottime set to 0 (was 300ms)

                        Slottime sets how long the TNC should wait before checking to see if
                        it should try to gain access to the channel.

                        > Persist set to 0 (just to be sure. It was 63)

                        Persist controls the "odds" of whether the channel should be checked or not.

                        These two combined determine when to try sending a packet. The unit
                        waits the desired slottime, then the unit picks a random number
                        between 0 and 255. If that random number is less than persist, the
                        radio keys up, otherwise it goes back to the top waiting for slottime
                        to expire. With persist set at 0, it's pretty hard to get a random
                        number less than zero.


                        > PPersist set to off
                        > DWait set to 0

                        Dwait is the other way to hold off... check that manual.

                        > Ackprior is off (not sure if it matters)

                        Dunno...
                        --
                        James
                        VE6SRV
                      • Rob Giuliano
                        I was reading somewhere that there is an implementation where the use is reversed. That was what prompted the thought. Robert Giuliano KB8RCO ... From: James
                        Message 11 of 14 , Mar 18, 2013
                        • 0 Attachment
                          I was reading somewhere that there is an implementation where the use is reversed.
                          That was what prompted the thought.
                           
                          Robert Giuliano
                          KB8RCO


                          ---------------------------------------------
                          From: James Ewen <ve6srv@...>
                          To: aprsisce@yahoogroups.com
                          Sent: Monday, March 18, 2013 5:12 PM
                          Subject: Re: [aprsisce] Re: Delayed digipeats
                           
                          On Mon, Mar 18, 2013 at 8:52 AM, asbjorn.hauge <mailto:asbjorn.hauge%40yahoo.no> wrote:

                          > --- In mailto:aprsisce%40yahoogroups.com, Rob Giuliano <kb8rco@...> wrote:
                          >>
                          >> Are you sure this is not related to your "SlotTime" and "Persist" settings?
                          >
                          > That may just be the answer! I will check that when I get home.

                          3 to 15 seconds seems awfully long for slottime and persist.

                          If persist were set very low, then the odds of it being hit are pretty
                          slim, and if slottime were very high you could wait a long time
                          between random checks.... I suppose it is possible.

                          --
                          James
                          VE6SRV
                        • asbjorn.hauge
                          ... Yes I have the manual. I ve checked out every parameter and tried out settings for everything that is related to KISS-mode. It works, but it s slow. Just
                          Message 12 of 14 , Mar 21, 2013
                          • 0 Attachment
                            --- In aprsisce@yahoogroups.com, James Ewen <ve6srv@...> wrote:

                            > Do you have a user manual for your TNC? I only have the KPC-3 manual
                            > which describes the settings as it pertains to that device, but they
                            > should be similar.

                            Yes I have the manual. I've checked out every parameter and tried out settings for everything that is related to KISS-mode. It works, but it's slow.

                            Just to try out other possibilities: I have configured my TinyTrak4 to work in KISS, hooked it up and set APRSISCE/32 to use that one. It all works fairly well and all received packets are transferred to the software blazing fast (running 57600 baud). I still have a fair bit of delay using this setup (never less than three seconds from a free channel), while the same TNC config in UI-View is super-snappy (instant digipeat if channel is clear).

                            From the logs I posted earlier, I see that APRSISCE/32 adds some strange traffic to the RS232-port and logs sent strings as mostly HEX data. Could it be the way the program sends data or handles the COM-port? I will try running it on another computer and different serial port just for comparison.

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