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.
Part Number: CC1310
My customer will deploy several 15.4-Stack based sub-1ghz network in real scenario, customer will using Beacon mode from 15.4-Stack.
They want the sensor device to select better Gateway to join, such as better RSSI.
The default operation in the beacon mode, sensor device will use passive scan in every channel to wait for the Beacon send from Gateway.
But this process may consume a lot of power if the BO is big and all the channel mask are enabled.
So can we use the active scan to choose the right Beacon/Gateway, then switch to the specific channel to do the passive scan to sync with selected gateway.
That behavior violates the spec. According to IEEE 802.15.4-2015 section 220.127.116.11 (Active and passive channel scan):
"If a coordinator of a beacon-enabled PAN receives the Beacon Request command, it shall ignore thecommand and continue transmitting its periodic beacons as usual. If a coordinator of a nonbeacon-enabledPAN receives this command, it shall transmit a single Beacon frame using unslotted CSMA-CA."
This means a beacon-request packet receive by the collector in beacon-mode will be ignored.
A possible solution would be to dynamically change the beacon order at runtime. For example when you enable permit join on the collector also set the beacon order to be quick, when you disable it you can put it back to what your application needs.
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Brocklobsta:
In reply to Victor Xu:
The stack does not support responding to beacon requests with beacons in beacon mode.One reason for this is to not de-synchronize nodes in the network. If a node loses synch while a device is trying to join, it will listen for a series of beacon to lock in the timing. If the collector is responding to beacon requests asychronously, then the node will have a hard time resynching and wasting much more current (rx always on while listening for beacons).
You are correct that by reducing the BO the overall power consumption of every node in the network increases, but this increase in only temperary. Once all desired devices have join the network the BO can be increased to reduce power consumption. I imagine the BO will only be reduced for a minute or so. This solution can be fine tuned by selecting the optimal BO for joining. I also recommend BO=SO for the joining process.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.