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

179Re: [bacnet-mstpwg] Revised Addenda 2012an. Third time is the charm?

Expand Messages
  • Kerry Lynn
    Dec 15, 2013
    • 0 Attachment
      Hi Clif,

      Thanks for your comments.  Se my responses inline...


      On Fri, Dec 13, 2013 at 5:21 PM, Clifford H Copass <Clifford.H.Copass@...> wrote:
       

      I have been reading through Add-135-2012an-PPR2-draft-rc4.docx and found some places that confuse me.  I am checking to see if I am missing something significant or if there are some editorial corrections that can be made before public review.

       

      The term "CodeOctet" is giving me some problems.  In some places it sounds like a data octet and in some places it sounds like an index.  Is this where the omitted "zeros" are added back in by counting down the block size?  If so, that could be clearer.

       

      The fundamental definition is given on page 20:
      "A COBS code block consists of a single code octet, followed by zero or more data octets. The number of data octets is represented by the code octet."

      So a COBS-encoded field consists one or more code blocks, each or which begins with
      a code octet. Without more detail, I'm not sure which sections of the text are causing
      confusion.

      On page 25, I don't see what "CRC-32K register C31-C0" in the text has to do with the example code.

       

      The sentence
      "In operation, the CRC-32K register C31-C0 is initialized to all ones."
      is similar to the descriptions of the header and data CRC examples in Annex G.
      Would you just like to see "C31-C0" removed?

      On page 5, "See clause 19.X for the preferred approach…" seems too strong a statement.

       

      What text would you propose?
       

      On page 3, in the Rationale, the first sentence seems incomplete.  Also in the drawing, "CCITT-16 CRC" doesn't match the text which uses "CRC-16-CCITT".

       

      Would you propose to delete the first sentence?  It was perhaps more timely three years
      ago when 115,200 baud had just been approved.  Although the proposal doesn't explicitly
      forbid the use of large frames with low baud rates, vendors will hopefully realize this is a
      bad combination.

      There are many variations on the name "CRC-16-CCITT" but they all refer to the same
      polynomial.  "CRC-16-CCITT" and "CRC-32K" are the names used in the Wikipedia
      article on CRC polynomials.

      Please respond with your thoughts on the points above.

      Regards, -K-

       

      Cliff Copass

       

       

      From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Kerry Lynn
      Sent: Tuesday, December 10, 2013 11:31 AM
      To: bacnet-mstpwg
      Subject: [bacnet-mstpwg] Revised Addenda 2012an. Third time is the charm? [1 Attachment]

       

      [Attachment(s) from Kerry Lynn included below]


      Greetings,

      I have uploaded the third revision of the Add-135-2012an PPR2 draft up to the files
      area and have attached it here.

      It contains all the edits we discussed on last weeks call as well as resolutions to
      several good comments from John Hartman.

      This version contains a sample COBS-encoded frame (see X.4) but I did not have
      time to do a flowchart for COBS-decoding.  We have pseudo-code (9.10.3) and
      example code (X.3) so hopefully that will be sufficient.

      I also reversed spur-of-the-moment decision that we made on last weeks call,

      namely to define the range of Frame Types 32 - 63 as COBS-encoded.  I feel
      there are several good reasons for setting the range back to 32 - 127:

      a) We started PPR1 with the thoroughly MSTP-WG discussed range 8 - 127.

      b) That range was reduced to 32 - 127 just in case we ever want to define

           more "legacy" frames

      c) The rationale for reducing the COBS-encoded range still further was "in

          case a new technology comes forward".  I doubt that will ever occur.

      d) Adding a third range, e.g. "Undefined", to "COBS-encoded" and "Non-encoded"

         would seriously complicate the document at this point.

      e) The only current use of this range in the proposal is for the purposes of

          validating header fields

      f) If we really think some new format may come out later, then we can deal with

         that possibility by allocating Frame Types from 34 on.  This will permit later

         definition of a new range after COBS-encoded.

      If this decision or lack of a flowchart is a show-stopper, then we should discuss it

      at the next SSPC.

      Regards, -K-




    • Show all 10 messages in this topic