Assistance required capturing/decoding signal from Aclara Water Meter Transmit Unit (AKA: "MTU")

[foxale08]

Known:

• FCCID: LLB6327P
• Frequency: 452.8625 Mhz
• Baud Rate: 1200 Bps
• Bandwidth: 12.5 Khz (25Khz total)
• Example message contains 92 bits and takes 77 milliseconds to transmit

Suspected/Implied (based on documents):

• FSK Modulation
• Manchester Encoding
• Message size varies and can take up to 150 milliseconds to transmit

Suspected/Discovered:

• First 24 bits of frame: "fffaaa" (NRZ and Manchester II)
• Two message types

Example file after filtering:
g047_452.862M_250k.cu8.zip

As shown I can get a comprehensible signal from UHR but need help with rtl_433.

I can only seem to reliably capture the signals with the following (It does also seem to work without the offset):
rtl_433 -f 452862490 -s 250k -p 10 -Y "minlevel=-3,minmax,squelch" -S all

pi@pisdr:/media/pi/guest/452.862M $ /home/pi/Desktop/rtl_433/src/rtl_433 -A ./g047_452.862M_250k.cu8 -Y "minmax"
rtl_433 version nightly-17-g3264d01d branch master at 202303230949 inputs file rtl_tcp RTL-SDR SoapySDR with TLS
Use -h for usage help and see https://triq.org/ for documentation.
Trying conf file at "rtl_433.conf"...
Trying conf file at "/home/pi/.config/rtl_433/rtl_433.conf"...
Trying conf file at "/usr/local/etc/rtl_433/rtl_433.conf"...
Trying conf file at "/etc/rtl_433/rtl_433.conf"...
[Protocols] Registered 210 out of 243 device decoding protocols [ 1-4 8 10-12 15-17 19-23 25-26 29-36 38-60 63 67-71 73-100 102-105 108-116 119-121 124-128 130-149 151-161 163-168 170-175 177-197 199 201-215 217-228 230-232 234-241 243 ]
[Input] Test mode active. Reading samples from file: ./g047_452.862M_250k.cu8
Detected FSK package @0.101412s
Analyzing pulses...
Total count: 313, width: 94.96 ms (23741 S)
Pulse width distribution:
[ 0] count: 1, width: 0 us [0;0] ( 0 S)
[ 1] count: 45, width: 8 us [8;8] ( 2 S)
[ 2] count: 3, width: 72 us [68;76] ( 18 S)
[ 3] count: 26, width: 20 us [20;24] ( 5 S)
[ 4] count: 19, width: 12 us [12;12] ( 3 S)
[ 5] count: 25, width: 16 us [16;16] ( 4 S)
[ 6] count: 25, width: 36 us [32;48] ( 9 S)
[ 7] count: 14, width: 28 us [28;32] ( 7 S)
[ 8] count: 4, width: 112 us [100;124] ( 28 S)
[ 9] count: 63, width: 4 us [4;4] ( 1 S)
[10] count: 2, width: 52 us [52;56] ( 13 S)
[11] count: 48, width: 380 us [316;464] ( 95 S)
[12] count: 23, width: 732 us [660;808] ( 183 S)
[13] count: 2, width: 284 us [284;288] ( 71 S)
[14] count: 5, width: 512 us [484;560] ( 128 S)
[15] count: 4, width: 208 us [200;224] ( 52 S)
Gap width distribution:
[ 0] count: 41, width: 8 us [8;8] ( 2 S)
[ 1] count: 25, width: 12 us [12;12] ( 3 S)
[ 2] count: 33, width: 20 us [20;24] ( 5 S)
[ 3] count: 58, width: 4 us [4;4] ( 1 S)
[ 4] count: 23, width: 16 us [16;16] ( 4 S)
[ 5] count: 22, width: 36 us [36;48] ( 9 S)
[ 6] count: 6, width: 56 us [52;68] ( 14 S)
[ 7] count: 16, width: 28 us [28;32] ( 7 S)
[ 8] count: 2, width: 92 us [92;96] ( 23 S)
[ 9] count: 4, width: 140 us [128;168] ( 35 S)
[10] count: 17, width: 600 us [492;756] ( 150 S)
[11] count: 38, width: 440 us [380;496] ( 110 S)
[12] count: 1, width: 348 us [348;348] ( 87 S)
[13] count: 22, width: 840 us [756;900] ( 210 S)
[14] count: 4, width: 212 us [200;244] ( 53 S)
Pulse period distribution:
[ 0] count: 8, width: 8 us [8;8] ( 2 S)
[ 1] count: 40, width: 20 us [20;24] ( 5 S)
[ 2] count: 8, width: 120 us [100;144] ( 30 S)
[ 3] count: 34, width: 40 us [36;52] ( 10 S)
[ 4] count: 13, width: 16 us [16;16] ( 4 S)
[ 5] count: 27, width: 28 us [28;32] ( 7 S)
[ 6] count: 26, width: 60 us [52;76] ( 15 S)
[ 7] count: 7, width: 84 us [76;92] ( 21 S)
[ 8] count: 20, width: 12 us [12;12] ( 3 S)
[ 9] count: 5, width: 160 us [152;172] ( 40 S)
[10] count: 48, width: 820 us [656;1064] ( 205 S)
[11] count: 37, width: 408 us [324;496] ( 102 S)
[12] count: 13, width: 524 us [472;592] ( 131 S)
[13] count: 7, width: 1564 us [1348;1668] ( 391 S)
Pulse timing distribution:
[ 0] count: 1, width: 0 us [0;0] ( 0 S)
[ 1] count: 86, width: 8 us [8;8] ( 2 S)
[ 2] count: 9, width: 60 us [52;76] ( 15 S)
[ 3] count: 59, width: 20 us [20;24] ( 5 S)
[ 4] count: 44, width: 12 us [12;12] ( 3 S)
[ 5] count: 48, width: 16 us [16;16] ( 4 S)
[ 6] count: 52, width: 36 us [32;48] ( 9 S)
[ 7] count: 22, width: 28 us [28;32] ( 7 S)
[ 8] count: 8, width: 108 us [92;128] ( 27 S)
[ 9] count: 122, width: 4 us [4;4] ( 1 S)
[10] count: 5, width: 48 us [48;56] ( 12 S)
[11] count: 86, width: 408 us [316;492] ( 102 S)
[12] count: 51, width: 776 us [640;900] ( 194 S)
[13] count: 3, width: 272 us [244;288] ( 68 S)
[14] count: 17, width: 528 us [480;588] ( 132 S)
[15] count: 8, width: 200 us [168;224] ( 50 S)
Level estimates [high, low]: 9846, 155
RSSI: -2.2 dB SNR: 18.0 dB Noise: -20.2 dB
Frequency offsets [F1, F2]: 1478, 2742 (+5.6 kHz, +10.5 kHz)
Guessing modulation: Non Return to Zero coding (Pulse Code)
Attempting demodulation... short_width: 4, long_width: 4, reset_limit: 4096, sync_width: 0
Use a flex decoder with -X 'n=name,m=FSK_PCM,s=4,l=4,r=4096'

[foxale08]

Example unfiltered:
g004_452.862M_250k.zip

[zuckschwerdt]

Don't capture near DC, you are still too close to center add 10-30 kHz.
Your signal is clean but clipping, this is not good for stable demodulation. Load in https://triq.org/spectrogram-next/ and scroll zoom to see this.
1200 baud (raw speed) would be 833 µs per symbol, half that if it's 1200 baud payload speed. That way it should be -X 'n=name,m=FSK_PCM,s=417,l=417,r=1000'

[foxale08]

Awesome! Thank you. I will try this and I very much appreciate your response. I read about the DC offset but wasn't sure if I had gone far enough off center or was just overloading the receiver (-2.2 seems kinda hot.)

I did have a question about the Manchester encoding. Is there any easy way to get this FSK_PCM data decoded with rtl_433? The only option applicable option I see for decode is decode_dm and the output on the previously captured/adjusted files doesn't match what I'm getting in UHR.

[zuckschwerdt]

There is FSK_MC_ZEROBIT but you need to check the PCM first if it really is plain MC or if there are (de-)sync symbols somewhere.

[tjmc]

I have an Aclara 8150DD6 MTU that I decoded awhile back.

FSK
Differential Manchester
Transmits every 12 hours and ~15 minutes

If your meter id is 7587511 and the reading is 040685 they use a similar protocol. I did this a few years ago but would love to get the decoding into rtl_433.

https://github.com/tjmc/hexagram

[hildebrau]

@tjmc, I have a ACLARA 3451-103-XBW RF 3400 Water MTU supplied from City of Austin Water (TX). I have just connected an SDR to my computer and was using rtl_tcp & rtlamr to see my gas meter. I suspect I'll need to run rtl_433 to see this water meter in a different frequency perhaps; but it sounds like it'll be encoded. I was wondering if you could help me out with guidance of how to read the codes so that I can try running them through your hexagram code. My MTU ID# is 71004175 according to the label.

[tjmc]

There are some good docs about the process https://github.com/merbanan/rtl_433/blob/master/docs/ANALYZE.md. My ACLARA has a frequency sticker on it. If yours doesn't, rtl_power probably is your next step to figure it out.
Once you have the frequency you'll need to capture a signal to further figure out the rtl_433 settings you'll need to decode the raw bits.
In that ANALYZE doc, I think the key part is:

To get a clean signal remove the receiver antenna and place the device at 10cm to the receiver, that mostly isolates the transmissions.

If your device is like mine, it is battery powered. Mine only transmits every 12 hours and ~15min so expect not seeing a signal right away.

[hansdg1]

@hildebrau did you ever get this figured out?

[hildebrau]

Negative. @hansdg1

[BostonDanPhD]

I started looking into this. I saw somewhere that Aclara uses AES256128 encryption, so it may be moot to try to decode.

(Source: https://www.hubbell.com/aclara/en/products/p/12662462)

[foxale08]

The "MTU ID" printed on my unit is 8 digit starting with 4113. But I've never been able to see that in captures. I did install a flume device to read water use off the meter with the intention to directly compare the known use with the data transmitted but never circled back around to it. When I get some time I can work on it, I do see a value to the community in decoding this.

…

On Thu, Feb 1, 2024, 8:42 AM TJ ***@***.***> wrote: I have an Aclara 8150DD6 MTU that I decoded awhile back. FSK Differential Manchester Transmits every 12 hours and ~15 minutes If your meter id is 7587511 and the reading is 040685 they use a similar protocol. I did this a few years ago but would love to get the decoding into rtl_433. https://github.com/tjmc/hexagram — Reply to this email directly, view it on GitHub <#2476 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKFPHKHTV5YX4IJ4OUN7KQDYROLUXAVCNFSM6AAAAAAWXJNV6WVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DGMZVGEYTC> . You are receiving this because you authored the thread.Message ID: ***@***.***>