Trying to decode signal from Marlec Solar Iboost+

[mehstg]

I have a Marlec Solar Iboost+ solar diverter which communicates to it's display unit on 868.3mhz. From a few threads online it appears to use a TI CC1100 tranceiver.

I have some sample cu8 files recorded and would love to understand how you determine the encoding/modulation etc. Running -a on a recording gives me output like below:

*** signal_start = 4294957301, signal_end = 59789, signal_len = 69784, pulses_found = 6
Iteration 1. t: 9201    min: 4104 (4)    max: 14298 (2)    delta 16102010
Iteration 2. t: 9201    min: 4104 (4)    max: 14298 (2)    delta 0
Pulse coding: Short pulse length 4104 - Long pulse length 14298

Short distance: 269, long distance: 487, packet distance: 1872

p_limit: 9201
bitbuffer:: Number of rows: 3 
[00] { 1} 80        : 1
[01] { 4} 10        : 0001
[02] { 1} 00        : 0

[zuckschwerdt]

Please update your rtl_433, 21.05 is current. There should be a warning about -a. Use -A.

[mehstg]

Thanks for the quick response. Have updated and attached a full output of -A

output.txt output1.txt

[zuckschwerdt]

The three packets are: Noise or a preamble, then two FSK transmissions.

Detected FSK package    @0.630716s
Analyzing pulses...
Total count:  181,  width: 62.91 ms     (15727 S)
Pulse width distribution:
 [ 0] count:    1,  width: 3400 us [3400;3400]  ( 850 S)
 [ 1] count:   84,  width:   88 us [72;104] (  22 S)
 [ 2] count:   15,  width:  244 us [236;260]    (  61 S)
 [ 3] count:   49,  width:  164 us [148;180]    (  41 S)
 [ 4] count:   22,  width:  356 us [316;412]    (  89 S)
 [ 5] count:    3,  width:  484 us [476;492]    ( 121 S)
 [ 6] count:    7,  width:   68 us [68;68]  (  17 S)
Gap width distribution:
 [ 0] count:    1,  width:  112 us [112;112]    (  28 S)
 [ 1] count:   24,  width:  228 us [216;244]    (  57 S)
 [ 2] count:   85,  width:   72 us [60;88]  (  18 S)
 [ 3] count:   41,  width:  152 us [144;168]    (  38 S)
 [ 4] count:   15,  width:  316 us [300;388]    (  79 S)
 [ 5] count:    6,  width:  420 us [384;472]    ( 105 S)
 [ 6] count:    7,  width:  676 us [560;792]    ( 169 S)
 [ 7] count:    1,  width:   52 us [52;52]  (  13 S)
Pulse period distribution:
 [ 0] count:    1,  width: 3512 us [3512;3512]  ( 878 S)
 [ 1] count:   55,  width:  352 us [304;412]    (  88 S)
 [ 2] count:   45,  width:  236 us [224;252]    (  59 S)
 [ 3] count:   23,  width:  488 us [404;576]    ( 122 S)
 [ 4] count:   42,  width:  156 us [148;172]    (  39 S)
 [ 5] count:   14,  width:  780 us [568;888]    ( 195 S)
Pulse timing distribution:
 [ 0] count:    1,  width: 3400 us [3400;3400]  ( 850 S)
 [ 1] count:  154,  width:   80 us [68;104] (  20 S)
 [ 2] count:   39,  width:  236 us [216;260]    (  59 S)
 [ 3] count:   90,  width:  160 us [144;180]    (  40 S)
 [ 4] count:   41,  width:  344 us [300;412]    (  86 S)
 [ 5] count:    6,  width:  492 us [472;560]    ( 123 S)
 [ 6] count:   23,  width:   64 us [52;68]  (  16 S)
 [ 7] count:    1,  width:  112 us [112;112]    (  28 S)
 [ 8] count:    6,  width:  696 us [628;792]    ( 174 S)
 [ 9] count:    1,  width:    0 us [0;0]    (   0 S)
Level estimates [high, low]:  15964,      3
RSSI: -0.1 dB SNR: 37.3 dB Noise: -37.4 dB
Frequency offsets [F1, F2]:    5735,   -421 (+21.9 kHz, -1.6 kHz)
Guessing modulation: No clue...

That means it's likely FSK PCM with a bit width of 80 µs. Try: -X 'n=Marlex,m=FSK_PCM,s=80,l=80,r=1000'

[mehstg]

No joy with the FSK PCM commands above, I did notice in the output from rtl_433 it suggested

-X 'n=name,m=OOK_PWM,s=14832,l=42372,r=7536,g=0,t=0,y=25716'

Have tried with that, which gives me some output, but nothing that makes sense to me.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : @0.127464s
model     : name         count     : 2             num_rows  : 2             rows      : 
len       : 22           data      : fffff8, 
len       : 0            data      : 
codes     : {22}fffff8, {0}

[zuckschwerdt]

From the timings it looks like FSK_PCM should work. All pulse/gap widths are multiples of 80 µs.

The first block (which is seen as OOK) is warm-up / preamble or garbage. The analyzer can't handle PCM because there is no obvious "rhythm" to it -- thus no pdv link or suggestion of a -X.

Grab a sample then (-S unknown), check on https://triq.org/pdv/ that it looks plausible (remotely like e.g. https://triq.org/iqs/#/Schrader_TPMS_SMD3MA4/01/driving_315M_250k.cu8) then upload here as zip.

[mehstg]

g008_868.3M_1000k.cu8.zip

This seems to be the closest to your link above. It was transmitted just after I pressed the boost button on the unit and the remote display showed "Boosting for 15 mins". I realise this could either be transmitted as characters, or could just be a reference to a stored phrase on the display unit though.

[zuckschwerdt]

That would be a good file to investigate. The zip link is broken. Upload didn't work for some reason?

[mehstg]

Have just updated the link. Must have navigated away before it finished the upload.

[zuckschwerdt]

I guess the -A output is from a file input, not live? The sample rate is wrong then. The real bit width is 20 µs. This works: rtl_433 -s1M -X 'n=Marlec,m=FSK_PCM,s=20,l=20,r=1000' g008_868.3M_1000k.cu8 and gives {186}d555555569c8e9c88612aae6d5c2af41077c00401fbc3b8

Grab a good number of codes and put them in a https://triq.net/bitbench then find the data in there, or just post a link.

[mehstg]

Yes, the -A output was from file and not live. I'll grab a few and have a play. Thank you for your guidance.

Quick question, do you include the {186} when pasting in to bitbench

[zuckschwerdt]

Someday rtl_433 should recognize the _1000kon the cu8, but currently it doesn't and defaults to 250k. Always add -s 1M when using 1000k input files.

[zuckschwerdt]

When collecting codes in BitBench note that you can add comments, e.g. {186}d555555569c8e9c88612aae6d5c2af41077c00401fbc3b8 [boost button]

[mehstg]

I have uploaded some codes to bitbench - here

[zuckschwerdt]

Set a preamble align of aaab and four codes look similar (format string of 8h:

4e 47 4e 44 30 95 57 36 ae 15 7a 08 3b e0 02 00 fd e1 6e
4e 47 4e 44 b0 f8 5c 04 00 fe 23 f3 9a 0e 7e 39 91 08 38 00 00 00 00 00 01 11 23 2c 27 20 27 a0 16 0d 01 00 00 00 00 00 00 3c 3e 7
4e 47 4e 44 b2 f9 5c 04 00 00 00 00 00 00 d3 75 65 a4 74 24 e3 c2 30 70 00 00 00 00 00 03 07 4a ea a8 48 a9 66 64 61 a0 00 69 0
4e 47 4e 44 b2 f9 5c 04 03 92 0e 60 29 80 f0 28 00 00 00 00 00 01 94 c5 c4 e4 25 03 e2 c1 90 10 00 00 00 00 00 02 3c 86 b2 4a fb 0

Those leading bytes look like a device ID of sync word, also like ASCII, use a format string of 8c to see that.

It's generally too much data with no reference to the values (kWh etc.?) to take a guess. You'd need to collect codes in stable conditions, like very slowly changing kW reading, correlate with the head unit output and then try to find where those values are located in the bytes.

[mehstg]

i'll drain some water from the tank so it starts heating, that should give me a consistent output of different phrases and take another capture

[mehstg]

Have added a new bitbench here - I drained water off from the tank to force it to start heating via solar again. The text shown on the display was "Heating by Solar 1.21kW Htr1" where the kW value was constantly changing. Just thinking, but there are two transmitting devices here, the Solar iboost itself, but also the CT clamp down by the meter that measures how much energy is going back to grid....We are most interested in the transmissions from the Iboost device itself.

Bitbench link - here

[zuckschwerdt]

Format the BitBench like this. (i.e. comments in [..], preamble aaab, format "8h")

If you can, capture 20-50 messages while the kW is slowly changing. That way all codes should look mostly the same and the differing bits show where the kW value is hiding.

[mehstg]

I have captured over a 5min period. During this time, the system was heating using solar and the kW output was fluctuating between 0.9kW and about 1.4kW.

BitBench

[zuckschwerdt]

Good work. Sorry I didn't spot this earlier, but the codes aren't actually that long. It's multiple packets. PCM can't reliably transmit more than say two 00's, i.e. 16 bit without losing the timing. And we can actually see the gaps in amplitude:

I'll try to recover the shorter codes from your rows. Otherwise use this to capture from now on: rtl_433 -f 868.3M -X 'n=Marlec,m=FSK_PCM,s=20,l=20,g=350,r=600,preamble=aad391d391' or replay with rtl_433 -s 1M -Y minmax -X 'n=Marlec,m=FSK_PCM,s=20,l=20,g=350,r=600,preamble=aad391d391' myfile.cu8

The codes in your uploaded sample are now much better to view: BitBench.

[mehstg]

That’s excellent. I’ll take some more traces tomorrow as the sun has almost gone here today now (unless I can trick it in to thinking I’m exporting solar by flipping the polarity on the CT clamp.

This is much lower level than I am used to working at but really interesting. I appreciate your time.

[zuckschwerdt]

I've picked just the pristine looking codes from the one sample and the picture is looking much better now: BitBench. There is a value visibly counting and then some checksum-like fields at the end.

The preamble is aaaa..., the sync word is d391 (repeated twice), then there is a length byte, data (of length byte len), and a CRC-16 checksum (poly 0x8005 init 0xffff).

[zuckschwerdt]

There is now a "decoder" for this device class in current rtl_433. Get a fresh copy (or git pull) and recompile. The actual meaning of the data payload is not known. You need to run this and try to collect hints. There are at least 3 different message types (from the sample you provided): short messages, a very long message, and a long message from another device (the last one, slightly different freq). E.g.

2555cdab855e820ef800803f
2555cdab855e820eeb00803f
2555cdab855e820edf00803f
2555cdab855e820ed200803f
2555cdab855e820eba00803f
2555cdab855e820ead00803f
2555cdab855e820ea100803f
2555cdab855e820e8800803f
2555cdab855e820e7c00803f
2555cdab855e820e6f00803f
2555cdab855e820e6300803f
2555cdab855e820e4a00803f
2555cdab855e820e3e00803f
2555cdab855e820e3100803f
2555cdab855e820e2500803f
2555cdab855e820e1800803f
2555cdab855e820e0c00803f
69ec555e85003007c51b00ca86123107ea32124c50e8176819d10481531fd1f406d81d22fae309c3ea9baf
42ee55ca86123107c51b005e85003007c51b00040dd400350c803fc1b8

These messages are properly aligned and CRC checked. But the content might be whitened or encrypted perhaps.

[zuckschwerdt]

Maybe @duc996 can help with further decoding. He added the Archos-TBH in #1199. This protocol is eerily similar, basically I just copied the Archos-TBH code and it worked. I have no clue how they figured out the encryption scheme (the TI CC1100 has hardware encryption support and that might well be used here).

[mehstg]

That's great. I grabbed some more signals this morning using the decoder.

42eea45e85003007c51b00ca86123107c51b00040d4250350c803fb33d
2584cdab9443820ef800803f
2584cdab9443820eeb00803f
2584cdab9443820ed200803f
2584cdab9443820ead00803f
2584cdab9443820ea100803f
2584cdab9443820e8800803f
2584cdab9443820e6300803f
2584cdab9443820e5600803f
2584cdab9443820e4a00803f
2584cdab9443820e3e00803f
2584cdab9443820e3100803f
2584cdab9443820e2500803f
2584cdab9443820e1800803f
42ee84ca86123107c51b004394003007c51b00040dd700350c803ff471
2585cdabffff820e350c803f
2585cdabffff820e280c803f
2585cdabffff820e1c0c803f
2585cdabffff820e030c803f
2585cdabffff820ef70b803f
2585cdabffff820eea0b803f
2585cdabffff820ede0b803f
2585cdabffff820ed10b803f
2585cdabffff820ec50b803f
2585cdabffff820eb90b803f
2585cdabffff820eac0b803f
2585cdabffff820ea00b803f
2585cdabffff820e930b803f
2585cdabffff820e870b803f
2585cdabffff820e7b0b803f
2585cdabffff820e6e0b803f
2585cdabffff820e620b803f
2585cdabffff820e550b803f
2585cdabffff820e490b803f
2585cdabffff820e3d0b803f
2585cdabffff820e300b803f
2585cdabffff820e240b803f
2585cdabffff820e170b803f
2585cdabffff820e0b0b803f
2585cdabffff820eff0a803f
2585cdabffff820ef20a803f
2585cdabffff820ee60a803f
2585cdabffff820ed90a803f
2585cdabffff820ecd0a803f
2585cdabffff820ec10a803f
2585cdabffff820ea80a803f
2585cdabffff820e9b0a803f
2585cdabffff820e8f0a803f
2585cdabffff820e830a803f
2585cdabffff820e760a803f
2585cdabffff820e6a0a803f
2585cdabffff820e5d0a803f
2585cdabffff820e510a803f
2585cdabffff820e450a803f
2585cdabffff820e380a803f
2585cdabffff820e2c0a803f
2585cdabffff820e1f0a803f
2585cdabffff820e130a803f
2585cdabffff820e070a803f
2585cdabffff820efa09803f
2585cdabffff820eee09803f
2585cdabffff820ee109803f
2585cdabffff820ed509803f
2585cdabffff820ec909803f
2585cdabffff820ebc09803f
2585cdabffff820eb009803f
2585cdabffff820ea309803f
2585cdabffff820e7e09803f
2585cdabffff820e7209803f
2585cdabffff820e6509803f
2585cdabffff820e5909803f
2585cdabffff820e4d09803f
2585cdabffff820e4009803f
2585cdabffff820e3409803f
2585cdabffff820e2709803f
2585cdabffff820e1b09803f
2585cdabffff820e0f09803f
2585cdabffff820e0209803f
2585cdabffff820ef608803f
2585cdabffff820edd08803f
2585cdabffff820ed108803f
2585cdabffff820ec408803f
2585cdabffff820eb808803f
2585cdabffff820eab08803f
2585cdabffff820e9f08803f
2585cdabffff820e9308803f
2585cdabffff820e8608803f
2585cdabffff820e7a08803f
2585cdabffff820e6d08803f
2585cdabffff820e6108803f
2585cdabffff820e5508803f
2585cdabffff820e4808803f
2585cdabffff820e2f08803f
2585cdabffff820e2308803f
2585cdabffff820e1708803f
2585cdabffff820e0a08803f
2585cdabffff820ef107803f
2585cdabffff820ee507803f
2585cdabffff820ed907803f
2585cdabffff820ecc07803f
2585cdabffff820ec007803f
2585cdabffff820ea707803f
2585cdabffff820e9b07803f
2585cdabffff820e8e07803f
2585cdabffff820e8207803f
2585cdabffff820e7507803f
2585cdabffff820e6907803f
42eea55e85003007c51b00ca86123107c51b00040d2343350c803fde13
2586cdab855e820ef800803f
2586cdab855e820edf00803f
2586cdab855e820ed200803f
2586cdab855e820ec600803f
2586cdab855e820eba00803f
2586cdab855e820ead00803f
2586cdab855e820ea100803f
2586cdab855e820e7c00803f
2586cdab855e820e6f00803f
2586cdab855e820e6300803f
2586cdab855e820e5600803f
2586cdab855e820e4a00803f
2586cdab855e820e3e00803f
2586cdab855e820e3100803f
2586cdab855e820e2500803f
2586cdab855e820e1800803f
2586cdab855e820e0c00803f
42ee86ca86123107c51b005e85003007c51b00040da800350c803f7a3c
42eea65e85003007c51b00ca86123107c51b00040d0cdb350c803f8fc3
2587cdab855e820ef800803f
2587cdab855e820edf00803f
2587cdab855e820ed200803f
2587cdab855e820ec600803f
2587cdab855e820eba00803f
2587cdab855e820ead00803f
2587cdab855e820ea100803f
2587cdab855e820e9400803f
2587cdab855e820e8800803f
2587cdab855e820e7c00803f
2587cdab855e820e6300803f
2587cdab855e820e5600803f
2587cdab855e820e4a00803f
2587cdab855e820e3e00803f
2587cdab855e820e3100803f
2587cdab855e820e2500803f
2587cdab855e820e1800803f
69ec875e85003007c51b00ca86123107769f1bacb2df748ec76466a6317528c96cc2b0b5e7c1dc978d8c6b
42ee87ca86123107c51b005e85003007c51b00040daa00350c803f5730

[merbanan]

The CC110X family of chips has no built in encryption but they have an optional whitening step and FEC step. Neither seem to be used here. https://www.ti.com/lit/ds/symlink/cc1101.pdf page 38.

2555cdab855e820[ef8]00803f
2555cdab855e820[eeb]00803f

The marked region is clearly counting down something.

[merbanan]

2585cdab[ffff]820e6907803f
2586cdab[855e]820ef800803f

This seems to be a specific block.

[merbanan]

25[84]cdab9443820eeb00803f
25[85]cdabffff820ed108803f
25[86]cdab855e820e7c00803f
25[87]cdab855e820e3100803f

And this block is counting up for some reason.

[merbanan]

The next step is now to match observed states from the panel to actually transmitted codes.

The manual has some info about that possible states. https://www.marlec.co.uk/wp-content/uploads/2016/02/Solar-iBoost-User-Manual-SM-505B-01.07019.pdf

At least the kW value should be easy to find.

[zuckschwerdt]

You are right of course, whitening only. I was confused by the encryption example from the Archos-TBH. And the changing 2nd byte (84..87) shows that there is no xor chain also. Seems to be plain text then.

[zuckschwerdt]

The layout hints to two single byte values, then 2-byte values, and the 2-byte groups look like little endian, i.e. format TYPE?8h SEQ?8h <16h <16h <16h DOWN?<16h <16h BitBench with that format (for type "25").

[duc996]

I was at the same point as you when I tried to decode the archos-tbh but data frames changes a lot between transmissions. So I have searched for encryption. There was an android application for archos which I have de-compiled to find the key. So this is not helping you much. Your data don't change a lot between transmissions, so I don't think there is any encryption (you have already figured out that).

[mehstg]

I have just been doing more testing. It's difficult to match a transmission to an exact value. The screen fluctuates and shows between 1.51 and 1.69kwh, however the transmissions seem to come in batches, where i'll see nothing for 20 seconds or so, then suddenly receive many:

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-15 10:49:06
model     : Marlec-Solar Raw data  : 42eed95e85003007c51b00ca86123107c51b00040d5a88350c803f0213        Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-15 10:49:06
model     : Marlec-Solar Raw data  : 25e7cdab9443820ef800803f                Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-15 10:49:06
model     : Marlec-Solar Raw data  : 25e7cdab9443820eeb00803f                Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-15 10:49:06
model     : Marlec-Solar Raw data  : 25e7cdab9443820edf00803f                Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-15 10:49:06
model     : Marlec-Solar Raw data  : 25e7cdab9443820ed200803f                Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-15 10:49:06
model     : Marlec-Solar Raw data  : 25e7cdab9443820ec600803f                Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-15 10:49:06
model     : Marlec-Solar Raw data  : 25e7cdab9443820eba00803f                Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-15 10:49:06
model     : Marlec-Solar Raw data  : 25e7cdab9443820ead00803f                Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-15 10:49:06
model     : Marlec-Solar Raw data  : 25e7cdab9443820ea100803f                Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-15 10:49:06
model     : Marlec-Solar Raw data  : 25e7cdab9443820e9400803f                Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-15 10:49:06
model     : Marlec-Solar Raw data  : 25e7cdab9443820e8800803f                Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-15 10:49:06
model     : Marlec-Solar Raw data  : 25e7cdab9443820e7c00803f                Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-15 10:49:06
model     : Marlec-Solar Raw data  : 25e7cdab9443820e6f00803f                Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-15 10:49:06
model     : Marlec-Solar Raw data  : 25e7cdab9443820e6300803f                Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-15 10:49:06
model     : Marlec-Solar Raw data  : 25e7cdab9443820e5600803f                Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-15 10:49:06
model     : Marlec-Solar Raw data  : 25e7cdab9443820e4a00803f                Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-15 10:49:06
model     : Marlec-Solar Raw data  : 25e7cdab9443820e3e00803f                Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-15 10:49:06
model     : Marlec-Solar Raw data  : 25e7cdab9443820e3100803f                Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-15 10:49:06
model     : Marlec-Solar Raw data  : 25e7cdab9443820e2500803f                Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-15 10:49:06
model     : Marlec-Solar Raw data  : 25e7cdab9443820e1800803f                Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-15 10:49:06
model     : Marlec-Solar Raw data  : 42eee7ca86123107c51b004394003007c51b00040dd800350c803f41d9        Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-15 10:49:09
model     : Marlec-Solar Raw data  : 42ee004394003007c51b00ca86123107c51b00040d4db6350c803fe99e        Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-15 10:49:10
model     : Marlec-Solar Raw data  : 25e8cdab9443820ef800803f                Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-15 10:49:10
model     : Marlec-Solar Raw data  : 25e8cdab9443820eeb00803f                Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-15 10:49:10
model     : Marlec-Solar Raw data  : 25e8cdab9443820edf00803f                Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-15 10:49:10
model     : Marlec-Solar Raw data  : 25e8cdab9443820ed200803f                Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-15 10:49:10
model     : Marlec-Solar Raw data  : 25e8cdab9443820ec600803f                Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-15 10:49:10
model     : Marlec-Solar Raw data  : 25e8cdab9443820eba00803f                Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-15 10:49:10
model     : Marlec-Solar Raw data  : 25e8cdab9443820ead00803f                Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-15 10:49:10
model     : Marlec-Solar Raw data  : 25e8cdab9443820ea100803f                Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-15 10:49:10
model     : Marlec-Solar Raw data  : 25e8cdab9443820e9400803f                Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-15 10:49:10
model     : Marlec-Solar Raw data  : 25e8cdab9443820e8800803f                Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-15 10:49:10
model     : Marlec-Solar Raw data  : 25e8cdab9443820e7c00803f                Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-15 10:49:10
model     : Marlec-Solar Raw data  : 25e8cdab9443820e6f00803f                Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-15 10:49:10
model     : Marlec-Solar Raw data  : 25e8cdab9443820e5600803f                Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-15 10:49:10
model     : Marlec-Solar Raw data  : 25e8cdab9443820e4a00803f                Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-15 10:49:10
model     : Marlec-Solar Raw data  : 25e8cdab9443820e3e00803f                Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-15 10:49:10
model     : Marlec-Solar Raw data  : 25e8cdab9443820e3100803f                Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-15 10:49:10
model     : Marlec-Solar Raw data  : 25e8cdab9443820e2500803f                Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-15 10:49:10
model     : Marlec-Solar Raw data  : 25e8cdab9443820e1800803f                Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-15 10:49:10
model     : Marlec-Solar Raw data  : 25e8cdab9443820e0c00803f                Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-15 10:49:10
model     : Marlec-Solar Raw data  : 42eee8ca86123107c51b004394003007c51b00040dab00350c803f842e        Integrity : CRC

[duc996]

After a quick look I can say I have no clue about the protocol. There is a pairing procedure in the manual, so there must be some id in the frame, but I can't see any (at least) 16 bits value which is in all frames. The frame length is also strange. If I understand correctly there is only a power measurement and the sense and some battery information. The 69h frame has 43 bytes, what should all this information should be? Every byte is different in the second part of this frames!

For TBH I had a frame every 30 or 60 seconds. I was able to see the value change on the tbh display with the corresponding radio frame. Then it was easier to find the number format.

[zuckschwerdt]

The 69h frame has 43 bytes, what should all this information should be? Every byte is different in the second part of this frames!

Yes, that is very weird. What could such a simple device want to tell?

Best I can see, the 12 byte "25" frames are repeated with just 250 µs pause between. But the values still change. No sense in updating a display that fast. The 43 byte "69" frame immediatly follows the "25" ones at the same frequency. The 29 byte "42" frame is at a different frequency, seems to be a different device. Seeing that the transmitter timing matches so closely however, I guess it's query-response?

Wild speculation:

69 ec55 💛5e850030 💚07c51b00 💙ca861231 07ea32124c50e8176819d10481531fd1f406d81d22fae309c3ea9baf
   ^Qry  ^From?     ^To?       ^Huh?
42 ee55 💙ca861231 💚07c51b00 💛5e850030 💚07c51b00 040dd400350c803fc1b8
   ^Resp ^these     ^somehow    ^all       ^match

[merbanan]

2021-06-15 10:49:06 and 2021-06-15 10:49:10 (it actually starts a 09 and spills over to 10). This is 2 groups of transmissions.

In-between the 2 messages starting with 42eeXXX there are 19 25XXX messages.

My guess this that one of the message types is from the sender and one is from the receiver. From the manual this system allows pairing which implies some kind of bi-directional protocol. There is a iBoost Buddy that can view lots of data (https://www.marlec.co.uk/wp-content/uploads/2018/06/SM-503B-iBoost-Buddy-Manual-290518.pdf). This data must be sent over the air in some kind of format.

This much data makes it hard to figure out what is what. But one thing that can be done is to see what device transmits the different messages. If you enable logging of signal strength and move the receiver close to one of the devices we should see a clear difference.

I am also unsure what the target is?

Based on this:

https://www.marlec.co.uk/wp-content/uploads/2016/02/Solar-iBoost-Installer-Manual-SM-504B-01.07019.pdf

The sender can only measure watt and maybe energy. (kW and kWh)

[mehstg]

There are three devices.

The CT clamp measures power leaving the property going to the grid, this could possibly be sent across as current (Amps) or a conversion could be done to send power (Watts).

The Solar Iboost device itself, receives signal from the CT clamp and makes a decision how much power to put in to the immersion. Also sends information to the Iboost Buddy (How many kWH being put in to the immersion and also how many W being consumed by the house)

The Iboost Buddy receives signal from the Solar Iboost and displays on a screen.

Good idea RE capturing signal strength. My ultimate aim is to capture the kWH reading from the Iboost device itself so I know how much power is being diverted to the immersion at any point in time.

[zuckschwerdt]

@mehstg is it possible for you to take two devices offline in turn and observe which message remain? We need to known which device is sending what. Other possibility is to remove the antenna from the rtlsdr and put it next to each device, that should then show only those transmissions (or at least others with very faint signal). Get signal strength with -M level

[real-bombinho]

42 ee d9 5e 85 00 30 07 c5 1b 00 ca 86 12 31 07 c5 1b 00 04 0d 5a 88 35 0c 80 3f 02 13 42 ee e7 ca 86 12 31 07 c5 1b 00 43 94 00 30 07 c5 1b 00 04 0d d8 00 35 0c 80 3f 41 d9 42 ee 00 43 94 00 30 07 c5 1b 00 ca 86 12 31 07 c5 1b 00 04 0d 4d b6 35 0c 80 3f e9 9e

Here is a clear left shift

42 ee d9 5e 85 00 30 07 c5 1b 00 ca 86 12 31 07 c5 1b 00 04 0d 5a 88 35 0c 80 3f 02 13 42 ee e7 ca 86 12 31 07 c5 1b 00 43 94 00 30 07 c5 1b 00 04 0d d8 00 35 0c 80 3f 41 d9 42 ee 00 43 94 00 30 07 c5 1b 00 ca 86 12 31 07 c5 1b 00 04 0d 4d b6 35 0c 80 3f e9 9e

ooops '"07 c5 1b 00" is the FP32 value of 0.00000000' is wrong, I just noticed my converter playing up, Edit: me silly converting to fixed point, does not make much sense as FP32.

[dal31b05]

I'm keen to collaborate on this. I spent some time on it a year or so ago so happy to contribute what I found.

I started out using an SDR but we know the system uses CC1100 so I switched to using that. Main reason is it handles all of the faff of converting the RF protocol into data so once we have the RF settings cracked, we just get a data stream to play with. Knowing it's CC1100 also starts to tell us something about what we expect to see in the message format in terms of addressing, variables for message length and potential for CRC.

Obviously, all of this is what I think I have discovered so bear in mind, it could lead you down the same incorrect path.

On the subject of data whitening, the results with whitening off appear more credible, in that they are more consistent between transmissions. I think the modulation is MSK. It's the only scheme that produces any results in the data queue. So far I have been running it with the automated address and CRC checking switched off so I get the maximum number of transmissions out.

Frequency is set to 21656A

I found that 2C6E makes a credible sync word. I think this because using that and a 30/32 bit sync filter, I get messages that start with one of three addresses, presumably corresponding to the three devices. Messages with the same address appear in the same format as each other but not necessarily in the same format as messages with different addresses. In particular, as @real-bombinho says, the sensor does demonstrate some sort of shift between messages whereas the controller and Buddy appear to use a fixed format.

I have lots of captured files but if I'm honest, I didn't annotate them very well so getting involved would take a certain amount of going back over stuff. My first place to start will be trying some more number converters on the byte streams to see if anything obvious comes out. Any recommendation for a good source of functions that can be used to convert numbers in Excel, which is currently where my captured data is held? At one point I did find a byte position in some messages that looked like the slowly accumulating "Saved today" value so I have some small hope that my RF settings are close.

If the data remains impenetrable, the next step will be to rebuild the Arudino/CC1100 rig and fiddle about with the RF settings some more .

My aim started out as capturing the power and energy stats to display in OpenHAB but ultimately, I'd like to be able to remove the current clamp and replace it with messages based on the feed from my smart meter because looking at the values displayed on the Buddy, the CT is not very accurate.

If that works, I would then start controlling the replacement messages based on whether or not I wanted the excess energy diverted into the tank, thereby gaining control over the potential race condition between the iBoost and a future battery storage inverter.

[real-bombinho]

3rd byte (l2r) on messages starting with 42 or 69 equals 2nd byte on messages starting with 25. At least when followed by 0xca861231.

[dal31b05]

This is a file of messages captured from the sensor. It's prefixed with times and includes the RSSI and frequency offset values for each message at the end.

I don't know if the message length is correct so worth starting from the left. sensor.txt

[dal31b05]

Just having a bit of a play with this. We have different sync words. @zuckschwerdt suggested d391 and I found programming the CC1100 with 2c6e to consistently produced messages. These two values are the bitwise inverse of one another so I'm wondering if the values you are reading are all inverted (XOR FF).

[real-bombinho]

I had assumed something along that line as your data has barely any low numbers (242 occurrences of 0x00 vs 69773 occurrences of 0xFF.

[zuckschwerdt]

Good idea. If the sync word isn't obviously a known (2dd4) or best-practice pattern then there is no clue if it's inverted of shifted. Counting the "weight" of 0/1 is a good indicator. You can also use a format string of simply v in BitBench to get a feel for the bits.

[dal31b05]

When I first looked, could see the preamble and I found a pair of sync word transmissions 58dc 58dd, which passes the 30/32 test. However, looking again at whether the preamble is aaaa or 5555, I found the shifting one place to the left gave me the repeated pair 2c6e. Programming the CC1100 to use this as the sync delivers messages that appear to come from the various devices in the system.

Not saying I have found the right answer, but the explanation shows how I got to what I have.

I spent this morning trying to remember how I wired up the Arduino and which sketch is the latest. Once I have unpicked my lack of discipline in recording what I was doing at the time, I’ll reconstruct it and do some more formal tests passing known currents through the CT.

If you have the preamble as aaaa and the sync word as d391 then I suggest that all the bits in the bit stream could be inverted.

[dal31b05]

Doing a bit more verification on the sync word to make sure I don't guide anyone down a rabbit hole of wrong information.

Using the built in detection in the CC1100 chip, here is a trace of the GDOx outputs for a couple of arriving messages.

I can see carrier detected for a couple of bursts but only one passes sync word so the chip is differentiating between valid and invalid messages successfully. If I change the programming for sync word away from 2c6e. I still get carrier sense pulses but not sync word pulses. Carrier Sense asserts ~1ms before sync word, which makes sense.

Next up is to switch the chip to packet mode and pull the messages from FIFO using the sync word GDO output as a trigger for the microcontroller.

[dal31b05]

File captured over an hour. It appears that the sync word output isn't available in packet mode so I am using RX FIFO (option 0x01) as the trigger to the microcontroller that there is a message arriving.

Some info in case it helps: All devices

RSSI and Offset included to give a clue which device is transmitting Buddy is close by. Controller is one floor down Sensor is two floors down.

Packet length set to 46. Might be too short or too long.

Some reading from the buddy in case they can be found amongst the data: Saved Today = 7.11kWh Saved Yesterday = 4.22kWh Saved last 7 days = 34.36kWh Saved Last 28 days = 114.88kWh Saved Amount = 6467.08kWh

All devices.txt

[dal31b05]

This is a subsequent hour of data but this time with the forward error correction switched on. (https://github.com/merbanan/rtl_433/files/6797606/All.devices.FEC.on.txt)

[real-bombinho]

I have knitted a little dirty data manipulation program for the sensor.txt.

The given data appears to have no repeating lines etc. This way data can be shuffled around easier as a whole.

https://github.com/real-bombinho/BitstreamTool

[zuckschwerdt]

Sadly BitBench isn't good at large amounts of codes, ballpark 50 lines before it starts getting slow.

The lines in sensor.txt all all very long, shouldn't there be (3?) different lengths?