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.

[RayFoulkes]

OOPs, I have just found that there are already functions  (inline) in nrf_radio.h which sets and gets the power and this time it does include 8dbm (from nrf52840.h). These are:

__STATIC_INLINE void nrf_radio_txpower_set(nrf_radio_txpower_t tx_power)
{
NRF_RADIO->TXPOWER = (((uint32_t)tx_power) << RADIO_TXPOWER_TXPOWER_Pos);
}
and the equivalent "get".

So, all the work has been done for register writing.

Regards, Ray

[ovrebekk]

Hi Ray

Sorry for the slow reply, I forgot to look over my verified cases...

Feel free to share any information here on your blog, if you haven't already. Since it is a public case it is already out there

Good find on the nrf_radio functions, should make things easier. 

Regarding the documentation I agree it is slim on the interplay between different functions and libraries. Mainly this is a resource issue, as it takes a lot of time to write and maintain such documentation with all the changes there are to the various libraries and modules for every SDK update. For the foreseeable future I expect the examples will be the best reference for this ;) 

Best regards
Torbjørn

[RayFoulkes]

Hi Torbjørn, thanks for the response. I will write up my experience of using nrf_radio_txpower_set which has not been all plain sailing.

On the issue of documentation, my long-held view is that it is primarily a matter of training the software developers to think of the users. The developers KNOW how something is supposed to work so adding in a few comments in-line (as all the code documentation is inline) should be a few minutes work. It is useful to know the state of the system in which a call can be made and surely the developer knows that. An example of one developer who is trying to be helpful is whoever wrote nrf_dfu_trigger_usb_init which at least gives a few hints about how to use it. Unfortunately, there is a lot of code with much less helpful (or no) hints.

Just my thoughts, I know you cannot do anything about it! Keep smiling, Ray

[ovrebekk]

Hi Ray

Can't say I disagree

Next time you run into someone from Nordic sales mention it to them as well. At the end of the day requests for new features or improvements have to go through them ;)

Best regards
Torbjørn