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
  • Steinar Aanesland
    Thanks for quick reply :) Here is the log: 2013-05-22T19:48:03.408 Transmit(IS+RF) LA5VNA APWW10,WIDE1-1::LC5VNA ... 2013-05-22T19:48:11.704 Transmit(IS) Too
    Message 1 of 14 , May 22, 2013
    • 0 Attachment
      Thanks for quick reply :)
      Here is the log:


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


      LA5VNA Steinar
      loc:JO59jq


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

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

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

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

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


          LA5VNA Steinar
          loc:JO59jq


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

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

             

            Steve Daniels

            Amateur Radio Callsign G6UIM

            Torbay Freecycle  Owner

            http://uk.groups.yahoo.com/group/torbay_freecycle

            APRSISCE/32 Beta tester and WIKI editor http://aprsisce.wikidot.com

             


            From: aprsisce@yahoogroups.com [mailto: aprsisce@yahoogroups.com ] On Behalf Of Steinar Aanesland
            Sent: 22 May 2013 21:25
            To: aprsisce@yahoogroups.com
            Subject: Re: [aprsisce] Trying out a new mode with aprsis32 and multipsk in KISS on HF

             

             

            A text with 67 characters will take about 15 seconds.

            LA5VNA Steinar
            loc:JO59jq

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

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

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

              LA5VNA Steinar
              loc:JO59jq


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

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

                LA5VNA Steinar
                loc:JO59jq


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

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

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

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


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

                    Standard mode

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

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

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

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

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

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

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

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

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

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

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

                    ARQ FAE mode

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

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

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

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

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

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

                    ARQ FAE modulation description:

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

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

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

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

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

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

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

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

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

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


                    LA5VNA Steinar
                    loc:JO59jq


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