Power consumption in TX mode without TX

Hi Eugene,

But it is not clear if it depends from actual transmission of packet from nRF52840 side.

As usually transmision state is enabled beforehand and FEM can state in TX mode but actual transmission is not started.

What can be consumption in this state ?

The specified current consumption is while transmitting, when there is no input signal on the TRX pin the current consumption will be lower than 110mA in TX mode.

2. I can see FEM have very small consumption in Powerdown mode. But enable of it to RX or TX mode from PD can take ( 10 + 17us) at list.

I have event from Timer for wake up RADIO ( it take 40-50 us). I just think if it possible to attach to this event 3 GPIO lines and start to wakeup FEM to RX or TX mode at the same time when radio starts to wakeup ?

Or what is your recommendation for synchronous wakeup of FEM together with radio ?

There is all ready support for GPIO control of the nRF21540 in the nRF connect SDK, that handles the waking up the FEM from power down for the radio events. Here is some more information regarding this:

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/ug_radio_fem.html

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrfxlib/mpsl/doc/fem.html

Looks like better to keep FEM in PD mode and do not wakeup ut too much beforehand.

This is recommended for achieving the lowest average current consumption.
One thing to note is errata 13, there can be a higher current consumption in the power down state when any of the digital input pins(CSN, RX_EN, TX_EN, MODE, SCK, MOSI and ANT_SEL) are high. The workaround is to pull all of these pins low while in power down.

Best regards,

Bendik

Hi Bendik !

Is any exact digits available for case "The specified current consumption is while transmitting, when there is no input signal on the TRX pin the current consumption will be lower than 110mA in TX mode." or better to measure on our side ?

About GPIO control of FEM lines.

In our case we have intensive communication via USB virtual serial port  and USB ISR can consume even 60 us time.

Do I undestand right and your solution based on Timer and direct GPIO manipulation from Timer's ISR ? It should work but

if a lot of other long ISR in system, timer ISR can delay and wakeup of FEM from PD ( ~ 30us ) might be delayed.

Can something be composed by using PPI/GPIOTE ?

I have synchronous radio and RX/TX slot scheduled by Timer beforehand.

Regards,

Eugene

Hiihtaja said:

Is any exact digits available for case "The specified current consumption is while transmitting, when there is no input signal on the TRX pin the current consumption will be lower than 110mA in TX mode." or better to measure on our side ?

We don't specify the current consumption in this state, but I have measured the current draw from VDD to be 35mA while idle in TX mode. Keep in mind that this is only from one sample so it may not be representative of the typical value.

Hiihtaja said:

Do I undestand right and your solution based on Timer and direct GPIO manipulation from Timer's ISR ? It should work but

if a lot of other long ISR in system, timer ISR can delay and wakeup of FEM from PD ( ~ 30us ) might be delayed.

Can something be composed by using PPI/GPIOTE ?

The solution used in the nRF connect SDK uses PPI and the time compare events to enable the GPIO pins.

Hiihtaja said:

Is any exact digits available for case "The specified current consumption is while transmitting, when there is no input signal on the TRX pin the current consumption will be lower than 110mA in TX mode." or better to measure on our side ?

We don't specify the current consumption in this state, but I have measured the current draw from VDD to be 35mA while idle in TX mode. Keep in mind that this is only from one sample so it may not be representative of the typical value.

Hiihtaja said:

Do I undestand right and your solution based on Timer and direct GPIO manipulation from Timer's ISR ? It should work but

if a lot of other long ISR in system, timer ISR can delay and wakeup of FEM from PD ( ~ 30us ) might be delayed.

Can something be composed by using PPI/GPIOTE ?

The solution used in the nRF connect SDK uses PPI and the time compare events to enable the GPIO pins.