Transmit power control with Gazelle (gzll)

[RayFoulkes]

I am experimenting with trying to improve the current range of gzll nRF52840 dongle to dongle (which is not that far from what I need). I am developing using  nRF5_SDK_15.2.0_9412b96 with  SEGGER Embedded Studio for ARM Release 4.12 Build 2018112601.37855 Linux x64 on SUSE Linux.

I think that I understand from reading other posts that the only dynamic part of power control gazelle is relating to reduced power when pairing which reads the current TX power setting,  sets it to a value GZP_POWER configured in nrf_gzp_config.h and then restores it after pairing.

Can anyone confirm that gzll does no operation (other than pairing) with the power output after initialising it to NRF_GZLL_DEFAULT_TX_POWER (which, by the way, does not appear to be used anywhere in the entire source tree of the SDK). (or indeed, does it set the power output to that??).

A secondary question is relating to the ability to set the power using an existing function. There is a documented function nrf_gzll_set_tx_power (nrf_gzll_tx_power_t tx_power) but no explanation as to when it may be called e.g. when with respect to initialisation or operation of the radio. Furthermore, the definition of nrf_gzll_tx_power_t is shown below. It will be noted that it does not correspond to the available transmit power of the nRF52840 (+8dbm) so it is unusable for +8db.

/**
 * @enum nrf_gzll_tx_power_t
 * @brief Enumerator used for selecting the transmit (TX) power.
 */
typedef enum
{
    NRF_GZLL_TX_POWER_4_DBM,   ///<  4 dBm transmit power.
    NRF_GZLL_TX_POWER_0_DBM,   ///<  0 dBm transmit power.
    NRF_GZLL_TX_POWER_N4_DBM,  ///< -4 dBm transmit power.
    NRF_GZLL_TX_POWER_N8_DBM,  ///< -8 dBm transmit power.
    NRF_GZLL_TX_POWER_N12_DBM, ///< -12 dBm transmit power.
    NRF_GZLL_TX_POWER_N16_DBM, ///< -16 dBm transmit power.
    NRF_GZLL_TX_POWER_N20_DBM  ///< -20 dBm transmit power.
} nrf_gzll_tx_power_t;

The only place where nrf_gzll_set_tx_power  (which is a "binary resource") is used in the source tree of the SDK is twice in nrf_gzp_device.c for saving and restoring as above. So can anyone enlighten me as to when the TX power is set to default so I can change it shortly afterwards (please). I guess that, if the radio is not actually in use, I can just set the register appropriately. It would be good to know though, just when it is set.

Perhaps in the longer term gzll can be updated to support the nRF52840 or changed to accept a signed byte dbm (like the chip itself in register  0x50C) and "just do the closest you can with it" depending on the chip, rather than using an enumerated type.

Thanks in advance for any assitance.

Ray Foulkes

[ovrebekk]

Hi Ray

The only time the Gazell library will set the TX power is during nrf_gzll_init(..), where it is assigned a default value, and any time you call nrf_gzll_set_tx_power(..). 

In other words there is no dynamic change of TX power happening internally. This has to occur in the application (or in some other module using Gazell, like the GZP library). 

Any time Gazell is initialized and idle you can safely call nrf_gzll_set_tx_power(..), but if you are in the process of transmitting something I would recommend against it. 

To get around the limitation of the nrf_gzll_set_tx_power(..) function you can simply write to the TXPOWER register in the radio, that is correct. The same recommendation applies: Write to the register after initializing Gazell, before you start sending or receiving packets. 

I can request the library to be updated with support for +8dBm, but can obviously not make any promises as to if or when it is fixed. 

Best regards
Torbjørn

[RayFoulkes]

Wow, Torbjørn, thanks VERY much for such a clear response. I understand that library changes are not in your hands and I guess that gzll is not that high on the Nordic priority list.

I trust it is OK if I document this solution in my little blog since others might benefit  - I don't think that there is anything particularly secret or sensitive about it.

I must admit that I struggle a bit with the SDK documentation. There are general guides (such as those for gzll link layer and pairing) which give an overview  and the syntactic signature of data and subroutine invocations. Often the middle bit is missing i.e. the semantic part for the subroutine invocations such as preconditions, interdictions (when you can call and when you cannot) and postconditions (i.e. what state (if any) is the software left in after call.  The examples go so far, but they are only examples so you have to try to deduce the semantics from examples - which I find hard.

Anyway, at least Nordic do their very best to help clarify individual cases and I thank you very much once again for that.