- Jan 2View SourceThanks, -K-Can you take a look at it and send any comments to this list?Hi Everyone,In addition to a fifth version of the 135-2012an PPR2 draft that covered Cliff's
comments, I also uploaded a draft process for obtaining an MS/TP Frame Type
from ASHRAE. I based this on the form that is used to apply for a Vendor ID.On Thu, Jan 2, 2014 at 3:30 PM, Clifford H Copass <Clifford.H.Copass@...> wrote:
Sorry for being late getting back on this - I was out of the office for some time.
Looks like we should be good to go for public review. (I voted Yes).
My intent was to clean up as much confusion as possible within the bounds of editorial updates. This is harder outside of the face to face meetings (but does allow more time to read in detail).
Clif et al.
Please review -rc5 (just uploaded) to see if it addresses all of your comments.
On Tue, Dec 17, 2013 at 12:56 PM, Clifford H Copass <Clifford.H.Copass@...> wrote:
Perhaps if "code block" was defined in the context where it is used, that would be sufficient.
"CRC-32K" seems to be a value while functions are not. Changing the name of "crcValue" may solve the issue - or even better, reference it somewhere (i.e. in a code comment within the example) that "crcValue" is the value of "CRC-32K" in this example. I think the example in question supplies an updated "CRC-32K" through the return value "crc" which also needs to be specifically commented. All examples should do this for all variables that relate to any term used in the text.
If you want to keep the Rationale picture unchanged so it matches the original, then consider something like a parenthetical expression to explain the names are equivalent.
"…Since the CRC-16-CCITT is widely used, (also known as CCITT-16 CRC)…"
On Tue, Dec 17, 2013 at 9:23 AM, Clifford H Copass <Clifford.H.Copass@...> wrote:
[Attachment(s) from Clifford H Copass included below]
I don't really want to keep this back and forth running longer because we can continue based on public review comments, but I can't resist a little more…
Regarding the term "CodeOctet" and its definition - When I see "Code block", I immediately think of part of a computer program subroutine and have no concept of a COBS encoded data block. I believe this may be true for a large part of the audience for this document since it will be computer programming people trying to implement it.
John Hartman's proposal was to place all references to "code block" after the definition. Is
You're not suggesting that "code block" be replaced everywhere it appears in the document?
That would make our descriptions inconsistent with all the existing literature on COBS, including
Stuart Cheshire's PhD thesis (Stanford University) where it occurs nearly 70 times.
I agree that this optional feature will be difficult to implement for anyone who is unable (or unwilling)
to read the description and relate it to the examples and sample code. When I'm in that situation,
I search for and read papers on the topic.
When I look at the "C" code example on page 25, the only thing I see labeled "CRC-32K" is the comment about "…CRC-32K polynomial…" which is 0xEB31D82E in the code.
The function is named CalcCRC32K().
If I am trying to follow this example, I should not need to guess about what variables in the example correspond to what values in the text. This should be extremely clear.
What are your proposed changes? Should I change the name of the formal parameter "crcValue"
to "crc32k" or "crc32kValue"?
Won't this hypothetical reader be similarly confused by the example in G.2.1?
Regarding making the picture labels in the Rationale match the text, is this because of copyright restrictions or because of picture editing capabilities?
I am concerned about modifying it, then citing it as someone else's work. If you feel that agreement
with the figure is paramount, then the better course is to change the text to agree with the drawing.
Two years from now, the rationale will be gone but the text in the standard will persist. Searching
on "CCITT-16 CRC" will still get you to the Wikipedia "Cyclic redundancy check" article, where it is
consistently referred to as "CRC-16-CCITT".
If it is due to picture editing capabilities, I am attaching a modified picture (gif and jpg formats) made in just a few minutes with only the clunky picture editing tools that come with Windows 7. A better modification could be done with decent tools, but this looked satisfactory.
In most of this debate, my concern is that the people trying to implement this may NOT be COBS encoding experts or even communications experts. They should not be required to study the background material before being able to implement the BACnet standard. They should not need to guess about what the examples mean. When I read this from the prospective of someone seeing it for the first time, it is much harder to follow than it should or could be.
I'm not seeking a debate, but convergence. I'm only pushing back in areas that make the proposal
inconsistent with the existing literature or language used elsewhere in Clause 9.
I do not believe this proposal can be made perfect, no matter how long we work on it. However, it
should be standalone (when placed in context with the existing Clause 9) and understandable by
a good majority of those "skilled in the art". If the proposal does not yet meet that standard then I
welcome any proposed text that will improve it.
Lastly, I want to reiterate that this is an *optional* feature for all but BACnet router vendors who
claim conformance to the latest standard, so clearly the goal must be to capture 100% of that
audience (I assume they are communication experts, or at least should be). I have a complete
set of patches for Steve Karg's open BACnet stack (for his BDK board) as well as a Wireshark
dissector. I can copy these up to the mstpwg files area during the holiday break if that would be
Johnson Controls, Inc.
From: Kerry Lynn [mailto:kerlyn2001@...]
Sent: Monday, December 16, 2013 1:06 PM
To: Clifford H Copass
Subject: Re: [bacnet-mstpwg] Revised Addenda 2012an. Third time is the charm?
Thanks for your comments. See my responses inline...
On Mon, Dec 16, 2013 at 9:33 AM, Clifford H Copass <Clifford.H.Copass@...> wrote:
Some ideas and suggestions:
Regarding the use of "CodeOctet":
I think this can be resolved in the "9.5.2 Variables" section. "Code block" is repeatedly used with no reference as to what that means at this point in the text. Also, it seems like a single "code block" is not so much decoded octet by octet as it is processed, since most of the decoding seems to happen at the block boundaries rather than within the block. Finally, exclusively referring to "decoded" (multiple places in the variables section) leaves one wondering if there is any "encoding" required at all.
Consider something like the following for "CodeOctet" (and possibly similar changes elsewhere in the section):
"Used by devices that support COBS-encoded frames to count down the number of octets remaining to be processed in the current block of data within the frame."
What I am trying to get across here is that we are dealing with part of the frame (a subset) and to tie this into 9.10.3 where it refers to "Process a code octet" in several places.
DecodeCount, DecodeIndex, CodeOctet, LastCode, and DataOctet are local variables used
by the procedure in 9.10.3. John Hartman suggested moving them out of 9.5.2 (since they
are not used at all by the state machines) but I failed to heed his advice. I think moving the
variables would be a better solution than to have multiple terms for the same concept. "Code
block" is used consistently in the literature describing COBS, and it is used liberally throughout
the proposal. A less disruptive change would be to have a forward pointer to 9.10.3 at the
first mention of "code block".
Regarding "CRC-32K register C31-C0":
There needs to be a reference that exactly matches a register in the example. Would this be "crcValue"?
You need to first place G.3 in context. G.1 (Header CRC) and G.2 (Data CRC) are
essentially hardware-based descriptions that are then implemented as software
examples. I don't make any attempt to describe the CRC-32K examples from a
hardware perspective, so maybe the first thing to do is drop the word "register".
The language used in G.3 nearly identical to the earlier examples. I have also used
the same C API as shown in earlier examples. It doesn't seem that folks have had
difficulty associating the prose "CRC" with the formal parameter "crcValue" that is
used in the C example. The ASM example is just pulling the CRC bytes off the
stack (i.e. there is no "name" for the parameter).
Regarding "C31-C0", I thought that was a useful cue that the residue value shown
just below that paragraph is in big-endian order. I can remove "C31-C0" if that's the
Finally, there are at least four different concepts that I'm trying to keep straight
through consistent use of different terms: there's the "CRC32K" variable in 9.5.2
which is the actual running accumulator, there's "CRC-32K" which is the name of
the polynomial (and the calculation); there is "Modified CRC-32K" which is the
one's complement of CRC-32K, ordered LSB first; and then there is the "Encoded
CRC-32K" which is the Modified CRC-32K, COBS-encoded.
If so, something like the following would be more enlightening:
"In operation, the CRC32K register "crcValue" bits C31-C0 are initialized to all ones."
What I am trying to do here is to tie the text name (CRC32K) to a variable name used in the example and provide some hint as to what C32 (etc.) means. The "C31-C0" part could be deleted since I don't think it adds much clarity since a register can have bits that can be initialized to all ones. This would then read as:
"In operation, the CRC32K register "crcValue" bits are initialized to all ones."
How about "In operation, the CRC32K value is initialized to all ones."
"See clause 19.X for the preferred approach for determining…"
to something like
"See clause 19.X for an approach for determining…"
Consider deleting the last two words of the first sentence so it ends "…as well as opening up future possibilities." I don't think deleting the whole sentence is a good idea since it is the heart of the rationale (i.e. why do we want to make this change).
Sorry, I was looking at the first sentence. You're right that the second sentence
I would also like to see consistency in terminology for the uninitiated. Use "CCITT-16 CRC" or "CRC-16-CCITT" or whatever is chosen everywhere. Someone reading this for the first time may not realize these are the same thing.
As I said in my previous post, "CRC-16-CCITT" seems to be the most popular
search term for this polynomial so that's what I think should be used in the text.
I can't change the picture, so if it's the group consensus that it's confusing then
I will delete it.
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
On page 25, I don't see what "CRC-32K register C31-C0" in the text has to do with the example code.
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
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.
[Attachment(s) from Kerry Lynn included below]
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.