logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

[Solved] [lua] BME280 - How to correctly read the temperature from registers 0xFA-0xFC?

czasnagli 4587 49
ADVERTISEMENT
Treść została przetłumaczona polish » english Zobacz oryginalną wersję tematu
Report a violation of the law
| New topic
  • #31 17063611
    czasnagli
    Level 17  
    I already have the moisture reading done, but I want to ask about the dig_H4 and dig_H5 .
    For what purpose under Register content at dig_H4 the information [11:4]/[3:0] , and at dig_H5 --> [3:0]/[11:4] ?
    It seems to me, that to correctly read the value of dig_H4 and dig_H5 only the information in the box "Register Address" is needed.

    [lua] BME280 - How to correctly read the temperature from registers 0xFA-0xFC? .
  • ADVERTISEMENT
  • #32 17063799
    chemik22
    Level 14  
    czasnagli wrote:
    Why is [11]/[3] given under Register content at dig_H4 and --> [3]/[11] at dig_H5?



    The point is that in order to presumably save memory space they stuffed dig_H4/5 into two registers instead of, say, four. This, from the table, means that the 0xE4 register holds the bits 11 to 4 of dig_H4, while the bits 3 to 0 of 0xE5 hold the bits 3 to 0 of dig_H4. The analogy is the same for dig_H5. Note that both numbers are actually 12 bit values.


    It's a bit twisted and strange that they wanted to cram it into two registers by force. I remember that it takes a bit of work to read these values correctly. Not as simple as for temperature and pressure.

    Added after 4 [minutes]: .



    Maybe this will help you. I embraced these values this way. By shifting the bits accordingly and masking the others:


    Code: C / C++
    Log in, to see the code
    .
  • #33 17064892
    czasnagli
    Level 17  
    chemik22 wrote:
    Note that both numbers are actually 12 bit values.
    .
    Going back further to the "Register Address" I see, that at dig_H4 the bits are set in the correct order - from oldest to youngest [11:4]/[3:0] . However, with dig_H5 the bits are set in the wrong order [3:0]/[11:4] . If we want to read the 12 bit value dig_H5 then the bits should be set in this order [11:4]/[3:0] ?

    Thanks for the example you gave, but which registers are read when calculating dig_H4_a, dig_H4, dig_H5_a, dig_H5? I ask because I don't want to make a mistake at my place.

    [lua] BME280 - How to correctly read the temperature from registers 0xFA-0xFC? .
  • #34 17065726
    chemik22
    Level 14  
    Sorry for not specifying specific registers so:
    BME280_memory_r_callibration_b[3] is address 0xE4
    BME280_memory_r_callibration_b[4] is address 0xE5
    BME280_memory_r_callibration_b[5] is address 0xE6


    czasnagli wrote:
    If we want to read the 12 bit value of dig_H5 then the bits should be set in this order [11]/[3] ?
    .


    Well literally as you write... with this humidity is probably the most messed up thing about this whole BME280....


    If you do as in my example from the previous post by substituting their addresses 0xE4-6 for the corresponding "BME280_memory_r_callibration_b" then these values will be read exactly as intended by the BME280 creators ;) .
  • #35 17067257
    czasnagli
    Level 17  
    Presumably in the example for dig_H5_a the bit offset >>4 has been truncated.

    chemik22 wrote:
    Code: Lua
    Log in, to see the code
    .

    I also found a simplified version of the reading dig_H5 without & 0b11110000 , but I don't know if it is correct.

    [lua] BME280 - How to correctly read the temperature from registers 0xFA-0xFC? .
  • ADVERTISEMENT
  • #36 17067342
    chemik22
    Level 14  
    czasnagli wrote:
    I also found a simplified version of the dig_H5 readout without & 0b11110000, but I don't know if this is correct.
    .


    Yes it is correct, you can do that too and it will be ok.
  • #37 17067695
    czasnagli
    Level 17  
    The humidity reading works correctly, but only when the temperature is above 15°C . For example, at 15.03°C humidity is correct and is 47.42% but at 14.96°C the humidity is not correct because it is only 14.03% .
    Code: Lua
    Log in, to see the code
    .
    I may have made a mistake by replacing this entry
    Code: C / C++
    Log in, to see the code
    .
    such?
    Code: Lua
    Log in, to see the code
    .
  • #38 17068191
    chemik22
    Level 14  
    These conditions look cool. Strange these results because it clearly looks like these conditions don't work if it says you have the value v_x1_u32r = 588814594. I don't know how it is in Lua. But test yourself on some simple example if such a notation if "something there" then "something there" end works at all as you expect. In the terminal you will then find out....
  • #39 17070911
    czasnagli
    Level 17  
    In various lines of the script I inserted the printing of the variable v_x1_u32r to check the operation of the program. With the same colour, I marked the printed value of the variable v_x1_u32r_1 for temperatures above and below 15°C . In summary, it can be concluded that when the temperature dropped to 14.99°C it v_x1_u32r_1 took a negative value -38 . At that time, the calculated moisture content was only 10% , which is obviously an incorrect value.

    The variable marked in brown v_x1_u32r_5 was printed, confirming the operation of the second condition if v_x1_u32r > 419430400 . However, meeting this condition did not result in the calculation of the correct moisture content in the second case.

    Could the miscalculated moisture value be related to the fact that at some point the bit shifts are conducted on a negative number -38 ? The question remains about the first condition if , which did not work because the value v_x1_u32r was not less than zero.

    [lua] BME280 - How to correctly read the temperature from registers 0xFA-0xFC? .
  • ADVERTISEMENT
  • #40 17071897
    chemik22
    Level 14  
    czasnagli wrote:
    Could the miscalculated moisture value be related to the fact that at some point the bit shifts are conducted on a negative number -38 ?
    .


    If the bit shift was done in C/C++ then wouldn't expect problems but in Lua it's hard to tell. Probably the easiest thing to do is to test it on foot using an example, e.g. declare a value of -100 and shift the bits by e.g. 4 places, spit it out in a terminal and see if you get the same thing as you would in a Windows calculator or on a piece of paper counting
  • #41 17074576
    czasnagli
    Level 17  
    I checked in lua the correctness of the bit shifts on the number -100 . In lua after shifting to the left -100 <<4 I got the result -1600 . I got an identical result in this calculator --> http://calc.penjee.com/?s=vvAAAAlAJJehhhhlAJJ...JJeiiiiqslrAJJehhhhlAJJeiiiivvvlAJJbeAJJehhhh

    In lua after shifting to the right -100 >>4 I got the result 268435449 . I got an identical result in this calculator --> http://calc.penjee.com/?s=vvAAAAlAJJehhhhlAJJ...hhlAJJeiiiivvvlAJJbeAJJehhhhlAJJehhhlAJJeiiii

    If the above calculations are correct then the reason for the incorrect result of humidity below 15°C should be sought elsewhere.


    EDIT:

    Maybe I made an error in calculating adc_H ? If you can then provide your example of the calculation for adc_H .
    Code: Lua
    Log in, to see the code
    .
  • Helpful post
    #42 17075218
    chemik22
    Level 14  
    Here's the code for humidity:


    Code: C / C++
    Log in, to see the code
    .


    This can probably be simplified as well but with this notation it works without a problem.... I hope this solves the problem....
  • #43 17075656
    czasnagli
    Level 17  
    Thank you for the code :) . Based on it, I checked my calculations but found no error in them. After doing this, I did one more test. I moved the line marked by the red box higher in place of the arrow and then cooled the thermometer to below 15°C . In the posted snapshot, it can be seen that moving the line var1 = (var1 < 0 ? 0 : var1) triggered this condition. The variable v_x1_u32r_1 --> -.63 was set to b5ca7bca6f 0 ( v_x1_u32r_4 --> 0 ), and the calculated moisture content appears to be the correct value. At 15.03°C humidity was 40.17% , and at 14.99°C --> 40.11% .

    Wouldn't moving the condition higher up falsify the moisture results? Can the line remain at this point?

    [lua] BME280 - How to correctly read the temperature from registers 0xFA-0xFC? .

    [lua] BME280 - How to correctly read the temperature from registers 0xFA-0xFC?
  • ADVERTISEMENT
  • #44 17076016
    chemik22
    Level 14  
    czasnagli wrote:
    Would moving the condition higher not falsify the moisture results? Can the line remain in this location?
    .


    A bit strange that this condition depending on where in the code once works and once not.... Intriguing and incomprehensible...


    Generally such a change makes little difference because in the "old" place the condition should be caught faster (or slower) notice that the number var1 recalculated with the formula var1 = (var1 - (((((var1 >> 15) * (var1 >> 15)) >> 7) * ((int32_t)dig_H1)) >> 4)) is always less (or more) than the initial value depending on what character dig_H1 has....


    But something feels that it won't change much in real life because the humidity measurement is anyway with low accuracy so I think you can slowly start to enjoy a working sensor ;) .
  • #45 17077103
    czasnagli
    Level 17  
    chemik22 wrote:
    Slightly strange that this condition, depending on where in the code it works and doesn't work once.... Intriguing and incomprehensible...
    .
    In your example, the variable var1 is counted in three steps. In the first of these, there is only subtraction.
    Code: C / C++
    Log in, to see the code
    .
    If var1 < 0 then the following condition will be satisfied. Up to this point, the calculations in lua are correct.
    Code: C / C++
    Log in, to see the code
    .
    In the second and third steps the calculation of the value var1 is more complicated. I suspect that in one of these steps the minus sign is "lost" by making the calculated var1 always a positive number. Therefore placing the above condition after the second or third step of the calculation var1 will never allow it to be satisfied.
    Code: C / C++
    Log in, to see the code
    .

    Therefore, I would like to test your function for humidity on this page --> http://codepad.org/ substituting your data into it.
    Code: Lua
    Log in, to see the code
    .
    In addition to the function I would like to add printing the calculated value var1 after each of the three steps. I will compare these values with those calculated by lua and maybe find the error.

    Is it possible to test your function as I described on the above page or another page?
  • #46 17077178
    chemik22
    Level 14  
    czasnagli wrote:
    Is it possible to test your function as I have described on the above page or another page?
    .


    It is hard for me to say because I have never used such sites. Anyway, when calculating as I presented it and used it, there was never a problem with humidity (in the +90 to -15stC range I tested experimentally). In code written in C/C++ the sign has nowhere to get lost because everything is stored as int(s) i.e. with the sign which after and before the bit shift is exactly as it should be, I used to do such games on a piece of paper and programming the MCU and displaying the results and everything was always correct.


    Probably Lua somewhere does something not as the programmer would like, so you may have to recalculate everything in Excel or on a piece of paper for example. Break this whole formula down into the smallest possible steps spitting out a value after each step and look to see if what you see in the terminal is exactly what you have on the piece of paper recalculated correctly.


    ... in other words with debugging the code on foot, a bit of work but then you discover the cause ;) .
  • #47 17082372
    czasnagli
    Level 17  
    chemik22 wrote:
    .... In other words with debugging the code on foot, a bit of work but then you will discover the cause ;)
    .
    This is what I did and found the cause of the error. It turned out that shifting bits in a negative number with the function bit.rshift() is not a good idea. To shift bits in a negative number, use the function bit.arshift() . Below the result of the bit shift to the right for 4 (4 >>1) and -4 (-4 >>1).
    Code: Lua
    Log in, to see the code
    .
    Now the humidity reading works correctly without transferring the condition. Thank you for your help. :D .
  • #48 17083107
    chemik22
    Level 14  
    czasnagli wrote:
    It turned out that shifting bits in a negative number with the bit.rshift() function is not a good idea. To shift bits in a negative number, use the bit.arshift()
    function.


    Ah those secret ciphers and magic commands.... nice that it already works ;)


    Enjoy !
  • #49 17087628
    czasnagli
    Level 17  
    chemik22 wrote:
    Ah those secret ciphers and magic commands.... nice that it works already ;)
    .
    The temperature and humidity reading works OK. With pressure calculation there is a problem because in lua 5.2 64 bit numbers do not fit. For example, when shifted to the left 726576 <<31 I get 0 instead of 1560310079029248 .
  • #50 17794038
    czasnagli
    Level 17  
    Thank you for your help.
| New topic
Report a violation of the law

Topic summary

The discussion addresses how to correctly read and convert temperature data from the BME280 sensor registers 0xFA to 0xFC using Lua scripting. Initial attempts to read raw bytes directly from these registers yielded incorrect temperature values. It was clarified that the BME280 requires proper device addressing (commonly 0x76 or 0x77) and configuration of control registers (0xF4, 0xF5) to set measurement modes before reading sensor data. The temperature raw data (adc_T) is a 20-bit value formed by combining the three registers (MSB, LSB, XLSB) and right-shifting by 4 bits. Calibration parameters dig_T1, dig_T2, and dig_T3 must be read from registers 0x88 to 0x8D as 16-bit values with correct bit-shifting and sign handling. The temperature calculation follows the algorithm detailed on page 23 of the BME280 datasheet, involving intermediate variables var1, var2, and t_fine. Lua's limited bitwise operation support (especially in version 5.2) requires using bit32 or external libraries for shifts and logical operations. For humidity and pressure readings, similar calibration and combination of registers apply, with humidity calibration values (dig_H4, dig_H5) stored in split registers (0xE4 to 0xE6) requiring careful bit masking and shifting. Issues with humidity calculation below 15°C were resolved by using arithmetic right shifts (bit.arshift) for signed values instead of logical right shifts (bit.rshift). Pressure calculation is complicated by 64-bit arithmetic requirements, which Lua 5.2 cannot natively handle, causing overflow problems. The discussion includes code snippets and references to Arduino libraries and GitHub Lua implementations, emphasizing the need to adapt algorithms carefully for the Lua environment and hardware specifics like the Air200 GSM module. The final solution involves correct register addressing, configuration, bitwise data assembly, calibration parameter reading, and application of the datasheet's compensation formulas with attention to Lua's bitwise operation limitations.
Summary generated by the language model.
Popular Topics
ADVERTISEMENT