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

BQP32/Fldigi-KISS ARQ framing

Expand Messages
  • bob_cunnings
    Hi, I m trying to understand the framing used by the BPQ32/Fldigi-KISS RAW mode setup. The BPQ doc for the Fldigi driver states that the protocol used is
    Message 1 of 5 , Apr 20, 2014
    • 0 Attachment
      Hi,
      I'm trying to understand the framing used by the BPQ32/Fldigi-KISS RAW 
      mode setup. The BPQ doc for the Fldigi driver states that the protocol used is
      "compatible with FLARQ", so my first question is whether or not this ARQ
      spec being used:


      ?? It's revision 0.2, dated 2004.

      I can't quite square everything that appears in the fldigi monitor window or fldigi
      capture log with this spec, I suppose that non printable characters like <SOH>
      complicate matters and what I see printed can't be a byte for byte replica of the
      actual frames.

      In the headers I see what appear to be 2 block types not found in the spec -  
      type 'b' (sent in response to a disconnect request) and type 'u' (which seems
      to be used with unproto frames like beacons). Is this right?

      If the 0.2 ARQ protocol is outdated, is there another version of it
      out there somewhere? 

      I also that the received frames are pretty printed inside a pair of
      <STX> and <EOT> tags in the fldigi monitor window. Is it safe to 
      assume this is just a visual aid not reflecting any actual received characters?

      I like to understand what I see in the monitor window so I can follow the
      flow of a connection and know what's happening if something goes wrong.
        
      Thanks and 73,
      Bob NW8L
    • John Wiseman
      Bob, The packet payloads are the same as used by FLARQ, which is based on, but seems to be a superset of, the spec you quoted. As you have noticed, there are
      Message 2 of 5 , Apr 21, 2014
      • 0 Attachment
        Bob,

        The packet payloads are the same as used by FLARQ, which is based on, but
        seems to be a superset of, the spec you quoted. As you have noticed, there
        are extra packet types. The full set is:

        i Ident
        c Connect
        k Connect Ack
        r Connect NAK
        d Disconnect req
        s Data Ack/ Retransmit Req (status)
        p Poll
        f Format Fail
        b dis ack
        t talk

        a Abort
        o Abort ACK

        My driver runs in two modes, one using the <STX><EOT> framing, DLE
        transparency and the 4 byte ASCII CRC used by FLDIGI, and one using KISS
        framing and CRC, which results in slightly shorter packets, which is the
        default for BPQ<>BPQ connections.

        As some of the FLDIGI modems aren't 8 bit clean, Robert applies his own
        transparency encoding in the on-air packets, but ASCII text should appear on
        the FLDIGI monitor screen pretty much as it is sent.

        73, John
        ________________________________________
        From: BPQ32@yahoogroups.com [mailto:BPQ32@yahoogroups.com] On Behalf Of
        nw8l@...
        Sent: 21 April 2014 05:48
        To: BPQ32@yahoogroups.com
        Subject: [BPQ32] BQP32/Fldigi-KISS ARQ framing

         
        Hi,
        I'm trying to understand the framing used by the BPQ32/Fldigi-KISS RAW 
        mode setup. The BPQ doc for the Fldigi driver states that the protocol used
        is
        "compatible with FLARQ", so my first question is whether or not this ARQ
        spec being used:

        http://www.w1hkj.com/FlarqHelpFiles/ARQ2.pdf

        ?? It's revision 0.2, dated 2004.

        I can't quite square everything that appears in the fldigi monitor window or
        fldigi
        capture log with this spec, I suppose that non printab le characters like
        <SOH>
        complicate matters and what I see printed can't be a byte for byte replica
        of the
        actual frames.

        In the headers I see what appear to be 2 block types not found in the spec -
         
        type 'b' (sent in response to a disconnect request) and type 'u' (which
        seems
        to be used with unproto frames like beacons). Is this right?

        If the 0.2 ARQ protocol is outdated, is there another version of it
        out there somewhere? 

        I also that the received frames are pretty printed inside a pair of
        <STX> and <EOT> tags in the fldigi monitor window. Is it safe to 
        assume this is just a visual aid not reflecting any actual received
        characters?

        I like to understand what I see in the monitor window so I can follow the
        flow of a connection and know what's happening if something goes wrong.
          
        Thanks and 73,
        Bob NW8L
      • bob_cunnings
        John, Thanks for the info. When your driver is working in KISS mode I see that transmit frames are printed verbatim to the fldigi monitor window, including the
        Message 3 of 5 , Apr 21, 2014
        • 0 Attachment
          John,

          Thanks for the info. When your driver is working in KISS mode I see that transmit frames are printed verbatim to the fldigi monitor window, including the KISS FEND characters which print as 'A-grave' on the screen.

          Looking at headers it appears that the 4 byte header in the spec is reduced to 2 bytes, just the stream ID and the block type. It also appears that the CRC is only 2 bytes, not 4 as in the spec.

          What I notice about the connection request frames is that they include what appears to be a parameter string which is always "T60R5W10". Is it safe to assume that these are the usual FLARQ "timeout", "retries" and "wait time" parameters seen in the FLARQ application, set to the default values?

          Thanks and 73, 
          Bob NW8L

          ---In BPQ32@yahoogroups.com, <john.wiseman@...> wrote :

          Bob,

          The packet payloads are the same as used by FLARQ, which is based on, but
          seems to be a superset of, the spec you quoted. As you have noticed, there
          are extra packet types. The full set is:

          i Ident
          c Connect
          k Connect Ack
          r Connect NAK
          d Disconnect req
          s Data Ack/ Retransmit Req (status)
          p Poll
          f Format Fail
          b dis ack
          t talk

          a Abort
          o Abort ACK

          My driver runs in two modes, one using the <STX><EOT> framing, DLE
          transparency and the 4 byte ASCII CRC used by FLDIGI, and one using KISS
          framing and CRC, which results in slightly shorter packets, which is the
          default for BPQ<>BPQ connections.

          As some of the FLDIGI modems aren't 8 bit clean, Robert applies his own
          transparency encoding in the on-air packets, but ASCII text should appear on
          the FLDIGI monitor screen pretty much as it is sent.

          73, John

        • John Wiseman
          Bob, Yes, when in the default mode it eliminates the irrelevent header bytes and uses the two byte HDLC CRC instead of the 4 byte ascii CRC, which saves 4
          Message 4 of 5 , Apr 22, 2014
          • 0 Attachment

            Bob,

             

            Yes, when in the default mode it eliminates the irrelevent header bytes and uses the two byte HDLC CRC instead of the 4 byte ascii CRC, which saves 4 bytes per frame. When in FLARQ compatibility mode it sends in the FLARQ format.

            The T60R5W10 is currently hard coded, but should really be set from the configured parameters. They are the Connect timeout, retry count and response timeout values.

            73,

            John

             


            From: BPQ32@yahoogroups.com [mailto: BPQ32@yahoogroups.com ] On Behalf Of nw8l@...
            Sent: 22 April 2014 03:19
            To: BPQ32@yahoogroups.com
            Subject: RE: [BPQ32] BQP32/Fldigi-KISS ARQ framing

             

             

            John,

             

            Thanks for the info. When your driver is working in KISS mode I see that transmit frames are printed verbatim to the fldigi monitor window, including the KISS FEND characters which print as 'A-grave' on the screen.

             

            Looking at headers it appears that the 4 byte header in the spec is reduced to 2 bytes, just the stream ID and the block type. It also appears that the CRC is only 2 bytes, not 4 as in the spec.

             

            What I notice about the connection request frames is that they include what appears to be a parameter string which is always "T60R5W10". Is it safe to assume that these are the usual FLARQ "timeout", "retries" and "wait time" parameters seen in the FLARQ application, set to the default values?

             

            Thanks and 73, 

            Bob NW8L

             

            ---In BPQ32@yahoogroups.com , <john.wiseman@...> wrote :

            Bob,

            The packet payloads are the same as used by FLARQ, which is based on, but
            seems to be a superset of, the spec you quoted. As you have noticed, there
            are extra packet types. The full set is:

            i Ident
            c Connect
            k Connect Ack
            r Connect NAK
            d Disconnect req
            s Data Ack/ Retransmit Req (status)
            p Poll
            f Format Fail
            b dis ack
            t talk

            a Abort
            o Abort ACK

            My driver runs in two modes, one using the <STX><EOT> framing, DLE
            transparency and the 4 byte ASCII CRC used by FLDIGI, and one using KISS
            framing and CRC, which results in slightly shorter packets, which is the
            default for BPQ<>BPQ connections.

            As some of the FLDIGI modems aren't 8 bit clean, Robert applies his own
            transparency encoding in the on-air packets, but ASCII text should appear on
            the FLDIGI monitor screen pretty much as it is sent.

            73, John

          • bob_cunnings
            John, Ok, good to know. Yes, I had noticed that changing TIMEOUT or RETRIES values in the port definition for the fldigi driver had no effect on any parameters
            Message 5 of 5 , Apr 22, 2014
            • 0 Attachment
              John,

              Ok, good to know. Yes, I had noticed that changing TIMEOUT or RETRIES values in the port definition for the fldigi driver had no effect on any parameters in the connection request frame.

              I located the relevant fldigi source on BerliOS.  Should have done that sooner. arq.cxx and arq.h bring enlightenment about the FLARQ framing details, and kiss_io.cxx and kiss_io.h in the fldigi-kiss branch tell the rest of the story. Together with you explanation of the BPQ32 KISS frame contents, what I see all makes sense now.

              Thanks for your help!

              73, Bob NW8L


              ---In BPQ32@yahoogroups.com, <john.wiseman@...> wrote :

              Bob,

               

              Yes, when in the default mode it eliminates the irrelevent header bytes and uses the two byte HDLC CRC instead of the 4 byte ascii CRC, which saves 4 bytes per frame. When in FLARQ compatibility mode it sends in the FLARQ format.

              The T60R5W10 is currently hard coded, but should really be set from the configured parameters. They are the Connect timeout, retry count and response timeout values.

              73,

              John


            Your message has been successfully submitted and would be delivered to recipients shortly.