Questions related to battery + board temperature #1
Comments
|
Some more board temperature readings. Interesting thing is that it went down for a while (to around 10), but when I moved it, it went up to > 200 again. After moving it a bit (without restart): |
|
And leaving it on the same place for a while (going from 240 down to 7): |
|
I asked the same question in the forum: Battery voltage is: (3000+10*data)/1000 |
|
It looks like there is an issue with the "getBoardTemperature" function. It reads two bytes from the LSM303, but it returns only 1 byte. The datasheet states
If the return statement of the getBoardTemperature() is changed to this:
Then I think the value should be a correct celsius degree Unless I have misunderstood something here? |
|
@KKjelstad without looking at the datasheet I can tell that the code looks suspicious. The LSM303D datasheet states:
To me that means we need to do: And make the function type int16_t, or else do Can someone test this? |
|
@keestux I have done some testing by reading out the H and L bytes. First I cooled down the board. (readings approx. every minute)
This is the code I used: By using 20 + ((temp + 4) / 8) it seems to fit with Celsius, but it is hard to interpret the datasheet to this. |
|
@keestux @KKjelstad The original code should be fine. @KKjelstad there is no problem with the conversion from 16-bit int to 8-bit int because the operating temperature range is -40..+85 (so you will/should never see a value outside this range), which fits well in a signed byte. |
|
@alextsam Hmm, to me this makes no sense. First, I don't see any match with the description in the datasheet. Second, why would you want to cripple a function to 8 bit if the device gives 12 bit? @KKjelstad the datasheet is not clear at all. I just found some other software on github (PX4 Firmware) which states this in the source code, lsm303d.cpp: Then some other software (dcms_media, LSM303D_spi.ino) has: This is similar to what you are experiencing. |
|
@keestux Could you elaborate what doesn't match with the datasheet? The value is not "crippled" as long as it is Celsius in the range -40..+85. Plus the Lora packet specs allowed for only 1 byte, in Celsius. Regarding that the temperature given is an offset, unfortunately I cannot find anything related in the datasheet. @KKjelstad Could you try to replace the "return temp;" with "return temp / 8 + 25;" |
|
@alextsam @keestux I have replaced the return statement with:
Not sure how much heat the device generates it self, but when idling in the office here the temp value stabilized on 28 which results in 3.5. Adding an offset of 25 makes it too high compared to the room temperature so I am currently testing 20 which seems to result in a better match. Adding 4 to the temp value is for correct rounding. |
|
@alextsam The datasheet states:
I don't see that coming back in the logic. The datasheet should really explain what that means, but I think the upper 4 bits could be zero. If that is the case you first need to shift left, and back to do sign extension. No? Furthermore, is there a need to drop the accuracy? Why not make the function return a float? |
|
Hi, @alextsam @KKjelstad , I have also been toying with the SODAQ One temperature sensor and can confirm the readings of @KKjelstad i.e.
The raw reading appears to increase by a value of 8 per degree Celsius temperature change, so division by 8 IS necessary to calculate a usable temperature value while factoring in the 20 degree C offset. I have used the following formula: @KKjelstad I do not understand the need to add 4 to the intermediate result. Can you elaborate? Division by 8 will also make the final result fit in a (signed) byte for the operating range of -40 to 85 degrees C. It is doubtful if returning a float instead of an int would improve 'accuracy' given the still fuzziness of the calculation of the final result. I empathize with the frustration of @keestux as the datasheet is partly lacking or ambiguous with regard to relevant details. A temperature offset of 20 degrees C is mentioned nowhere, a temperature value of 25 degrees C is mentioned in several places in the datasheet, but is unclear if this is to be interpreted as an offset for calculation or as a baseline for sensor characteristics. BTW, I am referencing the LSM303D datasheet as found here: http://www.st.com/resource/en/datasheet/lsm303d.pdf I have searched the Internet for source code that actually uses the embedded temperature sensor but have found no example of code that adds either 20 degrees or 25 degrees Celsius to calculate a final result. Apparently no one is using this for ambient temperature readings per se, but the few code examples found use the temperature sensor to correct for drift in the accelerometer / magnetometer of the LSM303D (see http://www.degruyter.com/downloadpdf/j/afit.2015.36.issue-1/afit-2015-0020/afit-2015-0020.xml. Changing the sampling rate as suggested in http://forum.sodaq.com/t/interpreting-payload-data-from-the-sodaqone-universaltracker/374 does not significantly influence the reading (I have experimented with the range 3.125 - 25 Hz). Neither does changing to high resolution (by setting bits M_RES [1:0] of the CTRL5 register to 11). |
|
@mrjdomingus Adding 4 just ensures that the value is rounded to the correct value when operating with integers. One degree has eight steps so it means the value 0 to 7 of "int16_t temp" corresponds to 0 to 0.875 degrees. Dividing all values between 0 to 7 by eight using integer results in 0. Which is wrong since a value of 4 (0.5 degrees) should be rounded up to 1. One improvement I have considered is to use half degrees in the lora message. The current range is -128 to 127 which is wider than the operating temperature range of -40..+85. There is room for a half degree resolution within that range. |
|
@mrjdomingus @KKjelstad |
Hi! I've received the SodaqOne yesterday and with the pre-installed tracker and boot menu, it was really easy to get it up and running 👍
Most values I've been able to parse, but some of them I'm not sure if I understand them correctly:
Battery:
In the readme the battery voltage is documented as the value beween 3-4.5V. Does this mean the value defines the steps between 3 and 3.5V? So to get the voltage, I have to make the following calculation?
3.0 + (1.5/255 * value) = voltageBoard temperature:
Given that I'm getting values > 200 back, and my board is not on fire 😉 , how should this be interpreted? Should I divide the result by 10?
The text was updated successfully, but these errors were encountered: