For link16, it is leastSignificantBitFirst, so as each bit arrives, add it
to the left end of a growing string of bits that you accumulate starting on
the right.
Here is a fake 70 bit word displayed as individual bits the way Link16 is
commonly displayed, below that is each hex nibble, and below that each byte
as hex.
bit 70
bit 1
v
V
00 0101 1001 0000 1101 1001 1011 1011 1110 0000 0010 1000 0000 1100 0000
1011 0000 1100
5 9 0 D 9 B B E 0 2 8 0 C 0 B
0 C
90 D9 BB E0 28 0C 0B
0C
byte 8 byte 7 .... ... byte 2
byte 1
Most commonly, when converted to bytes in a file these 70 bit words will be
padded with 2 more bits so they are an even 9 bytes long. (add 2 more 0
bits to the left of that string of bits).
That way each new 70 bit word starts on a byte boundary.
It doesn't have to be done that way, but commonly is. I've also seen 10
bits of padding (making each word 10 bytes), and 5 bits of padding making
each word 75 bits long (why anyone would want that I have no clue.)
If you looked at this data in an ordinary hex editor, you will see 0C 0B 0C
28 E0 BB D9 90 .... because the hex editor displays byte 1 first, then
successive bytes to the right.
You will find an ordinary hex editor almost useless when working with
leastSignificantBitFirst data. You have to lay it out like the above, right
to left, to figure out anything about it.
Now, Link16 data is usually carried using a header format that comes
before the actual link16 data. So really you are likely to have some number
of bytes of header, then the data bytes 0C 0B 0C 28 E0 BB D9 90 ... in that
order.
On Thu, Dec 7, 2023 at 2:38 PM Roger L Costello <coste...@mitre.org> wrote:
> Thanks Steve.
>
>
>
> As it turns out, I am working with the Link-16 data format. You are saying
> that the stream of received bits – 0 then 1 then 1 then 1 then 0 then 0
> then 1 then 0 then … - are viewed in this fashion:
>
>
>
> High memory address Low memory address
>
> 0010 0001 ................................................ 0100 1110
>
> Hex: 21 ……………………………………. 4E
>
>
>
> That is consistent with the Link-16 specification.
>
>
>
> Here’s where I get confused. Suppose I store those bits into a file. Then
> I open the file in a hex editor. How will the hex editor display the data?
>
>
>
> Will the hex editor display the four bits at the lowest memory address
> (1110) in hex digit form (E), followed by the four bits at the
> next-to-lowest memory address (0100) in hex digit form (4):
>
>
>
> E4 ……………………………… 12
>
>
>
> Or will the hex editor see the bits in reverse order:
>
>
>
> Low memory address High memory address
>
> 0111 0010 ………………………………………… 1000 0100
>
> Hex: 72 ………………………………………………. 84
>
>
>
> And display this:
>
>
>
> 72 ………………………………………….. 84
>
>
>
> That is wildly different!
>
>
>
> Eek! I am so confused! Help!
>
>
>
> *From:* Steve Lawrence <slawre...@apache.org>
> *Sent:* Thursday, December 7, 2023 1:16 PM
> *To:* users@daffodil.apache.org
> *Subject:* [EXT] Re: Bits are streamed into an application ... the bits
> are put in memory ... is the first bit received at the lowest memory
> address?
>
>
>
> The most likely interpretation is that the 2-bit field will have a value
> of "01", with a decimal value of 1. This is what DFDL calls dfdl:
> bitOrder="mostSignificantBitFirst" and is what most data formats use. DFDL
> also has dfdl: bitOrder="leastSignificantBitFirst",
>
> The most likely interpretation is that the 2-bit field will have a value
>
> of "01", with a decimal value of 1. This is what DFDL calls
>
> dfdl:bitOrder="mostSignificantBitFirst" and is what most data formats use.
>
>
>
> DFDL also has dfdl:bitOrder="leastSignificantBitFirst", which is common
>
> in some old military formats like VMF and Link16. One way to imagine
>
> this is as if the memory addresses and bits were ordered and read
>
> right-to-left. So, your example would look like this:
>
>
>
> High memory address Low memory address
>
> 0 0 ................................................ 1 1 0
>
>
>
> So we have the same data, and you still read the low memory address bits
>
> first, it's just all backwards. Because we read right-to-left, the first
>
> two bits are now "10". Note that interpreting the value of the bits is
>
> the same as normal, so "10" evaluates to 2--all that changes is the
>
> order in which we read bits.
>
>
>
> I haven't seen any formats where the high memory address bits would be
>
> read first and would lead to the 2-bit field being "00". DFDL doesn't
>
> have a way to model this.
>
>
>
> On 2023-12-07 12:28 PM, Roger L Costello wrote:
>
> > Hi Folks,
>
> >
>
> > A basic question about bits.
>
> >
>
> > Scenario: an application is receiving a message. The message arrives as a
> > stream of bits. The first bit received is 0. The second bit received is 1.
> > The third bit received is another 1. ... The second-to-last bit received is
> > 0. The last bit received is 0.
>
> >
>
> > The application stores the message in memory.
>
> >
>
> > Will the first bit received be in the lowest memory address and the last
> > bit received in the highest memory address? I.e.,
>
> >
>
> > Low memory address High memory address
>
> > 0 1 1 ............................................................. 0 0
>
> >
>
> > The message contains a series of bit fields. The specification for the
> > message says the first field is two bits.
>
> >
>
> > Is the first field the bits 0 1 or the bits 00?
>
> >
>
> > /Roger
>
>
>
>
