EM7455, GNSS RX: switch(es) between GNSS IN and AUX MHF4 - control?

[frr]

Dear fellow Sierra users,

today I have a question regarding the multiple antenna ports of the EM7455. The following is a snippet from the Product Technical Spec:

I.e.: three ports, Main is for 3GPP mobile data (WWAN), GNSS is for GPS (and friends), and, AUX is special: it can work as a second port either for the WWAN or for the GNSS.
In this topic, I’m asking specifically about the GNSS side of things.

And my main question is: how is this multiplex of GNSS input ports cotrolled?

The tech spec document actually provides more detail, there’s a block diagram:

Based on this picture, I can make my questions a little more detailed:

• What software component decides, which route gets taken?
• i.e. whether AUX gets to serve the GNSS or the “3GPP RX diversity” ?
• Also, speaking of GNSS input, how does the switch between “dedicated GNSS in” vs. AUX get flipped?
• Is there a way to learn the status of these switches?
• Is there a way to control these switches explicitly?
• If the AUX port gets to serve the WWAN function, does it mean that the GNSS route gets cut, or do the two work simultaneously?

Why am I asking: an end customer claims that on several pieces of newly deployed tablet PC’s, containing the EM7455, “out of the box” the GNSS fails to use an external antenna (likely on the AUX port - will check). With some degree of certainty (not very high) it seems that this gets rectified, if you bring the tablet PC outdoor and let it catch a fix using its build-in antenna (likely on the GNSS port). After that, the failover to an external antenna works like a charm.

I’ve noticed some forum posts mentioning AT!CUSTOM=“GPSLPM”,[0|1] as a possible influence… except that, in my case W_DISABLE doesn’t seem to be in the game (pending a response from the vendor), and the problem description doesn’t match the LPM explanation: in the “flawed” state, the NMEA does not shut off entirely, we do get NMEA sentences, just the number of SV’s reported “good” is low (3-4) and the signal quality is poor. That said, I have yet to make the customer check AT!GSTATUS? if the problem resurfaces with another factory-fresh piece.

We’re aware that it takes at least 12 minutes to download the complete almanach.
The receiver actually looks happy much faster - in a minute or two.
While trying to reproduce the problem, I’ve turned off the PC, removed its main battery (it’s a mobile platform with a hefty LiIon pack) and let it “chill out” overnight. In the morning, after start, the GPS engine of the EM7455 initially reported no satellites in view and “all zeroes” position, but achieved an initial fix in a minute or two, with about 6 satellites good already. I don’t think this meant that it had the full almanach already - I know that the cheap receivers are “casual” like that. After a couple more minutes of runtime, I have around 9 satellites good (if not more). I have a 40dB antenna on the roof, with about 10 m of H500 cable. The SNR levels correspond to that - typically over 40 dB.

I’ve politely scorned the customer enough for potential obvious PEBKAC - poor view of the sky, broken antenna cable or some such. He is not a rookie, he has multiple pieces of the hardware and antennas, he seems to know what he’s doing and reporting.
Anyway - I’m getting off topic. Any clues as to how/why the initial reception could be so poor, would be welcome.

[frr]

I’ve been wondering about the dual function of the AUX port. Is this dual function “shared”, i.e. works for LTE RX, and simultaneously for GNSS RX? Or, is there an exclusive switch between this and that function? Because if this is exclusive, …

Consider a scenario, where the GNSS antenna on the AUX port is not very well filtered and not very well positioned. And, there’s a strong LTE transmitter near by, in a nearby band. Would the LTE module choose to use the AUX for LTE RX, thus cutting off the GNSS receiver stack from its AUX antenna?

Even if they’re simultaneous, is there maybe an AGC’ed LNA stage before the splitter? That might suppress GNSS reception in the presence of a strong nearby LTE tower…

So again… is there any way to check and/or steer these switches downstream of the AUX input port?
(Does Skylight have something to do with this? I haven’t installed it yet)

[frr]

I’ve just learned about AT!RXDEN and AT!ANTSEL.
At a closer look, they are probably irrelevant to GNSS, and possibly to the “AUX routing selection algorithm” that I’m trying to nail down.

AT!RXDEN is related to LTE RX only - it tells the LTE baseband to consider AUX for diversity, or not, or as a primary RX path.

AT!ANTSEL is not related to the inner signal path downstream of the AUX port. Instead, it is related to a potential external mux = a board-specific arrangement around the EM7455. I.e., the board-level integrator may have decided to use several narrow-band antennas, and have a mux on board to switch these to the MAIN (and possibly AUX, this is not clarified). The AT!ANTSEL is used to specify how GPIO’s are to be used to select between the possibly several antennas. You can specify a different bitwise combination of GPIO outputs per band.
Note that again this is related to LTE RX/TX - not much use for GNSS.