Rtl_433: Add support for SCM+

[stevenjev]

I notice that support for SCM was added #977 . However, I was also wondering if support for SCM+ could be added. Based on information from the rtlamr project, I believe that decoding SCM+ should be fairly similar to SCM as SCM+ is "Similar to SCM, allows greater precision and longer meter ID's."

The rtlamr project's scm+ decoding is available here: https://github.com/bemasher/rtlamr/tree/master/scmplus

I apologize, as this entire field is very new to me. I am trying to provide outputs of the signals captured, but while I am able to see the scm+ signals in rtlamr, I am having difficulty at the moment capturing the scm+ signals in rtl_433.

[merbanan]

We need samples, motivation and time to be able to add support for any type of protocol. Try playing around with the gain and frequency when you record the signals.

[stevenjev]

When I run rtlamr, default flags, decoding for scm and scm+, multiple signals are found/decoded quite frequently: https://pastebin.com/0eKt19g9

If I run: rtl_433 -f 912600155 -s 2359296 -S unknown (so what I believe are the same frequency and sample rate), I get these sample files: samples.zip

[phrrngtn]

Saved sample file of scmplus messages. It looks like rtlamr is just saving the blocks that it has detected messages in. I had previously thought it was saving all the samples but on looking at the file sizes and offsets a bit more closely, it seems that this is not the case.

https://www.dropbox.com/s/36fqt7s8sh1jzqf/scmplus.cu8?dl=0

phrrngtn@sdrpi:~ $ /home/pi/go/bin/rtlamr -samplefile=scmplus.cu8 -server=127.0.0.1:1234   -msgtype=scm+
17:46:15.919703 decode.go:45: CenterFreq: 912600155
17:46:15.920352 decode.go:46: SampleRate: 2359296
17:46:15.920400 decode.go:47: DataRate: 32768
17:46:15.920435 decode.go:48: ChipLength: 72
17:46:15.920515 decode.go:49: PreambleSymbols: 16
17:46:15.920553 decode.go:50: PreambleLength: 2304
17:46:15.920586 decode.go:51: PacketSymbols: 128
17:46:15.920619 decode.go:52: PacketLength: 18432
17:46:15.920658 decode.go:59: Protocols: scm+
17:46:15.920691 decode.go:60: Preambles: 0001011010100011
17:46:15.920723 main.go:119: GainCount: 29
{Time:2020-05-18T17:46:54.723 Offset:0 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0x07 EndpointID:1550406067 Consumption:   7962937 Tamper:0x0001 PacketCRC:0xBD54}}

[phrrngtn]

Here is the link to the IDM samples
https://www.dropbox.com/s/mnyyhbhydb8bs71/idm.cu8?dl=0

Here is the output of the program with the decoded messages

phrrngtn@sdrpi:~ $ /home/pi/go/bin/rtlamr -samplefile=idm.cu8 -server=127.0.0.1:1234   -msgtype=idm
17:48:48.531338 decode.go:45: CenterFreq: 912600155
17:48:48.532195 decode.go:46: SampleRate: 2359296
17:48:48.532305 decode.go:47: DataRate: 32768
17:48:48.532530 decode.go:48: ChipLength: 72
17:48:48.532657 decode.go:49: PreambleSymbols: 32
17:48:48.532751 decode.go:50: PreambleLength: 4608
17:48:48.532841 decode.go:51: PacketSymbols: 736
17:48:48.532949 decode.go:52: PacketLength: 105984
17:48:48.533046 decode.go:59: Protocols: idm
17:48:48.533220 decode.go:60: Preambles: 01010101010101010001011010100011
17:48:48.533541 main.go:119: GainCount: 29
{Time:2020-05-18T17:48:51.908 Offset:0 Length:229376 IDM:{Preamble:0x555516A3 PacketTypeID:0x1C PacketLength:0x5C HammingCode:0xC6 ApplicationVersion:0x04 ERTType:0x07 ERTSerialNumber: 1550406067 ConsumptionIntervalCount:128 ModuleProgrammingState:0xB8 TamperCounters:0005000E0100 AsynchronousCounters:0x00 PowerOutageFlags:000000080000 LastConsumptionCount:7962940 DifferentialConsumptionIntervals:[5 5 5 10 10 11 11 9 5 5 6 6 5
6 6 6 6 6 4 5 4 5 4 5 5 5 11 10 11 11 12 19 12 6 5 6 5 5 5 6 5 5 5 5 5 5 5] TransmitTimeOffset:1475 SerialNumberCRC:0xEEFA PacketCRC:0x5529}}
{Time:2020-05-18T17:49:03.134 Offset:229376 Length:229376 IDM:{Preamble:0x555516A3 PacketTypeID:0x1C PacketLength:0x5C HammingCode:0xC6 ApplicationVersion:0x04 ERTType:0x07 ERTSerialNumber:  11278109 ConsumptionIntervalCount:166 ModuleProgrammingState:0xBC TamperCounters:82019C2F2920 AsynchronousCounters:0x00 PowerOutageFlags:4042CA040101 LastConsumptionCount:338771 DifferentialConsumptionIntervals:[0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0] TransmitTimeOffset:4194 SerialNumberCRC:0xEABA PacketCRC:0xF689}}
{Time:2020-05-18T17:49:54.068 Offset:458752 Length:229376 IDM:{Preamble:0x555516A3 PacketTypeID:0x1C PacketLength:0x5C HammingCode:0xC6 ApplicationVersion:0x04 ERTType:0x07 ERTSerialNumber: 1550406067 ConsumptionIntervalCount:129 ModuleProgrammingState:0xB8 TamperCounters:0005204E0101 AsynchronousCounters:0x00 PowerOutageFlags:009020000000 LastConsumptionCount:7962944 DifferentialConsumptionIntervals:[4 5 5 5 10 10 11 11 9 5 5 6 6 5 6 6 6 6 6 4 5 4 5 4 5 5 5 11 10 11 11 12 19 12 6 5 6 5 5 5 6 5 5 5 5 5 5] TransmitTimeOffset:70 SerialNumberCRC:0xEEFA PacketCRC:0xF1D7}}
^C17:49:55.613262 main.go:332: read tcp 127.0.0.1:38634->127.0.0.1:1234: use of closed network connection

[evilpete]

I'll take a peek at it for ya

[evilpete]

OK, I got a test code working for SCM+ and idm, i can use some samples along with expected field values to validate the code. ( I am testing using the samples.zip that was posted above )

Note: my meter does not do SCM, thus require samples

[phrrngtn]

I think an easy way of generating cu8 samples and decoded output is to run rtlamr for a minute or two with invocations like this:
-samplefile=idm.cu8 -msgtype=idm
-samplefile=scm+.cu8 and -msgtype=scm+

It seems like the samples that are saved by rtlamr are just the ones from which it has successfully decoded a message.

[evilpete]

@stevenjev can you generate more samples, All the samples in the zip are of the same packet data and I need different data to validate.

[stevenjev]

Sorry! Yes I can generate. Here are samples from rtlamr for SCM+:
scmplus.cu8.zip

I don't believe there are any IDM signals around for me to capture but I will check. (Edit: No IDM signals around me)

09:57:23.568358 decode.go:45: CenterFreq: 912600155
09:57:23.568527 decode.go:46: SampleRate: 2359296
09:57:23.568539 decode.go:47: DataRate: 32768
09:57:23.568549 decode.go:48: ChipLength: 72
09:57:23.568558 decode.go:49: PreambleSymbols: 16
09:57:23.568568 decode.go:50: PreambleLength: 2304
09:57:23.568577 decode.go:51: PacketSymbols: 128
09:57:23.568586 decode.go:52: PacketLength: 18432
09:57:23.568607 decode.go:59: Protocols: scm+
09:57:23.568617 decode.go:60: Preambles: 0001011010100011
09:57:23.568627 main.go:119: GainCount: 29
{Time:2020-06-20T09:57:49.407 Offset:0 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68193659 Consumption:      3965 Tamper:0x4900 PacketCRC:0xC6E7}}
{Time:2020-06-20T09:58:19.074 Offset:49152 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68211547 Consumption:      6883 Tamper:0x4900 PacketCRC:0x39BE}}
{Time:2020-06-20T09:58:49.574 Offset:98304 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68211547 Consumption:      6883 Tamper:0x4900 PacketCRC:0x39BE}}
{Time:2020-06-20T09:58:58.407 Offset:147456 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68193659 Consumption:      3965 Tamper:0x4900 PacketCRC:0xC6E7}}
{Time:2020-06-20T09:58:59.074 Offset:196608 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68211547 Consumption:      6883 Tamper:0x4900 PacketCRC:0x39BE}}
{Time:2020-06-20T09:59:18.407 Offset:245760 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68193659 Consumption:      3965 Tamper:0x4900 PacketCRC:0xC6E7}}
{Time:2020-06-20T09:59:19.074 Offset:294912 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68211547 Consumption:      6883 Tamper:0x4900 PacketCRC:0x39BE}}
{Time:2020-06-20T09:59:28.574 Offset:344064 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68211547 Consumption:      6883 Tamper:0x4900 PacketCRC:0x39BE}}
{Time:2020-06-20T09:59:38.407 Offset:393216 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68193659 Consumption:      3965 Tamper:0x4900 PacketCRC:0xC6E7}}
{Time:2020-06-20T09:59:49.074 Offset:442368 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68211547 Consumption:      6883 Tamper:0x4900 PacketCRC:0x39BE}}

[evilpete]

See pull request #1410

[evilpete]

@stevenjev

I just noted the sample file you just shared had the same data as the samples posted on May 14th

{"time" : "@0.045207s", "model" : "SCM+", "protocol_id" : "0x1E", "endpoint_type" : "0xAB", "endpoint_id" : 68211547, "consumption_data" : 6883, "physical_tamper" : "0x4900", "mic" : "CRC"}

If you can send samples from a different endpoint or with a different consumption_data value it would help.

[stevenjev]

Here are samples, both with different consumption values from previously. I will see if I run longer if I am able to pick up a third endpoint: scmplus_two.cu8.zip

19:26:26.619985 decode.go:45: CenterFreq: 912600155
19:26:26.620112 decode.go:46: SampleRate: 2359296
19:26:26.620120 decode.go:47: DataRate: 32768
19:26:26.620125 decode.go:48: ChipLength: 72
19:26:26.620132 decode.go:49: PreambleSymbols: 16
19:26:26.620153 decode.go:50: PreambleLength: 2304
19:26:26.620169 decode.go:51: PacketSymbols: 128
19:26:26.620174 decode.go:52: PacketLength: 18432
19:26:26.620181 decode.go:59: Protocols: scm+
19:26:26.620186 decode.go:60: Preambles: 0001011010100011
19:26:26.620193 main.go:119: GainCount: 29
{Time:2020-06-20T19:26:29.867 Offset:0 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68211547 Consumption:      6886 Tamper:0x4900 PacketCRC:0xD24E}}
{Time:2020-06-20T19:27:19.367 Offset:49152 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68211547 Consumption:      6886 Tamper:0x4900 PacketCRC:0xD24E}}
{Time:2020-06-20T19:27:30.035 Offset:98304 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68193659 Consumption:      3977 Tamper:0x4900 PacketCRC:0xF975}}
{Time:2020-06-20T19:27:39.369 Offset:147456 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68211547 Consumption:      6886 Tamper:0x4900 PacketCRC:0xD24E}}
{Time:2020-06-20T19:27:49.869 Offset:196608 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68211547 Consumption:      6886 Tamper:0x4900 PacketCRC:0xD24E}}
{Time:2020-06-20T19:27:59.369 Offset:245760 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68211547 Consumption:      6886 Tamper:0x4900 PacketCRC:0xD24E}}
{Time:2020-06-20T19:28:09.035 Offset:294912 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68193659 Consumption:      3977 Tamper:0x4900 PacketCRC:0xF975}}

[evilpete]

a quick test from scmplus_two.cu8 gave:

{"model" : "SCM+", "protocol_id" : "0x1E", "endpoint_type" : "0xAB", 
"endpoint_id" : 68211547, "consumption_data" : 6886, "physical_tamper" : "0x4900", "mic" : "CRC"}

EndpointID: 68193659 is not in the sample. but since the Consumption & CRC differ from before can use it to validate :-)

i'll take a closer look tonight (my 12y son is getting annoyed i'm "typing to much" )

[stevenjev]

No worries! (And obviously no rush) Appreciate you taking a look at this. I ran it for a while and am just getting those two endpoints: scmplus_three.cu8.zip

19:30:00.945044 decode.go:45: CenterFreq: 912600155
19:30:00.945157 decode.go:46: SampleRate: 2359296
19:30:00.945168 decode.go:47: DataRate: 32768
19:30:00.945175 decode.go:48: ChipLength: 72
19:30:00.945180 decode.go:49: PreambleSymbols: 16
19:30:00.945185 decode.go:50: PreambleLength: 2304
19:30:00.945190 decode.go:51: PacketSymbols: 128
19:30:00.945195 decode.go:52: PacketLength: 18432
19:30:00.945201 decode.go:59: Protocols: scm+
19:30:00.945206 decode.go:60: Preambles: 0001011010100011
19:30:00.945211 main.go:119: GainCount: 29
{Time:2020-06-20T19:30:09.395 Offset:0 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68211547 Consumption:      6886 Tamper:0x4900 PacketCRC:0xD24E}}
{Time:2020-06-20T19:30:09.507 Offset:49152 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68193659 Consumption:      3977 Tamper:0x4900 PacketCRC:0xF975}}
{Time:2020-06-20T19:30:29.007 Offset:98304 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68193659 Consumption:      3977 Tamper:0x4900 PacketCRC:0xF975}}
{Time:2020-06-20T19:30:29.395 Offset:147456 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68211547 Consumption:      6886 Tamper:0x4900 PacketCRC:0xD24E}}
{Time:2020-06-20T19:31:00.395 Offset:196608 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68211547 Consumption:      6886 Tamper:0x4900 PacketCRC:0xD24E}}
{Time:2020-06-20T19:31:09.007 Offset:245760 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68193659 Consumption:      3977 Tamper:0x4900 PacketCRC:0xF975}}
{Time:2020-06-20T19:31:37.895 Offset:294912 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68192588 Consumption:      6383 Tamper:0x4900 PacketCRC:0xD590}}
{Time:2020-06-20T19:31:49.507 Offset:344064 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68193659 Consumption:      3977 Tamper:0x4900 PacketCRC:0xF975}}
{Time:2020-06-20T19:32:50.010 Offset:393216 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68193659 Consumption:      3977 Tamper:0x4900 PacketCRC:0xF975}}
{Time:2020-06-20T19:33:19.898 Offset:442368 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68211547 Consumption:      6886 Tamper:0x4900 PacketCRC:0xD24E}}
{Time:2020-06-20T19:33:50.397 Offset:491520 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68211547 Consumption:      6886 Tamper:0x4900 PacketCRC:0xD24E}}
{Time:2020-06-20T19:33:59.010 Offset:540672 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68193659 Consumption:      3977 Tamper:0x4900 PacketCRC:0xF975}}
{Time:2020-06-20T19:33:59.898 Offset:589824 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68211547 Consumption:      6886 Tamper:0x4900 PacketCRC:0xD24E}}
{Time:2020-06-20T19:34:19.010 Offset:638976 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68193659 Consumption:      3977 Tamper:0x4900 PacketCRC:0xF975}}
{Time:2020-06-20T19:34:19.898 Offset:688128 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68211547 Consumption:      6886 Tamper:0x4900 PacketCRC:0xD24E}}
{Time:2020-06-20T19:34:29.398 Offset:737280 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68211547 Consumption:      6886 Tamper:0x4900 PacketCRC:0xD24E}}
{Time:2020-06-20T19:34:39.010 Offset:786432 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68193659 Consumption:      3977 Tamper:0x4900 PacketCRC:0xF975}}
{Time:2020-06-20T19:34:49.898 Offset:835584 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68211547 Consumption:      6886 Tamper:0x4900 PacketCRC:0xD24E}}
{Time:2020-06-20T19:35:39.399 Offset:884736 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68211547 Consumption:      6886 Tamper:0x4900 PacketCRC:0xD24E}}
{Time:2020-06-20T19:35:50.010 Offset:933888 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68193659 Consumption:      3977 Tamper:0x4900 PacketCRC:0xF975}}
{Time:2020-06-20T19:35:59.399 Offset:983040 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68211547 Consumption:      6886 Tamper:0x4900 PacketCRC:0xD24E}}
{Time:2020-06-20T19:36:09.899 Offset:1032192 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68211547 Consumption:      6886 Tamper:0x4900 PacketCRC:0xD24E}}
{Time:2020-06-20T19:36:19.399 Offset:1081344 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68211547 Consumption:      6886 Tamper:0x4900 PacketCRC:0xD24E}}
{Time:2020-06-20T19:36:29.011 Offset:1130496 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68193659 Consumption:      3977 Tamper:0x4900 PacketCRC:0xF975}}
{Time:2020-06-20T19:37:07.899 Offset:1179648 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68192588 Consumption:      6383 Tamper:0x4900 PacketCRC:0xD590}}
{Time:2020-06-20T19:37:09.012 Offset:1228800 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68193659 Consumption:      3977 Tamper:0x4900 PacketCRC:0xF975}}
{Time:2020-06-20T19:37:20.400 Offset:1277952 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68211547 Consumption:      6886 Tamper:0x4900 PacketCRC:0xD24E}}
{Time:2020-06-20T19:38:29.400 Offset:1327104 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68211547 Consumption:      6886 Tamper:0x4900 PacketCRC:0xD24E}}
{Time:2020-06-20T19:38:29.512 Offset:1376256 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68193659 Consumption:      3977 Tamper:0x4900 PacketCRC:0xF975}}
{Time:2020-06-20T19:38:49.012 Offset:1425408 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68193659 Consumption:      3977 Tamper:0x4900 PacketCRC:0xF975}}
{Time:2020-06-20T19:38:49.400 Offset:1474560 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68211547 Consumption:      6886 Tamper:0x4900 PacketCRC:0xD24E}}
{Time:2020-06-20T19:39:17.900 Offset:1523712 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68192588 Consumption:      6383 Tamper:0x4900 PacketCRC:0xD590}}
{Time:2020-06-20T19:39:20.400 Offset:1572864 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68211547 Consumption:      6886 Tamper:0x4900 PacketCRC:0xD24E}}
{Time:2020-06-20T19:39:29.012 Offset:1622016 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68193659 Consumption:      3977 Tamper:0x4900 PacketCRC:0xF975}}
{Time:2020-06-20T19:40:09.512 Offset:1671168 Length:49152 SCM+:{ProtocolID:0x1E EndpointType:0xAB EndpointID:  68193659 Consumption:      3977 Tamper:0x4900 PacketCRC:0xF975}}

No sure why that endpoint is not in the sample. Hopefully it is in this latest one. Let me know if there's anything else you need! I can always find a reason to run my tap for a bit to get another consumption value haha

[evilpete]

_(my kid is distracted with mindcraft)_

Humm... still just endpoint_id: 68211547

I can "see" there are are 14 data bursts with 12 readable so there is EndpointID filtering going on somewhere

Registered 1 out of 154 device decoding protocols [ 154 ]
Test mode active. Reading samples from file: samples3/scmplus_three.cu8

{"time" : "@0.001018s", "model" : "SCM+", "ProtocolID" : "0x1E", "EndpointType" : "0xAB", "EndpointID" : 68211547, "Consumption" : 6886, "Tamper" : "0x4900", "PacketCRC" : "0xD24E", "MeterType" : "Water", "mic" : "CRC"}
{"time" : "@0.032136s", "model" : "SCM+", "ProtocolID" : "0x1E", "EndpointType" : "0xAB", "EndpointID" : 68211547, "Consumption" : 6886, "Tamper" : "0x4900", "PacketCRC" : "0xD24E", "MeterType" : "Water", "mic" : "CRC"}
{"time" : "@0.096084s", "model" : "SCM+", "ProtocolID" : "0x1E", "EndpointType" : "0xAB", "EndpointID" : 68211547, "Consumption" : 6886, "Tamper" : "0x4900", "PacketCRC" : "0xD24E", "MeterType" : "Water", "mic" : "CRC"}
{"time" : "@0.126554s", "model" : "SCM+", "ProtocolID" : "0x1E", "EndpointType" : "0xAB", "EndpointID" : 68211547, "Consumption" : 6886, "Tamper" : "0x4900", "PacketCRC" : "0xD24E", "MeterType" : "Water", "mic" : "CRC"}
{"time" : "@0.147310s", "model" : "SCM+", "ProtocolID" : "0x1E", "EndpointType" : "0xAB", "EndpointID" : 68211547, "Consumption" : 6886, "Tamper" : "0x4900", "PacketCRC" : "0xD24E", "MeterType" : "Water", "mic" : "CRC"}
{"time" : "@0.147310s", "model" : "SCM+", "ProtocolID" : "0x1E", "EndpointType" : "0xAB", "EndpointID" : 68211547, "Consumption" : 6886, "Tamper" : "0x4900", "PacketCRC" : "0xD24E", "MeterType" : "Water", "mic" : "CRC"}
{"time" : "@0.179334s", "model" : "SCM+", "ProtocolID" : "0x1E", "EndpointType" : "0xAB", "EndpointID" : 68211547, "Consumption" : 6886, "Tamper" : "0x4900", "PacketCRC" : "0xD24E", "MeterType" : "Water", "mic" : "CRC"}
{"time" : "@0.179334s", "model" : "SCM+", "ProtocolID" : "0x1E", "EndpointType" : "0xAB", "EndpointID" : 68211547, "Consumption" : 6886, "Tamper" : "0x4900", "PacketCRC" : "0xD24E", "MeterType" : "Water", "mic" : "CRC"}
{"time" : "@0.209991s", "model" : "SCM+", "ProtocolID" : "0x1E", "EndpointType" : "0xAB", "EndpointID" : 68211547, "Consumption" : 6886, "Tamper" : "0x4900", "PacketCRC" : "0xD24E", "MeterType" : "Water", "mic" : "CRC"}
{"time" : "@0.209991s", "model" : "SCM+", "ProtocolID" : "0x1E", "EndpointType" : "0xAB", "EndpointID" : 68211547, "Consumption" : 6886, "Tamper" : "0x4900", "PacketCRC" : "0xD24E", "MeterType" : "Water", "mic" : "CRC"}
{"time" : "@0.209991s", "model" : "SCM+", "ProtocolID" : "0x1E", "EndpointType" : "0xAB", "EndpointID" : 68211547, "Consumption" : 6886, "Tamper" : "0x4900", "PacketCRC" : "0xD24E", "MeterType" : "Water", "mic" : "CRC"}
{"time" : "@0.272885s", "model" : "SCM+", "ProtocolID" : "0x1E", "EndpointType" : "0xAB", "EndpointID" : 68211547, "Consumption" : 6886, "Tamper" : "0x4900", "PacketCRC" : "0xD24E", "MeterType" : "Water", "mic" : "CRC"}
{"time" : "@0.313310s", "model" : "SCM+", "ProtocolID" : "0x1E", "EndpointType" : "0xAB", "EndpointID" : 68211547, "Consumption" : 6886, "Tamper" : "0x4900", "PacketCRC" : "0xD24E", "MeterType" : "Water", "mic" : "CRC"}

[stevenjev]

Hmm.. I wonder if this has any relation to issues discussed in #1386

[evilpete]

@stevenjev
No, all the packets in the PauseView screen shot are accounted for but two weaker ones

[evilpete]

@stevenjev if you want to test out the decoder you can grab it from my fork's scmplus brach given it may take some time before the pull request is merged.

Plus it it would be a good idea to test it on live data before the merge also.

[Also If you get some IDM data samples I may be able to crank out a decoder for that also given the protocol simplicity and existing documentation]

[stevenjev]

@evilpete Good idea, I just built and tested. No problem detecting the meter with the Endpoint ID: 68211547:

time      : 2020-06-22 22:51:14
model     : SCM+         Protocol_ID: 0x1E         Endpoint_Type: 0xAB       Endpoint_ID: 68211547     Consumption: 6896         Tamper    : 0x4900        crc       : 0x238D        Meter_Type: Water         Integrity : CRC

This also happens to be my meter, which is about 30 feet away from my antenna. The other endpoint ID: 68193659 must be my neighbors and is not strong enough (I'm guessing) to pick up (using rlt_433, instead of rtlamr). Thanks again for working on this, very appreciated!

Edit: Unfortunately after running for a day, I still have not picked up and IDM signals to provide. Sorry!

[evilpete]

I have a IDM decoder 90% written, but do plan to submit it till I have more then one sample to validate with.

[stevenjev]

@evilpete Unfortunately I won’t be able to provide the IDM signals. I also see that your SCM+ decoder was merged. That’s great! I’m thinking I should close this issue as it originally pertained to SCM+ and maybe a separate issue for IDM could be opened in an attempt to gather signals to test?

[evilpete]

@phrrngtn would you mind posting more idm iq data samples ?

[phrrngtn]

Sure. Here is one from a while back https://www.dropbox.com/s/mnyyhbhydb8bs71/idm.cu8?dl=0
I am not sure how many are in there. I will fire up another instance of rtlamr later on this morning and post the samples and the decodes.

[phrrngtn]

Here you go: 39 samples over a period of an hour or so. I generated it with rtlamr arguments including -unique=true -samplefile=/home/phrrngtn/idm_samples_20200625.cu8 -format=json -msgtype=idm,netidm but on a Pi in my basement as opposed to a PC in my home office. I can pick up way more signals up here but I could not get rtl_tcp to work (turns out that something must be blocking it on windows from default port 1234 as I was able to get it to work by using a different port number). In any case, I can generate plenty more if you need them. I can also git add your repo and build and run stuff on the pi.

https://www.dropbox.com/s/ttkz61fh6jxpfvv/idm_20200625.zip?dl=0

unzip -l idm_20200625.zip
Archive:  idm_20200625.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
  8945664  2020-06-25 08:48   idm_samples_20200625.cu8
    22414  2020-06-25 08:48   idm_json_20200625.json
---------                     -------
  8968078                     2 files


 wc idm_json_20200625.json
   39    39 22414 idm_json_20200625.json

[evilpete]

@phrrngtn thank you...

I should be able to crank-out a day or two in.
(not sure how to difference between the two types of IDM packets, yet)

[phrrngtn]

I looked through https://github.com/bemasher/rtlamr/wiki/Protocol and the source code for idm.go and netidm.go and was unable to figure it out.

@bemasher, how did you do it?

[evilpete]

I asked that in rtlamr:155 and was told

_"Net meters typically have an endpoint type of 8, while non-net meters have type 7."_

but this does not agree with the data sample @phrrngtn provided :

{Time":"2020-06-25T08:22:08.569276915-04:00","Offset":1605632,"Length":229376,"Type":"NetIDM","Message":{"Preamble":1431639715,"ProtocolID":28,"PacketLength":92,"HammingCode":198,"ApplicationVersion":4,"ERTType":7,"ERTSerialNumber":1550406067,"ConsumptionIntervalCount":30,"ProgrammingState":184,"LastGeneration":125,"LastConsumption":0,"LastConsumptionNet":2223120656,"DifferentialConsumptionIntervals":[7695,545,2086,1475,6240,2180,4240,4616,240,7191,609,7224,1603,96,2052,12464,6152,8480,9226,352,12312,833,10292,1795,4248,4613,8416],"TransmitTimeOffset":2145,"SerialNumberCRC":61178,"PacketCRC":37271}}

{"Time":"2020-06-25T08:22:52.404629556-04:00","Offset":1835008,"Length":229376,"Type":"IDM","Message":{"Preamble":1431639715,"PacketTypeID":28,"PacketLength":92,"HammingCode":198,"ApplicationVersion":4,"ERTType":7,"ERTSerialNumber":11278109,"ConsumptionIntervalCount":246,"ModuleProgrammingState":188,"TamperCounters":"QgUWry0H","AsynchronousCounters":0,"PowerOutageFlags":"QUgmCEEF","LastConsumptionCount":339972,"DifferentialConsumptionIntervals":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,1,0,0],"TransmitTimeOffset":476,"SerialNumberCRC":60090,"PacketCRC":31799}}

[phrrngtn]

Hmm. I am away from the house for the weekend and only have my day-job computer with me: it is locked down administratively and I can't VPN to my home net to check which revision of rtlamr was running on the Pi. IIRC, I cloned the rtlamr repo a month or so ago and was running from HEAD. I definitely have not made any local modifications. I believe that there was only one process writing to that file (so I don't think there is any possibility that output from multiple processes is interleaved).

I can generate more samples on Monday and do some experiments with running with single -msgtype at a time.

[evilpete]

@phrrngtn thanks for the sample, saddy I can rtl_443 can only read a couple of the packets (even with clean up in Audacity).

if you have time, sample taking by rtl_433 may be better to read
rtl_433 -f 912600155 -s 2359296 -S unknown should do it

again thanks for your help, I have decoder written I just need to test it with more than 2 packets and validate the CRC method. ( as for netidm im going to ignore that issue until get idm validated )

---

many the packets read right up to the last 2 bytes (the crcs) and fails just 16bits short of a full packet (@merbanan any suggestions?)

im using
-f 914.9M -s 2359296 -X n=IDM_flex,m=OOK_MC_ZEROBIT,s=30,l=30,g=20000,r=20000,match={24}0x16a31c,preamble={8}0x55

[00] {720} 16 a3 1c 5c c6 04 17 00 ac 17 1d f8 bc 02 01 00 ef 09 00 00 00 00 00 00 00 00 00 00 05 30 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 00 00 00 02 0d 40 ea ba 93 89

should be 8 * 92 = 736 bits

idm-multiple.cu8.gz

[merbanan]

What does sigrok visuals say? Are the bits missing in the end?

[evilpete]

@merbanan regarding the last 2 bytes being dropped , looks like the demodulator the is giving up early, although to be fair the signal is a little weak getting only 90 or the 92 bytes.

---

Regarding IDM protocol support :

I am have both idm and netidm working but I unsure how to differentiate between the the two similar protocols
Both use the same Sync ID / Packet Type / length / App Version ID, see Idm for net meters and earlier comments in this thread.

If is ok with you, I’m going to submit a pull request with what I have for now. both work but both trigger on the same packets.

[evilpete]

Code submitted, See pull req #1421 and rtl_433_tests # 348

[evilpete]

@bemasher. while looking at idm and netidm packets from the same meter, I noted the same data in the first 6 bytes of netidm. 1st "Unknown" field as was in the idm 'Tamper Count" but are located at byte 13
thus can be safe to assume the first 6 bytes of netidm. 1st "Unknown" field is for 'Tamper Count"

I am noting it here because I included the "new" field to the rtl_433 idm pull request.

[merbanan]

Code merged, closing issue.