Replacement for QM12038 and support for multiple RFFE switches

[FinKM]

The nRF91 Thingy uses a pair of SD8T RF switches to tune the chip antenna to different LTE bands (and for GNSS). This setup uses two identical RF switches and the MAGPIO pins. Unfortunately, it seems the QM12038 is now discontinued and there are no clear drop-in (or even just functionally equivalent) parts available.

Info Request: Are there any recommended replacements for the QM12038, or a reference design using another topology?

The option for derivative designs is either to change the tuning network design completely which will add to development times and may degrade performance, or to find a suitable replacement. All production SP8T switches I can find use RFFE, which appears to be the preferred control solution for IOT devices going forward.

RFFE control using the same topology would require two switches with different (or hardware configurable) addresses to allow R/W operations to both. The Infineon BGS18MA12 looks like a good option as the device can change its address based on the connection of the SCK and SDA lines. This allows two identical chips to be placed back-to-back on the same RFFE bus without an address conflict.

The problem with this is that the nRF9160 AT Command %XMIPIRFFEDEV and %XMIPIRFFECTRL can only automatically control a single switch, not the two required for the Thingy-style tuning network.

Feature Request: Add modem firmware support for multiple RFFE switches (with different addresses) to be set when the modem changes between bands/modes

[Jared]

Hi,

You're correct, the RF Switch is discontinued, and at this point we are still looking for viable replacements. At this point, there isnt a alternative that we have tested and verified that I can suggest.

The Infineon BGS18MA12 looks like a good option as the device can change its address based on the connection of the SCK and SDA lines. This allows two identical chips to be placed back-to-back on the same RFFE bus without an address conflict.

I don't think that it's pin compatible? I think something like this would be closer to a replacement, but I see that it is also marked as discontinued..

regards

Jared 

[FinKM]

Hi Jared,

Okay, thanks for confirming.

Yes, the BGS18MA12 is an RFFE part which leads to the second part of my question about enabling multi-switch RFFE control instead of using the MAGPIO lines. The footprint isn't identical of course, but with all the comms pins on one side f the package it should be a minor layout modification.

Do let me know if you have any information on a potential RFFE implementation.

[FinKM]

Great, thanks. If they can give any idea of practicality and timescales that would be great, we're hoping to agree a final design for our board sooner rather than later and this has a big impact.

[Jared]

Hi Finlay,

Our modem fw developers have evaluated your feature request and has concluded that they will not implement this feature.

Adding a 2nd external MIPIRFFE is a huge ask (given the low usage of the first one even), and a major risk for SW functionality and timings. And it comes at a too late stage regarding SW releasing. So the feature request is rejected.

The thingy:91 development team has already stated that they will avoid any redesign. We have to wait and see how they implement this in a new revision. 

Also, I'm not that experienced with RFFE but the spec seems to mention controlling two slaves: 

regards

Jared 

[FinKM]

Hi Jared,

Can I just confirm that the request has been understood as follows?

I'm not suggesting a full second bus, but just modifying the %XMIPIRFFEDEV command to implement that part of the RFFE spec that you have highlighted to allow two peripheral/slave devices.

The %XMIPIRFFEDEV command takes an RFFE address as an argument which is likely being passed to the underlying RFFE driver. The feature request is to allow the %XMIPIRFFEDEV to take two addresses and sets of parameters, and call the underlying RFFE command twice.

Best,

Finlay

[FinKM]

Alternatively, if the %XMIPIRFFECTRL command is called multiple times with different slave addresses, does the modem already control both slave devices?

The example in section 3.6.2.2.5 of the Hardware Verification Guide gives the following example

AT%XMIPIRFFEDEV=1,6,41,52,184
AT%XMIPIRFFECTRL=1,0,1,28,184
AT%XMIPIRFFECTRL=1,1,1,28,56,3,1,2,A,B,800,C,D,1600,E,F,2200
AT%XMIPIRFFECTRL=1,2,1,28,184
AT%XMIPIRFFECTRL=1,3,1,28,184 AT+CFUN=0

If these commands are called again with another address, are both device addresses accessed? If so then that's all that is needed for our two-switch use case.

AT%XMIPIRFFEDEV=1,6,41,52,184
AT%XMIPIRFFECTRL=1,0,1,28,184
AT%XMIPIRFFECTRL=1,1,1,28,56,3,1,2,A,B,800,C,D,1600,E,F,2200
AT%XMIPIRFFECTRL=1,2,1,28,184
AT%XMIPIRFFECTRL=1,3,1,28,184 AT+CFUN=0

AT%XMIPIRFFEDEV=2,6,41,52,184
AT%XMIPIRFFECTRL=2,0,1,28,184
AT%XMIPIRFFECTRL=2,1,1,28,56,3,1,2,A,B,800,C,D,1600,E,F,2200
AT%XMIPIRFFECTRL=2,2,1,28,184
AT%XMIPIRFFECTRL=2,3,1,28,184 AT+CFUN=0

[Jared]

Hi, 

FinKM said:

Can I just confirm that the request has been understood as follows?

I'm not suggesting a full second bus, but just modifying the %XMIPIRFFEDEV command to implement that part of the RFFE spec that you have highlighted to allow two peripheral/slave devices.

The %XMIPIRFFEDEV command takes an RFFE address as an argument which is likely being passed to the underlying RFFE driver. The feature request is to allow the %XMIPIRFFEDEV to take two addresses and sets of parameters, and call the underlying RFFE command twice.

I'm double checking this with the developers but my understanding based on their feedback is that feature request was understood correct.

FinKM said:

Alternatively, if the %XMIPIRFFECTRL command is called multiple times with different slave addresses, does the modem already control both slave devices?

The example in section 3.6.2.2.5 of the Hardware Verification Guide gives the following example

AT%XMIPIRFFEDEV=1,6,41,52,184
AT%XMIPIRFFECTRL=1,0,1,28,184
AT%XMIPIRFFECTRL=1,1,1,28,56,3,1,2,A,B,800,C,D,1600,E,F,2200
AT%XMIPIRFFECTRL=1,2,1,28,184
AT%XMIPIRFFECTRL=1,3,1,28,184 AT+CFUN=0

If these commands are called again with another address, are both device addresses accessed? If so then that's all that is needed for our two-switch use case.

AT%XMIPIRFFEDEV=1,6,41,52,184
AT%XMIPIRFFECTRL=1,0,1,28,184
AT%XMIPIRFFECTRL=1,1,1,28,56,3,1,2,A,B,800,C,D,1600,E,F,2200
AT%XMIPIRFFECTRL=1,2,1,28,184
AT%XMIPIRFFECTRL=1,3,1,28,184 AT+CFUN=0

AT%XMIPIRFFEDEV=2,6,41,52,184
AT%XMIPIRFFECTRL=2,0,1,28,184
AT%XMIPIRFFECTRL=2,1,1,28,56,3,1,2,A,B,800,C,D,1600,E,F,2200
AT%XMIPIRFFECTRL=2,2,1,28,184
AT%XMIPIRFFECTRL=2,3,1,28,184 AT+CFUN=0

I have to verify this with the developers as well, I'll be back with more.

Also, another engineer suggested two possible workarounds:

• Use a single MIPI RFFE controlled device that can switch both ends of the network, like SKY13552-669LF (granted, it is only 2x SP6T, not SP8T, but we only use 6 states in Thingy:91 anyway)
• Have they considered SKY13418-485LF as a replacement for the Qorvo switch? Looks like a drop-in replacement to me. There are also some SP6T alternatives: SKY13416-485LF and RFSW6062. These are from a cursory look at Mouser, so there might be reasons not to choose them.

regards

Jared 

[Jared]

Hi,

I can confirm that the request was understood correctly. 

FinKM said:

The example in section 3.6.2.2.5 of the Hardware Verification Guide gives the following example

AT%XMIPIRFFEDEV=1,6,41,52,184
AT%XMIPIRFFECTRL=1,0,1,28,184
AT%XMIPIRFFECTRL=1,1,1,28,56,3,1,2,A,B,800,C,D,1600,E,F,2200
AT%XMIPIRFFECTRL=1,2,1,28,184
AT%XMIPIRFFECTRL=1,3,1,28,184 AT+CFUN=0

If these commands are called again with another address, are both device addresses accessed? If so then that's all that is needed for our two-switch use case.

AT%XMIPIRFFEDEV=1,6,41,52,184
AT%XMIPIRFFECTRL=1,0,1,28,184
AT%XMIPIRFFECTRL=1,1,1,28,56,3,1,2,A,B,800,C,D,1600,E,F,2200
AT%XMIPIRFFECTRL=1,2,1,28,184
AT%XMIPIRFFECTRL=1,3,1,28,184 AT+CFUN=0

AT%XMIPIRFFEDEV=2,6,41,52,184
AT%XMIPIRFFECTRL=2,0,1,28,184
AT%XMIPIRFFECTRL=2,1,1,28,56,3,1,2,A,B,800,C,D,1600,E,F,2200
AT%XMIPIRFFECTRL=2,2,1,28,184
AT%XMIPIRFFECTRL=2,3,1,28,184 AT+CFUN=0

From modem developers:

No it doesn't work like that unfortunately. The commands you list are configurations. The actual control of pins happens automatically deep in RF control domain with fast cycle. We can only store and act on one configuration.

regards
Jared