Well, that would seem logical, except that a value of 0 means -32768 somethings (feet? inches? microns?), and a value of 0xFFFF means 32767 somethings, so at a minimum some offset is needed.

But, until we understand why the user guide claims that 0xFF00 means 0 somethings, how to deal with the two bytes is pure conjecture.

And, it assumes that both bytes have already arrived.

So, the value comes in as a two-byte signed int, in meters, big end first. This is about as simple as it can possibly be. I’d tweak outsider’s code to this

int altitude = Serial.read();
altitude <<= 8;
altitude |= Serial.read();

but it doesn’t matter all that much.

… actually: -32768 is nine bits. What? Are you sure that’s what the user guide says?

Thanks for all the replies.
You were absolutely right: the user guide was completely off (actually not a commercially available product, just a description about an old software which might have changed).

So it was dead simple after all:

0xFF9C = -100m
0x0064 = +100m

To convert with the bitwise operations works perfect, thanks!

I don't seem to be able to simulate '0m' though. Any thoughts?

To convert with the bitwise operations works perfect, thanks!

I don't seem to be able to simulate '0m' though. Any thoughts?

Well, if FF9C is -100, and 0064 is +100, you sould be able to add them (in hex) to get zero.

C and 4 is 16. So that's zero, carry one. 9 and 6 and one is 16, so again that's zeo and carry the one. 0 and F and 1 is 16, same again and what do you know - zero is 0x0000!