Water counter DIEHL IZAR RC 868 iG4
660 views
Skip to first unread message
rVs
Feb 26, 2019, 3:08:08 PM2/26/19
to rtl_433
My house has a new water counter : DIEHL IZAR RC 868 iG4
Reading the user guide
"Emitting information:
- Every 12 seconds in R3 mode - OMS protocol for the index and alarms.
Detailed information regarding leaks and historic of consumptions are transmitted every 6 sendings.
- Every 15 minutes in R4 long-range network mode."
- Every 12 seconds in R3 mode - OMS protocol for the index and alarms.
Detailed information regarding leaks and historic of consumptions are transmitted every 6 sendings.
- Every 15 minutes in R4 long-range network mode."
I cant't manage to get the sent informations with rtl_433.
I put a few capture in the attached zip file with this state
Can someone help me to decode this device ?
Thanks.
Karl Lohner
Feb 26, 2019, 6:58:42 PM2/26/19
to rVs, rtl_433
I couldn't come up with a working flex spec in rtl_433. My guess is that this is maybe a wireless M-Bus signal and probably beyond the current scope of rtl_433.
Using Universal Radio Hacker I can pull the data, though. Signals are FSK modulated. Bit length of 12 samples, error tolerance of 1, ignoring the repeating "0101" sync symbols before what appears to be "00001111" to start the data, here's the hex-encoded data frames:
g001: 0f4dc9c72664d34b69639c5ac2d38d64e5a596539a595658d59664b8ce4e3c63a5ca7199964ed326593a62ec6b45a38d98f459c9b43a6c9c72b8
g002: 0f4bc9c72664d34d956b1c5ac2d38d64ec5ac9539a595658b59665334d4f17166b4d25a4b8d63a6a65d1935a4f2a654e32f1c96671a4b963d136749b49a59a6d1673138b3a59b1d324d32f4665a4ea633b4d25b139a6b295a34f4b1cb16c4e2e98d971695aa59972d349a96666a35a9
g003: 0f4dc9c72664d34b69639c5ac2d38d64e5a596539a595658d59664b8ce4e3c63a5ca7199964ed326593a62ec6b45a38d98f459c9b43a6c9c72b8
g004: 0f4dc9c72664d34d956b1c5ac2d38d64dc5b13939a595658d59665a2f22f1c5665ac7135ac6934e965c69c56d198e6a69c664d6cb16567348d4
g005: 0f4dc9c72664d34b69639c5ac2d38d64e5a596539a595658d59664b8ce4e3c63a5ca7199964ed326593a62ec6b45a38d98f459c9b43a6c9c72b8
g006: 0f4dc9c72664d34d956b1c5ac2d38d64dc5b13939a595658d59665a2f22f1c5665ac7135ac6934e965c69c56d198e6a69c664d6cb16567348d4
g007: 0f4dc9c72664d34b69639c5ac2d38d64e5a596539a595658d59664b8ce4e3c63a5ca7199964ed326593a62ec6b45a38d98f459c9b43a6c9c72b8
g008: 0f4dc9c72664d34d956b1c5ac2d38d64dc5b13939a595658d59665a2f22f1c5665ac7135ac6934e965c69c56d198e6a69c664d6cb16567348d4
g009: 0f4dc9c72664d34b69639c5ac2d38d64e5a596539a595658d59664b8ce4e3c63a5ca7199964ed326593a62ec6b45a38d98f459c9b43a6c9c72b
g010: 0f4dc9c72664d34d956b1c5ac2d38d64dc5b13939a595658d59665a2f22f1c5665ac7135ac6934e965c69c56d198e6a69c664d6cb16567348d4
g011: 0f4bc9c72664d34b69639c5ac2d38d64d9a56c939a595658b596669c96c6c2dcd236723662ce671d1c9749b42ec596c8b729ca364e8d934b666663d1c5a9c4da6c39ca65d0b70e96cb3498b8d9b29a71669ca399670b4e58cb9b2d1c69c8e9d2559c64b8f2719b0e94d9934cdd0ba560
g012: 0f4dc9c72664d34d956b1c5ac2d38d64dc5b13939a595658d59665a2f22f1c5665ac7135ac6934e965c69c56d198e6a69c664d6cb16567348d4
g013: 0f4dc9c72664d34b69639c5ac2d38d64e5a596539a595658d59664b8ce4e3c63a5ca7199964ed326593a62ec6b45a38d98f459c9b43a6c9c72b8
g014: 0f4bc9c72664d34d956b1c5ac2d38d64ec5ac9539a595658b59665334d4f17166b4d25a4b8d63a6a65d1935a4f2a654e32f1c96671a4b963d136749b49a59a6d1673138b3a59b1d324d32f4665a4ea633b4d25b139a6b295a34f4b1cb16c4e2e98d971695aa59972d349a96666a35a9
g015: 0f4dc9c72664d34b69639c5ac2d38d64e5a596539a595658d59664b8ce4e3c63a5ca7199964ed326593a62ec6b45a38d98f459c9b43a6c9c72b8
g016: 0f4dc9c72664d34d956b1c5ac2d38d64dc5b13939a595658d59665a2f22f1c5665ac7135ac6934e965c69c56d198e6a69c664d6cb16567348d4
g017: 0f4dc9c72664d34b69639c5ac2d38d64e5a596539a595658d59664b8ce4e3c63a5ca7199964ed326593a62ec6b45a38d98f459c9b43a6c9c72b80
g018: 0f4dc9c72664d34d956b1c5ac2d38d64dc5b13939a595658d59665a2f22f1c5665ac7135ac6934e965c69c56d198e6a69c664d6cb16567348d4
I'd guess that since this device says it uses OMS, you might be able to use the info in this document to decode this data:
You might have better luck using this project to decode the data:
--Karl.
--
You received this message because you are subscribed to the Google Groups "rtl_433" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtl_433+u...@googlegroups.com.
To post to this group, send email to rtl...@googlegroups.com.
Visit this group at https://groups.google.com/group/rtl_433.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rtl_433/df17f90b-7463-46c1-bf92-438fbf450db8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Benjamin Larsson
Feb 27, 2019, 4:06:46 AM2/27/19
to rtl...@googlegroups.com
On 2019-02-27 00:58, Karl Lohner wrote:
> I couldn't come up with a working flex spec in rtl_433. My guess is
> that this is maybe a wireless M-Bus signal and probably beyond the
> current scope of rtl_433.
>
> Using Universal Radio Hacker I can pull the data, though. Signals are
> FSK modulated. Bit length of 12 samples, error tolerance of 1, ignoring
> the repeating "0101" sync symbols before what appears to be "00001111"
> to start the data, here's the hex-encoded data frames:
>
Sounds like wireless M-Bus. The data is manchester encoded but I think
> I couldn't come up with a working flex spec in rtl_433. My guess is
> that this is maybe a wireless M-Bus signal and probably beyond the
> current scope of rtl_433.
>
> Using Universal Radio Hacker I can pull the data, though. Signals are
> FSK modulated. Bit length of 12 samples, error tolerance of 1, ignoring
> the repeating "0101" sync symbols before what appears to be "00001111"
> to start the data, here's the hex-encoded data frames:
>
we need to fix the demodulator to handle the 000111 sync code. We'll get
there eventually. As always good samples are welcome.
MvH
Benjamin Larsson
Simon Eigeldinger
Feb 27, 2019, 11:30:45 AM2/27/19
to rtl...@googlegroups.com
Hi Benjamin and all,
We also have a bunch of those Diehl Izar water meters over here.
If someone needs samples of that i could get some.
though i can't read the display of the meter.
Greetings,
Simon
---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus
We also have a bunch of those Diehl Izar water meters over here.
If someone needs samples of that i could get some.
though i can't read the display of the meter.
Greetings,
Simon
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus
Simon Eigeldinger
Feb 27, 2019, 12:08:40 PM2/27/19
to rtl...@googlegroups.com
Hi all,
I just ran
rtl_433 -f 868950000 -s 1200000 -A -a -S unknown
And i got flooded with a lot of data.
I just was running that for 3-4 minutes and i got nearly 300 samples.
https://www.dropbox.com/s/90hm35r4y8war17/m-bus%20mode%20c%20and%20t.7z?dl=1
Seems there is some action over here on 868 mhz :-).
The analyzed data is also available in the 7z file.
We also have some Diehl Izar water meters around and i guess some other
m-bus systems as well.
But i don't know them yet.
So if someone wants to play with the samples, here they are.
Greetings,
Simon
Am 26.02.2019 um 21:08 schrieb rVs:
> My house has a new water counter : DIEHL IZAR RC 868 iG4
>
> Reading the user guide
>
> https://www.meterbuy.com/fileadmin/user_upload/Data_sheets/150922_-_Guide_utilisateur_IZAR_RC_868_i_G4__05_2015_GB_FR_01.pdf
>
> "Emitting information:
> - Every 12 seconds in R3 mode - OMS protocol for the index and alarms.
> Detailed information regarding leaks and historic of consumptions are
> transmitted every 6 sendings.
> - Every 15 minutes in R4 long-range network mode."
>
> I cant't manage to get the sent informations with rtl_433.
>
> I put a few capture in the attached zip file with this state
>
>
I just ran
rtl_433 -f 868950000 -s 1200000 -A -a -S unknown
And i got flooded with a lot of data.
I just was running that for 3-4 minutes and i got nearly 300 samples.
https://www.dropbox.com/s/90hm35r4y8war17/m-bus%20mode%20c%20and%20t.7z?dl=1
Seems there is some action over here on 868 mhz :-).
The analyzed data is also available in the 7z file.
We also have some Diehl Izar water meters around and i guess some other
m-bus systems as well.
But i don't know them yet.
So if someone wants to play with the samples, here they are.
Greetings,
Simon
Am 26.02.2019 um 21:08 schrieb rVs:
> My house has a new water counter : DIEHL IZAR RC 868 iG4
>
> Reading the user guide
>
> https://www.meterbuy.com/fileadmin/user_upload/Data_sheets/150922_-_Guide_utilisateur_IZAR_RC_868_i_G4__05_2015_GB_FR_01.pdf
>
> "Emitting information:
> - Every 12 seconds in R3 mode - OMS protocol for the index and alarms.
> Detailed information regarding leaks and historic of consumptions are
> transmitted every 6 sendings.
> - Every 15 minutes in R4 long-range network mode."
>
> I cant't manage to get the sent informations with rtl_433.
>
> I put a few capture in the attached zip file with this state
>
>
> Can someone help me to decode this device ?
>
> Thanks.
>
>
>
>
>
>
> Thanks.
>
>
>
>
>
rVs
Feb 27, 2019, 1:22:00 PM2/27/19
to rtl_433
Thanks for your interest.
I've tried rtlamr, but did I do something wrong or ?
/root/go/bin/rtlamr --centerfreq=868950000 -samplerate=1200000 -msgtype=all -server=127.0.0.1:1234
19:02:22.918999 decode.go:45: CenterFreq: 912380000
19:02:22.919407 decode.go:46: SampleRate: 2359296
19:02:22.919474 decode.go:47: DataRate: 32768
19:02:22.919525 decode.go:48: ChipLength: 72
19:02:22.919579 decode.go:49: PreambleSymbols: 32
19:02:22.919633 decode.go:50: PreambleLength: 4608
19:02:22.919685 decode.go:51: PacketSymbols: 736
19:02:22.919738 decode.go:52: PacketLength: 105984
19:02:22.919813 decode.go:59: Protocols: scm,scm+,idm,r900
19:02:22.919899 decode.go:60: Preambles: 111110010101001100000,0001011010100011,01010101010101010001011010100011,00000000000000001110010101100100
19:02:22.919982 main.go:114: GainCount: 29
19:02:22.918999 decode.go:45: CenterFreq: 912380000
19:02:22.919407 decode.go:46: SampleRate: 2359296
19:02:22.919474 decode.go:47: DataRate: 32768
19:02:22.919525 decode.go:48: ChipLength: 72
19:02:22.919579 decode.go:49: PreambleSymbols: 32
19:02:22.919633 decode.go:50: PreambleLength: 4608
19:02:22.919685 decode.go:51: PacketSymbols: 736
19:02:22.919738 decode.go:52: PacketLength: 105984
19:02:22.919813 decode.go:59: Protocols: scm,scm+,idm,r900
19:02:22.919899 decode.go:60: Preambles: 111110010101001100000,0001011010100011,01010101010101010001011010100011,00000000000000001110010101100100
19:02:22.919982 main.go:114: GainCount: 29
No other output.
Meanwhile, in rtl_tcp window :
ll+, now 501
ll+, now 502
ll-, now 0
ll+, now 1
ll+, now 2
ll+, now 3
ll+, now 4
ll+, now 5
ll+, now 6
ll+, now 7
ll+, now 8
ll+, now 9
ll+, now 10
ll+, now 11
ll+, now 12
ll+, now 13
ll+, now 14
ll+, now 15
ll+, now 16
ll+, now 17
ll+, now 502
ll-, now 0
ll+, now 1
ll+, now 2
ll+, now 3
ll+, now 4
ll+, now 5
ll+, now 6
ll+, now 7
ll+, now 8
ll+, now 9
ll+, now 10
ll+, now 11
ll+, now 12
ll+, now 13
ll+, now 14
ll+, now 15
ll+, now 16
ll+, now 17
Best regards.
Karl Lohner
Feb 27, 2019, 2:28:12 PM2/27/19
to rVs, rtl_433
On Wed, Feb 27, 2019 at 1:22 PM rVs wrote:
> I've tried rtlamr, but did I do something wrong or ?
I think for questions regarding rtlamr, you'd need to contact the maintainers of that project. This mailing list specific for for rtl_433.
On Wed, Feb 27, 2019 at 12:08 PM Simon Eigeldinger wrote:
> I just ran
> rtl_433 -f 868950000 -s 1200000 -A -a -S unknown
>And i got flooded with a lot of data.
I took a look at a couple of these IQ files. They seem to be in a similar modulation and data encoding as what was submitted at the beginning of this thread.
On Wed, Feb 27, 2019 at 4:06 AM Benjamin Larsson wrote:
> Sounds like wireless M-Bus. The data is manchester encoded but I think
> we need to fix the demodulator to handle the 000111 sync code.
Looking at these messages a bit more, it seems they're using "3 out of 6" encoding (not Manchester).
After a sync/prefix of "010000111101" look at 6 symbols at a time. Here's what may be the mapping:
010110 => 0
001101 => 1
001110 => 2
001011 => 3
011100 => 4
011001 => 5
011010 => 6
010011 => 7
101100 => 8
100101 => 9
100110 => A
100011 => B
110100 => C
110001 => D
110010 => E
101001 => F
(I found this mapping here: https://github.com/heliflieger/a-culfw/blob/master/culfw/clib/mbus/3outof6.c)
For example, looking at the g001 IQ file from the first message in this thread:
g001: 0f4dc9c72664d34b69639c5ac2d38d64e5a596539a595658d59664b8ce4e3c63a5ca7199964ed326593a62ec6b45a38d98f459c9b43a6c9c72b8
Convert this to binary and chunk up into 6 bit groupings:
Binary Symbols 3of6 HEX
------------------------------------------------------- --------
[01]0000 111101 XX
001101 110010 011100 011100 100110 011001 001101 001101 1e44a511
001011 011010 010110 001110 011100 010110 101100 001011 36024083
010011 100011 010110 010011 100101 101001 011001 011001 7b079f55
010011 100110 100101 100101 010110 010110 001101 010110 7a990010
010110 011001 001011 100011 001110 010011 100011 110001 053b27bd
100011 101001 011100 101001 110001 100110 011001 011001 bf4fda55
001110 110100 110010 011001 011001 001110 100110 001011 2ce552a3
101100 011010 110100 010110 100011 100011 011001 100011 86c0bb5b
110100 010110 011100 100110 110100 001110 100110 110010 c04ac2ae
011100 011100 101011 100000 44XX
I was expecting to find "C18FA756573" in this data, as that is what is apparently the device ID as per the photo in the first message in this thread, but I don't see it...
--Karl.
Robert Bradley
Feb 27, 2019, 2:59:56 PM2/27/19
to rtl_433
Does this help - this was the data I got in Jan
nohup rtl_sdr -f 868.95M -s 1600000 - 2>/dev/null | rtl-wmbus/build/rtl_wmbus > watercapture2 &
And I get
T1;1;1;2019-01-04 21:16:33.000;27;43;A104949E;0x1944304c9e9404a1b201a2411c00137ea431d71c07cf1a6a8f0a
T1;1;1;2019-01-04 21:16:42.000;23;41;A104949E;0x1944304c9e9404a1b201a2511c00137eb31e9eb7261cc3b19608
T1;1;1;2019-01-04 21:16:50.000;28;34;A104949E;0x1944304c9e9404a1b201a2611c00137e8a6f444a4468a9dcbd0f
T1;1;1;2019-01-04 21:16:59.000;21;39;A104949E;0x1944304c9e9404a1b201a2711c00137e9d400de165bb7007a40d
T1;1;1;2019-01-04 21:17:07.000;31;50;A104949E;0x1944304c9e9404a1b201a2011c00137ef88cf1b080807d06eb00
T1;1;1;2019-01-04 21:17:17.000;29;48;A104949E;0x1944304c9e9404a1b201a2111c00137eefa3b81ba153a4ddf202
T1;1;1;2019-01-04 21:17:25.000;24;52;A104949E;0x1944304c9e9404a1b201a2211c00137ed6d262e6c327ceb0d905
T1;1;1;2019-01-04 21:17:33.000;28;50;A104949E;0x1944304c9e9404a1b201a2311c00137ec1fd2b4de2f4176bc007
T1;1;1;2019-01-04 21:17:42.000;29;35;A104949E;0x1944304c9e9404a1b201a2411c00137ea431d71c07cf1a6a8f0a
T1;1;1;2019-01-04 21:17:51.000;28;41;A104949E;0x1944304c9e9404a1b201a2511c00137eb31e9eb7261cc3b19608
T1;1;1;2019-01-04 21:17:59.000;22;35;A104949E;0x1944304c9e9404a1b201a2611c00137e8a6f444a4468a9dcbd0f
T1;1;1;2019-01-04 21:18:08.000;25;39;A104949E;0x1944304c9e9404a1b201a2711c00137e9d400de165bb7007a40d
T1;1;1;2019-01-04 21:18:16.000;27;53;A104949E;0x1944304c9e9404a1b201a2011c00137ef88cf1b080807d06eb00
T1;1;1;2019-01-04 21:18:26.000;27;51;A104949E;0x1944304c9e9404a1b201a2111c00137eefa3b81ba153a4ddf202
T1;1;1;2019-01-04 21:18:34.000;28;43;A104949E;0x1944304c9e9404a1b201a2211c00137ed6d262e6c327ceb0d905
T1;1;1;2019-01-04 21:18:42.000;24;45;A104949E;0x1944304c9e9404a1b201a2311c00137ec1fd2b4de2f4176bc007
T1;1;1;2019-01-04 21:18:51.000;20;32;A104949E;0x1944304c9e9404a1b201a2411c00137ea431d71c07cf1a6a8f0a
T1;1;1;2019-01-04 21:19:00.000;24;35;A104949E;0x1944304c9e9404a1b201a2511c00137eb31e9eb7261cc3b19608
T1;1;1;2019-01-04 21:19:08.000;30;35;A104949E;0x1944304c9e9404a1b201a2611c00137e8a6f444a4468a9dcbd0f
T1;1;1;2019-01-04 21:19:17.000;24;40;A104949E;0x1944304c9e9404a1b201a2711c00137e9d400de165bb7007a40d
T1;1;1;2019-01-04 21:19:25.000;26;50;A104949E;0x1944304c9e9404a1b201a2011c00137ef88cf1b080807d06eb00
T1;1;1;2019-01-04 21:19:34.000;25;45;A104949E;0x1944304c9e9404a1b201a2111c00137eefa3b81ba153a4ddf202
T1;1;1;2019-01-04 21:19:43.000;23;43;A104949E;0x1944304c9e9404a1b201a2211c00137ed6d262e6c327ceb0d905
T1;1;1;2019-01-04 21:19:51.000;32;48;A104949E;0x1944304c9e9404a1b201a2311c00137ec1fd2b4de2f4176bc007
T1;1;1;2019-01-04 21:20:00.000;35;32;A104949E;0x1944304c9e9404a1b201a2411c00137ea431d71c07cf1a6a8f0a
Columns : Type, crc_ok, 3_out_of_6_ok, time, rssi_after_sync, rssi_on_last_bit, raw_datagram.
Reply all
Reply to author
Forward
0 new messages