Bresser Lightning Sensor. #2140
Comments
|
It does not look like the Acurite lightning detector we have and does no exactly match the FineOffset-W57. Get raw codes with The lenght is 8 to 10 bytes, not sure with the trailer in that codes above. Record a few different codes and post here. |
|
Btw. the code above is |
|
no data with -X 'n=Bresser-Lightning,m=FSK_PCM,s=484,l=484,r=5000,preamble=aa2dd4' but following without preamble=aa2dd4 time : 2022-08-09 17:12:44 time : 2022-08-09 17:13:43 time : 2022-08-09 17:14:41 |
|
Can you upload |
|
here is, |
|
I see. It was a confusion about the sample rate. Use this: |
|
here is the output time : 2022-08-09 17:34:11 time : 2022-08-09 17:35:10 time : 2022-08-09 17:36:08 time : 2022-08-09 17:37:07 |
|
This is only always the same code |
|
its also 5c5d0d9ca82a98abaaa8, but i will collect more codes and paste them here. thank you a lot ! |
|
Hello, i collect some more codes last night, not sure whether these help for further checks or not. 5c5d0d9ca82a98abaaaa0000000 time : 2022-08-09 18:19:02 time : 2022-08-09 18:44:23 time : 2022-08-10 03:00:38 time : 2022-08-10 03:09:25 time : 2022-08-10 03:32:49 time : 2022-08-10 03:33:47 time : 2022-08-10 03:43:32 regards, |
|
i follow your advice and use power drill which trigger a lighting sensor here is the results. time : 2022-08-10 16:52:45 time : 2022-08-10 16:53:03 time : 2022-08-10 16:53:12 time : 2022-08-10 16:53:15 time : 2022-08-10 16:54:13 time : 2022-08-10 16:55:18 time : 2022-08-10 16:56:41 time : 2022-08-10 16:57:25 time : 2022-08-10 16:59:22 time : 2022-08-10 16:59:32 |
|
Very good. Here is a BitBench with that data. Maybe @rct can spot which fields encode things like distance and count. |
|
This appears to follow the protocol of Bresser 7-in-1 messages (both OEM'd by CCL Electronics). It looks like a 16 bit digest followed by a 16 bit ID followed by a 12? bit BCD count and then the rest. |
|
@anthyz oh, of course! very good find! After undoing the whitening (0xaa) it's LFSR-16 gen 8810 key abf9 final xor 899e |
|
From reading the manual apparently the sensor does some basic loud noise detection, too. No indication it's reported in a message, though. Might be good to experiment with that as well as triggering messages with different sensitivity levels selected. |
|
here is some messages with different sensitivity levels selected. Sensitivity LOW + triggering the sensor. time : 2022-08-11 17:20:39 time : 2022-08-11 17:21:15 time : 2022-08-11 17:22:13 Sensitivity - Medium + triggering the sensor time : 2022-08-11 17:24:43 time : 2022-08-11 17:24:45 time : 2022-08-11 17:25:20 time : 2022-08-11 17:25:30 |
|
I've update the BitBench link above. At least an event counter is visible. |
|
The sensitivity setting is not in the message, and it looks like there's occasionally a bad bit flip at the end (see the two examples with digest 0x3b72). For distance, byte[7] could be a candidate. I wonder if experimenting with the sensitivity set to high would get more varied results. |
|
Good morning, messages i've posted in the begging were with sensitivity level - High,
|
|
@zuckschwerdt, what might be the decoder for distance and eventually for distance as per suggestion above for byte [7]. im in area where the forecast for the next days is heavy thunderstorms, which could be good opportunity for testing. thank you in advance, |
|
Sorry, I don't have any experience with lightning sensors. Log all data if you can and maybe note down some prominent events (with the "every 3 seconds between lightning and thunder equals a kilometer" estimate). |
|
Just a wild guess, but IF the sensor uses an "AS3935 Franklin Lightning Sensor IC" by AMS, the datasheet (e.g. https://www.digikey.de/htmldatasheets/production/1124289/0/0/1/as3935.html) might provide some insights about the kind of data and encoding to be expected. |
here is the picture of the board, there is RFID transponder coil ma5532-ae, google says Developed to work with austriamicrosystems AS3935 Franklin Lightning Sensor IC (e.g. https://www.coilcraft.com/en-us/products/rf/rfid-transponders/x-y-axis-transponder-coil-2mhz/ma5532/) |
|
I would like to bet on what kind of IC U3 is... |
|
And there is a serial interface (RX, TX), too! Maybe it has something to tell you, too! |
|
Excellent finds! According to Table 17 in section 8.9.3 of the AS3935 datasheet there are 16 possible distance values. The byte[7] values seen so far in the bitbench data (01, 05, and 08) are consistent with this table. |
|
more data from the heavy thunderstorms we just had + video :) 1660585221297348.MP4 |
|
Removing dups and broken codes this BitBench shows 4 events, the first at 21 km, then 3 overhead ;) |
Nice test setup! :-) |
|
Probably there isn't anything else in it. From the "4Cast PRO WIFI Weather Center with 7in1 Outdoor Sensor" (PN 7003210/7803210/7903210) manual, section 4.3.13.2 LIGHTNING DETECT MODE (OPTIONAL SENSOR): The energy provided by the AS3935 might be contained in the radio message. From the IC datasheet: Well, if it has no physical meaning and is just a relative value (due to noise adjustment etc.), then it wouldn't be too useful anyway. |
|
The last 16 bit (mostly |
|
Any chance to identify the battery status bit by connecting an adjustable power supply? |
|
The next most interesting things could be the sensitivity switch position and the noise level, which might be available in the message. |
|
Just for completeness: |
|
Sorry didn't see the mention from a number of days ago. I've got experience with the two Acurite devices that have the AS3935 in them. There is also an RPI board that has an AS3935 that I haven't tried. At least on the two Acurite devices, the strike count is non-volatile. On the 6045M sensor it is a 7 bit counter (...so wraps back to 0 after 127.) The module embedded in the Atlas uses a 9 bit counter. On the Acurite devices, and IIRC the AS3935 too, the distance to the edge of the storm estimation resets to the maximum value when the power is cycled. So you might want to try removing/reinserting the batteries after you've recorded some strikes to see what changes and hopefully you'll find the distance estimation field. The 16 possible distance values for the AS3935 are: 1, 5, 6, 8, 10, 12, 14, 17, 20, 24, 27, 31, 34, 37, 40, 63 63 indicates that no distance estimate has been done/no lightning has been detected since power up. 40KM is the stated maximum detection range, so the highest valid distance estimate you should see is 40. 1 indicates that the storm is overhead. (Acurite consoles show that as 0 miles/km from what I've been told). IIRC the values from the AS3935 directly are intended to be in KM. (Acurite unfortunately chose to compress the distance values into 5 bits (0 .. 31). I think they use a table lookup which I think has some small errors in it, so I don't see a formula that works. I've collected mappings between the Acurite message values and what their Access bridge devices translates it into as miles. I've yet to do a PR for that.) Two other bits that are in the Acurite messages to look for:
I was able to trigger some false detection by waving the sensor over RFI generating devices and their connecting cables (like an RPI). Someone told me they were able to get false positives by placing the sensor close enough to the electronic ignition of their gas fired boiler/water heater. Hope this helps. |
I tested it by soldering RX TX and connected to a serial to usb (two different ones) converter with different baud rates, no outputs at my side. Even if you press the reset button, nothing. |
|
Hi All, I do not have this sensor but looking at the pcb FYI .. CCL Electronics Mac |
|
HI, did anyone wrote a test decoder yet? |
|
Hi, I made some tests using near empty battery and the messages are changing for
|
|
I also tried to write a decoder, but I am not a coder and so I could only copy data from the bresser 7 in 1 and made a long try and error, not knowing really what I am doing :-) Maybe some one can look at the code and check if I am totally wrong? Thanks |
|
Additional there seems to be a message that is shorter and at the end , the message is changing from 0000 to 0002, no matter if the battery is full or not f6aab508aaaa90aaaaa8 I hope this information are useful |
|
Hi looks like after the CTR comes the battery indicator. 8 for full 0 for battery low. |
|
Some more info: |
Could be the 'startup' bit at bit3 (for pairing with the station). But ~1 hour seems to be a little long for this purpose. |
|
What's the status and path forward? Is someone working on a PR? |
gdt
added
the
feedback
|
Hi, |
|
Hey, i just try the decoder, but no messages return from the sensor with Exact sample rate is: 1000000.026491 Hz many thanks in advance, |
|
Hi I tried the decoder today unfortunatly I did not get a response either. I used the latest docker container which currently comes with rtl_433 version 23.11 (2023-11-28) rtl_433 -R249 -f 868.3M -X 'n=Bresser-Lightning,m=FSK_PCM,s=120,l=120,r=2000,preamble=aa2dd4' I obtain the values: When using "rtl_433 -f 868.3M -v -R249" I get the following output Pulse data: 1 pulses |
|
Hi, I tested with my device and also it does not work. Changing for testing Changing the DECODE_FAIL_MIC to: int chk = (msg[0] << 8) | msg[1]; it shows: Maybe different sensors around? |
|
Hi @franki29 : I guess you're on the good way. Confirmed by another github repo, https://github.com/RFD-FHEM, @elektron-bbs already decoded this lightning device, protocol 131, added in January. Extract: Few gaps, one at the msg length , should be 10 byte / 80 bit (20 nibbles in RFD-FHEM) and not 25 bytes as other Bresser sensors. another at digest level, should be , LFSR-16 gen 8810 key abf9 final xor 899e , as already proposed by @zuckschwerdt here The rest is the same, type = 0x3 after dewhitened, so normal that we have type = 0x9 here before the XOR 0xA. For me the rtl_433 device is easy to update accordingly. Edit : Done, I just updated the device. Please try and give feedback here. Thx |
|
Hi @ProfBoc75 ,yes I can confirm that it works: Some more information: |
|
@ProfBoc75 I just tested the code and it seems to work, cool! However I tried to integrate the sensor in home assistant using mqtt output. The device gets automatically detected with mqtt-auto-discovery but only shows the strike count as a sensor. Looking into the mqtt-auto-discovery script showed that that this key is not picked up however "storm_dist_km" is, which is also used in fineoffset_wh31l.c, should be picked up in the latest version and is used for lightning distance Other keys that are used for lightning distance are "storm_dist" and "strike_distance" both are used in acurite.c however these report in miles. Which would imply that the suffix "_km" should be added to keep it clear. Since distance_km is not really descriptive I would suggest to change to either "storm_dist_km" since it is already used and support by mqtt auto-discovery or to "strike_distance_km" to keep the key more consistent with strike_count. mqtt-auto-discovery script is found here https://github.com/merbanan/rtl_433/blob/master/examples/rtl_433_mqtt_hass.py) |
|
I have already prepared that change and I'll PR it now. |
Hello,
recently i bought mentioned lightning sensor, but not supported yet.
i followed the suggestion by recording sample here is the result.
est mode active. Reading samples from file: g045_868M_1000k.cu8
baseband_demod_FM: low pass filter for 250000 Hz at cutoff 25000 Hz, 40.0 us
Detected FSK package @0.088888s
Analyzing pulses...
Total count: 57, width: 71.66 ms (17915 S)
Pulse width distribution:
[ 0] count: 6, width: 1500 us [1456;1712] ( 375 S)
[ 1] count: 47, width: 484 us [480;492] ( 121 S)
[ 2] count: 4, width: 976 us [972;980] ( 244 S)
Gap width distribution:
[ 0] count: 47, width: 484 us [480;492] ( 121 S)
[ 1] count: 4, width: 1456 us [1456;1460] ( 364 S)
[ 2] count: 1, width: 1936 us [1936;1936] ( 484 S)
[ 3] count: 3, width: 968 us [968;972] ( 242 S)
[ 4] count: 1, width: 2428 us [2428;2428] ( 607 S)
Pulse period distribution:
[ 0] count: 10, width: 2116 us [1944;2432] ( 529 S)
[ 1] count: 41, width: 968 us [968;976] ( 242 S)
[ 2] count: 3, width: 1452 us [1452;1456] ( 363 S)
[ 3] count: 2, width: 2912 us [2908;2916] ( 728 S)
Pulse timing distribution:
[ 0] count: 10, width: 1484 us [1456;1712] ( 371 S)
[ 1] count: 94, width: 484 us [480;492] ( 121 S)
[ 2] count: 7, width: 972 us [968;980] ( 243 S)
[ 3] count: 1, width: 1936 us [1936;1936] ( 484 S)
[ 4] count: 1, width: 2428 us [2428;2428] ( 607 S)
[ 5] count: 1, width: 36060 us [36060;36060] (9015 S)
Level estimates [high, low]: 15927, 424
RSSI: -0.1 dB SNR: 15.7 dB Noise: -15.9 dB
Frequency offsets [F1, F2]: 22601, 2388 (+86.2 kHz, +9.1 kHz)
Guessing modulation: Pulse Code Modulation (Not Return to Zero)
view at https://triq.org/pdv/#AAB031060105CC01E403CC0790097C8CDC8191919191919191919191919191919191919191919191919091A1819190918091819355+AAB014060105CC01E403CC0790097C8CDCA1A28291919455+AAB01E060105CC01E403CC0790097C8CDC91919192A0919191819191919191919555
Attempting demodulation... short_width: 484, long_width: 484, reset_limit: 495616, sync_width: 0
Use a flex decoder with -X 'n=name,m=FSK_PCM,s=484,l=484,r=495616'
pulse_demod_pcm(): Analyzer Device
bitbuffer:: Number of rows: 1
[00] {222} f5 55 55 55 55 55 51 6e a2 e2 e8 6c e5 41 54 c5 5d 55 50 00 00 00 00 00 00 00 00 00
Flex decoder data:
X 'n=test,m=FSK_PCM,s=484,l=484,r=495616
time : 2022-08-08 18:26:49
model : test count : 1 num_rows : 1 rows :
len : 35 data : 6ae500000
codes : {35}6ae500000
is there already decoder which i can use or someone who have decode it ?
thank you in advance,
The text was updated successfully, but these errors were encountered: