Using BLE with three & four pin PA/LNA frontend?

[SebastianA]

We use a frontend that requires four pins and the timeslot API with our own protocol on nRF52832 & nRF52840. This works fine, but for BLE to work properly we need to leave the frontend in bypass-tx mode outside of our timeslots, causing excessive energy usage.

We would like to put the frontend in idle mode when not used, then let the softdevice switch it to bypass-tx/bypass-rx as needed. For that to work we need the softdevice to set two pins per mode.

Is it possible to use the configured PPI's forks to connect them to another GPIOTE TASKS_OUT to lower the energy usage? Any other way to make this work with the current softdevice versions?

Are there any plans to have proper support for PA/LNAs with more pins in softdevice?

[Andreas]

Hi,

 

As you say the Softdevice toggles two pins, TXEN and RXEN. If you need to control more pins, you need to do this manually in your application. You can fork out other pins, but there is no guarantee this is a feasible  solution for the FEM you plan to use, you will have to study the control logic described in the datasheet.

Not sure I have seen any parts that strictly require 3 or4 control lines, which part are you planning to use?

 

Best regards,
Andreas

[SebastianA]

Hi!

We are using Skyworks SE2431L, but we also sell a library with our networking protocol that our customers use with different FEMs. They configure our library with a list of up to four pins and the wanted signal levels for the different modes of operation.

Our library comes in two flavors, one with and one without softdevice support. We would like both variants to have the same features to make it easier for the customers to start using softdevice.


I'll have to see if we have enough PPIs and GPIOTE channels left to support three pins this way.

Would it be possible to let the forked PPI trigger a quick interrupt or can the CPU be busy at prio 0 when the PPI is triggered?

BR,
Sebastian

[Andreas]

Hi,

 

OK, I see. With this control specification, if you are not able to fork the TXEN/RXEN PPI channels to a GPIOTE you could look into using Radio Notification signals and set the necessary pins ahead of the radio activity. The Softdevice processing may happen at any time, I would be more confident in using this than firing an interrupt off PPI, hopefully the extra few µA for some µs is acceptable given that you run a PA in the first place.

 

Best regards,
Andreas