This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC1310: Maximum number of connected devices in WM-bus data collector mode

Part Number: CC1310
Other Parts Discussed in Thread: WMBUS

Hello!

An old thread discussing the CC1310 running the wmbus-cc13xx-rtos  stack version 1.2.0 mentions that the data collector mode only can keep track of 16 devices. Does the current version (2.0.0) have the same limitation? and if it does, is there any sensible way round it or should we look for another solution?

BR

Joakim

  • Hi Joakim,

    The limit is defined in "release.h" and I would expect you to be able to increase it to maybe 32 meters (don't remember the actual maximum). The limitation in the end boiles down to NVS limitations from what I can remember. There is plans for a CC1312 version (more flash, more ram) and the limit would likely be much higher here.

    Could you share some details around how many meters you would wish to track etc. and I could try to help you get a better answer/solution to this.

  • Hello M-W and many thanks for a clear and good reply.

    Our end customer needs to be able to listen to, in the order of, 200 devices or so.

    However after digging some more I have concluded that we are only interested in the unidirectional modes, that is S1, T1, and C1.

    However when i look at the hex files in the latest download (wmbus_cc13x0_rtos_2_0_0) I only find support for bidirectional data collectors, that is S2, T2 and C2.

    Do you know if it is possible to implement unidirectional collectors with the current stack, and if so, that would allow for listening to more meters?

    Best regards

    Joakim

  • Hi Joakim,

    I'm not aware of any way to explicitly tell the collector to only support unidirectional data. The direction support is typically dictated by the meter where the collector can support either. No matter what, I do not think limiting the collector side to "listening only" would play into the upper limit (whatever this exact number is, I have reached out to the expert for a clarification on this) as the driving factor is typically encryption keys etc.

    The collector would require the same amount of information stored in the NVM for a meter no matter the direction, as things such as meter ID and encryption key is still required (assuming encryption is used that is). As for the actual modes, I expect you to have no issue with the "S2, T2 and C2" images for the collector as these can still receive from S1, T1 and C1 type meters.

  • Thanks for yet another swift and comprehensive answer. I'll eagerly await the clarification from the expert :)

    Would the situation change if encryption was not used?

  • Hi Joakim,

    I unfortunately think the answer to you initial question is that you are limited to 16 meters as the pre-compiled library stand today. We are still going over this internally to see what we could potentially do from the stack point of view. While encryption is part of the reason for this, I'm not sure not using it would allow you to increase the number (but still pending a answer on this)

    Now on your use-case as such, as you are going for a "listen only" kind of approach, a solution could be to write your own wmbus RX application. The embus radio patches and settings are available to anyone and not limited to the stack as such. This means that you could (with some effort but quite easily) put together a RX only application to just sniff the air for wmbus telegrams. While this might not be as "plug-and-play", it would allow you to tailor it very much in your favor (depending on what parts of the stack you are actually interested in). 

  • Hi Joakim,

    I got some additional information from the developers in addition to my old reply. In the uni-directional case, you should be able to increase the number up to the point that you run out of FLASH/RAM. I do not know the exact number but more then 16.