• State Not Answered
  • Replies 20 replies
  • Subscribers 65 subscribers
  • Views 488 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 328680
Options

NCS: Softdevice+Mesh+Ext. Advertising -> TX Power Control?

mesh777

Hello,

I have trouble again with TX Power control. This time using Softdevice Controller and NCS2.6.0.

Previous issue which was solved (this was using Zephyr Controller):  NCS Mesh: TX Power register value does not change when changing TX Power via HCI 

Is there a common solution to control TX Power runtime, when running Mesh + Extended Advertising and Softdevice controller?

Thanks in advance! :)

Parents
  • 0

    Hi mesh777,

    You should be able to control the TX Power following the method demonstrated in the Bluetooth: HCI Power Control sample.

    Please note that the SoftDevice Controller only raise the TX Power momentarily for the radio action, and then will set it back to 0. A crude way I used to confirm things are working is to repeatedly print out the content of the TXPOWER register.

    Hieu

  • 0 in reply to Hieu
    Hieu said:
    Please note that the SoftDevice Controller only raise the TX Power momentarily for the radio action, and then will set it back to 0

    What is the reason of such behaviour? Does it mean that TX Power needs to be reconfigured continuously or it is handled by Softdevice automatically?

    The reference sample does not take into account multiple AVD sets, when EXT ADV is enabled. Maybe Conn Handle somehow can be determined to configure each set?

  • 0 in reply to mesh777
    CONFIG_BT_CTLR_TX_PWR_ANTENNA and the CONFIG_BT_CTLR_TX_PWR configuration line sets the default TX Power for all activities.
    Therefore, without a runtime reconfiguration, the SoftDevice Controller should use the configured default.
    Also note that the CONFIG_BT_CTLR_TX_PWR choices depends on CONFIG_BT_CTLR_TX_PWR_ANTENNA being not set. If the _ANTENNA configuration is set, it takes priority.
    mesh777 said:
    In your sample code you do not print value of 0 by the way, otherwise it is 0 most of the time.

    Yes, I too find that it is 0 for the absolutely vast majority of the time and can't figure out a good way to see the few "8\n" among the hundreds of "0\n," so I set up that logic instead.

    I guess if we really want to, we could also set a logic to get the statistic on how often and for how long TXPOWER stays in a particular value.

  • 0 in reply to Hieu
    Hieu said:
    CONFIG_BT_CTLR_TX_PWR_ANTENNA and the CONFIG_BT_CTLR_TX_PWR configuration line sets the default TX Power for all activities.
    Hieu said:
    Yes, I too find that it is 0 for the absolutely vast majority of the time

    These two things sounds contradicting in my opinion, if all activities set to happen with 8dbm, then why most of the time register is set to 0dBm?

  • 0 in reply to mesh777

    No, it isn't necessarily contradicting, if you consider that the radio only transmits for a little time overall. In Bluetooth Mesh, the radio needs to be on receive as much as possible to not miss messages.

    Remember that there is a limit of 100 Lower-Transport PDU per 10-second moving window, too. So even if your node has a lot it wants to send, it can't transmit all the time.

  • 0 in reply to Hieu

    But why to reconfigure it always back to 0dBm then?

    Or it is related to not retained register value due transceiver power modes or something?

  • 0 in reply to mesh777
    mesh777 said:

    But why to reconfigure it always back to 0dBm then?

    Or it is related to not retained register value due transceiver power modes or something?

    TXPOWER-set-to-0 is just a known state to make it simpler to support multiple TX Power for different activities. Examples include but not limited to other BLE activities, or user application's MPSL timeslot API use, or Power Envelope Control.

    • Reply Children
    Related