The io_lib function ichebcomp seems to store the first trace value in little-endian order. The decoder has the same bug in reverse so it balances out, but it does mean that any decorder which follows the specification will get corrupt data.
That's a blast from the past! I see what you mean, the code does look distinctly odd with data[0] = le_int2(ZTR_FORM_ICHEB) for the first element and all other data[] elements being be_int2().
However, I think this is correct. The ZTR specification states:
> ICHEB (#74) - integer based 16-bit chebyshev polynomial predictor
> -----------
> Version 1.2 onwards
> This replaces the floating point CHEB445 format in ZTR v1.1.
>
>
> Byte number 0 1 2 N
> +--+--+-- - --+
> Hex values |4A| 0| data |
> +--+--+-- - --+
>
> This method takes big-endian 16-bit data and attempts to curve-fit it using
> chebyshev polynomials.
So the first two bytes are 0x4a 0x00 and then a series of 16-bit big endian integers from then on. This is because the first BYTE in every ZTR block encodes the format. Because the data contained in this block happens to be 16-bit, a nul padding byte is added so that the rest of the data stream is still 16-bit aligned, for processing simplicity (otherwise we would need a memmove to avoid unaligned access errors on platforms like SPARC).
Or are you saying that the first actual trace value is also little endian? I cannot see that in the code.
Last edit: James Bonfield 2015-12-11
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
d16 points to the big-endian raw data, so on little-endian machines the first value gets swapped to little-endian. But if it's only used on raw data blocks it doesn't matter, because they start with 0x00 0x00 anyway.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That's a blast from the past! I see what you mean, the code does look distinctly odd with data[0] = le_int2(ZTR_FORM_ICHEB) for the first element and all other data[] elements being be_int2().
However, I think this is correct. The ZTR specification states:
So the first two bytes are 0x4a 0x00 and then a series of 16-bit big endian integers from then on. This is because the first BYTE in every ZTR block encodes the format. Because the data contained in this block happens to be 16-bit, a nul padding byte is added so that the rest of the data stream is still 16-bit aligned, for processing simplicity (otherwise we would need a memmove to avoid unaligned access errors on platforms like SPARC).
Or are you saying that the first actual trace value is also little endian? I cannot see that in the code.
Last edit: James Bonfield 2015-12-11
Actually I'm referring to this line:
d16 points to the big-endian raw data, so on little-endian machines the first value gets swapped to little-endian. But if it's only used on raw data blocks it doesn't matter, because they start with 0x00 0x00 anyway.