How to configure the COEX interface as input on nRF9160

[psychogenic]

Greetings,

The only examples I can seem to locate of using the Coexistence Interface on nRF9160 is with the internal GPS but the documentation states that "COEX0: Input to the LTE modem from the external device. When active high, indicates that the external device transceiver is turned on." 

That's the function I'm looking for, where an external device tells the '9160 to be quiet while it's using the airwaves.

I'm not certain I get the  %XCOEX0 AT command, as it seems to relate to using COEX0 as an output that's tied to internal GPS use.  My questions:

1. Can COEX0 be used as an input from external devices to keep the LTE radio quiet?
2. Does it need to be configured to behave this way and, if so, how?

Thanks for any hints on this and please don't hesitate if you need more info.

[Heidi]

Hi!

Can COEX0 be used as an input from external devices to keep the LTE radio quiet?

As of today, this functionality is unfortunately not implemented. 

For now, you can only set this as an output, as per the AT command documentation you refer to AT%XCOEX0.

If you want more information on future roadmaps regarding this functionality, you can contact your regional sales manager. PM me your location and I can give you the contact information. 

Best regards,

Heidi

[psychogenic]

Oh, hum.  Ok, so the workaround is to do it "manually"?  I.e. tell the LTE to shutdown before operating other transmitters?

[Heidi]

In theory yes, but what is the other transmitter you are using?

[psychogenic]

The current board has an nRF9160 and an nRF5340, and we intend to use the on-board GPS as well and perhaps some other radio stuff in future revisions.

So, in short, I've got an ORed logic where any active transmitter (including a GPIO from the '9160 to indicate when we're using GPS) drives the COEX0 line high and the hope was to leave the LTE alone and rely on coexistence to quiet the transmissions while any of the others want to be active.

[Heidi]

Okay, so the suggested work-around is to use AT+CFUN=20 to suspend LTE and let GPS run. 

However, it is not really necessary for the application to try to schedule the modem and GNSS. Modem firmware has a built-in scheduling system so that the GNSS tracker will run during PSM and eDRX (and even normal DRX) gaps. Of course, to find a (cold start) fix a longer continuous GNSS period is needed, eDRX/DRX cycle is usually not enough for that.

Regarding LTE vs BLE, the BLE can avoid sending when COEX2 (automated signal from nRF91) is high. There is no way for BLE to suspend LTE modem via a signal to any COEX pin.

[psychogenic]

All right, CFUN=20 is what the a-gps sample uses, so I'll stick with that.

As for BLE side controlling the LTE modem: ok, will work around this with software, but please confirm that I did read the docs correctly and that, in theory, this will be possible through COEX0.  Is this so?

As a PS, it would be really sweet if the docs would mention when a feature is coming soon rather than actually available.

[Heidi]

psychogenic said:

but please confirm that I did read the docs correctly and that, in theory, this will be possible through COEX0.

 Yes, you read the docs correctly.

psychogenic said:

As a PS, it would be really sweet if the docs would mention when a feature is coming soon rather than actually available.

I completely agree and I'll try to get the documentation improved to reflect the current status of development.