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)
    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 1 of 14 , May 22 1:07 PM
    • 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 2 of 14 , May 22 1:24 PM
      • 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 3 of 14 , May 22 1:40 PM
        • 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 4 of 14 , May 22 1:45 PM
          • 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 5 of 14 , May 31 11:23 AM
            • 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 6 of 14 , May 31 1:07 PM
              • 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 7 of 14 , May 31 1:34 PM
                • 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.