MSCL
MSCL copied to clipboard
LORD-MicroStrain
Can a new wireless node be added to the network while an existing node is transmitting data?
It depends on the functional requirements of your application. Using a SyncSamplingNetwork object the network scheduling is reconfigured every time a node is added - using our implementation this cannot be done while any of the nodes in the network are sampling. If nodes are already configured in a network, however, sampling can be started (WirelessNode::resendStartSyncSampling()) and stopped (WirelessNode::setToIdle()) on individual nodes as long as the base station beacon is on.
When nodes are added to a SyncSamplingNetwork, the transmission schedule and other required network configuration values are written to the nodes themselves, so as long as the node configurations do not change sampling can be initialized within the network at any time.
If for some reason you cannot pre-configure the whole network (unknown nodes in range, bandwidth limitations, etc.) you could potentially keep track of each node's configuration and the network schedule and remove nodes or fit new nodes into the existing schedule on the fly but this workflow is not supported in MSCL. Let me know if this is something you want to look into implementing and I can point you in the direction of our existing scheduling logic.
Hope this helps!
Yes this helps. I have been getting an intermittent issue trying to put a node to sleep. First I set the node to idle which works then i try to put it to sleep which always works but sometimes I will get this error message “Failed to read LXRS Protocol” even with no other nodes in the network.
Ron
Sent from my iPad
On Aug 10, 2021, at 11:38 AM, mglord @.***> wrote:
It depends on the functional requirements of your application. Using a SyncSamplingNetwork object the network scheduling is reconfigured every time a node is added - using our implementation this cannot be done while any of the nodes in the network are sampling. If nodes are already configured in a network, however, sampling can be started (WirelessNode::resendStartSyncSampling()) and stopped (WirelessNode::setToIdle()) on individual nodes as long as the base station beacon is on.
When nodes are added to a SyncSamplingNetwork, the transmission schedule and other required network configuration values are written to the nodes themselves, so as long as the node configurations do not change sampling can be initialized within the network at any time.
If for some reason you cannot pre-configure the whole network (unknown nodes in range, bandwidth limitations, etc.) you could potentially keep track of each node's configuration and the network schedule and remove nodes or fit new nodes into the existing schedule on the fly but this workflow is not supported in MSCL. Let me know if this is something you want to look into implementing and I can point you in the direction of our existing scheduling logic.
Hope this helps!
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.
Just to make sure I'm understanding correctly - is the 'Failed to read LXRS Protocol' error thrown within the WirelessNode::sleep() function or sometime after the node is successfully put into sleep mode? If afterwards, can you track down which function is throwing this exception or outline the WirelessNode and BaseStation function calls that occur directly after sleep()?
This happens When sleep() is called, it is an intermittent issue. Looking at the led on the board it always indicates that the device has been put to sleep.
Sent from my iPad
On Aug 10, 2021, at 3:15 PM, mglord @.***> wrote:
Just to make sure I'm understanding correctly - is the 'Failed to read LXRS Protocol' error thrown within the WirelessNode::sleep() function or sometime after the node is successfully put into sleep mode? If afterwards, can you track down which function is throwing this exception or outline the WirelessNode and BaseStation function calls that occur directly after sleep()?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.