Decode some data

From: ANT_THOMAS25 May 2020 18:41
To: ALL1 of 10
I've built some wireless temperature sensors which work fine on my current setup, but I'm looking to improve it. Without going into all the boring details, I have some data I need to manually decode.

This data contains a float, long and char*.
I've figured out the long and char and need to decode the float. Ideally in a bash script since that's how I'm currently working

Some examples of the payload data and the known actual values.

Payload : 0, 0, 108, 65, 60, 16, 0, 0, 97, 0
temp=14.75
bat=4156
adr=a

Payload : 0, 0, 63, 65, 30, 16, 0, 0, 111, 0
temp=11.94
bat=4126
adr=o

Payload : 0, 0, 157, 65, 98, 19, 0, 0, 98, 0
temp=19.62
bat=4962
adr=b

Payload : 0, 0, 144, 65, 208, 17, 0, 0, 108, 0
temp=18.00
bat=4560
adr=l


And my decoding so far of the first example

Payload : 0, 0, 108, 65, 60, 16, 0, 0, 97, 0
char = adr = a

Payload : 0, 0, 108, 65, 60, 16, 0, 0, 97, 0
long 8bit to 16bit
(16 x 256) + 60 = 4156
bat=4156
edit - made an error here

Payload : 0, 0, 108, 65, 60, 16, 0, 0, 97, 0
I need to decode this to the temp 14.75 float value.

Any ideas?
EDITED: 26 May 2020 11:53 by ANT_THOMAS
From: Peter (BOUGHTONP)26 May 2020 11:12
To: ANT_THOMAS 2 of 10
What makes you think the 65 in position 4 should be used for both bat and temp?

And how certain are you of those example numbers?

Because 144 = 18 * 8 - which seems very coincidental, especially combined with 157 / 8 giving 19.625, but that doesn't work for the first two examples...

However, 14.75 * 8 is 118 - a single digit out. I don't see anything similar for 11.94 and 63

From: ANT_THOMAS26 May 2020 11:52
To: Peter (BOUGHTONP) 3 of 10
I got that massively wrong up there - have edited.
From: Peter (BOUGHTONP)26 May 2020 12:00
To: ANT_THOMAS 4 of 10
So the other numbers are definitely all correct?

How does the data actually come in - presumably it's either binary or hex encoded rather than decimals?

Shouldn't the sensor provide documentation of the format? (Or does it expect using its own crappy software?)

From: ANT_THOMAS26 May 2020 12:01
To: Peter (BOUGHTONP) 5 of 10
I have now figured it out, kinda.
So it seems the temps are 3dp and there has been some rounding which put me off the scent a bit.
The encoding is IEEE 754

And goes as follows

0, 0, 108, 65, 60, 16, 0, 0, 97, 0

In binary
65 = 01000001
108 = 01101100

Then put that in a suitable sequence for IEEE 754 with 0 padding at the end
01000001 01101100 00000000 00000000

That converts to 14.75.

Just need to do the binary to IEEE 754 floating point number in bash somehow, or at least called from a bash script now I have the binary numbers in bash.
 
From: ANT_THOMAS26 May 2020 12:06
To: ANT_THOMAS 6 of 10
Also, the leading zeros in the array may be the padding at the end, as some other examples contain "128" at place 2, so I think I need to include them. But that's easy enough.
0, 0, 108, 65
From: ANT_THOMAS26 May 2020 12:08
To: Peter (BOUGHTONP) 7 of 10
Numbers are correct, as I've now manually successfully decoded it.
In terms of documentation, I've made and coded these sensors myself, I just didn't entirely understand how the data was encoded with the library (RadioHead ASK).

Now just need to figure out a command line binary to IEEE 754 floating point number conversion.
From: Peter (BOUGHTONP)26 May 2020 12:21
To: ANT_THOMAS 8 of 10
Bash doesn't do floating point, but I still expected it to be a simple case of calling bc or something, but nothing useful comes up from relevant searches.

Guess you'll have to convert your manual steps to Perl or Python?

From: ANT_THOMAS26 May 2020 12:26
To: Peter (BOUGHTONP) 9 of 10
Yeah, seen similar. Was wanting to use bc. Now looking at some other simple programs, C++, Perl or Python should handle it, then feed it back in.
From: ANT_THOMAS26 May 2020 13:36
To: ALL10 of 10
Done, decoded using some simple python.