I see there are a lot of experts here on how to decode RF signals. I'm all done with that but I'm having problems understanding the pattern I am seeing - maybe someone has seen a similar pattern before.
The following spreadsheet contains all the raw data and my analysis so far:
The RF (433MHz) sends its data every minute or so. The following readout is available:
Channel (1-8 via DIP)
Humidity (0-99%)
Temperature (-40 - +60 C)
Fahrenheit/Celsius
I already know what bytes represent the channel and I do know the humidity (marked in violet and blue):
I don't know yet where to find temperature. After doing some plotting I found some correlated data with temperature:
Then I sorted the data by temperature and had a breakthrough: I found out that there are some kind of temperature ranges (colored in light red in the screenshot):
And temperature range & column I&J together are the solution to where the temperature resides, but I have no mathematical clue what the rule is besides seeing the pattern. Looking at the above screenshot:
It appears that there are 255 distinctive values per range (2^8-1). 17 in Range 2 (-1 to -10C) equals -10,6C. 17 in range 4 (15-30C) equals 20,8C.
I haven't checked for exact cut off points, i.e. I haven't seen a 255 / 256 value yet or 0, but I will try to achieve that tonight to create exact temperature ranges instead of the estimates I have right now. I will also try to find the exact maximum as the 60° Celsius most probably is just a marketing thing - or maybe it really is exactly 60C... The minimum of -40C I will not achieve.
My question is: Has anyone seen temperature scales such as this? With a temperature range and 255 values being mapped to a respective temperature? Is there some kind of formula I am not seeing besides this mapping?
I could seriously write down all mappings (such as the 17 example above), but I doubt that is the correct way to go about this. The Google Spreadsheet with all the data is above so feel free to do your own sleuthing.
I'm not familiar with all the bit-calculations (mod / xor / and / whatever) hence my problems. What do you mean by "decimal case"? I'm pretty sure the base unit is Celsius.
H & I definitely represents the temperature. J definitely represents the "range" - whatever that means.
I know that range=4, I & J=17 is always 17,8C. Adding 2 to 17 (making it 19) equals 17,9C (0,1 C degree more). Adding another 2 (making I&J=21) is 18,0C.
This rule generally holds, but sometimes the increase of 0,1C is not 2 but 1 - so I know that there is some kind of formula behind this and not a simple mapping (i.e. every increase of 2 in I&J equals an increase of 0,1C - this rule doesn't always hold).
Is the "temperature" you state the value displayed by the unit, or from a different thermometer?
I would expect something like 12 bits to be used to represent the measurement.
In some sensors these are BCD values, e.g. the digits 249 representing 24.9 C, in others the field is just an integer, e.g. (temperature in C)*10 plus an offset.
You're perfectly right. I have done ablöst of searching and found exactly the two types of temperature sensors.
There is a little LCD screen displaying the readouts I wrote about in the OP. There also is a LED which blinks whenever data is transmitted which is how I know the data is really coming from the sensor.
Just look at the Google Sheet - I have done al lot more testing and lots of data available.
It might be a 12 bit number just combining H&I&j gives a 12 bit number but I can't make out senseful data that way as I can't figure out the correct offset if it exists.
So I created the 12bit --> decimal conversion for H&I&J. I do see some linear tendencies but can't figure out a formula (see the white on black columns for HIJ and temp*10):
The Google Spreadsheet is also updated of course (see tab 12bit / 12bit sorted):
jremington:
Is the "temperature" you state the value displayed by the unit, or from a different thermometer?
As I wrote previously: It is the temperature of the device as displayed on the LCD screen of the device. It is not an external thermometer.
Will try with Fahrenheit! Haven't thought about that, though I can switch the unit from celsius to fahrenheit on the device itself (which is why I always assumed the values I see must be Celsius). Will make some testings with Fahrenheit now.
Houston, we have liftoff! The values with the unit set to Fahrenheit make a lot more sense!
A increase of 10 of the 12-bit HIJ value represents an increase of 1 degree Fahrenheit!
Ohh, and more more thing: The Fahrenheit value * 10 is simply HIJ - 400, e.g.
1148 - 400 = 748 ~ 74,8F
1156 - 400 = 756 ~ 75,6F
Looking at the values which were supposed to be in Celsius now also makes sense:
1134 equals 73,4F it also equals 23C. 23C converted to Fahrenheit is 73,4F.
The unit sends everything in Fahrenheit! It appears the DIP for Celsius/Fahrenheit in the back is simply switching the display, but not what the unit sends.
Yeah I could but I don't really need checksum for non critical applications. I seems too much work figuring what number is multiplied/divided/added to receice a valid checksum.
