David WoodhouseThe temperature reading is non-obvious, and appears to be inversely proportional to the temperature. Also, when the temperature is on the borderline between two values and is fluctuating, the depth reading appears to fluctuate with it — there is some adjustment being done according to the measured temperature. Two experiments were performed to help understand this.
Firstly, the unit was placed in the freezer at -20°C until the temperature reading became stable (at 35). It was then removed and placed in a stable location at about 18°C and roughly 250cm from a wall. The readings were monitored as it warmed up to ambient temperature.
Secondly, the unit was placed in a warm room and then the heating was turned off and the window opened. Readings were monitored overnight as the temperature dropped to 5.7°C and then rose again. The maximum and minimum ambient temperature at which each value from the sensor was seen, was charted.
Using the results of the second experiment, a chart was plotted to illustrate an estimate of the meanings of the temperature values. A good fit is achieved by assuming that 35 indicates -10°C, which is the lowest rated temperature of the system, and 17 indicates 20°C.
These assumptions are further validated by the results of the depth calibration in the first experiment. For each temperature reading, an assumed actual temperature is now available, and the speed of sound at that temperature can be calculated.
Remember, in the first experiment the ambient temperature was actually about 18°C, with the speed of sound being ~342m/s. But the unit had just been taken out of the freezer and was still warming up, so its reading of the temperature was inaccurate. To start with, it was assuming that the temperature was -8.3°C and thus the speed of sound was only 326m/s, and thus it was under-reading the distance by 5%. If we adjust for the temperature misreading, a distance of 251.46cm is obtained.
Similar calculations are seen in the table above, for each temperature value. It can be seen that the assumptions (35==-10°C, 17==20°C) give a reasonable fit for these data too, with a minimal variance between the minimum and maximum "adjusted" depth readings as the unit warmed up.
Conclusion
Given the above, it seems reasonable to conclude that the transmitter is giving a pre-adjusted depth value which already takes into account the temperature and the resulting speed of sound, and that the temperature indicated by a given temperature reading t is calculated by:
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
Yeah, I am thinking that the 4, 6, 8 , a, and c are predetermined and used for humidity, or to flag a hot condition. And I am wondering if when it gets cold enough that the microcontroller just goes to sleep in order for the receiver to get the ! warning. I agree with what you found. I think that the temp corrections are for the range of 20C to -10C. It is just a matter of working out the flags.
Are you sure? yes | no
do you have the datalog from this available?
Are you sure? yes | no
got it , nevermind.
Are you sure? yes | no
You can have the oven one too: http://david.woodhou.se/watchman-oven.txt — see the top bits of the 'flags' word go to 0xc0 as it gets really hot (about 60°C) and then fall back to 0xa0, 0x80 as it cools down. So maybe that's a separate 3-bit indication of temperature? Or maybe it's something like humidity and just *seems* to vary with temperature?
Anyway, it's been in the oven at 60°C and I've updated http://david.woodhou.se/watchman.ods with some more data (and will add more as it continues cooling down). It's decidedly non-linear at those temperatures.
Are you sure? yes | no
I've published the spreadsheet at http://david.woodhou.se/watchman.ods
In there, there's also an analysis of the expansion of the oil itself — which accounts for about a 4% difference in volume between -10°C and 20°C. It's probably worth adjusting for that on the receiver side.
Are you sure? yes | no