Incorrect pressure Oregon Scientific BTHGN129 (ID: 5d35)

[ROV28]

Hi,

I'm trying to add the Oregon Scientific BTHGN129 (ID: 5d35) sensor to RTL_433, but I.m not getting the correct value for the pressure, if I use the same method as for the BHTR968 [ ((msg[7] & 0x0f) | (msg[8] & 0xf0))+856 ], I get a pressure of 1071mbar, which is impossible: a) According to the manual the range is 700-1050mbar. Where does die +856 come from? Adding 856 makes it impossible to get a value lower than 856. b) 1050mbar is the all-time high in this country :-), at the moment is should be around 1034mbar.

Ok, adjusting the offset could be and quick 'fix' but then the next question arises, a range of 700-1050mbar with a 1mbar resolution is not possible with 8 bit?!

About the protocol I found:

ID Code(s) | Message Length (nibbles)

---

5D35 | 21

---

Nibbles | Contents | Temp/RH plus Barometer

---

10..8 | Temperature | LSD is 0.1 degC 11 | Temperature Sign | Non-zero for negative values 13..12 | Relative Humidity | Percent 16..14 | Pressure | Binary (not BCD) in units of 0.01 inHg 17..18 | Unknown

---

But I assume this table is incorrect: IMO nibble[14] is the 'Comfort' nibble and nibble[18] is the 'Forecast' nibble. And 'inHg', does not match with the 1mbar resolution?!

This is how far I got, a logging: Nibble[0]: 5 Nibble[1]: 13 =>d Nibble[2]: 5 Nibble[3]: 3 ==> SensorID: 5d35 Nibble[4]: 2 ==> Channel: 2 Nibble[5]: 4 Nibble[6]: 11 ==> Rolling code: 114 Nibble[7]: 0 ==> Flags 1: 0 Nibble[8]: 5 Nibble[9]: 0 Nibble[10]: 2 Nibble[11]: 0 ==> Temperature: +20.5 Nibble[12]: 3 Nibble[13]: 6 ==> Humidity: 63% Nibble[14]: 4 ==> Comfort: 4 Nibble[15]: 7 Nibble[16]: 13 ==> Pressure: 215 Nibble[17]: 0 Nibble[18]: 2 ==> Forecast: 2 Nibble[19]: 5 Nibble[20]: 5

Can someone help me in the right direction? Thanks in advance!

Best regards, Robert

[YepYip]

Hi,

I am also looking at the correct way to read pressure information from BTHGN129. I have an assumption and as you can log information from this sensor, can you try my theory ?

In you example, you got 13 and 7 and you told that you have 215 as a result.

My theory is : The information is binary signed so you don't have 215 but -41. I have readen that this information must be added to 1071 to obtain the pressure. In your example, the result is 1071 - 41 = 1030 hPa.

Can you try to confirm this theory please ?

[ROV28]

Hi,

This is what I do now:

barometer_mbar = ((message[7]& 0x0f) | (message[8] & 0xf0))*2 + ((message[9]>>4) & 0x01) + 602;

The *2 is just a left bit shift. The addition of the 602 is a 'calibration factor', which I obtained by comparing my readings with those of the nearest official weather station. Up to now it looks very good; The deviation is always less than 2 mbar w.r.t. the official station.

I came to this option because the resolution is 1 mbar (according to the manual) and the range is 700 -1050 mbar (according to the same manual); This cannot be done by 2 nibbles => 8bits, you need at least 9 bits to obtain this range with the stated resolution. I found nowhere the function of nibble[17]...

Best regards, Robert

[jamaron]

Hi,

Thanks Robert, good discovery. However, I'm wondering the usage of message[9] bit 4, I haven't seen it changing its state. Instead, I get very accurate results (+- 0.5 mbar when compared to official measurement) with BTHGN129 (id:5D53) using formula

barometer_mbar = ((message[7]& 0x0f) | (message[8] & 0xf0))*2 + (message[8] & 0x01) + 597;

Offset 597 is altitude dependent, so that part may be different for other locations, but otherwise this formula seems to be correct for BTHGN129.

[ROV28]

Hi Jamaron,

I do see the last digit changing (thus message[9] bit 4), but I have to admit, often are the steps by 2 mbar. You do see the change by 1 mbar steps?

BR, Robert

[ROV28]

Example of a reading of Domoticz:

2017-10-04 14:30:00	1019
2017-10-04 14:35:00	1019
2017-10-04 14:40:00	1017
2017-10-04 14:45:00	1017
2017-10-04 14:50:00	1017
2017-10-04 14:55:00	1017
2017-10-04 15:00:00	1017
2017-10-04 15:05:00	1017
2017-10-04 15:10:00	1017
2017-10-04 15:15:00	1017
2017-10-04 15:20:00	1017
2017-10-04 15:25:00	1017
2017-10-04 15:30:00	1017
2017-10-04 15:35:00	1017
2017-10-04 15:40:00	1017
2017-10-04 15:45:00	1017
2017-10-04 15:50:00	1017
2017-10-04 15:55:00	1017
2017-10-04 16:00:00	1017
2017-10-04 16:05:00	1017
2017-10-04 16:10:00	1017
2017-10-04 16:15:00	1017
2017-10-04 16:20:00	1017
2017-10-04 16:25:00	1017
2017-10-04 16:30:00	1017
2017-10-04 16:35:00	1017
2017-10-04 16:40:00	1017
2017-10-04 16:45:00	1017
2017-10-04 16:50:00	1017
2017-10-04 16:55:00	1017
2017-10-04 17:00:00	1017
2017-10-04 17:05:00	1017
2017-10-04 17:10:00	1017
2017-10-04 17:15:00	1017
2017-10-04 17:20:00	1017
2017-10-04 17:25:00	1016
2017-10-04 17:30:00	1016

From 1019 to 1017 but then from 1017 to 1016...

[jamaron]

Yes, I do see linear change by 1 mbar steps, following accurately the official measurement.

[ROV28]

Confirm. This gives indeed a better response, thanks!

PS It makes me curious what bit 4 means...

[jamaron]

Assuming this is correct 'Nibble[18]: 2 ==> Forecast: 2', bit 4 would be part of forecast value. I have seen nibble[18] having values 0, 2 and 3, don't know how to interpret those values.

[ROV28]

The barometer is nibble[15], nibble[16] and the LSB of nibble[17] leaves 3 bits here, where are those for (since (at least the MSB of) the nibble changes)?

Nibble[18] is used for 'forecast', I have in my code:

`code:

    if      (forecast == 2)   { forecast_str = "Rain/Snow";     bar_for = 4; }

    else if (forecast == 3)   { forecast_str = "Cloudy/Rainy";  bar_for = 3; }

    else if (forecast == 6)   { forecast_str = "Partly Cloudy"; bar_for = 2; }

    else if (forecast == 0xc) { forecast_str = "Sunny";         bar_for = 1; }`

'forecast' comes from the BTHGN129, 'bar_for' is the translation for the Domotics sensor. If these are 100% correct, I do not know.

[tmo26]

Should the pressure values be correct in the meantime? Reason for asking: I still see pressure values from the BTHGN129 which are way off.

Examples:

• from 1044.36 → 1066.04 (22mbar) from one measurement to the next (impossible, given the short timeframe between measurements)
• from 1082.5 → 1055.2 (27.3mbar) in 45min (real pressure drop was about 2.5…3mbar in that timeframe)
• from 1079 → 1168 (89mbar) in 60min (see picture; real pressure increase was 1000 → 1030mbar in that timeframe) → smells like factor 3, but doesn't fit to factor 9..10 from the example above

[Graphic from weewx, but wrong pressure values are already present in the rtl_433 data]

In general, the values seem to only take discrete values, not continuous (see graphic above).

Installed software: rtl_433 version 18.05 rtl-sdr version 0.6 weewx 3.8.2

Please let me know if I can help in resolving this issue.

[ROV28]

I think the code is correct, I do not see those jumps in values, it goes by 1mbar steps and very close (within 1~2mbar) to the nearest weather station.

The code I use is:

float get_os_barometer(unsigned char *message, unsigned int sensor_id) { float barometer_mbar = 0; barometer_mbar = ((message[7]& 0x0f) | (message[8] & 0xf0))*2 + (message[8] & 0x01) + 602; return barometer_mbar; }

The +602 is a "calibration" offset, that is the alignment I did one with the nearest weather station.

The values I saw this morning:

2018-09-23 20:40:00	1016
2018-09-23 20:45:00	1017
2018-09-23 20:50:00	1017
2018-09-23 20:55:00	1017
2018-09-23 21:00:00	1017
2018-09-23 21:05:00	1017
2018-09-23 21:10:00	1017
2018-09-23 21:15:00	1018
2018-09-23 21:20:00	1018
2018-09-23 21:25:00	1018
2018-09-23 21:30:00	1018
2018-09-23 21:35:00	1018
2018-09-23 21:40:00	1018
2018-09-23 21:45:00	1018
2018-09-23 21:50:00	1018
2018-09-23 21:55:00	1018
2018-09-23 22:00:00	1019
2018-09-23 22:05:00	1019
2018-09-23 22:10:00	1019
2018-09-23 22:15:00	1019
2018-09-23 22:20:00	1019
2018-09-23 22:25:00	1019
2018-09-23 22:30:00	1019
2018-09-23 22:35:00	1019
2018-09-23 22:40:00	1019
2018-09-23 22:45:00	1020
2018-09-23 22:50:00	1020
2018-09-23 22:55:00	1020
2018-09-23 23:00:00	1020
2018-09-23 23:05:00	1020
2018-09-23 23:10:00	1020
2018-09-23 23:15:00	1020
2018-09-23 23:20:00	1020
2018-09-23 23:25:00	1020
2018-09-23 23:30:00	1021

[ROV28]

Pushed the wrong button...

[zuckschwerdt]

The current code seems to use (different) 12 bits and assumes inHg as unit?

float pressure = ((message[8]<<4)+message[7]) / 100.0 * 33.8639;

See https://github.com/merbanan/rtl_433/blob/master/src/devices/oregon_scientific.c#L79

[ROV28]

That's correct, the values of the BTHGN129 are in mbar (not inHg).

I came to that by calculating the lower and upper limit. Using inHg the range is less than specified in the manual of the BTHGN129... :-)

[tmo26]

@ROV28 With your code I'm getting much better values now: 1029mbar vs. 1035mbar reported from nearby airport. I will monitor the values for 24h and report back.

[ROV28]

Change the +602 in +608... :-)

[merbanan]

Can someone send a PR if the current code is not optimal?

[merbanan]

Someone needs to record signals from this transmitter and at the same time look at the values reported from an official receiver, then we can start figuring out the correct output. But if someone thinks there is a better value in the current code feel free to submit a PR. Closing issue.

[netspoon]

I've recently started using a BTHGN129 for pressure and humidity, and using ROV28's code shows figures which track a physical barometer I have and online pressure figures for my location. Even the calibration of 602 seems spot on for my unit.

However, I think the unit occasionally transmits something else which gets picked up as incorrect figures, and these often show incorrect numbers in both humidity and pressure at the same time. eg: a consistent 1028mbar / 64% suddenly gets a 602mbar and 5% reading. The 602 suggests null data arrived for the pressure

I captured some data files and ran them through again, here's a file with a valid reading and a problem one if it's any help to work out what's going on ?

Test mode active. Reading samples from file: issue-g11022_433.92M_250k.cu8 Input format: CU8 IQ (2ch uint8) AlectoV1 Checksum/Parity error OS v2.1 sync byte search - test_val=55996665 pattern=55990000 mask=ffff0000 OS v2.1 Sync test val 55996665 found, starting decode at byte index 5 bit 0 raw pressure data : c1 0a

---

time : @0.131744s brand : OS model : BTHGN129 House Code: 212 Channel : 1 Battery : OK Celsius : 15.10 C Humidity : 59 % Pressure : 1007.00 hPa pulse_demod_manchester_zerobit(): Oregon Scientific Weather Sensor bitbuffer:: Number of rows: 1 [00] {224} 55 55 55 55 99 66 65 66 5a 6a a6 65 aa 6a 66 6a aa 69 66 aa 99 a5 6a 5a 59 66 9a 69 AlectoV1 Checksum/Parity error OS v2.1 sync byte search - test_val=55996665 pattern=55990000 mask=ffff0000 OS v2.1 Sync test val 55996665 found, starting decode at byte index 5 bit 0 raw pressure data : 00 00

---

time : @0.403084s brand : OS model : BTHGN129 House Code: 212 Channel : 1 Battery : OK Celsius : -15.10 C Humidity : 6 % Pressure : 602.00 hPa pulse_demod_manchester_zerobit(): Oregon Scientific Weather Sensor bitbuffer:: Number of rows: 1 [00] {145} 55 55 55 55 99 66 65 66 5a 6a a6 6d aa 6a 66 6a cd 34 80

[merbanan]

Can you upload the files? There is one obvious difference and that is the length of the buffer 224 bits vs 145 bits. For some reason data is missing in the bitbuffer that is sent to the decoder.

[merbanan]

And the cause of this can be seen there on line 433(!) here: https://github.com/merbanan/rtl_433/blob/master/src/devices/oregon_scientific.c#L433

The message is not validated. All other messages are, can you uncomment that code and see if you get any signals at all?

[jamaron]

Validation should be like this: if ((validate_os_v2_message(msg, 185, num_valid_v2_bits, 19) == 0))

[netspoon]

Here's 3 files

Archive.zip

[merbanan]

@jamaron can you send a PR?

[jamaron]

Sorry, not right now.

[merbanan]

@netspoon ok, the transmitter goes haywire in these samples. And because the validation check is not present you get erranous output.

[merbanan]

@netspoon Ok, I tested @jamaron patch and it removed the corrupted messages.

[netspoon]

file issue-g9077_433.92M_250k.cu8 looks like a double payload... I wondered if the unit sent additional data on occasion... but if it's just 'broken' data then putting back the validation would do it.. thanks.

[merbanan]

@jamaron thanks for the fix. Send a PR later so you get the credit.

[merbanan]

This looks like it has been fixed. Closing issue.