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.

[Jared]

Hi,

Discussed this with our HW developers and they haven't really decided on anything yet but they doubt that they will do anything that would require a redesign of the matching network. They didn't really have anything to share regarding a potential RFFE implementation at this point.

regards

Jared 

[FinKM]

Hi Jared,

Okay not sure if it's the same team, but can you ask the SW/Firmware team about updating the modem firmware to allow multiple RFFE switches to be controlled automatically? This would allow us to progress the design in-house - we're happy to make the layout and tuning changes as required.

Best,

Finlay

[Jared]

Hi Finlay,

I have forwarded this feature request to our Thingy:91 developers.

regards

Jared

[FinKM]

Okay, are they the team working on the modem software/firmware itself? This won't just be an issue for the Thingy:91

[Jared]

Hi,

Yes, both!

regards

Jared 

[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