CC1310: Read a meter using wMBus

Hi Firas,

Assigning an expert to comment. 

Thanks, 
Elin

Hi

We only provide the documentation that comes with the Stack on how to access the functionalities of SF Wireless M-Bus stack via serial interface.

There you will find a full list of the different commands that you can send.

To get further details on the wmbus, you would need to get the spec.

BR

Siri

Please we need at least:

> A log of packets for reading a real meter

> How to add a real meter (which we know only its address and no information about its RF module's address or its encryption key!) to the list of a collector.

> How to get the current list of collector.

Please we need some answers to go with our implementation with your hardware!

I'm still expecting a help from your side!
I tried to use SF Wireless M-Bus stack via serial interface (in both windows/Linux) and I'm getting valid responses for my requests. But I need an example on how to read a real meter. I added a real meter to the list of a collector (CC1310 with serial_CC13xx_Collector_T2). But what is the next command to make it read the meter?
How to get the read telegrams!

Hi Firas,

I'm sorry that there is no available examples on how to setup a basic meter and collector test. Please see below for a set of commands that can be used together with the SFSERIALCLI tool to add a meter to a collector and receive packets from the meter (green text is what is sent using the tool): 

Collector size:

1) Ping: 

-> 00 00 0a

2) Clean buffers to ensure clean state:

-> 01 01 02 

3) Read out the address of the collector:

-> 01 02 03

    Responds:

Manufacturer ID:        d1 33
Identifier:                    80 00 00 02
Version                       23
Type                           07

4) Remove all meters from the collector to ensure clean list: 

01 07 05 [Meter ID]
01 07 05 [ff ff] // All Meters
-> 01 07 05 ff ff

5) Add preferred meter and its parameters to meter list:

01 07 04 [MTR_ADDR] [MODE] [RF_ADAPTER] [ENC_KEY] // T-Mode,  MTR_ADDR read from the Meter
01 07 04 [d1 33 80 00 00 01 23 07] [T-MODE] [No RF Adapter] [ENC_KEY]
01 07 04 [d1 33 80 00 00 01 23 07] [01] [00 00 00 00 00 00 00 00] [00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff]
-> 01 07 04 d1 33 80 00 00 01 23 07 01 00 00 00 00 00 00 00 00 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff

Meter size:

1) Ping: 

-> 00 00 0a

2) Clean buffers to ensure clean state:

-> 01 01 02 

3) Read out the address of the meter:

-> 01 02 03

    Responds:

Manufacturer ID:        d1 33
Identifier:                    80 00 00 01
Version                       23
Type                           07

4) Set the encryption key for the meter device:

01 05 08 [ENC_KEY]
01 05 08 [00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff]
-> 01 05 08 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff

5) Set the collector address to be connected to

01 05 0a [COL_ADDR]
01 05 0a [d1 33 80 00 00 02 23 00] // This address was read from the Collector
-> 01 05 0a d1 33 80 00 00 02 23 00

6) Set the meter as connected

01 05 02 [Property] [Property status]
01 05 02 [Connection Status] [True] // Meter is connected to Collector
01 05 02 [01] [01]
-> 01 05 02 01 01

7) Sends a Meter telegram

01 04 02 [Control field] [Control information] [Synchronous] Length encrypted] [Payload]
01 04 02 [Send No-Reply] [Control information] [Do not set the synchronous flag][encrypt the whole telegram] [Payload]
01 04 02 [44] [7a] [00] [ff ff] [00 01 02 03 04]
-> 01 04 02 44 7a 00 ff ff 00 01 02 03 04

On the collector side, you should receive:

01 02 03 04 2F

As for 2) How do you expect to be able to read a meter if you do not know the encryption key it uses?

Thanks  for your detailed answer,

I'm in contact with the manufaaacturer of the meter to get the Encryption key.

My question please:

After I add the meter (real meter) to the collector list, how to receive the data from meter, or how to check and read the received data telegram? Which serial command should I use to extract the read data of the meter? I checked the "Collector APL Interface" and didn't find related serial command.

Thanks for your help.

Hi Firas,

Assuming the meter is sending data, you would get "indication responses" from the collector device containing the telegram. What this mean is that you would get asynchronous serial SATP_APL_COL_INDICATION_RX packets each time you receive a new telegram, you do not need to poll for it.

If you look at the Serial APL documentation, these are listed under SATP APL Commands -> SATP API IDENTIFIER 0x09: ...

Question please:

For real meter I don't think that we can apply step 5/6:

M-W said:

5) Set the collector address to be connected to

6) Set the meter as connected

Then how the meter will learn about the collector?

Hello again,

M-W said:

As for 2) How do you expect to be able to read a meter if you do not know the encryption key it uses?

We asked the meter's manufacturer and we got the following answer:

The samples we send you do not have an encryption key. In these non-encrypted versions, the 15th and 16th Bytes of the data package are seen as '0x00'. If it is encrypted, these bytes with encryption bytes differ according to the encryption mode. There will be no need for your tests at the moment.

My question,

I checked the serial protocol and "SATP_APL_COL_ADD_METER" command doesn't give us the possibility to define a meter without an encryption key!

So it seems that this stack doesn't include non-encrypted communication with the meter right?

If there is a way of defining a meter without its encryption key (and we know that the meter supports reading without encryption) please we need to learn about it.

Hi Firas,

I'm working on this and will get back to you as soon as possible.

Hi Firas,

It is assumed that the one provisioning the network has some knowledge of it, for example knowing which collector they want to connect to. One can provision a meter to the network by issuing "installation requests" from the meter but you still need to specify the collector in question. 

As for encryption, if mode 0 is configured, then the device will simply ignore the encryption key. What this means is that you still use the same "add meter" API and use any key value you want (as this would not be used for mode 0). 

M-W said:

As for encryption, if mode 0 is configured, then the device will simply ignore the encryption key. What this means is that you still use the same "add meter" API and use any key value you want (as this would not be used for mode 0). 

Wireless M-Bus mode: [1 Byte]

• 0x00: Mode S.
• 0x01: Mode T.
• 0x02: Mode C.
• 0x03: Mode N.
• 0x04: Mode S sync. Used for synchronized messages in meters.
• 0x05: Unknown mode.

Does that mean, that only S mode supports reading in non-encrypted mode?

I have a meter with T mode, and the manufacturer said it's possible to read it in non-encrypted mode!

Hi Firas,

What you refer to is the protocol mode, not encryption mode. Have a look at "SATP_APL_MTR_SET_ENC_MODE" for how to set encryption mode.

M-W said:

It is assumed that the one provisioning the network has some knowledge of it, for example knowing which collector they want to connect to. One can provision a meter to the network by issuing "installation requests" from the meter but you still need to specify the collector in question. 

Does that means that the meter should be programmed with the collector's address?

I followed your mentioned steps for adding a meter to the collector's list and it works for the CC1310 LaunchPad flashed with "Serial_CC13xx_Meter_T2_C2.hex" (demo meter).

And as explained in the demo I was able to receive periodic data as follow:

01 09 03 00 00 44 0F 00 01 06 11 03 8C A0 D6 90 0F 00 2C 25 02 00 00 00 D6 76 F7 E6 A9 11 72 00 7A 6A 00 10 07 10 2F 2F 06 6D 8A 00 00 01 01 00 2F 2F 2F 2F 2F 2F

But when I follow the same with real meter which works in non-encryption mode, I receive nothing! No SATP_APL_COL_INDICATION_RX is received from the real meter!

Any suggestion?

Firas,

Maybe you should check out the RC1180MBUS3 from Radiocrafts were the concentrator is more completely implemented. 

-no-more-wires

Hi Firas,

Yes, the meter need to be made aware about the collector at some point. How you do this on your particular meter I can't say for sure. 

What I'm doing with the meter is only define it in the list of the collector. 

Isn't enough to do so?

The manufacturer doesn't provide any application to configure the meter! How to make the meter aware of the collector? 

Hi Firas,

Out of curiosity, what is the meter you are using in this scenario?

Do you have access to any test tool (such as a sniffer) to verify that the meter is sending any data?

I'm testing with these two meters.

BAYLAN's manufacturer informed us that the meter uses non-encryption mode so we added  the meter to the list of collector using the following packet:

01 07 04 0B 2C 01 21 34 32 14 07 01 00 00 00 00 00 00 00 00 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff

We tested also to add HYDRUS meter to the list of our collector:

01 07 04 11 A5 65 61 95 31 13 07 01 00 00 00 00 00 00 00 00 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff

M-W said:

Do you have access to any test tool (such as a sniffer) to verify that the meter is sending any data?

Today I was trying to use CC1310 LaunchPad as a sniffer using SmartRF Studio 7 as illustrated in the capture below, and I tried Continuous RX and Packet RX. But it seems that doesn't work!

How can I configure LaunchPad to work as sniffer to check received packets from meters?

Thanks for your time and help

Firas

Hi Firas,

I would expect to be able to capture at least RSSI values using SmartRF Studio in continuous RX mode on the same frequency. Note that if the a´packages are small, they could be missed but I would assume a spike or two.

I tried t get some information on the meters in question and the only thing I could seem to find is that the Diehl meter only activates the radio when the meter is actively reading (meaning there would need be some water flowing). Do you have any access to a "test" mode or are the meters actually installed somewhere?

M-W said:

Do you have any access to a "test" mode or are the meters actually installed somewhere?

Unfortunately no access to a "test" mode. Meter are not installed anywhere.

But we are in contact with BAYLAN, and we can request any helpful issue.

What do you suggest?

Assuming the meter device address is correct I would ask them how to test out the WmBUS functionality for a device that is not installed. In other words, see if there is a test mode or equivalent (or if the radio is always sending).

I would assume that most meters would be delivered with the radio inactive as having it running while "on the shelf" would mean the battery life would take a severe hit. This means that there must be a way to activate the radio (like in the Diehl case, actually having the meter operating seem to turn on the radio).

The Diehl has some kind of interface which I assume they could use to configure the device in field as needed, maybe this could also be used to test the device in an desk environment. 

M-W said:

I would expect to be able to capture at least RSSI values using SmartRF Studio in continuous RX mode on the same frequency. Note that if the a´packages are small, they could be missed but I would assume a spike or two.

You can see below a record for sometime, I run it for more than 2 minutes and the period in meter is 1 minute, and I couldn't see any distinguished spike!
In this capture collector was OFF and only the meter exists.

I did another sniffing when the collector is ON and has the meter added to its list. I found very small spikes as you can see, can we consider them from meter? 

Hi Firas,

I would assume much larger spikes as the device is basically next to each other, right? I would suggest you maybe take one of the LPs and run the HW test commands (there is separate docs for that but the interface is the same) and put the device into "unmodulated carrier" to verify that you see the signal from the LP.

Hi M-W

M-W said:

I would assume much larger spikes as the device is basically next to each other, right?

Right they are very close (on the same table).

M-W said:

put the device into "unmodulated carrier"

How can I put the device in "unmodulated carrier" ?

B.R

Firas

Hi Firas,

The HW test commands is described in the "Hardware Testing Interface", to put the device into CW test mode, you would need to do the following steps:

"Start HW Testing": 01 0A 02

"Set test mode to unmodulated CW": 01 0A 04 01

This would generate a unmodulated carrier on the TX frequency that you can pick up with the "Continuous RX" view in SmartRF Studio.

Hi M-W,

I run the HW test and here is the captures.

B.R

Hi Firas,

Can you test at the frequencies 868.30 MHz, 868.95 MHz and 869.525 MHz as well? While it seems like you can see the signal, the RSSI is very bad, I would expect much higher levels, this could be because you are actually not tuned to the WmBUS frequencies (the three I listed above for S, C, T).

Hi M-W,

Find below the captures for the suggested modes/frequencies.

B.R

Hi M-W,

I was checking some documents and read in "Combined wM-Bus C-Mode and T-Mode Patch" that T-Mode may need a special patch!

My question:

What I did to flash the CC1310 is to load the binarries or Hex output (serial_CC13xx_Collector_T2) files to it using Smart RF programmer 2, is that enough to make the CC1310 works in T-Mode? Or I need also to apply the patch?

If so, how to apply it please?

B.R

Seems like all is OK, then you know that the setup is working as expected when trying to sniff for radio activity. 

You do not need to worry about the patches, the hex files in question are complete applications, they include everything. Patches and RF settings is taken care of by the stack.

Actually I repeated the sniff for radio activity and I got the following spike, may it be from the meter? I'm sniffing at the same frequency which it works on.

Hi Firas, 

If you have nothing else running around you it could very well be, it is hard to say but it is a strong signal at the correct frequency. Try to run it for a while and then unplug it and see if it stops. 

Hi,

Unfortunately, this meter has built in battery and it's not possible to unplug it.

sorry for repeating my question but I need an answer:

I was checking some documents and read in "Combined wM-Bus C-Mode and T-Mode Patch" that T-Mode may need a special patch!

My question:

What I did to flash the CC1310 is to load the binarries or Hex output (serial_CC13xx_Collector_T2) files to it using Smart RF programmer 2, is that enough to make the CC1310 works in T-Mode? Or I need also to apply the patch?

If so, how to apply it please?

B.R

"I was checking some documents and read in "Combined wM-Bus C-Mode and T-Mode Patch" that T-Mode may need a special patch!": This is just applicable if you are following the app note. As I read your first mail you are using the WMBus stack which sets up the radio for you.

I need to sniff to the radio as you can see so I can read what are the packets sent by the meter.

Is there a demo application like "rfPacketRx" which sniff to the radio packets and writes them to the UART?

I have CC1310 LaunchPad which I can test with.

OK I'll try that,

But please I noticed the following table in the documentation of the stack.

We are flashing the collector with T2 mode, collector should work with 868.3 MHz  to send data to meter and 868.95 to receive data from the meter. Is that right?

My question:

If the meter supports only T1 (on frequency 868.95) will the collector be able to receive data from it?

Hi Firas.

You should be OK, main difference here is direction, I would expect the stack to handle this for you. If you want, you can always try to compile a T1 image for sanity checking. 

Have you been able to setup a sniffer project based on the app note?

M-W said:

Have you been able to setup a sniffer project based on the app note?

Actually I read the application note of it, and as I understand, it's like an application which is able to receive both C mode and T mode packets from the meter!

OK this is fine, but not the sniffer I want to have.

I already flashed the CC1310 LP with Both:

• T2 mode and tested to receive meter's data and failed!
• C2 mode and tested to receive meter's data and failed!

What I want to have is T2 mode application but can show me all received packet even if it was from a meter which I didn't add to collector's meters list (or added it with wrong address!)

In this way I'll be able to receive the meter's packet (which I was able to see on T1 frequency 868.95 MHz), and checking it I'll know the problem which prevents me from receive data from this real meter (Diehl and BAYLAN meters) While I'm able to receive data from demo meter (using LP flashed with Meter application), and I was also able to receive data from demo meter in both modes: encrypted and non-encrypted modes.

Can you please tell me how to configure/modify the wMBus application to make it show me all received packets regardless whether this meter  in the list or not!

This is the sniffer I want to have and will solve my problem!

Sorry for wasting your time, but we spent huge time trying to solve this problem (reading real meter) and had no positive results :(

B.R

Firas

Hi Firas,

Unfortunately I can't give you directions on how to turn the stack into a sniffer, it is not designed to be a sniffer, it is written to follow the wmbus standard. For the case of verifying what you meters are actually doing, you can always use the "sniffer you don't want".

I'm trying to see if I can get my hands on similar meters as the one you are using to perform some test myself. Could you provide the full product number etc for the models you use?

M-W said:

I'm trying to see if I can get my hands on similar meters as the one you are using to perform some test myself. Could you provide the full product number etc for the models you use?

I already provided you with a capture of the used meters:

And you can find its document here:

254513-DE-EN-HYDRUS_CommunicationDescription_EN.pdf

Yes, the diehl one was rather clear, the Baylan one was not, this is why I asked for the actual part number (as there so many different variants of it).

For BAYLAN meter, we got the following information from the manufacturer about the meter:

BAYLAN ID: 0B2C
Ident Number: 01213432
Version: 0x14 (20)
Type: 07 (water)

And it supports T mode and works on the correct frequency 868.95, and when I sniff the radio on this frequency I got spikes with -20 dBm.

Hi Firas,

Do we know that Baylan gives the ID number in hex? Have you tried adding it as both (I know you have tried the first one):

BAYLAN ID: 0B2C
Ident Number: 01 21 34 32
Version: 0x14 (20)
Type: 07 (water)

and

BAYLAN ID: 0B2C
Ident Number: 01213432 = 00 12 83 F8
Version: 0x14 (20)
Type: 07 (water)