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: CC1310 - WMBUS Meter Limitation

Part Number: CC1310
Other Parts Discussed in Thread: WMBUS,

Hi,

 

I struggle with the max number of supported meters as a collector in the wMBus Stack of Stackforce in combination with the CC1310.

Where is the reason for the limitation of 16 meters? Is it because of the hardware or is the limitation in the stack?

And is it possible to use more meters with another Hardware or another version from StackForce?

 

I think a possible solution could be the deactivation of the "address filtering" property in the collector. Then all received telegramms are forwarded to the application layer. Then the mapping to known meters and the encryption would be done by our own code but it could be possible to work with more meters than 16.

Do you know anything about limitations with that deactivated address filtering?

Or where could I ask for more information?

 

Related Forum Threads:

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz/f/156/p/687323/2537578#2537578?jktype=e2e

and

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz/f/156/t/852548?tisearch=e2e-sitesearch&keymatch=WMBUS

 

Thanks

Best regards

SB

  • Hi SB,

    I will get in touch with the experts on this to see how turning address filtering of could impact the stack (if it does at all). In the mean while, could you elaborate on the use-case you have, for example, max number of devices you expect to support etc?

  • Hi M-W,

    thanks for your attention.

    We are intereseted in using the CC1310 and the wMBus Stack for collecting meterecords from a lot of meters. For "a lot of meters" we do not want to define a max number but we were thinking about hundreds of meters. This is for a commercial use case and we are testing different possibilities at the moment.

    It would be interesting for us to know if there is an "advanced" StackForce wMBusStack (maybe this would cost more) which would support more meters, alternatively we would like to know more about limitations when using the stack without address filering.

    Best regards,

    SB

  • Hi SB;

    We are looking into this further internally in terms of what is possible to do with the stack (and additions that might be needed to fully disable the address filtering). 

    As for your use-case, it sound much like a "listen only" kind of application, do you expect the meters to have been "installed" in a usual manner or would you in theory be "OK" with a sniffer approach? If it is the latter, then you could implement the subset of features needed yourself quite easily as the wmbus patches and settings are available for the device (not related to the stack). 

  • Hi M-W,

    for this use case we would be "OK" with a "listen only" sniffer approach, when we know more about the limitations there. But we are also still interested wether there is an "extended" StackForce wMBus Stack version where more meters could be "installed".

    Best regards

    SB

  • Hi SB,

    the "listen only" approach I suggested was without using the stack, the limitations would thus be up to the implementer of the radio RX chain. As for the stack, I'm still looking into this internally but being close to the holidays, I expect some delay on clear feedback. Right now there is no possibility what I can tell to extend the number of meters in the stack from an "installed" point of view but I have recorded the feedback as we look over the use-case/request internally.

  • Hi SB, 

    I got feedback from the developers that there should be no real risks turning of the address filtering in the stack. If you do this (compile configuration + serial command) then the stack will just forward the telegrams up to the host (as you expected). While most of the handling is left to the host in that case, the CRC of the packets are still being validated by the stack.