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

Trying out a new mode with aprsis32 and multipsk in KISS on HF

Expand Messages
  • Steinar Aanesland
    Hi all ,I hope this is not to out of topic for this group. As some of you probably know, 300b packet is not the best choice on HF, but there are some
    Message 1 of 14 , May 18, 2013
    • 0 Attachment
      Hi all ,I hope this is not to out of topic for this group.

      As some of you probably know, 300b packet is not the best choice on HF,
      but there are some alternatives.
      One of them is ALE400 . ALE400 is ARQ mode in Multipsk.

      I have made me a small lab testing out the ALE400/Multipsk software in
      KISS with aprsis32 and UI-View32.

      My lab is like this:

      I am using to PCes simulating station "LA5VNA" and station "LC5VNA".
      They are connecting together trough their mic's and they loudspeakers.

      I was first testing out a combination of
      Multipsk/KISS/UI-View32 on station "LA5VNA", and a combination of
      Multipsk/KISS/aprsis32 on station "LC5VNA".

      [Multipsk/KISS/UI-View32]<===mic's/loudspeakers==>[Multipsk/KISS/aprsis32]

      Beaconing was working great form station "a" and "b". Both maps was
      updated, but when trying the message function something

      strange was happening.

      When UI-View32 (station "LA5VNA") was sending a message like "test",
      this appeared in the middle window of multipsk:
      LA5VNA :LC5VNA :test{12

      When aprsis32 (station"LC5VNA") was responding with an ack, this was
      appearing in the
      lower window of multipsk on station"LA5VNA" :

      [End of TX] FAE APRS frame
      LC5VNA :LA5VNA :ack12 [FAE APRS]
      ...KISS frame repeated

      Station"LA5VNA" had got its ack and seems to be happy.


      BUT, when aprsis32 (station"LC5VNA") was sending a "test" message,
      thisappeared in the middle window of Multipsk:
      LC5VNA :LA5VNA :test{PU}HX

      When is UI-View32 (station "LA5VNA") was responding with an ack, this
      was appearing in the
      lower window of Multipsk on station"LC5VNA" :

      [End of TX] FAE APRS frame
      LA5VNA :LA5VNA :ackPU}HX [FAE APRS]
      ...KISS frame repeated


      The aprsis32 (station"LC5VNA") seems not to recognize ackPU}HX as an ACK
      so it keep repeating the "test" message until it times

      out.


      I was then trying with only UI-View32on both station"LC5VNA" and
      "LA5VNA" and everything works fine. With only aprsis32 there

      was absolutely no way of getting the stations to recognize the ACK's

      Does anyone have a clue of was going on ?

      If you want to try this , download latest ver of multipsk, but remember
      to read the "ALE_and_ALE400_APRS_with_UI-

      VIEW_through_Multipsk_easy.doc"
      https://dl.dropboxusercontent.com/u/16381257/MULTIPSK_TEST_16_05_2013.ZIP


      LA5VNA Steinar
      loc:JO59jq
    • Lynn W Deffenbaugh (Mr)
      Please bring up Enables / View Logs / Port( ) and enable it and do the message test again. I m suspecting that something in the chain is mucking
      Message 2 of 14 , May 18, 2013
      • 0 Attachment
        Please bring up Enables / View Logs / Port(<YourRFPort>) and enable it
        and do the message test again. I'm suspecting that something in the
        chain is mucking about with the curly brace inside the ack sequence
        which is the Reply-Ack protocol. This is supposed to be fully backward
        compatible (I've had many QSOs with UI-View users), so it must be
        something in the ALE/ARQ/MultiPSK chain that is introducing something
        strange.

        If you also check Enables / Logging / File Enabled, then the trace from
        above will also go into your APRSIS32.LOG file that you can send on to
        KJ4ERJ@... with a reminder of what it is I'm looking at.

        While you've got it all put together, try messaging back and forth with
        a UI-View station over the APRS-IS and/or standard packet just to show
        that the same configuration of the stations (outside of the RF path)
        truly does function. It's a case of "show what works" and then "what's
        different" must be the source of the problem.

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

        PS. Has anyone used MultiPSK's KISS mode for other APRS messaging? Is
        this even possible?

        On 5/18/2013 7:56 AM, Steinar Aanesland wrote:
        > Hi all ,I hope this is not to out of topic for this group.
        >
        > As some of you probably know, 300b packet is not the best choice on HF,
        > but there are some alternatives.
        > One of them is ALE400 . ALE400 is ARQ mode in Multipsk.
        >
        > I have made me a small lab testing out the ALE400/Multipsk software in
        > KISS with aprsis32 and UI-View32.
        >
        > My lab is like this:
        >
        > I am using to PCes simulating station "LA5VNA" and station "LC5VNA".
        > They are connecting together trough their mic's and they loudspeakers.
        >
        > I was first testing out a combination of
        > Multipsk/KISS/UI-View32 on station "LA5VNA", and a combination of
        > Multipsk/KISS/aprsis32 on station "LC5VNA".
        >
        > [Multipsk/KISS/UI-View32]<===mic's/loudspeakers==>[Multipsk/KISS/aprsis32]
        >
        > Beaconing was working great form station "a" and "b". Both maps was
        > updated, but when trying the message function something
        >
        > strange was happening.
        >
        > When UI-View32 (station "LA5VNA") was sending a message like "test",
        > this appeared in the middle window of multipsk:
        > LA5VNA :LC5VNA :test{12
        >
        > When aprsis32 (station"LC5VNA") was responding with an ack, this was
        > appearing in the
        > lower window of multipsk on station"LA5VNA" :
        >
        > [End of TX] FAE APRS frame
        > LC5VNA :LA5VNA :ack12 [FAE APRS]
        > ...KISS frame repeated
        >
        > Station"LA5VNA" had got its ack and seems to be happy.
        >
        >
        > BUT, when aprsis32 (station"LC5VNA") was sending a "test" message,
        > thisappeared in the middle window of Multipsk:
        > LC5VNA :LA5VNA :test{PU}HX
        >
        > When is UI-View32 (station "LA5VNA") was responding with an ack, this
        > was appearing in the
        > lower window of Multipsk on station"LC5VNA" :
        >
        > [End of TX] FAE APRS frame
        > LA5VNA :LA5VNA :ackPU}HX [FAE APRS]
        > ...KISS frame repeated
        >
        >
        > The aprsis32 (station"LC5VNA") seems not to recognize ackPU}HX as an ACK
        > so it keep repeating the "test" message until it times
        >
        > out.
        >
        >
        > I was then trying with only UI-View32on both station"LC5VNA" and
        > "LA5VNA" and everything works fine. With only aprsis32 there
        >
        > was absolutely no way of getting the stations to recognize the ACK's
        >
        > Does anyone have a clue of was going on ?
        >
        > If you want to try this , download latest ver of multipsk, but remember
        > to read the "ALE_and_ALE400_APRS_with_UI-
        >
        > VIEW_through_Multipsk_easy.doc"
        > https://dl.dropboxusercontent.com/u/16381257/MULTIPSK_TEST_16_05_2013.ZIP
        >
        >
        > LA5VNA Steinar
        > loc:JO59jq
        >
        >
        >
        >
        > ------------------------------------
        >
        > Yahoo! Groups Links
        >
        >
        >
        >
      • Steinar Aanesland
        Lynn Thank for your reply. I will do some more testing and send you the log :) Has anyone used MultiPSK s KISS mode for other APRS messaging? Is this even
        Message 3 of 14 , May 18, 2013
        • 0 Attachment
          Lynn


          Thank for your reply. I will do some more testing and send you the log :)


          " Has anyone used MultiPSK's KISS mode for other APRS messaging? Is
          this even possible?" Yes, take a look at this youtube:
          http://www.youtube.com/watch?v=4lKbhtChkGw

          LA6VNA S





          On 18.05.2013 15:43, Lynn W Deffenbaugh (Mr) wrote:
          > Please bring up Enables / View Logs / Port(<YourRFPort>) and enable it
          > and do the message test again. I'm suspecting that something in the
          > chain is mucking about with the curly brace inside the ack sequence
          > which is the Reply-Ack protocol. This is supposed to be fully backward
          > compatible (I've had many QSOs with UI-View users), so it must be
          > something in the ALE/ARQ/MultiPSK chain that is introducing something
          > strange.
          >
          > If you also check Enables / Logging / File Enabled, then the trace from
          > above will also go into your APRSIS32.LOG file that you can send on to
          > KJ4ERJ@... with a reminder of what it is I'm looking at.
          >
          > While you've got it all put together, try messaging back and forth with
          > a UI-View station over the APRS-IS and/or standard packet just to show
          > that the same configuration of the stations (outside of the RF path)
          > truly does function. It's a case of "show what works" and then "what's
          > different" must be the source of the problem.
          >
          > Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
          >
          > PS. Has anyone used MultiPSK's KISS mode for other APRS messaging? Is
          > this even possible?
          >
          > On 5/18/2013 7:56 AM, Steinar Aanesland wrote:
          >> Hi all ,I hope this is not to out of topic for this group.
          >>
          >> As some of you probably know, 300b packet is not the best choice on HF,
          >> but there are some alternatives.
          >> One of them is ALE400 . ALE400 is ARQ mode in Multipsk.
          >>
          >> I have made me a small lab testing out the ALE400/Multipsk software in
          >> KISS with aprsis32 and UI-View32.
          >>
          >> My lab is like this:
          >>
          >> I am using to PCes simulating station "LA5VNA" and station "LC5VNA".
          >> They are connecting together trough their mic's and they loudspeakers.
          >>
          >> I was first testing out a combination of
          >> Multipsk/KISS/UI-View32 on station "LA5VNA", and a combination of
          >> Multipsk/KISS/aprsis32 on station "LC5VNA".
          >>
          >> [Multipsk/KISS/UI-View32]<===mic's/loudspeakers==>[Multipsk/KISS/aprsis32]
          >>
          >> Beaconing was working great form station "a" and "b". Both maps was
          >> updated, but when trying the message function something
          >>
          >> strange was happening.
          >>
          >> When UI-View32 (station "LA5VNA") was sending a message like "test",
          >> this appeared in the middle window of multipsk:
          >> LA5VNA :LC5VNA :test{12
          >>
          >> When aprsis32 (station"LC5VNA") was responding with an ack, this was
          >> appearing in the
          >> lower window of multipsk on station"LA5VNA" :
          >>
          >> [End of TX] FAE APRS frame
          >> LC5VNA :LA5VNA :ack12 [FAE APRS]
          >> ...KISS frame repeated
          >>
          >> Station"LA5VNA" had got its ack and seems to be happy.
          >>
          >>
          >> BUT, when aprsis32 (station"LC5VNA") was sending a "test" message,
          >> thisappeared in the middle window of Multipsk:
          >> LC5VNA :LA5VNA :test{PU}HX
          >>
          >> When is UI-View32 (station "LA5VNA") was responding with an ack, this
          >> was appearing in the
          >> lower window of Multipsk on station"LC5VNA" :
          >>
          >> [End of TX] FAE APRS frame
          >> LA5VNA :LA5VNA :ackPU}HX [FAE APRS]
          >> ...KISS frame repeated
          >>
          >>
          >> The aprsis32 (station"LC5VNA") seems not to recognize ackPU}HX as an ACK
          >> so it keep repeating the "test" message until it times
          >>
          >> out.
          >>
          >>
          >> I was then trying with only UI-View32on both station"LC5VNA" and
          >> "LA5VNA" and everything works fine. With only aprsis32 there
          >>
          >> was absolutely no way of getting the stations to recognize the ACK's
          >>
          >> Does anyone have a clue of was going on ?
          >>
          >> If you want to try this , download latest ver of multipsk, but remember
          >> to read the "ALE_and_ALE400_APRS_with_UI-
          >>
          >> VIEW_through_Multipsk_easy.doc"
          >> https://dl.dropboxusercontent.com/u/16381257/MULTIPSK_TEST_16_05_2013.ZIP
          >>
          >>
          >> LA5VNA Steinar
          >> loc:JO59jq
          >>
          >>
          >>
          >>
          >> ------------------------------------
          >>
          >> Yahoo! Groups Links
          >>
          >>
          >>
          >>
          >
          >
          > ------------------------------------
          >
          > Yahoo! Groups Links
          >
          >
          >
        • Steve Daniels
          Looks interesting had a brief play with it today, going to figure out how to interface it with APRSIS32 next Perhaps you could write something up on it that I
          Message 4 of 14 , May 19, 2013
          • 0 Attachment

            Looks interesting had a brief play with it today, going to figure out how to interface it with APRSIS32 next

            Perhaps you could write something up on it that I can put in the WIKI

             

            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 Steinar Aanesland
            Sent: 18 May 2013 12:56
            To: APRSIS32
            Subject: [aprsisce] Trying out a new mode with aprsis32 and multipsk in KISS on HF

             

             

            Hi all ,I hope this is not to out of topic for this group.

            As some of you probably know, 300b packet is not the best choice on HF,
            but there are some alternatives.
            One of them is ALE400 . ALE400 is ARQ mode in Multipsk.

            I have made me a small lab testing out the ALE400/Multipsk software in
            KISS with aprsis32 and UI-View32.

            My lab is like this:

            I am using to PCes simulating station "LA5VNA" and station "LC5VNA".
            They are connecting together trough their mic's and they loudspeakers.

            I was first testing out a combination of
            Multipsk/KISS/UI-View32 on station "LA5VNA", and a combination of
            Multipsk/KISS/aprsis32 on station "LC5VNA".

            [Multipsk/KISS/UI-View32]<===mic's/loudspeakers==>[Multipsk/KISS/aprsis32]

            Beaconing was working great form station "a" and "b". Both maps was
            updated, but when trying the message function something

            strange was happening.

            When UI-View32 (station "LA5VNA") was sending a message like "test",
            this appeared in the middle window of multipsk:
            LA5VNA :LC5VNA :test{12

            When aprsis32 (station"LC5VNA") was responding with an ack, this was
            appearing in the
            lower window of multipsk on station"LA5VNA" :

            [End of TX] FAE APRS frame
            LC5VNA :LA5VNA :ack12 [FAE APRS]
            ...KISS frame repeated

            Station"LA5VNA" had got its ack and seems to be happy.

            BUT, when aprsis32 (station"LC5VNA") was sending a "test" message,
            thisappeared in the middle window of Multipsk:
            LC5VNA :LA5VNA :test{PU}HX

            When is UI-View32 (station "LA5VNA") was responding with an ack, this
            was appearing in the
            lower window of Multipsk on station"LC5VNA" :

            [End of TX] FAE APRS frame
            LA5VNA :LA5VNA :ackPU}HX [FAE APRS]
            ...KISS frame repeated

            The aprsis32 (station"LC5VNA") seems not to recognize ackPU}HX as an ACK
            so it keep repeating the "test" message until it times

            out.

            I was then trying with only UI-View32on both station"LC5VNA" and
            "LA5VNA" and everything works fine. With only aprsis32 there

            was absolutely no way of getting the stations to recognize the ACK's

            Does anyone have a clue of was going on ?

            If you want to try this , download latest ver of multipsk, but remember
            to read the "ALE_and_ALE400_APRS_with_UI-

            VIEW_through_Multipsk_easy.doc"
            https://dl.dropboxusercontent.com/u/16381257/MULTIPSK_TEST_16_05_2013.ZIP

            LA5VNA Steinar
            loc:JO59jq

          • Steinar Aanesland
            Hi all After long time struggle , I finally got things working . Last night I was starting from scratch setting up a completely new test installation, and now
            Message 5 of 14 , May 22, 2013
            • 0 Attachment
              Hi all

              After long time struggle , I finally got things working . Last night I
              was starting from scratch setting up a completely new test installation,
              and now station "LA5VNA" and station "LC5VNA" are now able to send a
              message and than reply with an ACK.

              There is only one catch, it is only working nicely with UI-View32. When
              I am sending a message with UI-View32 it goes about 30 seconds before
              UI-View32 broadcast a new message. This is plenty of time for another
              station to detect the message and reply with an ACK.

              When I am trying with my favorite APRS program aprsis32, aprsis32
              sending a new message only 1 second after the first one. If the RX
              station is able to detect the first message and reply with an ACK, this
              ACK will never be detected because it collides with the second
              retransmission of the message . This goes back and forth until a
              collision is avoiding and the ACK, is detected .

              Is there a way to avoid the collision, or is this timing of the second
              retransmission hard coded into aprsis32 ?

              LA5VNA Steinar
              loc:JO59jq




              Den 18.05.2013 15:59, skrev Steinar Aanesland:
              > Lynn
              >
              >
              > Thank for your reply. I will do some more testing and send you the log :)
              >
              >
              > " Has anyone used MultiPSK's KISS mode for other APRS messaging? Is
              > this even possible?" Yes, take a look at this youtube:
              > http://www.youtube.com/watch?v=4lKbhtChkGw
              >
              > LA6VNA S
              >
              >
              >
              >
              >
              > On 18.05.2013 15:43, Lynn W Deffenbaugh (Mr) wrote:
              >> Please bring up Enables / View Logs / Port(<YourRFPort>) and enable it
              >> and do the message test again. I'm suspecting that something in the
              >> chain is mucking about with the curly brace inside the ack sequence
              >> which is the Reply-Ack protocol. This is supposed to be fully backward
              >> compatible (I've had many QSOs with UI-View users), so it must be
              >> something in the ALE/ARQ/MultiPSK chain that is introducing something
              >> strange.
              >>
              >> If you also check Enables / Logging / File Enabled, then the trace from
              >> above will also go into your APRSIS32.LOG file that you can send on to
              >> KJ4ERJ@... with a reminder of what it is I'm looking at.
              >>
              >> While you've got it all put together, try messaging back and forth with
              >> a UI-View station over the APRS-IS and/or standard packet just to show
              >> that the same configuration of the stations (outside of the RF path)
              >> truly does function. It's a case of "show what works" and then "what's
              >> different" must be the source of the problem.
              >>
              >> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
              >>
              >> PS. Has anyone used MultiPSK's KISS mode for other APRS messaging? Is
              >> this even possible?
              >>
              >> On 5/18/2013 7:56 AM, Steinar Aanesland wrote:
              >>> Hi all ,I hope this is not to out of topic for this group.
              >>>
              >>> As some of you probably know, 300b packet is not the best choice on HF,
              >>> but there are some alternatives.
              >>> One of them is ALE400 . ALE400 is ARQ mode in Multipsk.
              >>>
              >>> I have made me a small lab testing out the ALE400/Multipsk software in
              >>> KISS with aprsis32 and UI-View32.
              >>>
              >>> My lab is like this:
              >>>
              >>> I am using to PCes simulating station "LA5VNA" and station "LC5VNA".
              >>> They are connecting together trough their mic's and they loudspeakers.
              >>>
              >>> I was first testing out a combination of
              >>> Multipsk/KISS/UI-View32 on station "LA5VNA", and a combination of
              >>> Multipsk/KISS/aprsis32 on station "LC5VNA".
              >>>
              >>> [Multipsk/KISS/UI-View32]<===mic's/loudspeakers==>[Multipsk/KISS/aprsis32]
              >>>
              >>> Beaconing was working great form station "a" and "b". Both maps was
              >>> updated, but when trying the message function something
              >>>
              >>> strange was happening.
              >>>
              >>> When UI-View32 (station "LA5VNA") was sending a message like "test",
              >>> this appeared in the middle window of multipsk:
              >>> LA5VNA :LC5VNA :test{12
              >>>
              >>> When aprsis32 (station"LC5VNA") was responding with an ack, this was
              >>> appearing in the
              >>> lower window of multipsk on station"LA5VNA" :
              >>>
              >>> [End of TX] FAE APRS frame
              >>> LC5VNA :LA5VNA :ack12 [FAE APRS]
              >>> ...KISS frame repeated
              >>>
              >>> Station"LA5VNA" had got its ack and seems to be happy.
              >>>
              >>>
              >>> BUT, when aprsis32 (station"LC5VNA") was sending a "test" message,
              >>> thisappeared in the middle window of Multipsk:
              >>> LC5VNA :LA5VNA :test{PU}HX
              >>>
              >>> When is UI-View32 (station "LA5VNA") was responding with an ack, this
              >>> was appearing in the
              >>> lower window of Multipsk on station"LC5VNA" :
              >>>
              >>> [End of TX] FAE APRS frame
              >>> LA5VNA :LA5VNA :ackPU}HX [FAE APRS]
              >>> ...KISS frame repeated
              >>>
              >>>
              >>> The aprsis32 (station"LC5VNA") seems not to recognize ackPU}HX as an ACK
              >>> so it keep repeating the "test" message until it times
              >>>
              >>> out.
              >>>
              >>>
              >>> I was then trying with only UI-View32on both station"LC5VNA" and
              >>> "LA5VNA" and everything works fine. With only aprsis32 there
              >>>
              >>> was absolutely no way of getting the stations to recognize the ACK's
              >>>
              >>> Does anyone have a clue of was going on ?
              >>>
              >>> If you want to try this , download latest ver of multipsk, but remember
              >>> to read the "ALE_and_ALE400_APRS_with_UI-
              >>>
              >>> VIEW_through_Multipsk_easy.doc"
              >>> https://dl.dropboxusercontent.com/u/16381257/MULTIPSK_TEST_16_05_2013.ZIP
              >>>
              >>>
              >>> LA5VNA Steinar
              >>> loc:JO59jq
              >>>
              >>>
              >>>
              >>>
              >>> ------------------------------------
              >>>
              >>> Yahoo! Groups Links
              >>>
              >>>
              >>>
              >>>
              >>
              >>
              >> ------------------------------------
              >>
              >> Yahoo! Groups Links
              >>
              >>
              >>
              >
              >
              >
              > ------------------------------------
              >
              > Yahoo! Groups Links
              >
              >
              >
              >
              >
            • Lynn W Deffenbaugh (Mr)
              See http://aprsisce.wikidot.com/message-retries If you re getting the first retry in 1 second, then I ve got a bust somewhere. Can you bring up and enable the
              Message 6 of 14 , May 22, 2013
              • 0 Attachment
                See http://aprsisce.wikidot.com/message-retries

                If you're getting the first retry in 1 second, then I've got a bust
                somewhere. Can you bring up and enable the Transmit trace log to
                confirm or deny your message retry timings?

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

                PS. I didn't invent the initial 8 second retry delay either. See Bob's
                original page at

                http://aprs.org/txt/messages101.txt

                In fact, UI-View's 30 second initial retry falls under Bob's statement
                of "Not ONCE like most follow-on clones." in point # 2. UI-View
                sometimes isn't the "gold standard" of APRS implementation. At least,
                not in a universal opinion.

                On 5/22/2013 3:11 PM, Steinar Aanesland wrote:
                > Hi all
                >
                > After long time struggle , I finally got things working . Last night I
                > was starting from scratch setting up a completely new test installation,
                > and now station "LA5VNA" and station "LC5VNA" are now able to send a
                > message and than reply with an ACK.
                >
                > There is only one catch, it is only working nicely with UI-View32. When
                > I am sending a message with UI-View32 it goes about 30 seconds before
                > UI-View32 broadcast a new message. This is plenty of time for another
                > station to detect the message and reply with an ACK.
                >
                > When I am trying with my favorite APRS program aprsis32, aprsis32
                > sending a new message only 1 second after the first one. If the RX
                > station is able to detect the first message and reply with an ACK, this
                > ACK will never be detected because it collides with the second
                > retransmission of the message . This goes back and forth until a
                > collision is avoiding and the ACK, is detected .
                >
                > Is there a way to avoid the collision, or is this timing of the second
                > retransmission hard coded into aprsis32 ?
                >
                > LA5VNA Steinar
                > loc:JO59jq
                >
                >
                >
                >
                > Den 18.05.2013 15:59, skrev Steinar Aanesland:
                >> Lynn
                >>
                >>
                >> Thank for your reply. I will do some more testing and send you the log :)
                >>
                >>
                >> " Has anyone used MultiPSK's KISS mode for other APRS messaging? Is
                >> this even possible?" Yes, take a look at this youtube:
                >> http://www.youtube.com/watch?v=4lKbhtChkGw
                >>
                >> LA6VNA S
                >>
                >>
                >>
                >>
                >>
                >> On 18.05.2013 15:43, Lynn W Deffenbaugh (Mr) wrote:
                >>> Please bring up Enables / View Logs / Port(<YourRFPort>) and enable it
                >>> and do the message test again. I'm suspecting that something in the
                >>> chain is mucking about with the curly brace inside the ack sequence
                >>> which is the Reply-Ack protocol. This is supposed to be fully backward
                >>> compatible (I've had many QSOs with UI-View users), so it must be
                >>> something in the ALE/ARQ/MultiPSK chain that is introducing something
                >>> strange.
                >>>
                >>> If you also check Enables / Logging / File Enabled, then the trace from
                >>> above will also go into your APRSIS32.LOG file that you can send on to
                >>> KJ4ERJ@... with a reminder of what it is I'm looking at.
                >>>
                >>> While you've got it all put together, try messaging back and forth with
                >>> a UI-View station over the APRS-IS and/or standard packet just to show
                >>> that the same configuration of the stations (outside of the RF path)
                >>> truly does function. It's a case of "show what works" and then "what's
                >>> different" must be the source of the problem.
                >>>
                >>> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
                >>>
                >>> PS. Has anyone used MultiPSK's KISS mode for other APRS messaging? Is
                >>> this even possible?
                >>>
                >>> On 5/18/2013 7:56 AM, Steinar Aanesland wrote:
                >>>> Hi all ,I hope this is not to out of topic for this group.
                >>>>
                >>>> As some of you probably know, 300b packet is not the best choice on HF,
                >>>> but there are some alternatives.
                >>>> One of them is ALE400 . ALE400 is ARQ mode in Multipsk.
                >>>>
                >>>> I have made me a small lab testing out the ALE400/Multipsk software in
                >>>> KISS with aprsis32 and UI-View32.
                >>>>
                >>>> My lab is like this:
                >>>>
                >>>> I am using to PCes simulating station "LA5VNA" and station "LC5VNA".
                >>>> They are connecting together trough their mic's and they loudspeakers.
                >>>>
                >>>> I was first testing out a combination of
                >>>> Multipsk/KISS/UI-View32 on station "LA5VNA", and a combination of
                >>>> Multipsk/KISS/aprsis32 on station "LC5VNA".
                >>>>
                >>>> [Multipsk/KISS/UI-View32]<===mic's/loudspeakers==>[Multipsk/KISS/aprsis32]
                >>>>
                >>>> Beaconing was working great form station "a" and "b". Both maps was
                >>>> updated, but when trying the message function something
                >>>>
                >>>> strange was happening.
                >>>>
                >>>> When UI-View32 (station "LA5VNA") was sending a message like "test",
                >>>> this appeared in the middle window of multipsk:
                >>>> LA5VNA :LC5VNA :test{12
                >>>>
                >>>> When aprsis32 (station"LC5VNA") was responding with an ack, this was
                >>>> appearing in the
                >>>> lower window of multipsk on station"LA5VNA" :
                >>>>
                >>>> [End of TX] FAE APRS frame
                >>>> LC5VNA :LA5VNA :ack12 [FAE APRS]
                >>>> ...KISS frame repeated
                >>>>
                >>>> Station"LA5VNA" had got its ack and seems to be happy.
                >>>>
                >>>>
                >>>> BUT, when aprsis32 (station"LC5VNA") was sending a "test" message,
                >>>> thisappeared in the middle window of Multipsk:
                >>>> LC5VNA :LA5VNA :test{PU}HX
                >>>>
                >>>> When is UI-View32 (station "LA5VNA") was responding with an ack, this
                >>>> was appearing in the
                >>>> lower window of Multipsk on station"LC5VNA" :
                >>>>
                >>>> [End of TX] FAE APRS frame
                >>>> LA5VNA :LA5VNA :ackPU}HX [FAE APRS]
                >>>> ...KISS frame repeated
                >>>>
                >>>>
                >>>> The aprsis32 (station"LC5VNA") seems not to recognize ackPU}HX as an ACK
                >>>> so it keep repeating the "test" message until it times
                >>>>
                >>>> out.
                >>>>
                >>>>
                >>>> I was then trying with only UI-View32on both station"LC5VNA" and
                >>>> "LA5VNA" and everything works fine. With only aprsis32 there
                >>>>
                >>>> was absolutely no way of getting the stations to recognize the ACK's
                >>>>
                >>>> Does anyone have a clue of was going on ?
                >>>>
                >>>> If you want to try this , download latest ver of multipsk, but remember
                >>>> to read the "ALE_and_ALE400_APRS_with_UI-
                >>>>
                >>>> VIEW_through_Multipsk_easy.doc"
                >>>> https://dl.dropboxusercontent.com/u/16381257/MULTIPSK_TEST_16_05_2013.ZIP
                >>>>
                >>>>
                >>>> LA5VNA Steinar
                >>>> loc:JO59jq
                >>>>
                >>>>
                >>>>
                >>>>
                >>>> ------------------------------------
                >>>>
                >>>> Yahoo! Groups Links
                >>>>
                >>>>
                >>>>
                >>>>
                >>>
                >>> ------------------------------------
                >>>
                >>> Yahoo! Groups Links
                >>>
                >>>
                >>>
                >>
                >>
                >> ------------------------------------
                >>
                >> Yahoo! Groups Links
                >>
                >>
                >>
                >>
                >>
                >
                >
                > ------------------------------------
                >
                > Yahoo! Groups Links
                >
                >
                >
                >
              • Steinar Aanesland
                Thanks for quick reply :) Here is the log: 2013-05-22T19:48:03.408 Transmit(IS+RF) LA5VNA APWW10,WIDE1-1::LC5VNA ... 2013-05-22T19:48:11.704 Transmit(IS) Too
                Message 7 of 14 , May 22, 2013
                • 0 Attachment
                  Thanks for quick reply :)
                  Here is the log:


                  2013-05-22T19:48:03.408 Transmit(IS+RF) LA5VNA>APWW10,WIDE1-1::LC5VNA
                  :testing{AU}
                  2013-05-22T19:48:11.704 Transmit(IS) Too Soon (8297), RF-ing
                  LA5VNA>APWW10,WIDE1-1::LC5VNA :testing{AU}
                  2013-05-22T19:48:11.704 Transmit(RF) LA5VNA>APWW10,WIDE1-1::LC5VNA
                  :testing{AU}
                  2013-05-22T19:48:28.704 Transmit(IS) Too Soon (25291), RF-ing
                  LA5VNA>APWW10,WIDE1-1::LC5VNA :testing{AU}
                  2013-05-22T19:48:28.704 Transmit(RF) LA5VNA>APWW10,WIDE1-1::LC5VNA
                  :testing{AU}
                  2013-05-22T19:48:36.704 Transmit(IS+RF) LA5VNA>APWW10,WIDE1-1::LC5VNA
                  :testing{AU}


                  LA5VNA Steinar
                  loc:JO59jq


                  Den 22.05.2013 21:38, skrev Lynn W Deffenbaugh (Mr):
                  > See http://aprsisce.wikidot.com/message-retries
                  >
                  > If you're getting the first retry in 1 second, then I've got a bust
                  > somewhere. Can you bring up and enable the Transmit trace log to
                  > confirm or deny your message retry timings?
                  >
                  > Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
                  >
                  > PS. I didn't invent the initial 8 second retry delay either. See Bob's
                  > original page at
                  >
                  > http://aprs.org/txt/messages101.txt
                  >
                  > In fact, UI-View's 30 second initial retry falls under Bob's statement
                  > of "Not ONCE like most follow-on clones." in point # 2. UI-View
                  > sometimes isn't the "gold standard" of APRS implementation. At least,
                  > not in a universal opinion.
                  >
                  > On 5/22/2013 3:11 PM, Steinar Aanesland wrote:
                  >> Hi all
                  >>
                  >> After long time struggle , I finally got things working . Last night I
                  >> was starting from scratch setting up a completely new test installation,
                  >> and now station "LA5VNA" and station "LC5VNA" are now able to send a
                  >> message and than reply with an ACK.
                  >>
                  >> There is only one catch, it is only working nicely with UI-View32. When
                  >> I am sending a message with UI-View32 it goes about 30 seconds before
                  >> UI-View32 broadcast a new message. This is plenty of time for another
                  >> station to detect the message and reply with an ACK.
                  >>
                  >> When I am trying with my favorite APRS program aprsis32, aprsis32
                  >> sending a new message only 1 second after the first one. If the RX
                  >> station is able to detect the first message and reply with an ACK, this
                  >> ACK will never be detected because it collides with the second
                  >> retransmission of the message . This goes back and forth until a
                  >> collision is avoiding and the ACK, is detected .
                  >>
                  >> Is there a way to avoid the collision, or is this timing of the second
                  >> retransmission hard coded into aprsis32 ?
                  >>
                  >> LA5VNA Steinar
                  >> loc:JO59jq
                  >>
                  >>
                  >>
                  >>
                  >> Den 18.05.2013 15:59, skrev Steinar Aanesland:
                  >>> Lynn
                  >>>
                  >>>
                  >>> Thank for your reply. I will do some more testing and send you the log :)
                  >>>
                  >>>
                  >>> " Has anyone used MultiPSK's KISS mode for other APRS messaging? Is
                  >>> this even possible?" Yes, take a look at this youtube:
                  >>> http://www.youtube.com/watch?v=4lKbhtChkGw
                  >>>
                  >>> LA6VNA S
                  >>>
                  >>>
                  >>>
                  >>>
                  >>>
                  >>> On 18.05.2013 15:43, Lynn W Deffenbaugh (Mr) wrote:
                  >>>> Please bring up Enables / View Logs / Port(<YourRFPort>) and enable it
                  >>>> and do the message test again. I'm suspecting that something in the
                  >>>> chain is mucking about with the curly brace inside the ack sequence
                  >>>> which is the Reply-Ack protocol. This is supposed to be fully backward
                  >>>> compatible (I've had many QSOs with UI-View users), so it must be
                  >>>> something in the ALE/ARQ/MultiPSK chain that is introducing something
                  >>>> strange.
                  >>>>
                  >>>> If you also check Enables / Logging / File Enabled, then the trace from
                  >>>> above will also go into your APRSIS32.LOG file that you can send on to
                  >>>> KJ4ERJ@... with a reminder of what it is I'm looking at.
                  >>>>
                  >>>> While you've got it all put together, try messaging back and forth with
                  >>>> a UI-View station over the APRS-IS and/or standard packet just to show
                  >>>> that the same configuration of the stations (outside of the RF path)
                  >>>> truly does function. It's a case of "show what works" and then "what's
                  >>>> different" must be the source of the problem.
                  >>>>
                  >>>> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
                  >>>>
                  >>>> PS. Has anyone used MultiPSK's KISS mode for other APRS messaging? Is
                  >>>> this even possible?
                  >>>>
                  >>>> On 5/18/2013 7:56 AM, Steinar Aanesland wrote:
                  >>>>> Hi all ,I hope this is not to out of topic for this group.
                  >>>>>
                  >>>>> As some of you probably know, 300b packet is not the best choice on HF,
                  >>>>> but there are some alternatives.
                  >>>>> One of them is ALE400 . ALE400 is ARQ mode in Multipsk.
                  >>>>>
                  >>>>> I have made me a small lab testing out the ALE400/Multipsk software in
                  >>>>> KISS with aprsis32 and UI-View32.
                  >>>>>
                  >>>>> My lab is like this:
                  >>>>>
                  >>>>> I am using to PCes simulating station "LA5VNA" and station "LC5VNA".
                  >>>>> They are connecting together trough their mic's and they loudspeakers.
                  >>>>>
                  >>>>> I was first testing out a combination of
                  >>>>> Multipsk/KISS/UI-View32 on station "LA5VNA", and a combination of
                  >>>>> Multipsk/KISS/aprsis32 on station "LC5VNA".
                  >>>>>
                  >>>>> [Multipsk/KISS/UI-View32]<===mic's/loudspeakers==>[Multipsk/KISS/aprsis32]
                  >>>>>
                  >>>>> Beaconing was working great form station "a" and "b". Both maps was
                  >>>>> updated, but when trying the message function something
                  >>>>>
                  >>>>> strange was happening.
                  >>>>>
                  >>>>> When UI-View32 (station "LA5VNA") was sending a message like "test",
                  >>>>> this appeared in the middle window of multipsk:
                  >>>>> LA5VNA :LC5VNA :test{12
                  >>>>>
                  >>>>> When aprsis32 (station"LC5VNA") was responding with an ack, this was
                  >>>>> appearing in the
                  >>>>> lower window of multipsk on station"LA5VNA" :
                  >>>>>
                  >>>>> [End of TX] FAE APRS frame
                  >>>>> LC5VNA :LA5VNA :ack12 [FAE APRS]
                  >>>>> ...KISS frame repeated
                  >>>>>
                  >>>>> Station"LA5VNA" had got its ack and seems to be happy.
                  >>>>>
                  >>>>>
                  >>>>> BUT, when aprsis32 (station"LC5VNA") was sending a "test" message,
                  >>>>> thisappeared in the middle window of Multipsk:
                  >>>>> LC5VNA :LA5VNA :test{PU}HX
                  >>>>>
                  >>>>> When is UI-View32 (station "LA5VNA") was responding with an ack, this
                  >>>>> was appearing in the
                  >>>>> lower window of Multipsk on station"LC5VNA" :
                  >>>>>
                  >>>>> [End of TX] FAE APRS frame
                  >>>>> LA5VNA :LA5VNA :ackPU}HX [FAE APRS]
                  >>>>> ...KISS frame repeated
                  >>>>>
                  >>>>>
                  >>>>> The aprsis32 (station"LC5VNA") seems not to recognize ackPU}HX as an ACK
                  >>>>> so it keep repeating the "test" message until it times
                  >>>>>
                  >>>>> out.
                  >>>>>
                  >>>>>
                  >>>>> I was then trying with only UI-View32on both station"LC5VNA" and
                  >>>>> "LA5VNA" and everything works fine. With only aprsis32 there
                  >>>>>
                  >>>>> was absolutely no way of getting the stations to recognize the ACK's
                  >>>>>
                  >>>>> Does anyone have a clue of was going on ?
                  >>>>>
                  >>>>> If you want to try this , download latest ver of multipsk, but remember
                  >>>>> to read the "ALE_and_ALE400_APRS_with_UI-
                  >>>>>
                  >>>>> VIEW_through_Multipsk_easy.doc"
                  >>>>> https://dl.dropboxusercontent.com/u/16381257/MULTIPSK_TEST_16_05_2013.ZIP
                  >>>>>
                  >>>>>
                  >>>>> LA5VNA Steinar
                  >>>>> loc:JO59jq
                  >>>>>
                  >>>>>
                  >>>>>
                  >>>>>
                  >>>>> ------------------------------------
                  >>>>>
                  >>>>> Yahoo! Groups Links
                  >>>>>
                  >>>>>
                  >>>>>
                  >>>>>
                  >>>>
                  >>>> ------------------------------------
                  >>>>
                  >>>> Yahoo! Groups Links
                  >>>>
                  >>>>
                  >>>>
                  >>>
                  >>>
                  >>> ------------------------------------
                  >>>
                  >>> Yahoo! Groups Links
                  >>>
                  >>>
                  >>>
                  >>>
                  >>>
                  >>
                  >>
                  >> ------------------------------------
                  >>
                  >> Yahoo! Groups Links
                  >>
                  >>
                  >>
                  >>
                  >
                  >
                  >
                  > ------------------------------------
                  >
                  > Yahoo! Groups Links
                  >
                  >
                  >
                  >
                  >
                • Lynn W Deffenbaugh (Mr)
                  19:48:03 - Initial transmission to both IS and RF 19:48:11 - 8 seconds later - Transmission only to RF because too soon for -IS 19:48:28 - 17 seconds later yet
                  Message 8 of 14 , May 22, 2013
                  • 0 Attachment
                    19:48:03 - Initial transmission to both IS and RF
                    19:48:11 - 8 seconds later - Transmission only to RF because too soon
                    for -IS
                    19:48:28 - 17 seconds later yet - Transmission again only to RF (only 25
                    seconds since -IS)
                    19:48:36 - 8 seconds later yet to both IS and RF being 33 seconds past
                    the -IS dupe window

                    Yep, WAD - Working As Designed. 8+16+8+32+64+96+128 are the retry delays.

                    How long does your new HF modulation take to actually transmit the message?

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

                    On 5/22/2013 3:50 PM, Steinar Aanesland wrote:
                    > Thanks for quick reply :)
                    > Here is the log:
                    >
                    >
                    > 2013-05-22T19:48:03.408 Transmit(IS+RF) LA5VNA>APWW10,WIDE1-1::LC5VNA
                    > :testing{AU}
                    > 2013-05-22T19:48:11.704 Transmit(IS) Too Soon (8297), RF-ing
                    > LA5VNA>APWW10,WIDE1-1::LC5VNA :testing{AU}
                    > 2013-05-22T19:48:11.704 Transmit(RF) LA5VNA>APWW10,WIDE1-1::LC5VNA
                    > :testing{AU}
                    > 2013-05-22T19:48:28.704 Transmit(IS) Too Soon (25291), RF-ing
                    > LA5VNA>APWW10,WIDE1-1::LC5VNA :testing{AU}
                    > 2013-05-22T19:48:28.704 Transmit(RF) LA5VNA>APWW10,WIDE1-1::LC5VNA
                    > :testing{AU}
                    > 2013-05-22T19:48:36.704 Transmit(IS+RF) LA5VNA>APWW10,WIDE1-1::LC5VNA
                    > :testing{AU}
                    >
                    >
                    > LA5VNA Steinar
                    > loc:JO59jq
                    >
                    >
                    > Den 22.05.2013 21:38, skrev Lynn W Deffenbaugh (Mr):
                    >> See http://aprsisce.wikidot.com/message-retries
                    >>
                    >> If you're getting the first retry in 1 second, then I've got a bust
                    >> somewhere. Can you bring up and enable the Transmit trace log to
                    >> confirm or deny your message retry timings?
                    >>
                    >> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
                    >>
                    >> PS. I didn't invent the initial 8 second retry delay either. See Bob's
                    >> original page at
                    >>
                    >> http://aprs.org/txt/messages101.txt
                    >>
                    >> In fact, UI-View's 30 second initial retry falls under Bob's statement
                    >> of "Not ONCE like most follow-on clones." in point # 2. UI-View
                    >> sometimes isn't the "gold standard" of APRS implementation. At least,
                    >> not in a universal opinion.
                    >>
                    >> On 5/22/2013 3:11 PM, Steinar Aanesland wrote:
                    >>> Hi all
                    >>>
                    >>> After long time struggle , I finally got things working . Last night I
                    >>> was starting from scratch setting up a completely new test installation,
                    >>> and now station "LA5VNA" and station "LC5VNA" are now able to send a
                    >>> message and than reply with an ACK.
                    >>>
                    >>> There is only one catch, it is only working nicely with UI-View32. When
                    >>> I am sending a message with UI-View32 it goes about 30 seconds before
                    >>> UI-View32 broadcast a new message. This is plenty of time for another
                    >>> station to detect the message and reply with an ACK.
                    >>>
                    >>> When I am trying with my favorite APRS program aprsis32, aprsis32
                    >>> sending a new message only 1 second after the first one. If the RX
                    >>> station is able to detect the first message and reply with an ACK, this
                    >>> ACK will never be detected because it collides with the second
                    >>> retransmission of the message . This goes back and forth until a
                    >>> collision is avoiding and the ACK, is detected .
                    >>>
                    >>> Is there a way to avoid the collision, or is this timing of the second
                    >>> retransmission hard coded into aprsis32 ?
                    >>>
                    >>> LA5VNA Steinar
                    >>> loc:JO59jq
                    >>>
                    >>>
                    >>>
                    >>>
                    >>> Den 18.05.2013 15:59, skrev Steinar Aanesland:
                    >>>> Lynn
                    >>>>
                    >>>>
                    >>>> Thank for your reply. I will do some more testing and send you the log :)
                    >>>>
                    >>>>
                    >>>> " Has anyone used MultiPSK's KISS mode for other APRS messaging? Is
                    >>>> this even possible?" Yes, take a look at this youtube:
                    >>>> http://www.youtube.com/watch?v=4lKbhtChkGw
                    >>>>
                    >>>> LA6VNA S
                    >>>>
                    >>>>
                    >>>>
                    >>>>
                    >>>>
                    >>>> On 18.05.2013 15:43, Lynn W Deffenbaugh (Mr) wrote:
                    >>>>> Please bring up Enables / View Logs / Port(<YourRFPort>) and enable it
                    >>>>> and do the message test again. I'm suspecting that something in the
                    >>>>> chain is mucking about with the curly brace inside the ack sequence
                    >>>>> which is the Reply-Ack protocol. This is supposed to be fully backward
                    >>>>> compatible (I've had many QSOs with UI-View users), so it must be
                    >>>>> something in the ALE/ARQ/MultiPSK chain that is introducing something
                    >>>>> strange.
                    >>>>>
                    >>>>> If you also check Enables / Logging / File Enabled, then the trace from
                    >>>>> above will also go into your APRSIS32.LOG file that you can send on to
                    >>>>> KJ4ERJ@... with a reminder of what it is I'm looking at.
                    >>>>>
                    >>>>> While you've got it all put together, try messaging back and forth with
                    >>>>> a UI-View station over the APRS-IS and/or standard packet just to show
                    >>>>> that the same configuration of the stations (outside of the RF path)
                    >>>>> truly does function. It's a case of "show what works" and then "what's
                    >>>>> different" must be the source of the problem.
                    >>>>>
                    >>>>> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
                    >>>>>
                    >>>>> PS. Has anyone used MultiPSK's KISS mode for other APRS messaging? Is
                    >>>>> this even possible?
                    >>>>>
                    >>>>> On 5/18/2013 7:56 AM, Steinar Aanesland wrote:
                    >>>>>> Hi all ,I hope this is not to out of topic for this group.
                    >>>>>>
                    >>>>>> As some of you probably know, 300b packet is not the best choice on HF,
                    >>>>>> but there are some alternatives.
                    >>>>>> One of them is ALE400 . ALE400 is ARQ mode in Multipsk.
                    >>>>>>
                    >>>>>> I have made me a small lab testing out the ALE400/Multipsk software in
                    >>>>>> KISS with aprsis32 and UI-View32.
                    >>>>>>
                    >>>>>> My lab is like this:
                    >>>>>>
                    >>>>>> I am using to PCes simulating station "LA5VNA" and station "LC5VNA".
                    >>>>>> They are connecting together trough their mic's and they loudspeakers.
                    >>>>>>
                    >>>>>> I was first testing out a combination of
                    >>>>>> Multipsk/KISS/UI-View32 on station "LA5VNA", and a combination of
                    >>>>>> Multipsk/KISS/aprsis32 on station "LC5VNA".
                    >>>>>>
                    >>>>>> [Multipsk/KISS/UI-View32]<===mic's/loudspeakers==>[Multipsk/KISS/aprsis32]
                    >>>>>>
                    >>>>>> Beaconing was working great form station "a" and "b". Both maps was
                    >>>>>> updated, but when trying the message function something
                    >>>>>>
                    >>>>>> strange was happening.
                    >>>>>>
                    >>>>>> When UI-View32 (station "LA5VNA") was sending a message like "test",
                    >>>>>> this appeared in the middle window of multipsk:
                    >>>>>> LA5VNA :LC5VNA :test{12
                    >>>>>>
                    >>>>>> When aprsis32 (station"LC5VNA") was responding with an ack, this was
                    >>>>>> appearing in the
                    >>>>>> lower window of multipsk on station"LA5VNA" :
                    >>>>>>
                    >>>>>> [End of TX] FAE APRS frame
                    >>>>>> LC5VNA :LA5VNA :ack12 [FAE APRS]
                    >>>>>> ...KISS frame repeated
                    >>>>>>
                    >>>>>> Station"LA5VNA" had got its ack and seems to be happy.
                    >>>>>>
                    >>>>>>
                    >>>>>> BUT, when aprsis32 (station"LC5VNA") was sending a "test" message,
                    >>>>>> thisappeared in the middle window of Multipsk:
                    >>>>>> LC5VNA :LA5VNA :test{PU}HX
                    >>>>>>
                    >>>>>> When is UI-View32 (station "LA5VNA") was responding with an ack, this
                    >>>>>> was appearing in the
                    >>>>>> lower window of Multipsk on station"LC5VNA" :
                    >>>>>>
                    >>>>>> [End of TX] FAE APRS frame
                    >>>>>> LA5VNA :LA5VNA :ackPU}HX [FAE APRS]
                    >>>>>> ...KISS frame repeated
                    >>>>>>
                    >>>>>>
                    >>>>>> The aprsis32 (station"LC5VNA") seems not to recognize ackPU}HX as an ACK
                    >>>>>> so it keep repeating the "test" message until it times
                    >>>>>>
                    >>>>>> out.
                    >>>>>>
                    >>>>>>
                    >>>>>> I was then trying with only UI-View32on both station"LC5VNA" and
                    >>>>>> "LA5VNA" and everything works fine. With only aprsis32 there
                    >>>>>>
                    >>>>>> was absolutely no way of getting the stations to recognize the ACK's
                    >>>>>>
                    >>>>>> Does anyone have a clue of was going on ?
                    >>>>>>
                    >>>>>> If you want to try this , download latest ver of multipsk, but remember
                    >>>>>> to read the "ALE_and_ALE400_APRS_with_UI-
                    >>>>>>
                    >>>>>> VIEW_through_Multipsk_easy.doc"
                    >>>>>> https://dl.dropboxusercontent.com/u/16381257/MULTIPSK_TEST_16_05_2013.ZIP
                    >>>>>>
                    >>>>>>
                    >>>>>> LA5VNA Steinar
                    >>>>>> loc:JO59jq
                    >>>>>>
                    >>>>>>
                    >>>>>>
                    >>>>>>
                    >>>>>> ------------------------------------
                    >>>>>>
                    >>>>>> Yahoo! Groups Links
                    >>>>>>
                    >>>>>>
                    >>>>>>
                    >>>>>>
                    >>>>> ------------------------------------
                    >>>>>
                    >>>>> Yahoo! Groups Links
                    >>>>>
                    >>>>>
                    >>>>>
                    >>>>
                    >>>> ------------------------------------
                    >>>>
                    >>>> Yahoo! Groups Links
                    >>>>
                    >>>>
                    >>>>
                    >>>>
                    >>>>
                    >>>
                    >>> ------------------------------------
                    >>>
                    >>> Yahoo! Groups Links
                    >>>
                    >>>
                    >>>
                    >>>
                    >>
                    >>
                    >> ------------------------------------
                    >>
                    >> Yahoo! Groups Links
                    >>
                    >>
                    >>
                    >>
                    >>
                    >
                  • Steinar Aanesland
                    A text with 67 characters will take about 15 seconds. LA5VNA Steinar loc:JO59jq
                    Message 9 of 14 , May 22, 2013
                    • 0 Attachment
                      A text with 67 characters will take about 15 seconds.


                      LA5VNA Steinar
                      loc:JO59jq


                      Den 22.05.2013 22:07, skrev Lynn W Deffenbaugh (Mr):
                      > 19:48:03 - Initial transmission to both IS and RF
                      > 19:48:11 - 8 seconds later - Transmission only to RF because too soon
                      > for -IS
                      > 19:48:28 - 17 seconds later yet - Transmission again only to RF (only 25
                      > seconds since -IS)
                      > 19:48:36 - 8 seconds later yet to both IS and RF being 33 seconds past
                      > the -IS dupe window
                      >
                      > Yep, WAD - Working As Designed. 8+16+8+32+64+96+128 are the retry delays.
                      >
                      > How long does your new HF modulation take to actually transmit the message?
                      >
                      > Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
                      >
                      > On 5/22/2013 3:50 PM, Steinar Aanesland wrote:
                      >> Thanks for quick reply :)
                      >> Here is the log:
                      >>
                      >>
                      >> 2013-05-22T19:48:03.408 Transmit(IS+RF) LA5VNA>APWW10,WIDE1-1::LC5VNA
                      >> :testing{AU}
                      >> 2013-05-22T19:48:11.704 Transmit(IS) Too Soon (8297), RF-ing
                      >> LA5VNA>APWW10,WIDE1-1::LC5VNA :testing{AU}
                      >> 2013-05-22T19:48:11.704 Transmit(RF) LA5VNA>APWW10,WIDE1-1::LC5VNA
                      >> :testing{AU}
                      >> 2013-05-22T19:48:28.704 Transmit(IS) Too Soon (25291), RF-ing
                      >> LA5VNA>APWW10,WIDE1-1::LC5VNA :testing{AU}
                      >> 2013-05-22T19:48:28.704 Transmit(RF) LA5VNA>APWW10,WIDE1-1::LC5VNA
                      >> :testing{AU}
                      >> 2013-05-22T19:48:36.704 Transmit(IS+RF) LA5VNA>APWW10,WIDE1-1::LC5VNA
                      >> :testing{AU}
                      >>
                      >>
                      >> LA5VNA Steinar
                      >> loc:JO59jq
                      >>
                      >>
                      >> Den 22.05.2013 21:38, skrev Lynn W Deffenbaugh (Mr):
                      >>> See http://aprsisce.wikidot.com/message-retries
                      >>>
                      >>> If you're getting the first retry in 1 second, then I've got a bust
                      >>> somewhere. Can you bring up and enable the Transmit trace log to
                      >>> confirm or deny your message retry timings?
                      >>>
                      >>> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
                      >>>
                      >>> PS. I didn't invent the initial 8 second retry delay either. See Bob's
                      >>> original page at
                      >>>
                      >>> http://aprs.org/txt/messages101.txt
                      >>>
                      >>> In fact, UI-View's 30 second initial retry falls under Bob's statement
                      >>> of "Not ONCE like most follow-on clones." in point # 2. UI-View
                      >>> sometimes isn't the "gold standard" of APRS implementation. At least,
                      >>> not in a universal opinion.
                      >>>
                      >>> On 5/22/2013 3:11 PM, Steinar Aanesland wrote:
                      >>>> Hi all
                      >>>>
                      >>>> After long time struggle , I finally got things working . Last night I
                      >>>> was starting from scratch setting up a completely new test installation,
                      >>>> and now station "LA5VNA" and station "LC5VNA" are now able to send a
                      >>>> message and than reply with an ACK.
                      >>>>
                      >>>> There is only one catch, it is only working nicely with UI-View32. When
                      >>>> I am sending a message with UI-View32 it goes about 30 seconds before
                      >>>> UI-View32 broadcast a new message. This is plenty of time for another
                      >>>> station to detect the message and reply with an ACK.
                      >>>>
                      >>>> When I am trying with my favorite APRS program aprsis32, aprsis32
                      >>>> sending a new message only 1 second after the first one. If the RX
                      >>>> station is able to detect the first message and reply with an ACK, this
                      >>>> ACK will never be detected because it collides with the second
                      >>>> retransmission of the message . This goes back and forth until a
                      >>>> collision is avoiding and the ACK, is detected .
                      >>>>
                      >>>> Is there a way to avoid the collision, or is this timing of the second
                      >>>> retransmission hard coded into aprsis32 ?
                      >>>>
                      >>>> LA5VNA Steinar
                      >>>> loc:JO59jq
                      >>>>
                      >>>>
                      >>>>
                      >>>>
                      >>>> Den 18.05.2013 15:59, skrev Steinar Aanesland:
                      >>>>> Lynn
                      >>>>>
                      >>>>>
                      >>>>> Thank for your reply. I will do some more testing and send you the log :)
                      >>>>>
                      >>>>>
                      >>>>> " Has anyone used MultiPSK's KISS mode for other APRS messaging? Is
                      >>>>> this even possible?" Yes, take a look at this youtube:
                      >>>>> http://www.youtube.com/watch?v=4lKbhtChkGw
                      >>>>>
                      >>>>> LA6VNA S
                      >>>>>
                      >>>>>
                      >>>>>
                      >>>>>
                      >>>>>
                      >>>>> On 18.05.2013 15:43, Lynn W Deffenbaugh (Mr) wrote:
                      >>>>>> Please bring up Enables / View Logs / Port(<YourRFPort>) and enable it
                      >>>>>> and do the message test again. I'm suspecting that something in the
                      >>>>>> chain is mucking about with the curly brace inside the ack sequence
                      >>>>>> which is the Reply-Ack protocol. This is supposed to be fully backward
                      >>>>>> compatible (I've had many QSOs with UI-View users), so it must be
                      >>>>>> something in the ALE/ARQ/MultiPSK chain that is introducing something
                      >>>>>> strange.
                      >>>>>>
                      >>>>>> If you also check Enables / Logging / File Enabled, then the trace from
                      >>>>>> above will also go into your APRSIS32.LOG file that you can send on to
                      >>>>>> KJ4ERJ@... with a reminder of what it is I'm looking at.
                      >>>>>>
                      >>>>>> While you've got it all put together, try messaging back and forth with
                      >>>>>> a UI-View station over the APRS-IS and/or standard packet just to show
                      >>>>>> that the same configuration of the stations (outside of the RF path)
                      >>>>>> truly does function. It's a case of "show what works" and then "what's
                      >>>>>> different" must be the source of the problem.
                      >>>>>>
                      >>>>>> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
                      >>>>>>
                      >>>>>> PS. Has anyone used MultiPSK's KISS mode for other APRS messaging? Is
                      >>>>>> this even possible?
                      >>>>>>
                      >>>>>> On 5/18/2013 7:56 AM, Steinar Aanesland wrote:
                      >>>>>>> Hi all ,I hope this is not to out of topic for this group.
                      >>>>>>>
                      >>>>>>> As some of you probably know, 300b packet is not the best choice on HF,
                      >>>>>>> but there are some alternatives.
                      >>>>>>> One of them is ALE400 . ALE400 is ARQ mode in Multipsk.
                      >>>>>>>
                      >>>>>>> I have made me a small lab testing out the ALE400/Multipsk software in
                      >>>>>>> KISS with aprsis32 and UI-View32.
                      >>>>>>>
                      >>>>>>> My lab is like this:
                      >>>>>>>
                      >>>>>>> I am using to PCes simulating station "LA5VNA" and station "LC5VNA".
                      >>>>>>> They are connecting together trough their mic's and they loudspeakers.
                      >>>>>>>
                      >>>>>>> I was first testing out a combination of
                      >>>>>>> Multipsk/KISS/UI-View32 on station "LA5VNA", and a combination of
                      >>>>>>> Multipsk/KISS/aprsis32 on station "LC5VNA".
                      >>>>>>>
                      >>>>>>> [Multipsk/KISS/UI-View32]<===mic's/loudspeakers==>[Multipsk/KISS/aprsis32]
                      >>>>>>>
                      >>>>>>> Beaconing was working great form station "a" and "b". Both maps was
                      >>>>>>> updated, but when trying the message function something
                      >>>>>>>
                      >>>>>>> strange was happening.
                      >>>>>>>
                      >>>>>>> When UI-View32 (station "LA5VNA") was sending a message like "test",
                      >>>>>>> this appeared in the middle window of multipsk:
                      >>>>>>> LA5VNA :LC5VNA :test{12
                      >>>>>>>
                      >>>>>>> When aprsis32 (station"LC5VNA") was responding with an ack, this was
                      >>>>>>> appearing in the
                      >>>>>>> lower window of multipsk on station"LA5VNA" :
                      >>>>>>>
                      >>>>>>> [End of TX] FAE APRS frame
                      >>>>>>> LC5VNA :LA5VNA :ack12 [FAE APRS]
                      >>>>>>> ...KISS frame repeated
                      >>>>>>>
                      >>>>>>> Station"LA5VNA" had got its ack and seems to be happy.
                      >>>>>>>
                      >>>>>>>
                      >>>>>>> BUT, when aprsis32 (station"LC5VNA") was sending a "test" message,
                      >>>>>>> thisappeared in the middle window of Multipsk:
                      >>>>>>> LC5VNA :LA5VNA :test{PU}HX
                      >>>>>>>
                      >>>>>>> When is UI-View32 (station "LA5VNA") was responding with an ack, this
                      >>>>>>> was appearing in the
                      >>>>>>> lower window of Multipsk on station"LC5VNA" :
                      >>>>>>>
                      >>>>>>> [End of TX] FAE APRS frame
                      >>>>>>> LA5VNA :LA5VNA :ackPU}HX [FAE APRS]
                      >>>>>>> ...KISS frame repeated
                      >>>>>>>
                      >>>>>>>
                      >>>>>>> The aprsis32 (station"LC5VNA") seems not to recognize ackPU}HX as an ACK
                      >>>>>>> so it keep repeating the "test" message until it times
                      >>>>>>>
                      >>>>>>> out.
                      >>>>>>>
                      >>>>>>>
                      >>>>>>> I was then trying with only UI-View32on both station"LC5VNA" and
                      >>>>>>> "LA5VNA" and everything works fine. With only aprsis32 there
                      >>>>>>>
                      >>>>>>> was absolutely no way of getting the stations to recognize the ACK's
                      >>>>>>>
                      >>>>>>> Does anyone have a clue of was going on ?
                      >>>>>>>
                      >>>>>>> If you want to try this , download latest ver of multipsk, but remember
                      >>>>>>> to read the "ALE_and_ALE400_APRS_with_UI-
                      >>>>>>>
                      >>>>>>> VIEW_through_Multipsk_easy.doc"
                      >>>>>>> https://dl.dropboxusercontent.com/u/16381257/MULTIPSK_TEST_16_05_2013.ZIP
                      >>>>>>>
                      >>>>>>>
                      >>>>>>> LA5VNA Steinar
                      >>>>>>> loc:JO59jq
                      >>>>>>>
                      >>>>>>>
                      >>>>>>>
                      >>>>>>>
                      >>>>>>> ------------------------------------
                      >>>>>>>
                      >>>>>>> Yahoo! Groups Links
                      >>>>>>>
                      >>>>>>>
                      >>>>>>>
                      >>>>>>>
                      >>>>>> ------------------------------------
                      >>>>>>
                      >>>>>> Yahoo! Groups Links
                      >>>>>>
                      >>>>>>
                      >>>>>>
                      >>>>>
                      >>>>> ------------------------------------
                      >>>>>
                      >>>>> Yahoo! Groups Links
                      >>>>>
                      >>>>>
                      >>>>>
                      >>>>>
                      >>>>>
                      >>>>
                      >>>> ------------------------------------
                      >>>>
                      >>>> Yahoo! Groups Links
                      >>>>
                      >>>>
                      >>>>
                      >>>>
                      >>>
                      >>>
                      >>> ------------------------------------
                      >>>
                      >>> Yahoo! Groups Links
                      >>>
                      >>>
                      >>>
                      >>>
                      >>>
                      >>
                      >
                      >
                      >
                      > ------------------------------------
                      >
                      > Yahoo! Groups Links
                      >
                      >
                      >
                      >
                      >
                    • Steve Daniels
                      I think when Lynn gets around to doing something with the RF baud rate setting; adjusting the retry timings to account for baud rate might be a good idea Steve
                      Message 10 of 14 , May 22, 2013
                      • 0 Attachment

                        I think when Lynn gets around to doing something with the RF baud rate setting; adjusting the retry timings to account for baud rate might be a good idea

                         

                        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 Steinar Aanesland
                        Sent: 22 May 2013 21:25
                        To: aprsisce@yahoogroups.com
                        Subject: Re: [aprsisce] Trying out a new mode with aprsis32 and multipsk in KISS on HF

                         

                         

                        A text with 67 characters will take about 15 seconds.

                        LA5VNA Steinar
                        loc:JO59jq

                        Den 22.05.2013 22:07, skrev Lynn W Deffenbaugh (Mr):

                        > 19:48:03 - Initial transmission to both IS and RF
                        > 19:48:11 - 8 seconds later - Transmission only to RF because too soon
                        > for -IS
                        > 19:48:28 - 17 seconds later yet - Transmission again only to RF (only 25
                        > seconds since -IS)
                        > 19:48:36 - 8 seconds later yet to both IS and RF being 33 seconds past
                        > the -IS dupe window
                        >
                        > Yep, WAD - Working As Designed. 8+16+8+32+64+96+128 are the retry delays.
                        >
                        > How long does your new HF modulation take to actually transmit the
                        message?
                        >
                        > Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows
                        w:st="on">Mobile and Win32
                        >
                        > On 5/22/2013 3:50 PM, Steinar Aanesland wrote:
                        >> Thanks for quick reply :)
                        >> Here is the log:
                        >>
                        >>
                        >> 2013-05-22T19:48:03.408 Transmit(IS+RF)
                        LA5VNA>APWW10,WIDE1-1::LC5VNA
                        >> :testing{AU}
                        >> 2013-05-22T19:48:11.704 Transmit(IS) Too Soon (8297), RF-ing
                        >> LA5VNA>APWW10,WIDE1-1::LC5VNA :testing{AU}
                        >> 2013-05-22T19:48:11.704 Transmit(RF) LA5VNA>APWW10,WIDE1-1::LC5VNA
                        >> :testing{AU}
                        >> 2013-05-22T19:48:28.704 Transmit(IS) Too Soon (25291), RF-ing
                        >> LA5VNA>APWW10,WIDE1-1::LC5VNA :testing{AU}
                        >> 2013-05-22T19:48:28.704 Transmit(RF) LA5VNA>APWW10,WIDE1-1::LC5VNA
                        >> :testing{AU}
                        >> 2013-05-22T19:48:36.704 Transmit(IS+RF)
                        LA5VNA>APWW10,WIDE1-1::LC5VNA
                        >> :testing{AU}
                        >>
                        >>
                        >> LA5VNA Steinar
                        >> loc:JO59jq
                        >>
                        >>
                        >> Den 22.05.2013 21:38, skrev Lynn W Deffenbaugh (Mr):
                        >>> See http://aprsisce.wikidot.com/message-retries
                        >>>
                        >>> If you're getting the first retry in 1 second, then I've got a
                        bust
                        >>> somewhere. Can you bring up and enable the Transmit trace log to
                        >>> confirm or deny your message retry timings?
                        >>>
                        >>> Lynn (D) - KJ4ERJ - Author of
                        APRSISCE for Windows Mobile and Win32
                        >>>
                        >>> PS. I didn't invent the initial 8 second retry delay either. See
                        Bob's
                        >>> original page at
                        >>>
                        >>> http://aprs.org/txt/messages101.txt
                        >>>
                        >>> In fact, UI-View's 30 second initial retry falls under Bob's
                        statement
                        >>> of "Not ONCE like most follow-on clones." in point # 2.
                        UI-View
                        >>> sometimes isn't the "gold standard" of APRS
                        implementation. At least,
                        >>> not in a universal opinion.
                        >>>
                        >>> On 5/22/2013 3:11 PM, Steinar Aanesland wrote:
                        >>>> Hi all
                        >>>>
                        >>>> After long time struggle , I finally got things working . Last
                        night I
                        >>>> was starting from scratch setting up a completely new test
                        installation,
                        >>>> and now station "LA5VNA" and station
                        "LC5VNA" are now able to send a
                        >>>> message and than reply with an ACK.
                        >>>>
                        >>>> There is only one catch, it is only working nicely with
                        UI-View32. When
                        >>>> I am sending a message with UI-View32 it goes about 30 seconds
                        before
                        >>>> UI-View32 broadcast a new message. This is plenty of time for
                        another
                        >>>> station to detect the message and reply with an ACK.
                        >>>>
                        >>>> When I am trying with my favorite APRS program aprsis32, aprsis32
                        >>>> sending a new message only 1 second after the first one. If
                        the RX
                        >>>> station is able to detect the first message and reply with an
                        ACK, this
                        >>>> ACK will never be detected because it collides with the second
                        >>>> retransmission of the message . This goes back and forth until
                        a
                        >>>> collision is avoiding and the ACK, is detected .
                        >>>>
                        >>>> Is there a way to avoid the collision, or is this timing of
                        the second
                        >>>> retransmission hard coded into aprsis32 ?
                        >>>>
                        >>>> LA5VNA Steinar
                        >>>> loc:JO59jq
                        >>>>
                        >>>>
                        >>>>
                        >>>>
                        >>>> Den 18.05.2013 15:59, skrev Steinar Aanesland:
                        >>>>> Lynn
                        >>>>>
                        >>>>>
                        >>>>> Thank for your reply. I will do some more testing and send
                        you the log :)
                        >>>>>
                        >>>>>
                        >>>>> " Has anyone used MultiPSK's KISS mode for other APRS
                        messaging? Is
                        >>>>> this even possible?" Yes, take a look at this
                        youtube:
                        >>>>> http://www.youtube.com/watch?v=4lKbhtChkGw
                        >>>>>
                        >>>>> LA6VNA S
                        >>>>>
                        >>>>>
                        >>>>>
                        >>>>>
                        >>>>>
                        >>>>> On 18.05.2013 15:43, Lynn W Deffenbaugh (Mr) wrote:
                        >>>>>> Please bring up Enables / View Logs /
                        Port(<YourRFPort>) and enable it
                        >>>>>> and do the message test again. I'm suspecting that
                        something in the
                        >>>>>> chain is mucking about with the curly brace inside the
                        ack sequence
                        >>>>>> which is the Reply-Ack protocol. This is supposed to
                        be fully backward
                        >>>>>> compatible (I've had many QSOs with UI-View users), so
                        it must be
                        >>>>>> something in the ALE/ARQ/MultiPSK chain that is
                        introducing something
                        >>>>>> strange.
                        >>>>>>
                        >>>>>> If you also check Enables / Logging / File Enabled,
                        then the trace from
                        >>>>>> above will also go into your APRSIS32.LOG file that
                        you can send on to
                        >>>>>> KJ4ERJ@...
                        with a reminder of what it is I'm looking at.
                        >>>>>>
                        >>>>>> While you've got it all put together, try messaging
                        back and forth with
                        >>>>>> a UI-View station over the APRS-IS and/or standard
                        packet just to show
                        >>>>>> that the same configuration of the stations (outside
                        of the RF path)
                        >>>>>> truly does function. It's a case of "show what
                        works" and then "what's
                        >>>>>> different" must be the source of the problem.
                        >>>>>>
                        >>>>>> Lynn (D) - KJ4ERJ -
                        Author of APRSISCE for Windows Mobile and Win32
                        >>>>>>
                        >>>>>> PS. Has anyone used MultiPSK's KISS mode for other
                        APRS messaging? Is
                        >>>>>> this even possible?
                        >>>>>>
                        >>>>>> On 5/18/2013 7:56 AM, Steinar Aanesland wrote:
                        >>>>>>> Hi all ,I hope this is not to out of topic for
                        this group.
                        >>>>>>>
                        >>>>>>> As some of you probably know, 300b packet is not
                        the best choice on HF,
                        >>>>>>> but there are some alternatives.
                        >>>>>>> One of them is ALE400 . ALE400 is ARQ mode in
                        Multipsk.
                        >>>>>>>
                        >>>>>>> I have made me a small lab testing out the
                        ALE400/Multipsk software in
                        >>>>>>> KISS with aprsis32 and UI-View32.
                        >>>>>>>
                        >>>>>>> My lab is like this:
                        >>>>>>>
                        >>>>>>> I am using to PCes simulating station
                        "LA5VNA" and station "LC5VNA".
                        >>>>>>> They are connecting together trough their mic's
                        and they loudspeakers.
                        >>>>>>>
                        >>>>>>> I was first testing out a combination of
                        >>>>>>> Multipsk/KISS/UI-View32 on station
                        "LA5VNA", and a combination of
                        >>>>>>> Multipsk/KISS/aprsis32 on station
                        "LC5VNA".
                        >>>>>>>
                        >>>>>>>
                        [Multipsk/KISS/UI-View32]<===mic's/loudspeakers==>[Multipsk/KISS/aprsis32]
                        >>>>>>>
                        >>>>>>> Beaconing was working great form station
                        "a" and "b". Both maps was
                        >>>>>>> updated, but when trying the message function
                        something
                        >>>>>>>
                        >>>>>>> strange was happening.
                        >>>>>>>
                        >>>>>>> When UI-View32 (station "LA5VNA") was
                        sending a message like "test",
                        >>>>>>> this appeared in the middle window of multipsk:
                        >>>>>>> LA5VNA :LC5VNA :test{12
                        >>>>>>>
                        >>>>>>> When aprsis32 (station"LC5VNA") was
                        responding with an ack, this was
                        >>>>>>> appearing in the
                        >>>>>>> lower window of multipsk on
                        station"LA5VNA" :
                        >>>>>>>
                        >>>>>>> [End of TX] FAE APRS frame
                        >>>>>>> LC5VNA :LA5VNA :ack12 [FAE APRS]
                        >>>>>>> ...KISS frame repeated
                        >>>>>>>
                        >>>>>>> Station"LA5VNA" had got its ack and
                        seems to be happy.
                        >>>>>>>
                        >>>>>>>
                        >>>>>>> BUT, when aprsis32 (station"LC5VNA") was
                        sending a "test" message,
                        >>>>>>> thisappeared in the middle window of Multipsk:
                        >>>>>>> LC5VNA :LA5VNA :test{PU}HX
                        >>>>>>>
                        >>>>>>> When is UI-View32 (station "LA5VNA") was
                        responding with an ack, this
                        >>>>>>> was appearing in the
                        >>>>>>> lower window of Multipsk on
                        station"LC5VNA" :
                        >>>>>>>
                        >>>>>>> [End of TX] FAE APRS frame
                        >>>>>>> LA5VNA :LA5VNA :ackPU}HX [FAE APRS]
                        >>>>>>> ...KISS frame repeated
                        >>>>>>>
                        >>>>>>>
                        >>>>>>> The aprsis32 (station"LC5VNA") seems not
                        to recognize ackPU}HX as an ACK
                        >>>>>>> so it keep repeating the "test" message
                        until it times
                        >>>>>>>
                        >>>>>>> out.
                        >>>>>>>
                        >>>>>>>
                        >>>>>>> I was then trying with only UI-View32on both
                        station"LC5VNA" and
                        >>>>>>> "LA5VNA" and everything works fine. With
                        only aprsis32 there
                        >>>>>>>
                        >>>>>>> was absolutely no way of getting the stations to
                        recognize the ACK's
                        >>>>>>>
                        >>>>>>> Does anyone have a clue of was going on ?
                        >>>>>>>
                        >>>>>>> If you want to try this , download latest ver of
                        multipsk, but remember
                        >>>>>>> to read the "ALE_and_ALE400_APRS_with_UI-
                        >>>>>>>
                        >>>>>>> VIEW_through_Multipsk_easy.doc"
                        >>>>>>>
                        href="https://dl.dropboxusercontent.com/u/16381257/MULTIPSK_TEST_16_05_2013.ZIP">https://dl.dropboxusercontent.com/u/16381257/MULTIPSK_TEST_16_05_2013.ZIP
                        >>>>>>>
                        >>>>>>>
                        >>>>>>> LA5VNA Steinar
                        >>>>>>> loc:JO59jq
                        >>>>>>>
                        >>>>>>>
                        >>>>>>>
                        >>>>>>>
                        >>>>>>> ------------------------------------
                        >>>>>>>
                        >>>>>>> Yahoo! Groups Links
                        >>>>>>>
                        >>>>>>>
                        >>>>>>>
                        >>>>>>>
                        >>>>>> ------------------------------------
                        >>>>>>
                        >>>>>> Yahoo! Groups Links
                        >>>>>>
                        >>>>>>
                        >>>>>>
                        >>>>>
                        >>>>> ------------------------------------
                        >>>>>
                        >>>>> Yahoo! Groups Links
                        >>>>>
                        >>>>>
                        >>>>>
                        >>>>>
                        >>>>>
                        >>>>
                        >>>> ------------------------------------
                        >>>>
                        >>>> Yahoo! Groups Links
                        >>>>
                        >>>>
                        >>>>
                        >>>>
                        >>>
                        >>>
                        >>> ------------------------------------
                        >>>
                        >>> Yahoo! Groups Links
                        >>>
                        >>>
                        >>>
                        >>>
                        >>>
                        >>
                        >
                        >
                        >
                        > ------------------------------------
                        >
                        > Yahoo! Groups Links
                        >
                        >
                        >
                        >
                        >

                      • Steinar Aanesland
                        It make sense to me , but I am absolutely no expert on this ;) LA5VNA Steinar loc:JO59jq
                        Message 11 of 14 , May 22, 2013
                        • 0 Attachment
                          It make sense to me , but I am absolutely no expert on this ;)

                          LA5VNA Steinar
                          loc:JO59jq


                          Den 22.05.2013 22:40, skrev Steve Daniels:
                          > I think when Lynn gets around to doing something with the RF baud rate
                          > setting; adjusting the retry timings to account for baud rate might be a
                          > good idea
                          >
                          >
                          >
                          > 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 Steinar Aanesland
                          > Sent: 22 May 2013 21:25
                          > To: aprsisce@yahoogroups.com
                          > Subject: Re: [aprsisce] Trying out a new mode with aprsis32 and multipsk in
                          > KISS on HF
                          >
                          >
                          >
                          >
                          >
                          > A text with 67 characters will take about 15 seconds.
                          >
                          > LA5VNA Steinar
                          > loc:JO59jq
                          >
                          > Den 22.05.2013 22:07, skrev Lynn W Deffenbaugh (Mr):
                          >> 19:48:03 - Initial transmission to both IS and RF
                          >> 19:48:11 - 8 seconds later - Transmission only to RF because too soon
                          >> for -IS
                          >> 19:48:28 - 17 seconds later yet - Transmission again only to RF (only 25
                          >> seconds since -IS)
                          >> 19:48:36 - 8 seconds later yet to both IS and RF being 33 seconds past
                          >> the -IS dupe window
                          >>
                          >> Yep, WAD - Working As Designed. 8+16+8+32+64+96+128 are the retry delays.
                          >>
                          >> How long does your new HF modulation take to actually transmit the
                          > message?
                          >>
                          >> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
                          >>
                          >> On 5/22/2013 3:50 PM, Steinar Aanesland wrote:
                          >>> Thanks for quick reply :)
                          >>> Here is the log:
                          >>>
                          >>>
                          >>> 2013-05-22T19:48:03.408 Transmit(IS+RF) LA5VNA>APWW10,WIDE1-1::LC5VNA
                          >>> :testing{AU}
                          >>> 2013-05-22T19:48:11.704 Transmit(IS) Too Soon (8297), RF-ing
                          >>> LA5VNA>APWW10,WIDE1-1::LC5VNA :testing{AU}
                          >>> 2013-05-22T19:48:11.704 Transmit(RF) LA5VNA>APWW10,WIDE1-1::LC5VNA
                          >>> :testing{AU}
                          >>> 2013-05-22T19:48:28.704 Transmit(IS) Too Soon (25291), RF-ing
                          >>> LA5VNA>APWW10,WIDE1-1::LC5VNA :testing{AU}
                          >>> 2013-05-22T19:48:28.704 Transmit(RF) LA5VNA>APWW10,WIDE1-1::LC5VNA
                          >>> :testing{AU}
                          >>> 2013-05-22T19:48:36.704 Transmit(IS+RF) LA5VNA>APWW10,WIDE1-1::LC5VNA
                          >>> :testing{AU}
                          >>>
                          >>>
                          >>> LA5VNA Steinar
                          >>> loc:JO59jq
                          >>>
                          >>>
                          >>> Den 22.05.2013 21:38, skrev Lynn W Deffenbaugh (Mr):
                          >>>> See http://aprsisce.wikidot.com/message-retries
                          >>>>
                          >>>> If you're getting the first retry in 1 second, then I've got a bust
                          >>>> somewhere. Can you bring up and enable the Transmit trace log to
                          >>>> confirm or deny your message retry timings?
                          >>>>
                          >>>> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
                          >>>>
                          >>>> PS. I didn't invent the initial 8 second retry delay either. See Bob's
                          >>>> original page at
                          >>>>
                          >>>> http://aprs.org/txt/messages101.txt
                          >>>>
                          >>>> In fact, UI-View's 30 second initial retry falls under Bob's statement
                          >>>> of "Not ONCE like most follow-on clones." in point # 2. UI-View
                          >>>> sometimes isn't the "gold standard" of APRS implementation. At least,
                          >>>> not in a universal opinion.
                          >>>>
                          >>>> On 5/22/2013 3:11 PM, Steinar Aanesland wrote:
                          >>>>> Hi all
                          >>>>>
                          >>>>> After long time struggle , I finally got things working . Last night I
                          >>>>> was starting from scratch setting up a completely new test
                          > installation,
                          >>>>> and now station "LA5VNA" and station "LC5VNA" are now able to send a
                          >>>>> message and than reply with an ACK.
                          >>>>>
                          >>>>> There is only one catch, it is only working nicely with UI-View32. When
                          >>>>> I am sending a message with UI-View32 it goes about 30 seconds before
                          >>>>> UI-View32 broadcast a new message. This is plenty of time for another
                          >>>>> station to detect the message and reply with an ACK.
                          >>>>>
                          >>>>> When I am trying with my favorite APRS program aprsis32, aprsis32
                          >>>>> sending a new message only 1 second after the first one. If the RX
                          >>>>> station is able to detect the first message and reply with an ACK, this
                          >>>>> ACK will never be detected because it collides with the second
                          >>>>> retransmission of the message . This goes back and forth until a
                          >>>>> collision is avoiding and the ACK, is detected .
                          >>>>>
                          >>>>> Is there a way to avoid the collision, or is this timing of the second
                          >>>>> retransmission hard coded into aprsis32 ?
                          >>>>>
                          >>>>> LA5VNA Steinar
                          >>>>> loc:JO59jq
                          >>>>>
                          >>>>>
                          >>>>>
                          >>>>>
                          >>>>> Den 18.05.2013 15:59, skrev Steinar Aanesland:
                          >>>>>> Lynn
                          >>>>>>
                          >>>>>>
                          >>>>>> Thank for your reply. I will do some more testing and send you the log
                          > :)
                          >>>>>>
                          >>>>>>
                          >>>>>> " Has anyone used MultiPSK's KISS mode for other APRS messaging? Is
                          >>>>>> this even possible?" Yes, take a look at this youtube:
                          >>>>>> http://www.youtube.com/watch?v=4lKbhtChkGw
                          >>>>>>
                          >>>>>> LA6VNA S
                          >>>>>>
                          >>>>>>
                          >>>>>>
                          >>>>>>
                          >>>>>>
                          >>>>>> On 18.05.2013 15:43, Lynn W Deffenbaugh (Mr) wrote:
                          >>>>>>> Please bring up Enables / View Logs / Port(<YourRFPort>) and enable
                          > it
                          >>>>>>> and do the message test again. I'm suspecting that something in the
                          >>>>>>> chain is mucking about with the curly brace inside the ack sequence
                          >>>>>>> which is the Reply-Ack protocol. This is supposed to be fully
                          > backward
                          >>>>>>> compatible (I've had many QSOs with UI-View users), so it must be
                          >>>>>>> something in the ALE/ARQ/MultiPSK chain that is introducing something
                          >>>>>>> strange.
                          >>>>>>>
                          >>>>>>> If you also check Enables / Logging / File Enabled, then the trace
                          > from
                          >>>>>>> above will also go into your APRSIS32.LOG file that you can send on
                          > to
                          >>>>>>> KJ4ERJ@... <mailto:KJ4ERJ%40arrl.net> with a reminder of what
                          > it is I'm looking at.
                          >>>>>>>
                          >>>>>>> While you've got it all put together, try messaging back and forth
                          > with
                          >>>>>>> a UI-View station over the APRS-IS and/or standard packet just to
                          > show
                          >>>>>>> that the same configuration of the stations (outside of the RF path)
                          >>>>>>> truly does function. It's a case of "show what works" and then
                          > "what's
                          >>>>>>> different" must be the source of the problem.
                          >>>>>>>
                          >>>>>>> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
                          >>>>>>>
                          >>>>>>> PS. Has anyone used MultiPSK's KISS mode for other APRS messaging? Is
                          >>>>>>> this even possible?
                          >>>>>>>
                          >>>>>>> On 5/18/2013 7:56 AM, Steinar Aanesland wrote:
                          >>>>>>>> Hi all ,I hope this is not to out of topic for this group.
                          >>>>>>>>
                          >>>>>>>> As some of you probably know, 300b packet is not the best choice on
                          > HF,
                          >>>>>>>> but there are some alternatives.
                          >>>>>>>> One of them is ALE400 . ALE400 is ARQ mode in Multipsk.
                          >>>>>>>>
                          >>>>>>>> I have made me a small lab testing out the ALE400/Multipsk software
                          > in
                          >>>>>>>> KISS with aprsis32 and UI-View32.
                          >>>>>>>>
                          >>>>>>>> My lab is like this:
                          >>>>>>>>
                          >>>>>>>> I am using to PCes simulating station "LA5VNA" and station "LC5VNA".
                          >>>>>>>> They are connecting together trough their mic's and they
                          > loudspeakers.
                          >>>>>>>>
                          >>>>>>>> I was first testing out a combination of
                          >>>>>>>> Multipsk/KISS/UI-View32 on station "LA5VNA", and a combination of
                          >>>>>>>> Multipsk/KISS/aprsis32 on station "LC5VNA".
                          >>>>>>>>
                          >>>>>>>>
                          > [Multipsk/KISS/UI-View32]<===mic's/loudspeakers==>[Multipsk/KISS/aprsis32]
                          >>>>>>>>
                          >>>>>>>> Beaconing was working great form station "a" and "b". Both maps was
                          >>>>>>>> updated, but when trying the message function something
                          >>>>>>>>
                          >>>>>>>> strange was happening.
                          >>>>>>>>
                          >>>>>>>> When UI-View32 (station "LA5VNA") was sending a message like "test",
                          >>>>>>>> this appeared in the middle window of multipsk:
                          >>>>>>>> LA5VNA :LC5VNA :test{12
                          >>>>>>>>
                          >>>>>>>> When aprsis32 (station"LC5VNA") was responding with an ack, this was
                          >>>>>>>> appearing in the
                          >>>>>>>> lower window of multipsk on station"LA5VNA" :
                          >>>>>>>>
                          >>>>>>>> [End of TX] FAE APRS frame
                          >>>>>>>> LC5VNA :LA5VNA :ack12 [FAE APRS]
                          >>>>>>>> ...KISS frame repeated
                          >>>>>>>>
                          >>>>>>>> Station"LA5VNA" had got its ack and seems to be happy.
                          >>>>>>>>
                          >>>>>>>>
                          >>>>>>>> BUT, when aprsis32 (station"LC5VNA") was sending a "test" message,
                          >>>>>>>> thisappeared in the middle window of Multipsk:
                          >>>>>>>> LC5VNA :LA5VNA :test{PU}HX
                          >>>>>>>>
                          >>>>>>>> When is UI-View32 (station "LA5VNA") was responding with an ack,
                          > this
                          >>>>>>>> was appearing in the
                          >>>>>>>> lower window of Multipsk on station"LC5VNA" :
                          >>>>>>>>
                          >>>>>>>> [End of TX] FAE APRS frame
                          >>>>>>>> LA5VNA :LA5VNA :ackPU}HX [FAE APRS]
                          >>>>>>>> ...KISS frame repeated
                          >>>>>>>>
                          >>>>>>>>
                          >>>>>>>> The aprsis32 (station"LC5VNA") seems not to recognize ackPU}HX as an
                          > ACK
                          >>>>>>>> so it keep repeating the "test" message until it times
                          >>>>>>>>
                          >>>>>>>> out.
                          >>>>>>>>
                          >>>>>>>>
                          >>>>>>>> I was then trying with only UI-View32on both station"LC5VNA" and
                          >>>>>>>> "LA5VNA" and everything works fine. With only aprsis32 there
                          >>>>>>>>
                          >>>>>>>> was absolutely no way of getting the stations to recognize the ACK's
                          >>>>>>>>
                          >>>>>>>> Does anyone have a clue of was going on ?
                          >>>>>>>>
                          >>>>>>>> If you want to try this , download latest ver of multipsk, but
                          > remember
                          >>>>>>>> to read the "ALE_and_ALE400_APRS_with_UI-
                          >>>>>>>>
                          >>>>>>>> VIEW_through_Multipsk_easy.doc"
                          >>>>>>>>
                          > https://dl.dropboxusercontent.com/u/16381257/MULTIPSK_TEST_16_05_2013.ZIP
                          >>>>>>>>
                          >>>>>>>>
                          >>>>>>>> LA5VNA Steinar
                          >>>>>>>> loc:JO59jq
                          >>>>>>>>
                          >>>>>>>>
                          >>>>>>>>
                          >>>>>>>>
                          >>>>>>>> ------------------------------------
                          >>>>>>>>
                          >>>>>>>> Yahoo! Groups Links
                          >>>>>>>>
                          >>>>>>>>
                          >>>>>>>>
                          >>>>>>>>
                          >>>>>>> ------------------------------------
                          >>>>>>>
                          >>>>>>> Yahoo! Groups Links
                          >>>>>>>
                          >>>>>>>
                          >>>>>>>
                          >>>>>>
                          >>>>>> ------------------------------------
                          >>>>>>
                          >>>>>> Yahoo! Groups Links
                          >>>>>>
                          >>>>>>
                          >>>>>>
                          >>>>>>
                          >>>>>>
                          >>>>>
                          >>>>> ------------------------------------
                          >>>>>
                          >>>>> Yahoo! Groups Links
                          >>>>>
                          >>>>>
                          >>>>>
                          >>>>>
                          >>>>
                          >>>>
                          >>>> ------------------------------------
                          >>>>
                          >>>> Yahoo! Groups Links
                          >>>>
                          >>>>
                          >>>>
                          >>>>
                          >>>>
                          >>>
                          >>
                          >>
                          >>
                          >> ------------------------------------
                          >>
                          >> Yahoo! Groups Links
                          >>
                          >>
                          >>
                          >>
                          >>
                          >
                          >
                          >
                          >
                        • Steinar Aanesland
                          Hi Lynn, Do you think it is possible to corporate this 15 sec new ALE400 mode in the wait for reply timing window of aprsis32? LA5VNA Steinar loc:JO59jq
                          Message 12 of 14 , May 31, 2013
                          • 0 Attachment
                            Hi Lynn,

                            Do you think it is possible to corporate this 15 sec "new" ALE400 mode
                            in the "wait for reply timing window" of aprsis32?

                            LA5VNA Steinar
                            loc:JO59jq


                            Den 22.05.2013 22:07, skrev Lynn W Deffenbaugh (Mr):
                            > 19:48:03 - Initial transmission to both IS and RF
                            > 19:48:11 - 8 seconds later - Transmission only to RF because too soon
                            > for -IS
                            > 19:48:28 - 17 seconds later yet - Transmission again only to RF (only 25
                            > seconds since -IS)
                            > 19:48:36 - 8 seconds later yet to both IS and RF being 33 seconds past
                            > the -IS dupe window
                            >
                            > Yep, WAD - Working As Designed. 8+16+8+32+64+96+128 are the retry delays.
                            >
                            > How long does your new HF modulation take to actually transmit the message?
                            >
                            > Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
                            >
                            > On 5/22/2013 3:50 PM, Steinar Aanesland wrote:
                            >> Thanks for quick reply :)
                            >> Here is the log:
                            >>
                            >>
                            >> 2013-05-22T19:48:03.408 Transmit(IS+RF) LA5VNA>APWW10,WIDE1-1::LC5VNA
                            >> :testing{AU}
                            >> 2013-05-22T19:48:11.704 Transmit(IS) Too Soon (8297), RF-ing
                            >> LA5VNA>APWW10,WIDE1-1::LC5VNA :testing{AU}
                            >> 2013-05-22T19:48:11.704 Transmit(RF) LA5VNA>APWW10,WIDE1-1::LC5VNA
                            >> :testing{AU}
                            >> 2013-05-22T19:48:28.704 Transmit(IS) Too Soon (25291), RF-ing
                            >> LA5VNA>APWW10,WIDE1-1::LC5VNA :testing{AU}
                            >> 2013-05-22T19:48:28.704 Transmit(RF) LA5VNA>APWW10,WIDE1-1::LC5VNA
                            >> :testing{AU}
                            >> 2013-05-22T19:48:36.704 Transmit(IS+RF) LA5VNA>APWW10,WIDE1-1::LC5VNA
                            >> :testing{AU}
                            >>
                            >>
                            >> LA5VNA Steinar
                            >> loc:JO59jq
                            >>
                            >>
                            >> Den 22.05.2013 21:38, skrev Lynn W Deffenbaugh (Mr):
                            >>> See http://aprsisce.wikidot.com/message-retries
                            >>>
                            >>> If you're getting the first retry in 1 second, then I've got a bust
                            >>> somewhere. Can you bring up and enable the Transmit trace log to
                            >>> confirm or deny your message retry timings?
                            >>>
                            >>> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
                            >>>
                            >>> PS. I didn't invent the initial 8 second retry delay either. See Bob's
                            >>> original page at
                            >>>
                            >>> http://aprs.org/txt/messages101.txt
                            >>>
                            >>> In fact, UI-View's 30 second initial retry falls under Bob's statement
                            >>> of "Not ONCE like most follow-on clones." in point # 2. UI-View
                            >>> sometimes isn't the "gold standard" of APRS implementation. At least,
                            >>> not in a universal opinion.
                            >>>
                            >>> On 5/22/2013 3:11 PM, Steinar Aanesland wrote:
                            >>>> Hi all
                            >>>>
                            >>>> After long time struggle , I finally got things working . Last night I
                            >>>> was starting from scratch setting up a completely new test installation,
                            >>>> and now station "LA5VNA" and station "LC5VNA" are now able to send a
                            >>>> message and than reply with an ACK.
                            >>>>
                            >>>> There is only one catch, it is only working nicely with UI-View32. When
                            >>>> I am sending a message with UI-View32 it goes about 30 seconds before
                            >>>> UI-View32 broadcast a new message. This is plenty of time for another
                            >>>> station to detect the message and reply with an ACK.
                            >>>>
                            >>>> When I am trying with my favorite APRS program aprsis32, aprsis32
                            >>>> sending a new message only 1 second after the first one. If the RX
                            >>>> station is able to detect the first message and reply with an ACK, this
                            >>>> ACK will never be detected because it collides with the second
                            >>>> retransmission of the message . This goes back and forth until a
                            >>>> collision is avoiding and the ACK, is detected .
                            >>>>
                            >>>> Is there a way to avoid the collision, or is this timing of the second
                            >>>> retransmission hard coded into aprsis32 ?
                            >>>>
                            >>>> LA5VNA Steinar
                            >>>> loc:JO59jq
                            >>>>
                            >>>>
                            >>>>
                            >>>>
                            >>>> Den 18.05.2013 15:59, skrev Steinar Aanesland:
                            >>>>> Lynn
                            >>>>>
                            >>>>>
                            >>>>> Thank for your reply. I will do some more testing and send you the log :)
                            >>>>>
                            >>>>>
                            >>>>> " Has anyone used MultiPSK's KISS mode for other APRS messaging? Is
                            >>>>> this even possible?" Yes, take a look at this youtube:
                            >>>>> http://www.youtube.com/watch?v=4lKbhtChkGw
                            >>>>>
                            >>>>> LA6VNA S
                            >>>>>
                            >>>>>
                            >>>>>
                            >>>>>
                            >>>>>
                            >>>>> On 18.05.2013 15:43, Lynn W Deffenbaugh (Mr) wrote:
                            >>>>>> Please bring up Enables / View Logs / Port(<YourRFPort>) and enable it
                            >>>>>> and do the message test again. I'm suspecting that something in the
                            >>>>>> chain is mucking about with the curly brace inside the ack sequence
                            >>>>>> which is the Reply-Ack protocol. This is supposed to be fully backward
                            >>>>>> compatible (I've had many QSOs with UI-View users), so it must be
                            >>>>>> something in the ALE/ARQ/MultiPSK chain that is introducing something
                            >>>>>> strange.
                            >>>>>>
                            >>>>>> If you also check Enables / Logging / File Enabled, then the trace from
                            >>>>>> above will also go into your APRSIS32.LOG file that you can send on to
                            >>>>>> KJ4ERJ@... with a reminder of what it is I'm looking at.
                            >>>>>>
                            >>>>>> While you've got it all put together, try messaging back and forth with
                            >>>>>> a UI-View station over the APRS-IS and/or standard packet just to show
                            >>>>>> that the same configuration of the stations (outside of the RF path)
                            >>>>>> truly does function. It's a case of "show what works" and then "what's
                            >>>>>> different" must be the source of the problem.
                            >>>>>>
                            >>>>>> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
                            >>>>>>
                            >>>>>> PS. Has anyone used MultiPSK's KISS mode for other APRS messaging? Is
                            >>>>>> this even possible?
                            >>>>>>
                            >>>>>> On 5/18/2013 7:56 AM, Steinar Aanesland wrote:
                            >>>>>>> Hi all ,I hope this is not to out of topic for this group.
                            >>>>>>>
                            >>>>>>> As some of you probably know, 300b packet is not the best choice on HF,
                            >>>>>>> but there are some alternatives.
                            >>>>>>> One of them is ALE400 . ALE400 is ARQ mode in Multipsk.
                            >>>>>>>
                            >>>>>>> I have made me a small lab testing out the ALE400/Multipsk software in
                            >>>>>>> KISS with aprsis32 and UI-View32.
                            >>>>>>>
                            >>>>>>> My lab is like this:
                            >>>>>>>
                            >>>>>>> I am using to PCes simulating station "LA5VNA" and station "LC5VNA".
                            >>>>>>> They are connecting together trough their mic's and they loudspeakers.
                            >>>>>>>
                            >>>>>>> I was first testing out a combination of
                            >>>>>>> Multipsk/KISS/UI-View32 on station "LA5VNA", and a combination of
                            >>>>>>> Multipsk/KISS/aprsis32 on station "LC5VNA".
                            >>>>>>>
                            >>>>>>> [Multipsk/KISS/UI-View32]<===mic's/loudspeakers==>[Multipsk/KISS/aprsis32]
                            >>>>>>>
                            >>>>>>> Beaconing was working great form station "a" and "b". Both maps was
                            >>>>>>> updated, but when trying the message function something
                            >>>>>>>
                            >>>>>>> strange was happening.
                            >>>>>>>
                            >>>>>>> When UI-View32 (station "LA5VNA") was sending a message like "test",
                            >>>>>>> this appeared in the middle window of multipsk:
                            >>>>>>> LA5VNA :LC5VNA :test{12
                            >>>>>>>
                            >>>>>>> When aprsis32 (station"LC5VNA") was responding with an ack, this was
                            >>>>>>> appearing in the
                            >>>>>>> lower window of multipsk on station"LA5VNA" :
                            >>>>>>>
                            >>>>>>> [End of TX] FAE APRS frame
                            >>>>>>> LC5VNA :LA5VNA :ack12 [FAE APRS]
                            >>>>>>> ...KISS frame repeated
                            >>>>>>>
                            >>>>>>> Station"LA5VNA" had got its ack and seems to be happy.
                            >>>>>>>
                            >>>>>>>
                            >>>>>>> BUT, when aprsis32 (station"LC5VNA") was sending a "test" message,
                            >>>>>>> thisappeared in the middle window of Multipsk:
                            >>>>>>> LC5VNA :LA5VNA :test{PU}HX
                            >>>>>>>
                            >>>>>>> When is UI-View32 (station "LA5VNA") was responding with an ack, this
                            >>>>>>> was appearing in the
                            >>>>>>> lower window of Multipsk on station"LC5VNA" :
                            >>>>>>>
                            >>>>>>> [End of TX] FAE APRS frame
                            >>>>>>> LA5VNA :LA5VNA :ackPU}HX [FAE APRS]
                            >>>>>>> ...KISS frame repeated
                            >>>>>>>
                            >>>>>>>
                            >>>>>>> The aprsis32 (station"LC5VNA") seems not to recognize ackPU}HX as an ACK
                            >>>>>>> so it keep repeating the "test" message until it times
                            >>>>>>>
                            >>>>>>> out.
                            >>>>>>>
                            >>>>>>>
                            >>>>>>> I was then trying with only UI-View32on both station"LC5VNA" and
                            >>>>>>> "LA5VNA" and everything works fine. With only aprsis32 there
                            >>>>>>>
                            >>>>>>> was absolutely no way of getting the stations to recognize the ACK's
                            >>>>>>>
                            >>>>>>> Does anyone have a clue of was going on ?
                            >>>>>>>
                            >>>>>>> If you want to try this , download latest ver of multipsk, but remember
                            >>>>>>> to read the "ALE_and_ALE400_APRS_with_UI-
                            >>>>>>>
                            >>>>>>> VIEW_through_Multipsk_easy.doc"
                            >>>>>>> https://dl.dropboxusercontent.com/u/16381257/MULTIPSK_TEST_16_05_2013.ZIP
                            >>>>>>>
                            >>>>>>>
                            >>>>>>> LA5VNA Steinar
                            >>>>>>> loc:JO59jq
                            >>>>>>>
                            >>>>>>>
                            >>>>>>>
                            >>>>>>>
                            >>>>>>> ------------------------------------
                            >>>>>>>
                            >>>>>>> Yahoo! Groups Links
                            >>>>>>>
                            >>>>>>>
                            >>>>>>>
                            >>>>>>>
                            >>>>>> ------------------------------------
                            >>>>>>
                            >>>>>> Yahoo! Groups Links
                            >>>>>>
                            >>>>>>
                            >>>>>>
                            >>>>>
                            >>>>> ------------------------------------
                            >>>>>
                            >>>>> Yahoo! Groups Links
                            >>>>>
                            >>>>>
                            >>>>>
                            >>>>>
                            >>>>>
                            >>>>
                            >>>> ------------------------------------
                            >>>>
                            >>>> Yahoo! Groups Links
                            >>>>
                            >>>>
                            >>>>
                            >>>>
                            >>>
                            >>>
                            >>> ------------------------------------
                            >>>
                            >>> Yahoo! Groups Links
                            >>>
                            >>>
                            >>>
                            >>>
                            >>>
                            >>
                            >
                            >
                            >
                            > ------------------------------------
                            >
                            > Yahoo! Groups Links
                            >
                            >
                            >
                            >
                            >
                          • Lynn W Deffenbaugh (Mr)
                            What is the effective baud rate over the ALE400 mode channel? Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
                            Message 13 of 14 , May 31, 2013
                            • 0 Attachment
                              What is the effective baud rate over the ALE400 mode channel?

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

                              On 5/31/2013 2:23 PM, Steinar Aanesland wrote:
                              > Hi Lynn,
                              >
                              > Do you think it is possible to corporate this 15 sec "new" ALE400 mode
                              > in the "wait for reply timing window" of aprsis32?
                              >
                              > LA5VNA Steinar
                              > loc:JO59jq
                              >
                              >
                              > Den 22.05.2013 22:07, skrev Lynn W Deffenbaugh (Mr):
                              >> 19:48:03 - Initial transmission to both IS and RF
                              >> 19:48:11 - 8 seconds later - Transmission only to RF because too soon
                              >> for -IS
                              >> 19:48:28 - 17 seconds later yet - Transmission again only to RF (only 25
                              >> seconds since -IS)
                              >> 19:48:36 - 8 seconds later yet to both IS and RF being 33 seconds past
                              >> the -IS dupe window
                              >>
                              >> Yep, WAD - Working As Designed. 8+16+8+32+64+96+128 are the retry delays.
                              >>
                              >> How long does your new HF modulation take to actually transmit the message?
                              >>
                              >> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
                              >>
                              >> On 5/22/2013 3:50 PM, Steinar Aanesland wrote:
                              >>> Thanks for quick reply :)
                              >>> Here is the log:
                              >>>
                              >>>
                              >>> 2013-05-22T19:48:03.408 Transmit(IS+RF) LA5VNA>APWW10,WIDE1-1::LC5VNA
                              >>> :testing{AU}
                              >>> 2013-05-22T19:48:11.704 Transmit(IS) Too Soon (8297), RF-ing
                              >>> LA5VNA>APWW10,WIDE1-1::LC5VNA :testing{AU}
                              >>> 2013-05-22T19:48:11.704 Transmit(RF) LA5VNA>APWW10,WIDE1-1::LC5VNA
                              >>> :testing{AU}
                              >>> 2013-05-22T19:48:28.704 Transmit(IS) Too Soon (25291), RF-ing
                              >>> LA5VNA>APWW10,WIDE1-1::LC5VNA :testing{AU}
                              >>> 2013-05-22T19:48:28.704 Transmit(RF) LA5VNA>APWW10,WIDE1-1::LC5VNA
                              >>> :testing{AU}
                              >>> 2013-05-22T19:48:36.704 Transmit(IS+RF) LA5VNA>APWW10,WIDE1-1::LC5VNA
                              >>> :testing{AU}
                              >>>
                              >>>
                              >>> LA5VNA Steinar
                              >>> loc:JO59jq
                              >>>
                              >>>
                              >>> Den 22.05.2013 21:38, skrev Lynn W Deffenbaugh (Mr):
                              >>>> See http://aprsisce.wikidot.com/message-retries
                              >>>>
                              >>>> If you're getting the first retry in 1 second, then I've got a bust
                              >>>> somewhere. Can you bring up and enable the Transmit trace log to
                              >>>> confirm or deny your message retry timings?
                              >>>>
                              >>>> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
                              >>>>
                              >>>> PS. I didn't invent the initial 8 second retry delay either. See Bob's
                              >>>> original page at
                              >>>>
                              >>>> http://aprs.org/txt/messages101.txt
                              >>>>
                              >>>> In fact, UI-View's 30 second initial retry falls under Bob's statement
                              >>>> of "Not ONCE like most follow-on clones." in point # 2. UI-View
                              >>>> sometimes isn't the "gold standard" of APRS implementation. At least,
                              >>>> not in a universal opinion.
                              >>>>
                              >>>> On 5/22/2013 3:11 PM, Steinar Aanesland wrote:
                              >>>>> Hi all
                              >>>>>
                              >>>>> After long time struggle , I finally got things working . Last night I
                              >>>>> was starting from scratch setting up a completely new test installation,
                              >>>>> and now station "LA5VNA" and station "LC5VNA" are now able to send a
                              >>>>> message and than reply with an ACK.
                              >>>>>
                              >>>>> There is only one catch, it is only working nicely with UI-View32. When
                              >>>>> I am sending a message with UI-View32 it goes about 30 seconds before
                              >>>>> UI-View32 broadcast a new message. This is plenty of time for another
                              >>>>> station to detect the message and reply with an ACK.
                              >>>>>
                              >>>>> When I am trying with my favorite APRS program aprsis32, aprsis32
                              >>>>> sending a new message only 1 second after the first one. If the RX
                              >>>>> station is able to detect the first message and reply with an ACK, this
                              >>>>> ACK will never be detected because it collides with the second
                              >>>>> retransmission of the message . This goes back and forth until a
                              >>>>> collision is avoiding and the ACK, is detected .
                              >>>>>
                              >>>>> Is there a way to avoid the collision, or is this timing of the second
                              >>>>> retransmission hard coded into aprsis32 ?
                              >>>>>
                              >>>>> LA5VNA Steinar
                              >>>>> loc:JO59jq
                              >>>>>
                              >>>>>
                              >>>>>
                              >>>>>
                              >>>>> Den 18.05.2013 15:59, skrev Steinar Aanesland:
                              >>>>>> Lynn
                              >>>>>>
                              >>>>>>
                              >>>>>> Thank for your reply. I will do some more testing and send you the log :)
                              >>>>>>
                              >>>>>>
                              >>>>>> " Has anyone used MultiPSK's KISS mode for other APRS messaging? Is
                              >>>>>> this even possible?" Yes, take a look at this youtube:
                              >>>>>> http://www.youtube.com/watch?v=4lKbhtChkGw
                              >>>>>>
                              >>>>>> LA6VNA S
                              >>>>>>
                              >>>>>>
                              >>>>>>
                              >>>>>>
                              >>>>>>
                              >>>>>> On 18.05.2013 15:43, Lynn W Deffenbaugh (Mr) wrote:
                              >>>>>>> Please bring up Enables / View Logs / Port(<YourRFPort>) and enable it
                              >>>>>>> and do the message test again. I'm suspecting that something in the
                              >>>>>>> chain is mucking about with the curly brace inside the ack sequence
                              >>>>>>> which is the Reply-Ack protocol. This is supposed to be fully backward
                              >>>>>>> compatible (I've had many QSOs with UI-View users), so it must be
                              >>>>>>> something in the ALE/ARQ/MultiPSK chain that is introducing something
                              >>>>>>> strange.
                              >>>>>>>
                              >>>>>>> If you also check Enables / Logging / File Enabled, then the trace from
                              >>>>>>> above will also go into your APRSIS32.LOG file that you can send on to
                              >>>>>>> KJ4ERJ@... with a reminder of what it is I'm looking at.
                              >>>>>>>
                              >>>>>>> While you've got it all put together, try messaging back and forth with
                              >>>>>>> a UI-View station over the APRS-IS and/or standard packet just to show
                              >>>>>>> that the same configuration of the stations (outside of the RF path)
                              >>>>>>> truly does function. It's a case of "show what works" and then "what's
                              >>>>>>> different" must be the source of the problem.
                              >>>>>>>
                              >>>>>>> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
                              >>>>>>>
                              >>>>>>> PS. Has anyone used MultiPSK's KISS mode for other APRS messaging? Is
                              >>>>>>> this even possible?
                              >>>>>>>
                              >>>>>>> On 5/18/2013 7:56 AM, Steinar Aanesland wrote:
                              >>>>>>>> Hi all ,I hope this is not to out of topic for this group.
                              >>>>>>>>
                              >>>>>>>> As some of you probably know, 300b packet is not the best choice on HF,
                              >>>>>>>> but there are some alternatives.
                              >>>>>>>> One of them is ALE400 . ALE400 is ARQ mode in Multipsk.
                              >>>>>>>>
                              >>>>>>>> I have made me a small lab testing out the ALE400/Multipsk software in
                              >>>>>>>> KISS with aprsis32 and UI-View32.
                              >>>>>>>>
                              >>>>>>>> My lab is like this:
                              >>>>>>>>
                              >>>>>>>> I am using to PCes simulating station "LA5VNA" and station "LC5VNA".
                              >>>>>>>> They are connecting together trough their mic's and they loudspeakers.
                              >>>>>>>>
                              >>>>>>>> I was first testing out a combination of
                              >>>>>>>> Multipsk/KISS/UI-View32 on station "LA5VNA", and a combination of
                              >>>>>>>> Multipsk/KISS/aprsis32 on station "LC5VNA".
                              >>>>>>>>
                              >>>>>>>> [Multipsk/KISS/UI-View32]<===mic's/loudspeakers==>[Multipsk/KISS/aprsis32]
                              >>>>>>>>
                              >>>>>>>> Beaconing was working great form station "a" and "b". Both maps was
                              >>>>>>>> updated, but when trying the message function something
                              >>>>>>>>
                              >>>>>>>> strange was happening.
                              >>>>>>>>
                              >>>>>>>> When UI-View32 (station "LA5VNA") was sending a message like "test",
                              >>>>>>>> this appeared in the middle window of multipsk:
                              >>>>>>>> LA5VNA :LC5VNA :test{12
                              >>>>>>>>
                              >>>>>>>> When aprsis32 (station"LC5VNA") was responding with an ack, this was
                              >>>>>>>> appearing in the
                              >>>>>>>> lower window of multipsk on station"LA5VNA" :
                              >>>>>>>>
                              >>>>>>>> [End of TX] FAE APRS frame
                              >>>>>>>> LC5VNA :LA5VNA :ack12 [FAE APRS]
                              >>>>>>>> ...KISS frame repeated
                              >>>>>>>>
                              >>>>>>>> Station"LA5VNA" had got its ack and seems to be happy.
                              >>>>>>>>
                              >>>>>>>>
                              >>>>>>>> BUT, when aprsis32 (station"LC5VNA") was sending a "test" message,
                              >>>>>>>> thisappeared in the middle window of Multipsk:
                              >>>>>>>> LC5VNA :LA5VNA :test{PU}HX
                              >>>>>>>>
                              >>>>>>>> When is UI-View32 (station "LA5VNA") was responding with an ack, this
                              >>>>>>>> was appearing in the
                              >>>>>>>> lower window of Multipsk on station"LC5VNA" :
                              >>>>>>>>
                              >>>>>>>> [End of TX] FAE APRS frame
                              >>>>>>>> LA5VNA :LA5VNA :ackPU}HX [FAE APRS]
                              >>>>>>>> ...KISS frame repeated
                              >>>>>>>>
                              >>>>>>>>
                              >>>>>>>> The aprsis32 (station"LC5VNA") seems not to recognize ackPU}HX as an ACK
                              >>>>>>>> so it keep repeating the "test" message until it times
                              >>>>>>>>
                              >>>>>>>> out.
                              >>>>>>>>
                              >>>>>>>>
                              >>>>>>>> I was then trying with only UI-View32on both station"LC5VNA" and
                              >>>>>>>> "LA5VNA" and everything works fine. With only aprsis32 there
                              >>>>>>>>
                              >>>>>>>> was absolutely no way of getting the stations to recognize the ACK's
                              >>>>>>>>
                              >>>>>>>> Does anyone have a clue of was going on ?
                              >>>>>>>>
                              >>>>>>>> If you want to try this , download latest ver of multipsk, but remember
                              >>>>>>>> to read the "ALE_and_ALE400_APRS_with_UI-
                              >>>>>>>>
                              >>>>>>>> VIEW_through_Multipsk_easy.doc"
                              >>>>>>>> https://dl.dropboxusercontent.com/u/16381257/MULTIPSK_TEST_16_05_2013.ZIP
                              >>>>>>>>
                              >>>>>>>>
                              >>>>>>>> LA5VNA Steinar
                              >>>>>>>> loc:JO59jq
                              >>>>>>>>
                              >>>>>>>>
                              >>>>>>>>
                              >>>>>>>>
                              >>>>>>>> ------------------------------------
                              >>>>>>>>
                              >>>>>>>> Yahoo! Groups Links
                              >>>>>>>>
                              >>>>>>>>
                              >>>>>>>>
                              >>>>>>>>
                              >>>>>>> ------------------------------------
                              >>>>>>>
                              >>>>>>> Yahoo! Groups Links
                              >>>>>>>
                              >>>>>>>
                              >>>>>>>
                              >>>>>> ------------------------------------
                              >>>>>>
                              >>>>>> Yahoo! Groups Links
                              >>>>>>
                              >>>>>>
                              >>>>>>
                              >>>>>>
                              >>>>>>
                              >>>>> ------------------------------------
                              >>>>>
                              >>>>> Yahoo! Groups Links
                              >>>>>
                              >>>>>
                              >>>>>
                              >>>>>
                              >>>>
                              >>>> ------------------------------------
                              >>>>
                              >>>> Yahoo! Groups Links
                              >>>>
                              >>>>
                              >>>>
                              >>>>
                              >>>>
                              >>
                              >>
                              >> ------------------------------------
                              >>
                              >> Yahoo! Groups Links
                              >>
                              >>
                              >>
                              >>
                              >>
                              >
                              >
                              > ------------------------------------
                              >
                              > Yahoo! Groups Links
                              >
                              >
                              >
                              >
                            • Steinar Aanesland
                              Hi Lynn Here is a copy of all the info I can find in the help file about ALE400: ALE (MIL-STD-188-141A or 141A ) and ALE400 + Unproto + ARQ FAE Standard mode
                              Message 14 of 14 , May 31, 2013
                              • 0 Attachment
                                Hi Lynn

                                Here is a copy of all the info I can find in the help file about ALE400:


                                ALE (MIL-STD-188-141A or "141A")
                                and ALE400 + Unproto + ARQ FAE

                                Standard mode

                                Description (standard):
                                Baud rate : 125 bauds in "141A" mode and 50 bauds in "ALE400" mode
                                Speed : 76 wpm at 125 bauds and 30 wpm at 50 bauds
                                Modulation : FSK 8 tones (3 bits)
                                Reception mode: only one side (USB or LSB), USB is recommended
                                Character set : ASCII characters
                                Shape of pulse : rectangular
                                Space between tones : 250 Hz at 125 bauds or 50 Hz at 50 bauds
                                Bandwidth : 2000 Hz at 125 bauds or 400 Hz at 50 bauds
                                Demodulation : non-coherent,
                                Synchronization: automatic using the signal
                                Coding: Golay and average on 3 frames (with a 2/3 voting logic)
                                Interleaving : yes (within a block of 48 bits)
                                Drift tolerance : 10 à 20 Hz/mn according to signal-to-noise ratio
                                Pmean/Ppeak: 1
                                Lowest S/N: - 4 dB in "141A" mode and - 9 dB in "ALE400" mode
                                Note: pieces of information about the "141A" mode can be found on the
                                FS-1045A specification ("Telecommunications: HF radio Automatic Link
                                Establishment") and in the WEB sites:

                                In "141A" mode, before each frame, it is transmitted 12 symbols,
                                alternately on the lowest frequency and then on the highest frequency,
                                so for a duration of about 0.1 second (12/125 s). This is aimed to
                                permit the symbol synchronization just before the frame reception. This
                                does not exist within the FS-1045A specification:

                                In "ALE400" it is transmitted 28 symbols, alternately on the lowest
                                frequency and then on the highest frequency, so for a duration of about
                                0.56 second (28/50 s).

                                Unproto mode
                                It is proposed an Unproto (for "without protocol") mode. For this,
                                special frames are transmitted. They contain the necessary information
                                and don't obey to any protocol. Each frame is formed in the following way:

                                a) the information LQA (BER+SINAD) corresponding to the last received
                                frame, transmitted according to the FS-1045 specification,

                                b) the preamble "COMMAND" followed by CHR(0) and by the ASCII message
                                (CHR(32) to CHR(126)), transmitted according to the FS-1045
                                specification. As soon as, at least, one character is present in the
                                editor, this command is formed. It can't be transmitted more than 32
                                characters by frame.

                                The "carriage return + line feed" is replaced by the character CHR(126).
                                The idling character to form 3 characters block is the character CHR(127).
                                If there is no character to transmit, this command is not transmitted.
                                So, it will remain the LQA and the preamble THIS WAS followed by the
                                call. This small frame will be the idling frame.

                                c) the preamble THIS WAS followed by the call, transmitted according to
                                the FS-1045 specification.

                                Before each frame, it is transmitted 28 symbols, alternately on the
                                lowest frequency and then on the highest frequency, so for a duration of
                                about 0.22 second (28/125 s) in "141A" and 0.56 second in "ALE400".

                                Advantages: this mode permits to work as in PSK31, the transmission and
                                the reception being freely done by the Hams. There is no previous
                                connection (link). The systematically transmitted LQA permits to each
                                Ham to know, at any moment, how he is received by the other Ham.

                                "Unproto" beacon: it is proposed a beacon working (TX then RX,
                                alternately), which in TX, transmits according to the Unproto mode
                                previously defined. The advantage of this beacon is that it will be
                                enough to a Ham to transmit an Unproto frame between the Unproto frames
                                from the beacon, to know how it is received by the beacon (thanks to the
                                LQA).

                                ARQ FAE mode

                                This new ARQ mode is located, for the modulation, between the FS1045A
                                DTM and DBM ARQ modes. For the protocol it is located between the
                                FS1045A DTM and DBM modes and PAX/PAX2 modes.

                                "ARQ" is worth for "Automatic Repetition reQuest" and "FAE" for "Fast
                                Acknowledged Exchange".

                                It is a bilateral mode, which means that messages can be transmitted
                                from A to B and from B to A, in full duplex (protocol one, not physical
                                one). The ACK or NAK answer can be accompanied or not by a message (as
                                in PAX/PAX2).

                                The characters exchanged are 8 bits length so as to permit exchange in
                                all ASCII-ANSI languages (English, French, German, Russian...), but not
                                those with ideograms (as Japonese).

                                Contrary to DBM mode, the length of the frame is variable and depends of
                                the message length (as in DTM mode). But as DBM mode, the blocks are not
                                redundantly repeated and there is a global message interleaving (but
                                with a variable ID).

                                It can also be exchanged mails and files. Outlook Express (or
                                equivalent) can be used to import or export mails.

                                ARQ FAE modulation description:

                                Baud rate : 125 bauds in "141A" mode and 50 bauds in "ALE400" mode

                                Rough speed (125 bauds): maximum: 148 wpm (for 30 characters length
                                message) or 184 wpm (for 63 characters length message)

                                Use speed (125 bauds, non compressed) : maximum in unilateral: 88 wpm
                                (for 30 characters length message) and 125 wpm (for 63 characters length
                                message)

                                : maximum in bilateral: 120 wpm (for 30 characters length message) and
                                164 wpm (for 63 characters length message)

                                Use speed (50 bauds, non compressed) : maximum in unilateral: 40 wpm
                                (for 30 characters length message) and 56 wpm (for 63 characters length
                                message)
                                : maximum in bilateral: 56 wpm (for 30 characters length message) and 70
                                wpm (for 63 characters length message)

                                Use speed (125 bauds, compressed) : maximum in unilateral: 132 wpm (for
                                30 characters length message) and 187 wpm (for 63 characters length message)
                                maximum in bilateral: 180 wpm (for 30 characters length message) and 246
                                wpm (for 63 characters length message)

                                Use speed (50 bauds, compressed) : maximum in unilateral: 60 wpm (for 30
                                characters length message) and 87 wpm (for 63 characters length message)
                                maximum in bilateral: 85 wpm (for 30 characters length message) and 107
                                wpm (for 63 characters length message)

                                Modulation : FSK 8 tones (3 bits)
                                Reception mode: only one side (USB or LSB), USB is recommended
                                Character set : ASCII +ANSI characters (8 bits)

                                Shape of pulse : rectangular
                                Space between tones : 250 Hz in 125 bauds and 50 Hz in 50 bauds,
                                Bandwidth : 2000 Hz in 125 bauds and 400 Hz in 50 bauds,
                                Demodulation : non-coherent,
                                Synchronization: automatic using the signal
                                Coding: Golay
                                Interleaving : yes (global within a block of data (message + CRC))
                                Drift tolerance : 10 to 20 Hz/mn according to signal-to-noise ratio in
                                125 bauds and about 10 Hz/mn in 50 bauds,
                                Pmean/Ppeak: 1
                                Lowest S/N (125 bauds): - 6.5 dB(- 8.5 dB with many repetitions)
                                Lowest S/N (50 bauds): - 11.5 dB(- 13.5 dB with many repetitions)
                                A "soft decision" Memory Arq is implemented. It makes the transmission
                                more reliable (see details in the ARQ FAE protocol).

                                ARQ FAE protocol
                                The detailled specifications of the protocol are given, in English, in
                                the Word 95 document "ARQ_FAE_version_1_4" situated in the
                                "Specifications" heading on my WEB site (English page).


                                LA5VNA Steinar
                                loc:JO59jq


                                Den 31.05.2013 22:07, skrev Lynn W Deffenbaugh (Mr):
                                > What is the effective baud rate over the ALE400 mode channel?
                                >
                                > Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
                                >
                                > On 5/31/2013 2:23 PM, Steinar Aanesland wrote:
                                >> Hi Lynn,
                                >>
                                >> Do you think it is possible to corporate this 15 sec "new" ALE400 mode
                                >> in the "wait for reply timing window" of aprsis32?
                                >>
                                >> LA5VNA Steinar
                                >> loc:JO59jq
                                >>
                                >>
                                >> Den 22.05.2013 22:07, skrev Lynn W Deffenbaugh (Mr):
                                >>> 19:48:03 - Initial transmission to both IS and RF
                                >>> 19:48:11 - 8 seconds later - Transmission only to RF because too soon
                                >>> for -IS
                                >>> 19:48:28 - 17 seconds later yet - Transmission again only to RF (only 25
                                >>> seconds since -IS)
                                >>> 19:48:36 - 8 seconds later yet to both IS and RF being 33 seconds past
                                >>> the -IS dupe window
                                >>>
                                >>> Yep, WAD - Working As Designed. 8+16+8+32+64+96+128 are the retry delays.
                                >>>
                                >>> How long does your new HF modulation take to actually transmit the message?
                                >>>
                                >>> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
                                >>>
                                >>> On 5/22/2013 3:50 PM, Steinar Aanesland wrote:
                                >>>> Thanks for quick reply :)
                                >>>> Here is the log:
                                >>>>
                                >>>>
                                >>>> 2013-05-22T19:48:03.408 Transmit(IS+RF) LA5VNA>APWW10,WIDE1-1::LC5VNA
                                >>>> :testing{AU}
                                >>>> 2013-05-22T19:48:11.704 Transmit(IS) Too Soon (8297), RF-ing
                                >>>> LA5VNA>APWW10,WIDE1-1::LC5VNA :testing{AU}
                                >>>> 2013-05-22T19:48:11.704 Transmit(RF) LA5VNA>APWW10,WIDE1-1::LC5VNA
                                >>>> :testing{AU}
                                >>>> 2013-05-22T19:48:28.704 Transmit(IS) Too Soon (25291), RF-ing
                                >>>> LA5VNA>APWW10,WIDE1-1::LC5VNA :testing{AU}
                                >>>> 2013-05-22T19:48:28.704 Transmit(RF) LA5VNA>APWW10,WIDE1-1::LC5VNA
                                >>>> :testing{AU}
                                >>>> 2013-05-22T19:48:36.704 Transmit(IS+RF) LA5VNA>APWW10,WIDE1-1::LC5VNA
                                >>>> :testing{AU}
                                >>>>
                                >>>>
                                >>>> LA5VNA Steinar
                                >>>> loc:JO59jq
                                >>>>
                                >>>>
                                >>>> Den 22.05.2013 21:38, skrev Lynn W Deffenbaugh (Mr):
                                >>>>> See http://aprsisce.wikidot.com/message-retries
                                >>>>>
                                >>>>> If you're getting the first retry in 1 second, then I've got a bust
                                >>>>> somewhere. Can you bring up and enable the Transmit trace log to
                                >>>>> confirm or deny your message retry timings?
                                >>>>>
                                >>>>> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
                                >>>>>
                                >>>>> PS. I didn't invent the initial 8 second retry delay either. See Bob's
                                >>>>> original page at
                                >>>>>
                                >>>>> http://aprs.org/txt/messages101.txt
                                >>>>>
                                >>>>> In fact, UI-View's 30 second initial retry falls under Bob's statement
                                >>>>> of "Not ONCE like most follow-on clones." in point # 2. UI-View
                                >>>>> sometimes isn't the "gold standard" of APRS implementation. At least,
                                >>>>> not in a universal opinion.
                                >>>>>
                                >>>>> On 5/22/2013 3:11 PM, Steinar Aanesland wrote:
                                >>>>>> Hi all
                                >>>>>>
                                >>>>>> After long time struggle , I finally got things working . Last night I
                                >>>>>> was starting from scratch setting up a completely new test installation,
                                >>>>>> and now station "LA5VNA" and station "LC5VNA" are now able to send a
                                >>>>>> message and than reply with an ACK.
                                >>>>>>
                                >>>>>> There is only one catch, it is only working nicely with UI-View32. When
                                >>>>>> I am sending a message with UI-View32 it goes about 30 seconds before
                                >>>>>> UI-View32 broadcast a new message. This is plenty of time for another
                                >>>>>> station to detect the message and reply with an ACK.
                                >>>>>>
                                >>>>>> When I am trying with my favorite APRS program aprsis32, aprsis32
                                >>>>>> sending a new message only 1 second after the first one. If the RX
                                >>>>>> station is able to detect the first message and reply with an ACK, this
                                >>>>>> ACK will never be detected because it collides with the second
                                >>>>>> retransmission of the message . This goes back and forth until a
                                >>>>>> collision is avoiding and the ACK, is detected .
                                >>>>>>
                                >>>>>> Is there a way to avoid the collision, or is this timing of the second
                                >>>>>> retransmission hard coded into aprsis32 ?
                                >>>>>>
                                >>>>>> LA5VNA Steinar
                                >>>>>> loc:JO59jq
                                >>>>>>
                                >>>>>>
                                >>>>>>
                                >>>>>>
                                >>>>>> Den 18.05.2013 15:59, skrev Steinar Aanesland:
                                >>>>>>> Lynn
                                >>>>>>>
                                >>>>>>>
                                >>>>>>> Thank for your reply. I will do some more testing and send you the log :)
                                >>>>>>>
                                >>>>>>>
                                >>>>>>> " Has anyone used MultiPSK's KISS mode for other APRS messaging? Is
                                >>>>>>> this even possible?" Yes, take a look at this youtube:
                                >>>>>>> http://www.youtube.com/watch?v=4lKbhtChkGw
                                >>>>>>>
                                >>>>>>> LA6VNA S
                                >>>>>>>
                                >>>>>>>
                                >>>>>>>
                                >>>>>>>
                                >>>>>>>
                                >>>>>>> On 18.05.2013 15:43, Lynn W Deffenbaugh (Mr) wrote:
                                >>>>>>>> Please bring up Enables / View Logs / Port(<YourRFPort>) and enable it
                                >>>>>>>> and do the message test again. I'm suspecting that something in the
                                >>>>>>>> chain is mucking about with the curly brace inside the ack sequence
                                >>>>>>>> which is the Reply-Ack protocol. This is supposed to be fully backward
                                >>>>>>>> compatible (I've had many QSOs with UI-View users), so it must be
                                >>>>>>>> something in the ALE/ARQ/MultiPSK chain that is introducing something
                                >>>>>>>> strange.
                                >>>>>>>>
                                >>>>>>>> If you also check Enables / Logging / File Enabled, then the trace from
                                >>>>>>>> above will also go into your APRSIS32.LOG file that you can send on to
                                >>>>>>>> KJ4ERJ@... with a reminder of what it is I'm looking at.
                                >>>>>>>>
                                >>>>>>>> While you've got it all put together, try messaging back and forth with
                                >>>>>>>> a UI-View station over the APRS-IS and/or standard packet just to show
                                >>>>>>>> that the same configuration of the stations (outside of the RF path)
                                >>>>>>>> truly does function. It's a case of "show what works" and then "what's
                                >>>>>>>> different" must be the source of the problem.
                                >>>>>>>>
                                >>>>>>>> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
                                >>>>>>>>
                                >>>>>>>> PS. Has anyone used MultiPSK's KISS mode for other APRS messaging? Is
                                >>>>>>>> this even possible?
                                >>>>>>>>
                                >>>>>>>> On 5/18/2013 7:56 AM, Steinar Aanesland wrote:
                                >>>>>>>>> Hi all ,I hope this is not to out of topic for this group.
                                >>>>>>>>>
                                >>>>>>>>> As some of you probably know, 300b packet is not the best choice on HF,
                                >>>>>>>>> but there are some alternatives.
                                >>>>>>>>> One of them is ALE400 . ALE400 is ARQ mode in Multipsk.
                                >>>>>>>>>
                                >>>>>>>>> I have made me a small lab testing out the ALE400/Multipsk software in
                                >>>>>>>>> KISS with aprsis32 and UI-View32.
                                >>>>>>>>>
                                >>>>>>>>> My lab is like this:
                                >>>>>>>>>
                                >>>>>>>>> I am using to PCes simulating station "LA5VNA" and station "LC5VNA".
                                >>>>>>>>> They are connecting together trough their mic's and they loudspeakers.
                                >>>>>>>>>
                                >>>>>>>>> I was first testing out a combination of
                                >>>>>>>>> Multipsk/KISS/UI-View32 on station "LA5VNA", and a combination of
                                >>>>>>>>> Multipsk/KISS/aprsis32 on station "LC5VNA".
                                >>>>>>>>>
                                >>>>>>>>> [Multipsk/KISS/UI-View32]<===mic's/loudspeakers==>[Multipsk/KISS/aprsis32]
                                >>>>>>>>>
                                >>>>>>>>> Beaconing was working great form station "a" and "b". Both maps was
                                >>>>>>>>> updated, but when trying the message function something
                                >>>>>>>>>
                                >>>>>>>>> strange was happening.
                                >>>>>>>>>
                                >>>>>>>>> When UI-View32 (station "LA5VNA") was sending a message like "test",
                                >>>>>>>>> this appeared in the middle window of multipsk:
                                >>>>>>>>> LA5VNA :LC5VNA :test{12
                                >>>>>>>>>
                                >>>>>>>>> When aprsis32 (station"LC5VNA") was responding with an ack, this was
                                >>>>>>>>> appearing in the
                                >>>>>>>>> lower window of multipsk on station"LA5VNA" :
                                >>>>>>>>>
                                >>>>>>>>> [End of TX] FAE APRS frame
                                >>>>>>>>> LC5VNA :LA5VNA :ack12 [FAE APRS]
                                >>>>>>>>> ...KISS frame repeated
                                >>>>>>>>>
                                >>>>>>>>> Station"LA5VNA" had got its ack and seems to be happy.
                                >>>>>>>>>
                                >>>>>>>>>
                                >>>>>>>>> BUT, when aprsis32 (station"LC5VNA") was sending a "test" message,
                                >>>>>>>>> thisappeared in the middle window of Multipsk:
                                >>>>>>>>> LC5VNA :LA5VNA :test{PU}HX
                                >>>>>>>>>
                                >>>>>>>>> When is UI-View32 (station "LA5VNA") was responding with an ack, this
                                >>>>>>>>> was appearing in the
                                >>>>>>>>> lower window of Multipsk on station"LC5VNA" :
                                >>>>>>>>>
                                >>>>>>>>> [End of TX] FAE APRS frame
                                >>>>>>>>> LA5VNA :LA5VNA :ackPU}HX [FAE APRS]
                                >>>>>>>>> ...KISS frame repeated
                                >>>>>>>>>
                                >>>>>>>>>
                                >>>>>>>>> The aprsis32 (station"LC5VNA") seems not to recognize ackPU}HX as an ACK
                                >>>>>>>>> so it keep repeating the "test" message until it times
                                >>>>>>>>>
                                >>>>>>>>> out.
                                >>>>>>>>>
                                >>>>>>>>>
                                >>>>>>>>> I was then trying with only UI-View32on both station"LC5VNA" and
                                >>>>>>>>> "LA5VNA" and everything works fine. With only aprsis32 there
                                >>>>>>>>>
                                >>>>>>>>> was absolutely no way of getting the stations to recognize the ACK's
                                >>>>>>>>>
                                >>>>>>>>> Does anyone have a clue of was going on ?
                                >>>>>>>>>
                                >>>>>>>>> If you want to try this , download latest ver of multipsk, but remember
                                >>>>>>>>> to read the "ALE_and_ALE400_APRS_with_UI-
                                >>>>>>>>>
                                >>>>>>>>> VIEW_through_Multipsk_easy.doc"
                                >>>>>>>>> https://dl.dropboxusercontent.com/u/16381257/MULTIPSK_TEST_16_05_2013.ZIP
                                >>>>>>>>>
                                >>>>>>>>>
                                >>>>>>>>> LA5VNA Steinar
                                >>>>>>>>> loc:JO59jq
                                >>>>>>>>>
                                >>>>>>>>>
                                >>>>>>>>>
                                >>>>>>>>>
                                >>>>>>>>> ------------------------------------
                                >>>>>>>>>
                                >>>>>>>>> Yahoo! Groups Links
                                >>>>>>>>>
                                >>>>>>>>>
                                >>>>>>>>>
                                >>>>>>>>>
                                >>>>>>>> ------------------------------------
                                >>>>>>>>
                                >>>>>>>> Yahoo! Groups Links
                                >>>>>>>>
                                >>>>>>>>
                                >>>>>>>>
                                >>>>>>> ------------------------------------
                                >>>>>>>
                                >>>>>>> Yahoo! Groups Links
                                >>>>>>>
                                >>>>>>>
                                >>>>>>>
                                >>>>>>>
                                >>>>>>>
                                >>>>>> ------------------------------------
                                >>>>>>
                                >>>>>> Yahoo! Groups Links
                                >>>>>>
                                >>>>>>
                                >>>>>>
                                >>>>>>
                                >>>>>
                                >>>>> ------------------------------------
                                >>>>>
                                >>>>> Yahoo! Groups Links
                                >>>>>
                                >>>>>
                                >>>>>
                                >>>>>
                                >>>>>
                                >>>
                                >>>
                                >>> ------------------------------------
                                >>>
                                >>> Yahoo! Groups Links
                                >>>
                                >>>
                                >>>
                                >>>
                                >>>
                                >>
                                >>
                                >> ------------------------------------
                                >>
                                >> Yahoo! Groups Links
                                >>
                                >>
                                >>
                                >>
                                >
                                >
                                >
                                > ------------------------------------
                                >
                                > Yahoo! Groups Links
                                >
                                >
                                >
                                >
                                >
                              Your message has been successfully submitted and would be delivered to recipients shortly.