Improve Holman ws5029, Add support for AOK-5056 and correction for Emax #2419

ProfBoc75 · 2023-03-12T15:53:53Z

Hi,

I propose an improvement from the current Holman ws5029 decoding to take into account the xor checksum, partially with the lower nibble but better than nothing.
And also add the support for AOK-5056, same family product with UV & Lux sensor.

My samples

BitBench

zuckschwerdt · 2023-03-12T18:37:32Z

Thanks!
Can you run maintainer_update.py so README.md and rtl_433.1 also change?

zuckschwerdt · 2023-03-12T18:41:25Z

I really like your "bits details" drawing!

ProfBoc75 · 2023-03-15T10:00:39Z

Need a little correction for the wind speed. I have errors into Domoticz because of bad value to 128.9 kmh instead of 1 kmh,
Because the current speed is int , must be float value, I checked other weather stations, they are all using float values.

zuckschwerdt · 2023-03-15T10:09:56Z

the current speed is int , must be float value,

How does Domoticz read the value? From MQTT, JSON, or CSV? For JSON and MQTT at least the type int is the same as float.

ProfBoc75 · 2023-03-15T10:27:05Z

Domoticz from json , I saw a conversion km/h to m/s by dividing the value by 3.6f, (from domoticz/hardware/Rtl433.cpp , line 236).

wind_speed = ((float)atof(data["wind_avg_km_h"].c_str())) / 3.6F;

And I'm facing to this error lot of times, like 1 is 129 , I need to correct manually the value into Domoticz db.

In parallel, I monitor the weather station value from another rtl-sdr dongle, without error from rtl_433, but error into Domoticz. So for me, I deduct that the behavior is from Domoticz , some round value not done properly, may be because of int value.

zuckschwerdt · 2023-03-15T10:32:07Z

But atof("1") is the same as atof("1.0") and why would it be 129? Something else is wrong.
(because in a string any int is just a float with not decimals.)

ProfBoc75 · 2023-03-15T10:51:33Z

But atof("1") is the same as atof("1.0") and why would it be 129? Something else is wrong. (because in a string any int is just a float with not decimals.)

Agree, I'll try another test, to get the value from the current dongle I'm using into Domoticz, to check if it could come from it.
I was expecting some improvement now that the xor checksum is checked, but still partially check, since 1 and 129 the gap is at the upper nibble, and only the lower nibble from the xor is checked, this could be the reason.

Edit: before my test, I found 2 new wrong values, 127.1 kmh and 254.9 kmh, with respectively , 353 and 708 raw value into the Wind device in Domoticz DB. (speed = 10 * m/s )
127 / 3.6f = 35.2777... * 10 = 353 , then 353/10 = 35.3 * 3.6 = 127.08 , round to 127.1 kmh
255 / 3.6f = 70.8333.. * 10 = 708, then 708/10 = 70.8 * 3.6 = 254.88, round to 254.9 kmh.

127 and 255, impacting also the low nibble and were properly check, strange.
I started to monitor the value, it will take time since I don't always have the error, today 3 errors, so could be the xor checksum failure. to be continued ...

ProfBoc75 · 2023-03-16T16:03:29Z

Well, more than 24 hours later, still no error, I'm monitoring the json output. I will continue to monitor.

I have code data that can be used to found the good algorithm for the checksum / crc.

Into the code data, the 13th byte sounds to be the xor sum from the 12th first bytes, for sure for the lower nibble and I added it into the device improvement, but not the upper nibble, and I don't know how to find it ?
Is there a way to find the xor calcul (or checksum ?) for the upper nibble ? I need some help on this.

merbanan · 2023-03-16T16:10:53Z

Maybe revdgst can help.

zuckschwerdt · 2023-03-16T16:14:35Z

We have seen these checksums where the overflow of the lower half is folded into the upperhalf. It seems to be a kind if Fletcher checksum. We have not yet found a way to analyze those.

Yes, revdgst: if you have enough messages with only very slight changes then bitbrk can show which bit goes where in the checksum.

ProfBoc75 · 2023-03-20T11:34:53Z

Hi, thanks for help, but unfortunately no one give me a good result except it confirmed the XOR by shift up = 0x18 = 24 means the exact number of nibbles. But still no luck with the upper nibble.

In another hand, I monitored the messages for more than one full day, and no error, then it's running with Domoticz, same without errors, this means that the decoder is not so bad, acceptable for me.

So from my side, it's ok to merge it.

ProfBoc75 · 2023-03-21T09:59:47Z

Hi,

I have enough messages to work on this xor checksum and I found that the Upper Nibble is an xor between the upper xor and lower xor of the message with a kind of shift at the lower nibble (lfsr ?) .

I was able to extract all the 256 possibilities, see the table, still working on the good algorithm to make the map. For sure the result will be something related to lfsr.

xor_bytes of the 12 bytes message --> upper_result XOR ( LFSR xxx ??? of lower_result )

Here the table between the calculated XOR from the message (12 bytes) and the value of the 13th Byte checksum:

XOR Message	13th Byte
00	00
01	31
02	62
03	53
04	c4
05	f5
06	a6
07	97
08	88
09	b9
0A	ea
0B	db
0C	4c
0D	7d
0E	2e
0F	1f
10	10
11	21
12	72
13	43
14	d4
15	e5
16	b6
17	87
18	98
19	a9
1A	fa
1B	cb
1C	5c
1D	6d
1E	3e
1F	0f
20	20
21	11
22	42
23	73
24	e4
25	d5
26	86
27	b7
28	a8
29	99
2A	ca
2B	fb
2C	6c
2D	5d
2E	0e
2F	3f
30	30
31	01
32	52
33	63
34	f4
35	c5
36	96
37	a7
38	b8
39	89
3A	b0
3B	eb
3C	7c
3D	4d
3E	1e
3F	2f
40	40
41	71
42	22
43	13
44	84
45	b5
46	e6
47	d7
48	c8
49	f9
4A	aa
4B	9b
4C	0c
4D	3d
4E	6e
4F	5f
50	50
51	61
52	32
53	03
54	94
55	a5
56	f6
57	c7
58	d8
59	e9
5A	ba
5B	8b
5C	1c
5D	2d
5E	7e
5F	4f
60	60
61	51
62	02
63	33
64	a4
65	95
66	c6
67	f7
68	e8
69	d9
6A	8a
6B	bb
6C	2c
6D	1d
6E	4e
6F	7f
70	70
71	41
72	12
73	23
74	b4
75	85
76	a2
77	e7
78	f8
79	c9
7A	9a
7B	ab
7C	3c
7D	0d
7E	5e
7F	6f
80	80
81	b1
82	e2
83	d3
84	44
85	75
86	26
87	17
88	08
89	39
8A	6a
8B	5b
8C	cc
8D	fd
8E	ae
8F	9f
90	90
91	a1
92	f2
93	c3
94	54
95	65
96	36
97	07
98	18
99	29
9A	7a
9B	4b
9C	dc
9D	ed
9E	be
9F	8f
A0	a0
A1	91
A2	92
A3	f3
A4	64
A5	55
A6	06
A7	37
A8	28
A9	19
AA	4a
AB	7b
AC	ec
AD	dd
AE	8e
AF	bf
B0	b0
B1	81
B2	d2
B3	e3
B4	74
B5	45
B6	16
B7	27
B8	38
B9	09
BA	5a
BB	6b
BC	fc
BD	cd
BE	9e
BF	af
C0	c0
C1	f1
C2	a2
C3	93
C4	04
C5	35
C6	66
C7	57
C8	48
C9	79
CA	2a
CB	1b
CC	8c
CD	bd
CE	ee
CF	df
D0	d0
D1	e1
D2	b2
D3	83
D4	14
D5	25
D6	76
D7	47
D8	58
D9	69
DA	3a
DB	0b
DC	9c
DD	ad
DE	fe
DF	cf
E0	e0
E1	d1
E2	82
E3	b3
E4	24
E5	15
E6	46
E7	77
E8	68
E9	59
EA	0a
EB	3b
EC	ac
ED	9d
EE	ce
EF	ff
F0	f0
F1	c1
F2	92
F3	a3
F4	34
F5	05
F6	56
F7	67
F8	78
F9	49
FA	1a
FB	2b
FC	bc
FD	8d
FE	de
FF	ef

zuckschwerdt · 2023-03-21T10:49:14Z

Great success! This can be solved with a reverse Galois algorithm then (key = 0x31).
But there are 3 errors(?) in your table:

3a b0 should be 3a da
76 a2 should be 76 d6
a2 92 should be a2 c2

Can you double check that?
Do you have a file with all full message codes (before XOR)?

zuckschwerdt · 2023-03-21T10:58:44Z

Oh and it looks like a broken try at LFSR -- the "F" is missing ;)
For an LFSR this would be characteristic:

01 -> 31
02 -> 62
04 -> c4
08 -> 89
10 -> 13
20 -> 26
40 -> 4c
80 -> 98

not this:

01 -> 31
02 -> 62
04 -> c4
08 -> 88
10 -> 10
20 -> 20
40 -> 40
80 -> 80

ProfBoc75 · 2023-03-21T13:32:27Z

Good to find the algorithm ! Thanks a lot.
Sorry, yes, Excel removed duplicates and kept wrong values for these 3 XOR results.
And we can see that the length of the data is not good and then the message must be rejected ! ... ;)

Data	XOR	13th
c7670c61a91201109c9bc49eda0c000000000	3A	da
c7670c61a91201109c9bc49eda0c000000000	3A	da
c7670a327a240240ad0c2d32b02000000000	3A	b0 --> the wrong one
c7670a7289120100149a45b3da08000000000	3A	da
c7670a7289120100149a45b3da08000000000	3A	da

Data	XOR	13th
c7670cc2d22407026eb68fbca208000000000	76	a2 --> the wrong one
c7670cc169120280159187e1d604000000000	76	d6
c7670cc169120280159187e1d604000000000	76	d6
c7670cc169120280159187e1d604000000000	76	d6

Data	XOR	13th
c7670991f912029004cc002bc208000000000	A2	c2
c7670991f912029004cc002bc208000000000	A2	c2
c767087249120130004700559202000000000	A2	92 --> the wrong one
c76706f2a912000000184114c200000000000	A2	c2
c76706f2a912000000184114c200000000000	A2	c2
c76706f2a912000000184114c200000000000	A2	c2

ProfBoc75 · 2023-03-21T17:50:31Z

I'm updating the code to add the good checksum control and commit it very soon.

    uint8_t chk_calc = xor_bytes(b, 12);
    int chk_expected = lfsr_digest8_reflect(&chk_calc, 1, 0x00, 0x31);
    if (...

merbanan · 2023-03-21T19:05:10Z

@zuckschwerdt what is missing from revdgst to figure out this?

Besides that LGTM. This change will most likely be valid for the PWM model also.

merbanan · 2023-03-21T19:10:17Z

@ProfBoc75 this PR #947 seems to have all the details/data to complete the pwm version of the protocol. Can you look into that also?

ProfBoc75 · 2023-03-21T19:29:10Z

@ProfBoc75 this PR #947 seems to have all the details/data to complete the pwm version of the protocol. Can you look into that also?

Yes, sure, I will check that asap.

zuckschwerdt · 2023-03-21T20:04:18Z

@zuckschwerdt what is missing from revdgst to figure out this?

It's a broken L(F)SR. Not cyclic and thus exhausted after 8 bits. Or maybe just degenerate as the generator here would be 0x00 (only the key is doing the work). We could restart the the L(F)SR check each byte as a special case for gen=0x00. Or like suggested here we could xor all bytes first, then run (any) LFSR -- that could be a more general case perhaps?

And @ProfBoc75 is the first to figure this sad example of algorithm out. Very nice. I guess more codes could be using this?

merbanan · 2023-03-21T22:52:46Z

Or like suggested here we could xor all bytes first, then run (any) LFSR -- that could be a more general case perhaps?

Basically this is xor on all but the last message byte that instead uses a non linear mapping for the last byte. The question is if that has a good rf property regarding message validation.

I cant really see any other reason then to make the message unique. By doing this last step we can have a lot of protocols that have the exact same rf parameters but uses different values for the sbox. The hardware implementation would be simple. 12 xor and then one 256 bytes lookup table.

So I would not say it is a broken implementation but rater the tiniest step-up from xor. The sbox design is the tricky part so you need to generate it.

Anyway I think this is a worthy addition to revdgst. I do remember we had some other decoder where we also only where able to verify 4 bits of data.

ProfBoc75 · 2023-03-21T23:45:07Z

I found PWM Samples here Holman-WH5029-samples.zip from the subject PR #947 , sounds good to start from here, since the other files are truncated , missing end of the message which contains the checksum or whatever we can call it 😄 ... to be continued ...

zuckschwerdt · 2023-03-22T08:33:51Z

@merbanan I don't think it's a deliberate design. It clears the lower bits because the key is 0x31 (just the identity bit in the lower nibble) and that we don't rotate but shift the bits off. There is no LUT, it's just a mask that shifts.
Doing it this way has no useful properties (except obfuscation maybe). A digest (LFSR) would be robust, a CRC (0x31 is common choice there) would be, but 1 round of linear S-Box looks like a fail ;)
Anyway, yes, I'll add that to revdgst and run it on the some mystery checksums.

ProfBoc75 · 2023-03-22T11:16:47Z

Hi,

For the PWM, it's not the same algorithm, same approach, XOR of the bytes but the last, but not the same result as for the PCM.
Several XOR values are common to several expected results and the reverse too, so not possible to exactly map or reverse the control from the expected to XOR value with this method.
And it's not related to RF , the samples are good and the message is repeated 6 times the same into the frame.

data	XOR	11th Byte
aaa5984c00e42401704a80	20	80
aaa5984c00ea2601704deb	2B	eb
aaa5984c00ec2501704fbc	2C	bc
aaa5984c00ec2601704ded	2D	ed
aaa5984c00f5240170479c	3C	9c
aaa5984c00ef2401705c9d	3D	9d
aaa5984c00ea2301702271	41	71
aaa5984c00ed2401702dee	4E	ee --> Duplicate 11th Byte EE, issue here, XOR 4E or 7E
aaa5984c00e72501703cc4	54	c4
aaa5984c00e42601703d95	55	95
aaa5984c00f12301702f67	57	67 --> Duplicate XOR 57, issue here, 11th byte 67 or C7
aaa5984c00e32501703bc7	57	c7 --> Duplicate XOR 57, issue here, 11th byte 67 or C7
aaa5984c00ed2401703bf8	58	f8
aaa5984c00ed24017039fa	5A	fa
aaa5984c00ee2601703d9f	5F	9f
aaa5984c00ef24017001c0	60	c0
aaa5984c00df2301703d5b	6B	5b
aaa5984c00e72401701fd6	76	d6
aaa5984c00e82401701ed8	78	d8
aaa5984c00ed2401701dde	7E	de --> Duplicate XOR 73, issue here, 11th byte DE or EE
aaa5984c00ed2501701cee	7E	ee --> The worse case, duplicate for XOR and for 11th Byte ...

FYI : rtl_433 -r g*.cu8 -X "n=TEST,m=FSK_PWM,s=488,l=976,g=2000,r=6000,invert" to get the above values, I removed the last byte, not relevant, (always 00 or 80).

zuckschwerdt · 2023-03-22T11:31:02Z

I have an old test algorithm that I don't quite follow anymore, but it seems this is the same pattern but a key of 0x18?

ProfBoc75 · 2023-03-22T11:42:25Z

I have an old test algorithm that I don't quite follow anymore, but it seems this is the same pattern but a key of 0x18?

0x18 doesn't match, galois = lfsr_digest8_reflect(&xor, 1, 0x00, 0x18)

holman_ws5029pwm_decode: 11th byte 5b xor 6b galois e8
holman_ws5029pwm_decode: 11th byte 71 xor 41 galois 18
holman_ws5029pwm_decode: 11th byte 67 xor 57 galois c8
holman_ws5029pwm_decode: 11th byte c0 xor 60 galois 00
holman_ws5029pwm_decode: 11th byte d8 xor 78 galois 40
holman_ws5029pwm_decode: 11th byte 9d xor 3d galois 38
holman_ws5029pwm_decode: 11th byte 80 xor 20 galois 00
holman_ws5029pwm_decode: 11th byte ee xor 4e galois 90
holman_ws5029pwm_decode: 11th byte 9c xor 3c galois 20
holman_ws5029pwm_decode: 11th byte fa xor 5a galois 70
holman_ws5029pwm_decode: 11th byte d6 xor 76 galois d0
holman_ws5029pwm_decode: 11th byte de xor 7e galois 10
holman_ws5029pwm_decode: 11th byte f8 xor 58 galois 40
holman_ws5029pwm_decode: 11th byte c4 xor 54 galois e0
holman_ws5029pwm_decode: 11th byte c7 xor 57 galois c8
holman_ws5029pwm_decode: 11th byte c4 xor 54 galois e0
holman_ws5029pwm_decode: 11th byte bc xor 2c galois a0
holman_ws5029pwm_decode: 11th byte ee xor 7e galois 10
holman_ws5029pwm_decode: 11th byte ed xor 2d galois b8
holman_ws5029pwm_decode: 11th byte 9f xor 5f galois 08
holman_ws5029pwm_decode: 11th byte 95 xor 55 galois f8
holman_ws5029pwm_decode: 11th byte eb xor 2b galois e8

zuckschwerdt · 2023-03-22T12:06:08Z

Actually something more like this:

Add all odd rows (indexes 0, 2, ...) to result0, add all even rows (indexes 1, 3, ...) to result1.
Add result0, result1, result0 << 4, result0 << 5.
I.e. the shifting doesn't need to be in the loop. It effectivly just folds half the (final) lower bits up.

uint8_t xor_shift_bytes(uint8_t const message[], unsigned num_bytes, uint8_t shift_up)
{
    uint8_t result0 = 0;
    for (unsigned i = 0; i < num_bytes; i += 2) {
        result0 ^= message[i];
    }
    uint8_t result1 = 0;
    for (unsigned i = 1; i < num_bytes; i += 2) {
        result1 ^= message[i];
    }
    uint8_t resultx = 0;
    for (unsigned j = 0; j < 7; ++j) {
        if (shift_up & (1 << j))
            resultx ^= result0 << (j + 1);
    }
    return result0 ^ result1 ^ resultx;
}

ProfBoc75 · 2023-03-22T13:59:21Z

Actually something more like this:

Add all odd rows (indexes 0, 2, ...) to result0, add all even rows (indexes 1, 3, ...) to result1. Add result0, result1, result0 << 4, result0 << 5. I.e. the shifting doesn't need to be in the loop. It effectivly just folds half the (final) lower bits up.
uint8_t xor_shift_bytes(uint8_t const message[], unsigned num_bytes, uint8_t shift_up)
{
    uint8_t result0 = 0;
    for (unsigned i = 0; i < num_bytes; i += 2) {
        result0 ^= message[i];
    }
    uint8_t result1 = 0;
    for (unsigned i = 1; i < num_bytes; i += 2) {
        result1 ^= message[i];
    }
    uint8_t resultx = 0;
    for (unsigned j = 0; j < 7; ++j) {
        if (shift_up & (1 << j))
            resultx ^= result0 << (j + 1);
    }
    return result0 ^ result1 ^ resultx;
}

Good job ! this one is working for PWM.
I also tried for PCM with 0x31, but not the good result, does xor_shift_bytes() universal (to put into util.c ?) or only for this PWM use case ?

I will update the PWM part accordingly, and enrich also the comments that are very weak for PWM information (no bitbench, no byte position detail ... ) . Then all will be properly check, not only the lower nibble !

chk_calc = xor_shift_bytes(b, 10, 0x18);

holman_ws5029pwm_decode: 11th byte 5b chk_calc 5b
holman_ws5029pwm_decode: 11th byte 71 chk_calc 71
holman_ws5029pwm_decode: 11th byte 67 chk_calc 67
holman_ws5029pwm_decode: 11th byte c0 chk_calc c0
holman_ws5029pwm_decode: 11th byte d8 chk_calc d8
holman_ws5029pwm_decode: 11th byte 9d chk_calc 9d
holman_ws5029pwm_decode: 11th byte 80 chk_calc 80
holman_ws5029pwm_decode: 11th byte ee chk_calc ee
holman_ws5029pwm_decode: 11th byte 9c chk_calc 9c
holman_ws5029pwm_decode: 11th byte fa chk_calc fa
holman_ws5029pwm_decode: 11th byte d6 chk_calc d6
holman_ws5029pwm_decode: 11th byte de chk_calc de
holman_ws5029pwm_decode: 11th byte f8 chk_calc f8
holman_ws5029pwm_decode: 11th byte c4 chk_calc c4
holman_ws5029pwm_decode: 11th byte c7 chk_calc c7
holman_ws5029pwm_decode: 11th byte c4 chk_calc c4
holman_ws5029pwm_decode: 11th byte bc chk_calc bc
holman_ws5029pwm_decode: 11th byte ee chk_calc ee
holman_ws5029pwm_decode: 11th byte ed chk_calc ed
holman_ws5029pwm_decode: 11th byte 9f chk_calc 9f
holman_ws5029pwm_decode: 11th byte 95 chk_calc 95
holman_ws5029pwm_decode: 11th byte eb chk_calc eb

zuckschwerdt · 2023-03-22T15:55:27Z

I also tried for PCM with 0x31, but not the good result, does xor_shift_bytes() universal (to put into util.c ?) or only for this PWM use case ?

It's special for now. I'm not sure how they calculate something like this. It easy but very strange:
You xor all bytes. Then all odd bytes (0, 2, ...) are xored again but shifted by 4 and also by 5.
This sounds so random! It could be that they "fold" not bytes but 16-bit words, with a key of 0x1800 then.

ProfBoc75 · 2023-03-22T16:44:04Z

I propose to call this "mic" "Integrity" method "XORSHIFT" , instead of CHECKSUM or any other suggestion before my commit ?

zuckschwerdt · 2023-03-22T17:02:03Z

We only want to indicate the approximate strength. The strength of Sum/Xor and such is "CHECKSUM". We only care if the check is significantly better (Digest/CRC) then it's "CRC".

zuckschwerdt · 2023-03-22T18:31:24Z

src/devices/holman_ws5029.c

@@ -86,6 +87,25 @@ To get raw data

 #include "decoder.h"

+// see #2419 for more details about the xor_shift_bytes , used by PWM device


Line 14 now needs to be
/** int holman_ws5029pcm_decode(r_device *decoder, bitbuffer_t *bitbuffer)
otherwise the doc-comment above attaches to this helper function

Done, but I moved the xor_shift_bytes function to the bottom and enrich both doc-comments for PCM and PWM.
Let me know.

Very good, thanks. One thing: %.01f is not a sensible format ;) It is often in our code but it should be %.1f.

it was a copy paste of %.01f from the initial author, I just commit these "minor" corrections.

ProfBoc75 · 2023-04-13T09:38:42Z

Hi ,

Please notice a little correction to the Emax device, I was facing an error with the byte conversion (for wind and rain) , 0x01 is the 0 default value. So we need to remove 1 for each byte to get the good value, but the 0x00 was not properly calculate, expected 255 and it was 65536 because of "int" is 2 bytes data. So I added the 0xff mask to get 1 byte data and the expected 255.
The same approach was already done for the Lux value, that is already properly decoded.

No error since the improvement to AOK with the full checksum. So both Aok and Emax are ready to be merged.

Thanks.

zuckschwerdt · 2023-04-13T12:30:56Z

src/devices/emax.c

@@ -250,7 +250,7 @@ static int emax_decode(r_device *decoder, bitbuffer_t *bitbuffer)
    return ret;
 }

-static char const *output_fields[] = {
+static char const *const output_fields[] = {


This is already checked in. Can you rebase?

zuckschwerdt · 2023-04-13T12:31:58Z

src/devices/holman_ws5029.c

-Decoder for Holman Industries WS5029 weather station,
-a.k.a. Holman iWeather Station.
-https://www.holmanindustries.com.au/products/iweather-station/
+/** int holman_ws5029pcm_decode(r_device *decoder, bitbuffer_t *bitbuffer)


This should be just /** no function link.

zuckschwerdt · 2023-04-13T12:32:12Z

src/devices/holman_ws5029.c


    if (bitbuffer->num_rows != 1) {
+        if (decoder->verbose) {
+            fprintf(stderr, "%s: wrong number of rows (%d)\n", __func__, bitbuffer->num_rows);


Always use log functions

zuckschwerdt · 2023-04-13T12:33:05Z

src/devices/holman_ws5029.c

@@ -141,29 +211,61 @@ r_device const holman_ws5029pcm = {
        .fields      = output_fields,
 };

-/**
+/** int holman_ws5029pwm_decode(r_device *decoder, bitbuffer_t *bitbuffer)


A function link is /** @fn int holman…

Hi,

Should be better, I made few updates and did some git stuff. Let me know if it's ok for you.

Thx.

Yes, looks very good. One more thing: log texts must not have \n, change decoder_logf in line 100.

…ax (merbanan#2419)

ProfBoc75 added 3 commits March 12, 2023 12:48

Improve Holman ws5029 and Add support for AOK-5056

c71d0d1

Improve Holman ws5029 and Add support for AOK-5056

e75765c

Improve Holman ws5029 and Add support for AOK-5056

fdd879b

ProfBoc75 added 2 commits March 12, 2023 22:42

Improve Holman ws5029 and Add support for AOK-5056

5b64354

correct ref Optex 990018

9122409

ProfBoc75 added 2 commits March 15, 2023 11:01

change wind speed from int to float

145b805

change wind speed from int to float

9df18d9

add full checksum control with reverse Galois algo

a5473f8

add full checksum check with xor_shift_bytes for WS5029 PWM device

2898754

zuckschwerdt reviewed Mar 22, 2023

View reviewed changes

ProfBoc75 added 2 commits March 22, 2023 20:57

add full checksum check with xor_shift_bytes for WS5029 PWM device

eb1a43d

minor corrections

183f2fe

zuckschwerdt force-pushed the master branch from 976371b to fe3df68 Compare March 30, 2023 09:19

bytes convertion correction for 0x00 = ff

4062dbb

ProfBoc75 changed the title ~~Improve Holman ws5029 and Add support for AOK-5056~~ Improve Holman ws5029, Add support for AOK-5056 and correction for Emax Apr 13, 2023

zuckschwerdt reviewed Apr 13, 2023

View reviewed changes

ProfBoc75 and others added 4 commits April 14, 2023 17:18

Merge branch 'merbanan:master' into master

c7aedb9

comment fn and log corrections

dae10e1

Merge branch 'master' of https://github.com/ProfBoc75/rtl_433

64b0640

remove new line from log msg

f64bfbc

zuckschwerdt merged commit d44ef12 into merbanan:master Apr 14, 2023

andrewjw pushed a commit to andrewjw/rtl_433 that referenced this pull request Sep 29, 2023

Improve Holman ws5029, Add support for AOK-5056 and correction for Em…

9b06977

…ax (merbanan#2419)

		@@ -86,6 +87,25 @@ To get raw data

		#include "decoder.h"

		// see #2419 for more details about the xor_shift_bytes , used by PWM device

Improve Holman ws5029, Add support for AOK-5056 and correction for Emax #2419

Improve Holman ws5029, Add support for AOK-5056 and correction for Emax #2419

Conversation

ProfBoc75 commented Mar 12, 2023

zuckschwerdt commented Mar 12, 2023

zuckschwerdt commented Mar 12, 2023

ProfBoc75 commented Mar 15, 2023

zuckschwerdt commented Mar 15, 2023

ProfBoc75 commented Mar 15, 2023

zuckschwerdt commented Mar 15, 2023

ProfBoc75 commented Mar 15, 2023 • edited Loading

ProfBoc75 commented Mar 16, 2023

merbanan commented Mar 16, 2023

zuckschwerdt commented Mar 16, 2023

ProfBoc75 commented Mar 20, 2023

ProfBoc75 commented Mar 21, 2023

zuckschwerdt commented Mar 21, 2023

zuckschwerdt commented Mar 21, 2023

ProfBoc75 commented Mar 21, 2023

ProfBoc75 commented Mar 21, 2023

merbanan commented Mar 21, 2023

merbanan commented Mar 21, 2023

ProfBoc75 commented Mar 21, 2023

zuckschwerdt commented Mar 21, 2023

merbanan commented Mar 21, 2023

ProfBoc75 commented Mar 21, 2023

zuckschwerdt commented Mar 22, 2023

ProfBoc75 commented Mar 22, 2023 • edited Loading

zuckschwerdt commented Mar 22, 2023

ProfBoc75 commented Mar 22, 2023

zuckschwerdt commented Mar 22, 2023

ProfBoc75 commented Mar 22, 2023 • edited Loading

zuckschwerdt commented Mar 22, 2023

ProfBoc75 commented Mar 22, 2023

zuckschwerdt commented Mar 22, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ProfBoc75 Mar 22, 2023 • edited Loading

Choose a reason for hiding this comment

ProfBoc75 commented Apr 13, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ProfBoc75 commented Mar 15, 2023 •

edited

Loading

ProfBoc75 commented Mar 22, 2023 •

edited

Loading

ProfBoc75 commented Mar 22, 2023 •

edited

Loading

ProfBoc75 Mar 22, 2023 •

edited

Loading

ProfBoc75 commented Apr 13, 2023 •

edited

Loading