trond-snekvik
commented
8 years ago The mesh only uses a single advertisement channel at a time, and will be doing both its transmission and reception on that channel only. The channel is set in the initialization call, but can also be changed by this call to tc_radio_params_set() at any point. The intent is that the mesh channel shouldn't change for the lifetime of the mesh, as the mesh lacks a mechanism to synchronize such a change. Because of this, the functionality is not exposed in the rbc_mesh-api. The GATT interface, as you're pointing out, can change the channel/access address of a single device, which makes it more powerful than the on-board API. I'll look into aligning this, and I also believe the update causes only the receive parameters to change when you write to the GATT characteristics.
We're sort of wary of opening up these parameters in the rbc_mesh-api as the effects can be confusing and hard to deal with when you change the channel without any mesh-wide synchronization.
Can you explain how the channel is managed. From studying the code it appears that the channel is stored in g_state.channel which only seems to be modified at startup by the call to tc_init, and then again from the mesh_gatt_sd_ble_event_handle which calls tc_radio_params_set but only after a BLE_GATTS_EVT_WRITE event. I do not understand how this mesh is using the advertising channels based on what I can understand from this, so presumably I have mis-understood some of the mechanism.