Uploaded image for project: 'Daffodil'
  1. Daffodil
  2. DAFFODIL-2689

Asterix format uses DFDL disallowed 4th combination of byte order and bit order

Attach filesAttach ScreenshotAdd voteVotersWatch issueWatchersCreate sub-taskLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments
    XMLWordPrintableJSON

Details

    • New Feature
    • Status: Open
    • Major
    • Resolution: Unresolved
    • 3.3.0
    • None
    • Back End, Front End

    Description

      The Asterix CAT 034 message uses byteOrder bigEndian but bit order leastSignificantBitFirst for numbers that span bytes. For example they describe an 11-bit integer in this way:

      In this picture you can see they are numbering the bits from the right, leastSignificantBitFirst starting from 1. But the COUNTER field spans all of Octet 3, but also includes the least significant 3 bits of Octet 2. In those least significant 3 bits are the most significant (numerically) 3 bits of the 11 bit COUNTER integer, so this is bigEndian byte order, but leastSignificantBitFirst bit order.

      The DFDL standard does not allow this combination of bitOrder and byteOrder, as there was no known documented use case at the time the new bitOrder property was added to the DFDL specification. It was however, proposed that it was likely this combination would be needed, and here is a well-documented use case. 

      So Daffodil should lift this restriction and allow this combination.

      The workaround in the mean time is to parse this counter as two separate integers, one 3 bits and one 8 bits, and use an inputValueCalc expression to compute a field with the expected value. 

      Attachments

        Activity

          This comment will be Viewable by All Users Viewable by All Users
          Cancel

          People

            Unassigned Unassigned
            mbeckerle Mike Beckerle

            Dates

              Created:
              Updated:

              Slack

                Issue deployment