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

Re: [aprsisce] Trying out a new mode with aprsis32 and multipsk in KISS on HF

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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.