• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 56 subscribers
  • Views 115 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC1312PSIP: 15.4: Single Sensor + Multi-Collector / Broadcast Message support

Stephen Murphy
Prodigy 20 points

Part Number: CC1312PSIP

Hi there, we are working on a new project, bringing a legacy system up to date, and we have selected the CC series of parts to use in this endeavor. We are moving from a legacy 433MHz system to 915Mhz and intend to use the 15.4 stack to take advantage of frequency hopping, encryption, etc.

 

To get to the point - With the current system today, we have 1 or many remotes that can transmit a payload to be received by 1 or many base stations simultaneously. The only requirement is that a set of dip switches are set on each device with the same address. Essentially, every message is a broadcast, allowing us to deploy multiple redundant base stations for high reliability and zero latency in the case a single base station fails in any way.

 

The question is, can we deploy an identical setup today using the 15.4 stack? Can a single remote (15.4 Sensor) transmit a packet to be received by multiple base stations (15.4 Collectors) simultaneously? And in the case of a Collector failure, experience zero latency and zero packet loss.

  • 0
    TI__Expert 6097 points

    Hi Stephen,

    This is something that would not work out of the box.

    The TI 15.4-Stack is a start topology (sensor: one-to-one, collector:one-to-many) every collector forms and manages their own network with a different PAN-ID, therefore there can be only one collector per network. Sensors join the network and get assigned a short address given by the collector during an association procedure at the very beginning.

    Messages in the network include both the destination address, and the PAN-ID address. We support broadcast messages from the collector side(check the collector.c in the collector example), which do not require a device destination address, but still require a destination PAN address.

    Since sensors can only send messages within the network they belong to, and there can only be one collector per network, then it is not possible for sensors to send messages to collector that are not the network managers. 

    Every collector keeps track of the network information, what devices have joined, their assigned short address, their MAC address, their status, etc. Even if a message was able to be sent to a second collector, how to keep this network information synchronized is out of the scope the the TI 15.4 Stack.

    However, if a device disassociates, as documented in the app note (Connect One TI 15.4 Stack Sensor to Multiple Gateways), it is free to join another network.

    So I'm not sure if is this stack is the right way, could you explain the use case? Do you need a close network (with association procedure, network management etc..) as the TI 15.4-Stack?

    Best regards,

    Daniel

  • 0 in reply to Daniel Guarecuco Aguiar
    Intellectual 756 points

    Hi Daniel - thanks for your thorough reply. I'm going through the app note you shared now.

    We would really prefer to leverage the TI 15.4 stack as much as possible to simplify the regulatory process across our target regions.

    Can you share an estimate of how long the node balancing process might typically take? Latency is critical in our application, and we're specifically worried about the latency required for a node to fail several retries without proper ACK, drop from its existing network, join new network, re-transmit.

    Put another way, we want to emulate a one sensor to many collector broadcast as best we can, and this app note looks like the closest we'll get using the stock TI 15.4 stack. Are there any specific tips or strategies you can share to minimize latency when doing PAN coordinator switching? 

  • 0 in reply to Jim G
    TI__Expert 6097 points

    Hi Jim,

    At the moment I don't have any number for the load balancing described in the app note. It typically takes a few seconds for a sensor to fully join the network the first time: Beacon Request, Beacon Response, Association Request, Association Response, Configuration Request, Configuration Response.

    I will try to run a quick test tomorrow with the stock solution (1 collector)

    Best regards,

    Daniel

  • 0 in reply to Daniel Guarecuco Aguiar
    TI__Expert 6097 points

    Hi Jim,

    I ran the test with two collectors as in the app note. With Orphan back-off time = 5s, and JDDLC_MAX_RECONNECTION_ATTEMPTS = 5, so it could take about ~30s to give up on trying until it tries to connect to another collector. The association is quite fast, about 1-2s. 

    The back-off time and reconnection attempts are parameters you can tune yourself. You could shorten the back-off time and reduce the reconnection attempts. This is something you should try yourself.

    If you have installed SmartRF Packet Sniffer 2, you can observe the flow with the attached Wireshark capture. I removed the power on Collector 1 (0xaabb) on T = 40s, the device is fully connected to Collector 2 (0xbbaa) around T=82s

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/156/TI_2D00_15.4_5F00_dual_5F00_collector.pcapng

    Best regards,

    Daniel

  • 0 in reply to Daniel Guarecuco Aguiar
    Intellectual 756 points

    Thank you Daniel, this is helpful info for us. Much appreciated!