Create optional conf overlay that is triggered by writing to a service/characteristic

I want to define config values in an optional overlay that is enabled after writing to a custom service/characteristic using NCS. Based on this https://devzone.nordicsemi.com/nordic/b/archives/posts/nrf-connect-sdk-tutorial---part-2-1478313418#h128sk64757ef1a0yr9w1h6gklfucy966 it looks like it is possible to have optional overlay files, but I am not sure if I can trigger it in a conditional statement. 

If anyone can help point me in a direction of if it is possible and any potential examples it would be greatly appreciated. 

Parents Reply Children
  • Hi,

    jclyde said:
    I've only been able to find examples of values assigned in the prj.conf but I would like to be able to change the value of some of the config_bt_dis values or to treat the device as two completely different devices based on which service is in use.

    Could you provide link to examples?
    How would you like to change the values in config_bt_dis?
    Could you please elaborate on "... to treat the device as two completely different devices based on which service is in use"?

    Best regards,
    Dejan

  • In the NRF Connect HID samples prj.conf file there is this snippet  

     

    CONFIG_BT_DIS_PNP=y
    CONFIG_BT_DIS_PNP_VID_SRC=2
    CONFIG_BT_DIS_PNP_VID=0x1915
    CONFIG_BT_DIS_PNP_PID=0xEEEE
    CONFIG_BT_DIS_PNP_VER=0x0100

    As I mentioned my device does not support USB so I do not have a value to put here but there is a use case where a PNP value is required so I want to be able to toggle CONFIG_BT_DIS_PNP between y/n so I am not always advertising a PNP value when I do not need to be. 

    If that is not possible the my other potential solution was possibly creating 2 separate devices in zephyrs device tree each having their own Device Information Service and I can toggle between which device is actively advertising. But I do not know the feasibility of this solution either.

  • Hi,

    There are several potential options that you could use.
    There is a sample in zephyr\samples\bluetooth called peripheral_dis where settings_runtime_set can be used for changing values in DIS. The change should take effect immediately. If you would rather prefer not to use settings subsystem and to have more flexibility you might need to change service implementation. 
    If your device can be in different modes, then this mode can be stored in separate proprietary characteristic. Additional metadata could be added to the characteristic by adding user descriptor to the characteristic. It is also possible to add "custom PnP ID" characteristic to each of existing services using proprietary 128-bit UUID instead of standard16-bit UUID for PnP ID characteristic.

    Best regards,
    Dejan

Related