Hi,

If you look into the BLE SPEC, you will know that BLE uses 37 data channels to communicate with peer devices. And the channel map is configurable when establishing connection. After connection is established, both device will only use the channels which are exchanged to be used in the previous connection procedure.

For example, you could call the API cmd_le_gap_set_data_channel_classification to set the channel map, by clearing the specific bit in the channel map, link layer will automatically exchange the channel map with peer device when connecting. And all the channels which are consider to be OK by both sides will be used for communication after connection.

The bit order is LSB, e.g. byte 0 represents channel 0-7, byte  1 represents to channel 8-15 etc..

Thanks,

Kevin

Hi,

It isn't normal. I have reproduced the problem that the sleep time is always modulo 131072. I will report it to our R&D and let you know when the fix is available.

Thanks,

Kevin

Hi,

You don't need to switch the device role in your use case. Being a provisioner doesn't mean that it can't interact with other nodes. Below are the hints to implement your code.

1. Add the required models to your project, models are separated concepts from roles, so it doesn't matter if the device is a provisioner or node.

2. initialize the device as provisioner role and  establish your network by adding/configuring the nodes, I think you have done this successfully in your previous experiment.

3. Add/Bind appkey and configure the pub/sub locally by the mesh test class APIs. Note, this is very like the steps you configure a node, the only difference is it configured the node locally, so make sure all the appkeys used for control models are added and bound to the correct models. Publication and subscription addresses are correctly set.

4. After step 3 is done, you should be able to communicate with other nodes via model commands.

Thanks,

Kevin

Hi,

For the node reset procedure, timeout is expected. Firstly, you should take this in mind that any Bluetooth mesh packets could get lost by the remote device, this is the nature of Bluetooth Mesh. In the node reset procedure, when the remote node receives the config node reset command, it responds with node reset status and factory reset itself. The provisioner which sent the config node reset command may miss the status due to any reasons, in this case, timeout is triggered, however, the command actually succeeds.

For your application, I think you could add some method to work around this. Potential one could be scanning the unprovisioned beacon after timeout to see if the node factory reset itself or not. If not, try another round, if yes, consider the procedure has completed and delete the DDB entry if needed.

Thanks,

Kevin

Hi,

For the node reset procedure, timeout is expected. Firstly, you should take this in mind that any Bluetooth mesh packets could get lost by the remote device, this is the nature of Bluetooth Mesh. In the node reset procedure, when the remote node receives the config node reset command, it responds with node reset status and factory reset itself. The provisioner which sent the config node reset command may miss the status due to any reasons, in this case, timeout is triggered, however, the command actually succeeds.

For your application, I think you could add some method to work around this. Potential one could be scanning the unprovisioned beacon after timeout to see if the node factory reset itself or not. If not, try another round, if yes, consider the procedure has completed and delete the DDB entry if needed.

Thanks,

Kevin

Hi,

Sorry for taking so long to get back to this thread. I think the problem has been fixed in the latest SDK - v2.13.0. I have added your code to the empty project and get the expected return value as below.

--------------------------------------

expected(30) - real(29)
expected(-60) - real(-65)
expected(30) - real(29)

----------------------------------

Thanks,

Kevin

Hi,

Yes, the stack will check the time and returns to the normal state as soon as possible.

Thanks,

Kevin

Hi,

No, the node should still send packets even if it has lost the iv from the network. If you still have the node, can you try to use GDB to attach to it and give me the backtrace.

Thanks,

Kevin

Hi TC,

The frequency of calling to this command doesn't affect the replay attack performance. The variables for replay attack protection are all in RAM, syncing up them to flash is for power cycling. After a power cycle, it can load the latest value from flash, not from 0. The API is targeted to save the RPL before power loss. 

Thanks,

Kevin

Hi,

You can't change the state back to normal state and it needs to stay in iv update in progress state for at least 96 hours, this is by spec, you can see it on page 131 of Mesh Profile 1.0.1. 

Thanks,

Kevin