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

Macro issues OT3m

Expand Messages
  • Jonathan Karras
    I am new to the OT3m and the scripting language. While attempting to make a macro I ran in to a problem. Wondering if I am doing something wrong or what. The
    Message 1 of 17 , Aug 16, 2014

      I am new to the OT3m and the scripting language. While attempting to make a macro I ran in to a problem. Wondering if I am doing something wrong or what.


      The macro I am attempting to create is to beacon the UNIT, PARM, and EQNS APRS messages. I created a siz line macro like below. When I run the macro only the last 2 lines get executed. If I remove the macro write (only there for debugging) only the last beacon gets executed. I never see packets for EQNS or PARM.


      Just wondering if I am doing something wrong or if its a bug.


      Hardware: OT3m

      Firmware: 56476


      Macro TELPARM
        Macro Write "EQNS"
        Exec "BEACON :KE7BAP-15:EQNS.0,.1,0,0,.1,0,0,.1,0,0,.1,0,0,.1,0"
        Macro Write "PARM"
        Exec "BEACON :KE7BAP-15:PARM.Voltage,Aux1,Aux2,Aux3,Aux4,,,,,,CFG,JMP"
        Macro Write "UNIT"
        Exec "BEACON :KE7BAP-15:UNIT.Vdc,,,,,,,,,,,CFG,JMP"

      End Block

    • James Ewen
      On Sat, Aug 16, 2014 at 3:17 PM, Jonathan Karras jkarras@karras.net ... Welcome to the fun world of scripting macros... they are a lot of fun to play with, and
      Message 2 of 17 , Aug 16, 2014
        On Sat, Aug 16, 2014 at 3:17 PM, Jonathan Karras jkarras@...
        [tracker2] <tracker2@yahoogroups.com> wrote:

        > I am new to the OT3m and the scripting language. While attempting to make a macro
        > I ran in to a problem. Wondering if I am doing something wrong or what.

        Welcome to the fun world of scripting macros... they are a lot of fun
        to play with, and you can get some pretty amazing functionality out of
        the unit via macros!

        I would venture to say that "Yes, you are doing something wrong!",
        otherwise why would you be asking? :) The fun part is figuring out
        what's wrong!

        > The macro I am attempting to create is to beacon the UNIT, PARM, and EQNS APRS
        > messages. I created a siz line macro like below. When I run the macro only the last 2
        > lines get executed. If I remove the macro write (only there for debugging) only the last
        > beacon gets executed. I never see packets for EQNS or PARM.
        >
        > Just wondering if I am doing something wrong or if its a bug.

        There are probably a bunch of things happening...

        One thing that's common on the OT line is when people try to send
        multiple packets in a row, you can lose packets. This is most likely
        because the OT doesn't sit and wait for the network to digipeat a
        packet before sending the next packet.

        Digipeaters are supposed to immediately grab the channel and digipeat
        what they heard. Users are supposed to listen to the channel, and wait
        a random amount of time before sending a packet to help avoid packet
        collisions. Two packets back to back can cause a collision on the RF
        network, three would be worse.

        Looking at your raw packets as seen via the APRS-IS stream, we can see
        that your packets always get handled by a digipeater before being
        heard by an i-gate. So, we can guess that maybe there's a collision
        thing happening. If you listen locally, or were in direct reception
        range of an i-gate, you might not see the collision issue. But, since
        you are playing on an RF network with digipeaters, you need to deal
        with the collision issue.


        > Macro TELPARM
        > Macro Write "EQNS"
        > Exec "BEACON :KE7BAP-15:EQNS.0,.1,0,0,.1,0,0,.1,0,0,.1,0,0,.1,0"
        > Macro Write "PARM"
        > Exec "BEACON :KE7BAP-15:PARM.Voltage,Aux1,Aux2,Aux3,Aux4,,,,,,CFG,JMP"
        > Macro Write "UNIT"
        > Exec "BEACON :KE7BAP-15:UNIT.Vdc,,,,,,,,,,,CFG,JMP"
        >
        > End Block

        Depending on how you call this macro, the output can be a bit
        different. Let's assume that you send a remote command to the unit via
        an APRS message, such as this:

        CMD TELPARM from KE7BAP

        The unit should send a message back to you that says EQNS
        Then it should beacon a packet containing
        :KE7BAP-15:EQNS.0,.1,0,0,.1,0,0,.1,0,0,.1,0,0,.1,0
        The unit should send a message back to you that says PARM
        Then it should beacon a packet containing
        :PARM.Voltage,Aux1,Aux2,Aux3,Aux4,,,,,,CFG,JMP
        The unit should send a message back to you that says UNIT
        Then it should beacon a packet containing :KE7BAP-15:UNIT.Vdc,,,,,,,,,,,CFG,JMP

        I don't see the Macro Write messages on the APRS-IS stream, so you
        must have more script and you are calling the macro from within the
        script, which should put the macro write message to the console (I
        think).

        :KE7BAP-15 :UNIT.Vdc,,,,,,,,,,,CFG,JMP [Unsupported packet format]
        ::KE7BAP-15 :UNIT.Vdc,,,,,,,,,,,CFG,JMP [Invalid message packet]

        I also see that you're playing with trying to get the message
        formatting figured out properly...

        You can skip that issue by letting the OT3 format the messages properly.

        Instead of using the BEACON command and trying to get the APRS message
        formatting proper:

        Exec "BEACON :KE7BAP-15:EQNS.0,.1,0,0,.1,0,0,.1,0,0,.1,0,0,.1,0"

        Try this

        EXEC "SEND KE7BAP-15 EQNS.0,.1,0,0,.1,0,0,.1,0,0,.1,0,0,.1,0"

        The OT3 will look after padding the callsign properly, and getting the
        colons in the right spot, etc.

        (In the raw packets from the APRS-IS above, it looks like you have a
        space after your callsign that shouldn't be there. Your sample script
        is correct with 9 characters, but the raw data shows a space after
        your callsign which makes it 10 characters, which does not conform to
        spec)

        So, using the SEND command will make getting the message format correct easier.

        How do we space out sending those messages?

        How about something like this?

        Macro TELPARM
        On Second
        Increment Counter 3
        If Counter 3 = 5
        Exec "SEND KE7BAP-15 EQNS.0,.1,0,0,.1,0,0,.1,0,0,.1,0,0,.1,0"
        End Block
        If Counter 3 = 10
        Exec "SEND KE7BAP-15 PARM.Voltage,Aux1,Aux2,Aux3,Aux4,,,,,,CFG,JMP"
        End Block
        If Counter 3 = 15
        Exec "SEND KE7BAP-15 UNIT.Vdc,,,,,,,,,,,CFG,JMP"
        Set Counter 3 = 0
        End Block
        End Block

        I haven't tested this... I'm not sure if the ON SECOND counter will
        only count up while the MACRO is running, or if it will run
        continuously, incrementing COUNTER 3... even if it does, the IF
        statements inside the MACRO shouldn't run...

        The concept is to send the three packets with a 5 second separation
        between them.

        Try fiddling with something like that and see if it works.

        Where are you sending these telemetry definitions? If it's just to
        make the labels for aprs.fi, you can simply send them once, and
        aprs.fi will store them just about forever.

        There's not much else out there that makes use of telemetry
        definitions. I think there's another site online that uses telemetry
        definitions. APRSISCE/32 collects and saves telemetry definitions, but
        it doesn't do anything with them. SarTrack might use them too... can't
        recall.

        When I started sending telemetry, I made a script that sent the
        telemetry definitions at a defined interval. All I found I was doing,
        was making lots of noise on RF for no reason. Now all I do is send the
        definitions once, and aprs.fi saves them forever. I look at the
        telemetry exclusively at aprs.fi as I have no other means of seeing
        it. aprs.fi saves my telemetry in its database and allows me to see my
        long term trends. I'd have to run a client here 24/7 and save the data
        into a database to get the same functionality... I'm lazy, I let Hessu
        do that for me, and use his site to view my data.

        --
        James
        VE6SRV
      • owenvk
        Digipeaters are supposed to immediately grab the channel and digipeat what they heard. I have noticed in my recent exploration of APRS that digis tend to
        Message 3 of 17 , Aug 16, 2014
          "Digipeaters are supposed to immediately grab the channel and digipeat what they heard."I have noticed in my recent exploration of APRS that digis tend to "immediately grab the channel", and I am sure some lightweight thinkers have put forward rationale for this... but for example, there are two WIDE digis on very prominent hills. both within 20km of my home and can be heard for hundreds of km... and when they both "immediately grab the channel", they interfere with each other and you are unlikely to decode either of them.It is one of the contibutions to low success rates in getting posits to a remote iGate that hears both digis.Owen
        • James Ewen
          From your recent posts on this forum, it looks like you re very new into APRS and and still have some very idealistic concepts about how this is all supposed
          Message 4 of 17 , Aug 16, 2014
            From your recent posts on this forum, it looks like you're very new
            into APRS and and still have some very idealistic concepts about how
            this is all supposed to work. I used to be just like you... give me a
            little while, and I'll try and beat this optimism out of you. If I
            succeed, I might be allowed to join the "club".

            On Sat, Aug 16, 2014 at 9:23 PM, owenvk@... [tracker2]
            <tracker2@yahoogroups.com> wrote:

            > "Digipeaters are supposed to immediately grab the channel and digipeat what
            > they heard."I have noticed in my recent exploration of APRS that digis tend to
            > "immediately grab the channel", and I am sure some lightweight thinkers have
            > put forward rationale for this...

            Well, the primary "lightweight thinker" behind this concept is Bob
            Bruninga WB4APR, the guy that invented APRS.

            Have a Google for APRS packet fratricide. Bob's concept is that
            neighbouring digipeaters are SUPPOSED to intentionally interfere with
            each other, and in doing so, they stop packets from propagating over
            large distances. It's a ridiculous idea, and to attempt to be able to
            make it work, you have to expend a great deal of time and effort to
            find locations for digipeaters that would allow such a concept to
            work.

            I've butted heads with Bob a number of times over basic concepts like
            this. I put forth a concept to Bob back in 2002 about dynamic
            digipeating that would limit the packets digipeated based on the
            number of packet digipeats being requested, and the distance of the
            source station. That was dismissed as being bad for APRS because of
            the "randomness and unpredictability" of the digipeating of packets.
            Yet this packet fratricide concept is deemed to be APRS nirvana.

            > but for example, there are two WIDE digis on very prominent hills. both within 20km of my
            > home and can be heard for hundreds of km... and when they both "immediately grab the
            > channel", they interfere with each other and you are unlikely to decode either of them.

            Hey, sounds familiar, huh? That's how APRS is "supposed to work".
            Packet fratricide is working perfectly.

            > It is one of the contibutions to low success rates in getting posits to a remote iGate that hears both digis.

            But, by design this is EXACTLY how the digipeater network is supposed
            to work. Bob's suggested solution is to put a yagi on the i-gate so
            that it receives one digipeater stronger than the other. By getting
            one signal stronger than the other by a large enough margin, the FM
            capture effect will allow for a successful packet decode.

            Your local digipeaters are not installed properly to be able to
            support digipeating in the APRS network. One or the other would need
            to be relocated so that you don't get the overlap where you see the
            collisions. Yes, that's a pain in the backside, and it is very
            difficult to find locations where you can get the digipeaters set up
            to provide unique coverage, yet still be able to talk to the
            neighboring digipeaters, and also have excellent RX/TX coverage where
            it can hear those low powered trackers and other stations, and be
            heard by them as well with minimal holes in the coverage.

            I've argued this point for over a decade, and it falls of deaf ears.
            We have built a digipeater network of over 30 digipeaters here in
            Alberta, and they don't follow the intentional interference concept.
            Our digipeaters wait for a clear channel. This means that packets take
            slightly longer to propagate through the network (They are only 2 or 3
            hops max), but the packets make it through the network reliably. We
            also support the SSn-N concept, and have tested using AB7-7 numerous
            times. I can reliably get 5 hops across the province. I can't get
            further because 5 hops crosses the whole network!

            --
            James
            VE6SRV
          • Jonathan Karras
            Thanks for the reply. I thought about using counters to space things out but based on the radio burst length and lack of write messages to my console (I am
            Message 5 of 17 , Aug 16, 2014
              Thanks for the reply.

              I thought about using counters to space things out but based on the radio burst length and lack of write messages to my console (I am calling the macro manually via serial) it really seems as though the scripting engine is only calling the last two unique commands. I have not tried stacking three of say a port A write, macro write, and execute. I have tried each of those individually. Even when it was just port writes it only called the last one.

              As a test I created the following macro

              Version 1
              Macro MTEST
                PrintA "mtest"
                PrintA "print1"
                PrintA "print2"
                PrintA "print3"
              End Block

              Version 2
              Macro MTEST
                PrintA "mtest"
                Macro Write "m mtest"
                PrintA "print1"
                Macro Write "m print1"
                PrintA "print2"
                Macro Write "m print2"
                PrintA "print3"
                Macro Write "m print3"
              End Block

              When running version 1 the only message that is printed is "mtest". When I run version 2 of the macro all I get is "m print3".

              Until three individual radio bursts are seen I don't think it is packet fratricide. Besides it would be messages 2 & 3 that would be clobbered by collisions not message 1.

              As for the use of the telemetry labels and such my hope is to use them with aprs.fi. I am aware that the site caches them for 1 year (but seems actually cache them for ever). My plan was to only beacon them on startup in case I change or add items the sites would get updated.

              Thanks for the hint on using send rather than beacon. Until I was messing around again I forgot that telemetry messages are a beacon and the labels are a message. Previously I just used netcat to inject the EQNS, PARM, and UNITS messages directly into APRS-IS. In my previous runs I was using -1 SSID so forgot about the padding.

              Jonathan


              On Sat, Aug 16, 2014 at 4:25 PM, James Ewen ve6srv@... [tracker2] <tracker2@yahoogroups.com> wrote:
              On Sat, Aug 16, 2014 at 3:17 PM, Jonathan Karras jkarras@...
              [tracker2] <tracker2@yahoogroups.com> wrote:

              > I am new to the OT3m and the scripting language. While attempting to make a macro
              > I ran in to a problem. Wondering if I am doing something wrong or what.

              Welcome to the fun world of scripting macros... they are a lot of fun
              to play with, and you can get some pretty amazing functionality out of
              the unit via macros!

              I would venture to say that "Yes, you are doing something wrong!",
              otherwise why would you be asking? :) The fun part is figuring out
              what's wrong!

              > The macro I am attempting to create is to beacon the UNIT, PARM, and EQNS APRS
              > messages. I created a siz line macro like below. When I run the macro only the last 2
              > lines get executed. If I remove the macro write (only there for debugging) only the last
              > beacon gets executed. I never see packets for EQNS or PARM.
              >
              > Just wondering if I am doing something wrong or if its a bug.

              There are probably a bunch of things happening...

              One thing that's common on the OT line is when people try to send
              multiple packets in a row, you can lose packets. This is most likely
              because the OT doesn't sit and wait for the network to digipeat a
              packet before sending the next packet.

              Digipeaters are supposed to immediately grab the channel and digipeat
              what they heard. Users are supposed to listen to the channel, and wait
              a random amount of time before sending a packet to help avoid packet
              collisions. Two packets back to back can cause a collision on the RF
              network, three would be worse.

              Looking at your raw packets as seen via the APRS-IS stream, we can see
              that your packets always get handled by a digipeater before being
              heard by an i-gate. So, we can guess that maybe there's a collision
              thing happening. If you listen locally, or were in direct reception
              range of an i-gate, you might not see the collision issue. But, since
              you are playing on an RF network with digipeaters, you need to deal
              with the collision issue.


              > Macro TELPARM
              >   Macro Write "EQNS"
              >   Exec "BEACON :KE7BAP-15:EQNS.0,.1,0,0,.1,0,0,.1,0,0,.1,0,0,.1,0"
              >   Macro Write "PARM"
              >   Exec "BEACON :KE7BAP-15:PARM.Voltage,Aux1,Aux2,Aux3,Aux4,,,,,,CFG,JMP"
              >   Macro Write "UNIT"
              >   Exec "BEACON :KE7BAP-15:UNIT.Vdc,,,,,,,,,,,CFG,JMP"
              >
              > End Block

              Depending on how you call this macro, the output can be a bit
              different. Let's assume that you send a remote command to the unit via
              an APRS message, such as this:

              CMD TELPARM from KE7BAP

              The unit should send a message back to you that says EQNS
              Then it should beacon a packet containing
              :KE7BAP-15:EQNS.0,.1,0,0,.1,0,0,.1,0,0,.1,0,0,.1,0
              The unit should send a message back to you that says PARM
              Then it should beacon a packet containing
              :PARM.Voltage,Aux1,Aux2,Aux3,Aux4,,,,,,CFG,JMP
              The unit should send a message back to you that says UNIT
              Then it should beacon a packet containing :KE7BAP-15:UNIT.Vdc,,,,,,,,,,,CFG,JMP

              I don't see the Macro Write messages on the APRS-IS stream, so you
              must have more script and you are calling the macro from within the
              script, which should put the macro write message to the console (I
              think).

              :KE7BAP-15 :UNIT.Vdc,,,,,,,,,,,CFG,JMP [Unsupported packet format]
              ::KE7BAP-15 :UNIT.Vdc,,,,,,,,,,,CFG,JMP [Invalid message packet]

              I also see that you're playing with trying to get the message
              formatting figured out properly...

              You can skip that issue by letting the OT3 format the messages properly.

              Instead of using the BEACON command and trying to get the APRS message
              formatting proper:

               Exec "BEACON :KE7BAP-15:EQNS.0,.1,0,0,.1,0,0,.1,0,0,.1,0,0,.1,0"

              Try this

              EXEC "SEND KE7BAP-15 EQNS.0,.1,0,0,.1,0,0,.1,0,0,.1,0,0,.1,0"

              The OT3 will look after padding the callsign properly, and getting the
              colons in the right spot, etc.

              (In the raw packets from the APRS-IS above, it looks like you have a
              space after your callsign that shouldn't be there. Your sample script
              is correct with 9 characters, but the raw data shows a space after
              your callsign which makes it 10 characters, which does not conform to
              spec)

              So, using the SEND command will make getting the message format correct easier.

              How do we space out sending those messages?

              How about something like this?

              Macro TELPARM
              On Second
                Increment Counter 3
                If Counter 3 = 5
                   Exec "SEND KE7BAP-15 EQNS.0,.1,0,0,.1,0,0,.1,0,0,.1,0,0,.1,0"
                End Block
                If Counter 3 = 10
                   Exec "SEND KE7BAP-15 PARM.Voltage,Aux1,Aux2,Aux3,Aux4,,,,,,CFG,JMP"
                End Block
                If Counter 3 = 15
                   Exec "SEND KE7BAP-15 UNIT.Vdc,,,,,,,,,,,CFG,JMP"
                   Set Counter 3 = 0
                End Block
              End Block

              I haven't tested this... I'm not sure if the ON SECOND counter will
              only count up while the MACRO is running, or if it will run
              continuously, incrementing COUNTER 3... even if it does, the IF
              statements inside the MACRO shouldn't run...

              The concept is to send the three packets with a 5 second separation
              between them.

              Try fiddling with something like that and see if it works.

              Where are you sending these telemetry definitions? If it's just to
              make the labels for aprs.fi, you can simply send them once, and
              aprs.fi will store them just about forever.

              There's not much else out there that makes use of telemetry
              definitions. I think there's another site online that uses telemetry
              definitions. APRSISCE/32 collects and saves telemetry definitions, but
              it doesn't do anything with them. SarTrack might use them too... can't
              recall.

              When I started sending telemetry, I made a script that sent the
              telemetry definitions at a defined interval. All I found I was doing,
              was making lots of noise on RF for no reason. Now all I do is send the
              definitions once, and aprs.fi saves them forever. I look at the
              telemetry exclusively at aprs.fi as I have no other means of seeing
              it. aprs.fi saves my telemetry in its database and allows me to see my
              long term trends. I'd have to run a client here 24/7 and save the data
              into a database to get the same functionality... I'm lazy, I let Hessu
              do that for me, and use his site to view my data.

              --
              James
              VE6SRV


              ------------------------------------
              Posted by: James Ewen <ve6srv@...>
              ------------------------------------


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

              Yahoo Groups Links

              <*> To visit your group on the web, go to:
                  http://groups.yahoo.com/group/tracker2/

              <*> Your email settings:
                  Individual Email | Traditional

              <*> To change settings online go to:
                  http://groups.yahoo.com/group/tracker2/join
                  (Yahoo! ID required)

              <*> To change settings via email:
                  tracker2-digest@yahoogroups.com
                  tracker2-fullfeatured@yahoogroups.com

              <*> To unsubscribe from this group, send an email to:
                  tracker2-unsubscribe@yahoogroups.com

              <*> Your use of Yahoo Groups is subject to:
                  https://info.yahoo.com/legal/us/yahoo/utos/terms/


            • Scott Miller
              Hmm, I think the BEACON command is non-blocking and only queues an outgoing packet. If it hasn t been sent yet it ll be overwritten - there s not much space
              Message 6 of 17 , Aug 16, 2014
                Hmm, I think the BEACON command is non-blocking and only queues an outgoing packet.  If it hasn't been sent yet it'll be overwritten - there's not much space for buffers.  You'll need to have a delay between commands.

                Scott

                On 8/16/2014 2:17 PM, Jonathan Karras jkarras@... [tracker2] wrote:
                 

                I am new to the OT3m and the scripting language. While attempting to make a macro I ran in to a problem. Wondering if I am doing something wrong or what.


                The macro I am attempting to create is to beacon the UNIT, PARM, and EQNS APRS messages. I created a siz line macro like below. When I run the macro only the last 2 lines get executed. If I remove the macro write (only there for debugging) only the last beacon gets executed. I never see packets for EQNS or PARM.


                Just wondering if I am doing something wrong or if its a bug.


                Hardware: OT3m

                Firmware: 56476


                Macro TELPARM
                  Macro Write "EQNS"
                  Exec "BEACON :KE7BAP-15:EQNS.0,.1,0,0,.1,0,0,.1,0,0,.1,0,0,.1,0"
                  Macro Write "PARM"
                  Exec "BEACON :KE7BAP-15:PARM.Voltage,Aux1,Aux2,Aux3,Aux4,,,,,,CFG,JMP"
                  Macro Write "UNIT"
                  Exec "BEACON :KE7BAP-15:UNIT.Vdc,,,,,,,,,,,CFG,JMP"

                End Block


              • Scott Miller
                Bob s idea there was that the FM capture effect would take care of that, except for what he imagined as a narrow band between the two where there wouldn t be a
                Message 7 of 17 , Aug 16, 2014
                  Bob's idea there was that the FM capture effect would take care of that, except for what he imagined as a narrow band between the two where there wouldn't be a 2.2 dB difference, or whatever the required margin is.  In reality you need more margin than that, so yeah... it's really debatable how wise that is.

                  One of these days I'm going to implement deferred digipeating, where it'll hold off and only transmit if no other digi gets it within a randomized span.

                  I'm also planning a slotted digi.  Right now I've got 20 trackers running at 9600 baud and transmitting in 1/4 second time slots, with a 6-second cycle time.  The 6th second was going to be reserved for a digi that would aggregate all 20 slots, but I don't know if I'm going to have it done in time to deploy next week.  But if you check out my shop on aprs.fi right now you'll see it swarming with ambulances and trucks...

                  Scott

                  On 8/16/2014 8:23 PM, owenvk@... [tracker2] wrote:
                   

                  "Digipeaters are supposed to immediately grab the channel and digipeat what they heard."I have noticed in my recent exploration of APRS that digis tend to "immediately grab the channel", and I am sure some lightweight thinkers have put forward rationale for this... but for example, there are two WIDE digis on very prominent hills. both within 20km of my home and can be heard for hundreds of km... and when they both "immediately grab the channel", they interfere with each other and you are unlikely to decode either of them.It is one of the contibutions to low success rates in getting posits to a remote iGate that hears both digis.Owen


                • Scott Miller
                  I think I should just hire you to do all of my customer service, James! You re beating me to all of these. =] Scott
                  Message 8 of 17 , Aug 16, 2014
                    I think I should just hire you to do all of my customer service, James!  You're beating me to all of these. =]

                    Scott

                    On 8/16/2014 9:45 PM, James Ewen ve6srv@... [tracker2] wrote:
                     

                    From your recent posts on this forum, it looks like you're very new
                    into APRS and and still have some very idealistic concepts about how
                    this is all supposed to work. I used to be just like you... give me a
                    little while, and I'll try and beat this optimism out of you. If I
                    succeed, I might be allowed to join the "club".

                    On Sat, Aug 16, 2014 at 9:23 PM, owenvk@... [tracker2]
                    <tracker2@yahoogroups.com> wrote:

                    > "Digipeaters are supposed to immediately grab the channel and digipeat what
                    > they heard."I have noticed in my recent exploration of APRS that digis tend to
                    > "immediately grab the channel", and I am sure some lightweight thinkers have
                    > put forward rationale for this...

                    Well, the primary "lightweight thinker" behind this concept is Bob
                    Bruninga WB4APR, the guy that invented APRS.

                    Have a Google for APRS packet fratricide. Bob's concept is that
                    neighbouring digipeaters are SUPPOSED to intentionally interfere with
                    each other, and in doing so, they stop packets from propagating over
                    large distances. It's a ridiculous idea, and to attempt to be able to
                    make it work, you have to expend a great deal of time and effort to
                    find locations for digipeaters that would allow such a concept to
                    work.

                    I've butted heads with Bob a number of times over basic concepts like
                    this. I put forth a concept to Bob back in 2002 about dynamic
                    digipeating that would limit the packets digipeated based on the
                    number of packet digipeats being requested, and the distance of the
                    source station. That was dismissed as being bad for APRS because of
                    the "randomness and unpredictability" of the digipeating of packets.
                    Yet this packet fratricide concept is deemed to be APRS nirvana.

                    > but for example, there are two WIDE digis on very prominent hills. both within 20km of my
                    > home and can be heard for hundreds of km... and when they both "immediately grab the
                    > channel", they interfere with each other and you are unlikely to decode either of them.

                    Hey, sounds familiar, huh? That's how APRS is "supposed to work".
                    Packet fratricide is working perfectly.

                    > It is one of the contibutions to low success rates in getting posits to a remote iGate that hears both digis.

                    But, by design this is EXACTLY how the digipeater network is supposed
                    to work. Bob's suggested solution is to put a yagi on the i-gate so
                    that it receives one digipeater stronger than the other. By getting
                    one signal stronger than the other by a large enough margin, the FM
                    capture effect will allow for a successful packet decode.

                    Your local digipeaters are not installed properly to be able to
                    support digipeating in the APRS network. One or the other would need
                    to be relocated so that you don't get the overlap where you see the
                    collisions. Yes, that's a pain in the backside, and it is very
                    difficult to find locations where you can get the digipeaters set up
                    to provide unique coverage, yet still be able to talk to the
                    neighboring digipeaters, and also have excellent RX/TX coverage where
                    it can hear those low powered trackers and other stations, and be
                    heard by them as well with minimal holes in the coverage.

                    I've argued this point for over a decade, and it falls of deaf ears.
                    We have built a digipeater network of over 30 digipeaters here in
                    Alberta, and they don't follow the intentional interference concept.
                    Our digipeaters wait for a clear channel. This means that packets take
                    slightly longer to propagate through the network (They are only 2 or 3
                    hops max), but the packets make it through the network reliably. We
                    also support the SSn-N concept, and have tested using AB7-7 numerous
                    times. I can reliably get 5 hops across the province. I can't get
                    further because 5 hops crosses the whole network!

                    --
                    James
                    VE6SRV


                  • James Ewen
                    On Sat, Aug 16, 2014 at 11:30 PM, Scott Miller scott@opentrac.org ... You don t want to have viscous digipeating enabled on the main digipeaters... that will
                    Message 9 of 17 , Aug 16, 2014
                      On Sat, Aug 16, 2014 at 11:30 PM, Scott Miller scott@...
                      [tracker2] <tracker2@yahoogroups.com> wrote:

                      > One of these days I'm going to implement deferred digipeating, where it'll hold
                      > off and only transmit if no other digi gets it within a randomized span.

                      You don't want to have viscous digipeating enabled on the main
                      digipeaters... that will cause holes in the digipeater network.

                      Viscous digipeating should only be done on the first hop, more
                      specifically on WIDE1-1.

                      If you want, I can provide a reasoned discussion on why this is the
                      only place viscous digipeating is acceptable.

                      --
                      James
                      VE6SRV
                    • Bill Vodall
                      ... FWIW - http://wiki.ham.fi/Viscous_APRS_Digipeater
                      Message 10 of 17 , Aug 16, 2014
                        >> One of these days I'm going to implement deferred digipeating, where it'll hold
                        >> off and only transmit if no other digi gets it within a randomized span.

                        FWIW - http://wiki.ham.fi/Viscous_APRS_Digipeater


                        > Viscous digipeating should only be done on the first hop, more
                        > specifically on WIDE1-1.
                      • Scott Miller
                        I agree, it should be a fill-in thing. Watching 20 of these little trackers spewing out a combined 8 packets per second with no collisions reminds me just how
                        Message 11 of 17 , Aug 16, 2014
                          I agree, it should be a fill-in thing.

                          Watching 20 of these little trackers spewing out a combined 8 packets per second with no collisions reminds me just how horribly inefficient regular APRS is...

                          Scott

                          On 8/16/2014 10:43 PM, James Ewen ve6srv@... [tracker2] wrote:
                           

                          On Sat, Aug 16, 2014 at 11:30 PM, Scott Miller scott@...
                          [tracker2] <tracker2@yahoogroups.com> wrote:

                          > One of these days I'm going to implement deferred digipeating, where it'll hold
                          > off and only transmit if no other digi gets it within a randomized span.

                          You don't want to have viscous digipeating enabled on the main
                          digipeaters... that will cause holes in the digipeater network.

                          Viscous digipeating should only be done on the first hop, more
                          specifically on WIDE1-1.

                          If you want, I can provide a reasoned discussion on why this is the
                          only place viscous digipeating is acceptable.

                          --
                          James
                          VE6SRV


                        • James Ewen
                          On Sat, Aug 16, 2014 at 11:35 PM, Scott Miller scott@opentrac.org ... I don t get distracted by flashy LED lights! Uh, ignore the flashy LED lights under my RV
                          Message 12 of 17 , Aug 16, 2014
                            On Sat, Aug 16, 2014 at 11:35 PM, Scott Miller scott@...
                            [tracker2] <tracker2@yahoogroups.com> wrote:

                            > I think I should just hire you to do all of my customer service, James!
                            > You're beating me to all of these. =]

                            I don't get distracted by flashy LED lights!

                            Uh, ignore the flashy LED lights under my RV awning.

                            --
                            James
                            VE6SRV
                          • Bill Vodall
                            ... Still only 9600? :(
                            Message 13 of 17 , Aug 16, 2014
                              > Watching 20 of these little trackers spewing out a combined 8 packets per second

                              Still only 9600? :(
                            • James Ewen
                              On Sat, Aug 16, 2014 at 11:45 PM, Bill Vodall wa7nwp@gmail.com ... The page only looks at the effect of viscous digipeating as a factor at a single digipeater,
                              Message 14 of 17 , Aug 16, 2014
                                On Sat, Aug 16, 2014 at 11:45 PM, Bill Vodall wa7nwp@...
                                [tracker2] <tracker2@yahoogroups.com> wrote:

                                > FWIW - http://wiki.ham.fi/Viscous_APRS_Digipeater

                                The page only looks at the effect of viscous digipeating as a factor
                                at a single digipeater, and they only consider a reduced number of
                                digipeats as a successful result.

                                --
                                James
                                VE6SRV
                              • Lynn W. Deffenbaugh (Mr)
                                ... I have repeatedly asked for clarification on exactly this point of Bob s intended digipeater network design. When he says that digipeaters should digipeat
                                Message 15 of 17 , Aug 17, 2014
                                  On 8/17/2014 12:45 AM, James Ewen ve6srv@... [tracker2] wrote:
                                  > We have built a digipeater network of over 30 digipeaters here in
                                  > Alberta, and they don't follow the intentional interference concept.
                                  > Our digipeaters wait for a clear channel. This means that packets take
                                  > slightly longer to propagate through the network (They are only 2 or 3
                                  > hops max), but the packets make it through the network reliably. We
                                  > also support the SSn-N concept, and have tested using AB7-7 numerous
                                  > times. I can reliably get 5 hops across the province. I can't get
                                  > further because 5 hops crosses the whole network!

                                  I have repeatedly asked for clarification on exactly this point of Bob's
                                  intended digipeater network design. When he says that digipeaters
                                  should digipeat immediately, he's talking about a DWAIT of zero, no
                                  forced delay before transmitting a digipeated packet. But when pressed,
                                  the digipeaters ARE supposed to wait for a "clear channel". So, unless
                                  you have exactly matched digipeaters with exactly the same decoded,
                                  decision, and transmit delays, which IMHO pretty much excludes
                                  non-TNC-based digipeating due to serial interface and firmware/software
                                  differences, one will decide to transmit the packet before the other and
                                  the slower one will end up waiting for the channel to clear, completely
                                  eliminating the collisions.

                                  I've listened to the APRS channel with my own ears in many different
                                  areas of the country and I've rarely witnesses the simultaneous
                                  transmission with collisions without one stations "locking in" on my
                                  radio (capture effect) and being heard better than the other. I've
                                  actually heard my transmitted packets begin a digipeat from somewhere
                                  weak only to be clobbered by a stronger, closer, slower (apparently not
                                  hearing the remote digi strong enough to consider the channel "busy")
                                  digipeat that is decoded fine. And yes, I've been known to force
                                  repeated transmissions just to make sure it's my packet that's sounding
                                  that way.

                                  I don't recall ever being in a position where digipeats of my packets
                                  collided more than once or twice while mobile. I'm sure such places
                                  would exist in a static location, and in fact, could exist in areas
                                  where a fixed station can hear a pair of remote digipeaters that don't
                                  hear each other (classic "hidden transmitter" issue) and no amount of
                                  DWAIT, Busy, or so-called "viscous" fiddling at the digipeaters will fix
                                  that location's reception issues.

                                  So every area is different and needs to design and deploy what works
                                  best for that area. But digipeaters not waiting for a clear channel has
                                  never, as far as I know when properly queried, been Bob's intended
                                  design for digipeater deployment.

                                  Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
                                • James Ewen
                                  On Sat, Aug 16, 2014 at 11:09 PM, Jonathan Karras jkarras@karras.net ... You re going to make me pull out an OT3 and make me play with it to test all of this,
                                  Message 16 of 17 , Aug 17, 2014
                                    On Sat, Aug 16, 2014 at 11:09 PM, Jonathan Karras jkarras@...
                                    [tracker2] <tracker2@yahoogroups.com> wrote:

                                    > I thought about using counters to space things out but based on the radio
                                    > burst length and lack of write messages to my console (I am calling the
                                    > macro manually via serial) it really seems as though the scripting engine
                                    > is only calling the last two unique commands. I have not tried stacking three
                                    > of say a port A write, macro write, and execute. I have tried each of those
                                    > individually. Even when it was just port writes it only called the last one.

                                    You're going to make me pull out an OT3 and make me play with it to
                                    test all of this, aren't you?

                                    I haven't played with PRINTA or MACRO WRITE... I just send messages
                                    out to alert me over email.

                                    --
                                    James
                                    VE6SRV
                                  • Scott Miller
                                    Oh, they ll go much faster than that, but I need this batch to work with Kenwood rigs. Scott
                                    Message 17 of 17 , Aug 17, 2014
                                      Oh, they'll go much faster than that, but I need this batch to work with
                                      Kenwood rigs.

                                      Scott

                                      On 8/16/2014 10:53 PM, Bill Vodall wa7nwp@... [tracker2] wrote:
                                      >
                                      > > Watching 20 of these little trackers spewing out a combined 8
                                      > packets per second
                                      >
                                      > Still only 9600? :(
                                      >
                                      >
                                    Your message has been successfully submitted and would be delivered to recipients shortly.