• State Verified Answer
  • Replies 7 replies
  • Subscribers 62 subscribers
  • Views 4037 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 229299
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF9160 LTE modem coexistence interface

ERIK

I'm trying to understand how to make use of the nRF9160 LTE modem coexistence interface in a design.  I started asking about this topic in another thread about the BLE Gateway sample app: https://devzone.nordicsemi.com/f/nordic-q-a/46778/lte-sensor-gateway-sample-app

I've seen the spec entry for the LTE modem coexistence interface here: https://infocenter.nordicsemi.com/index.jsp?topic=%2Fps_nrf9160%2Fdita%2Fchapters%2Fradio_lte%2Fgnss_coext_if.html

However, I'm looking for more information.  Is there any further documentation of this interface?  In general, how is this interface intended to be used in a design?  Can you describe its use?  Can you give an example?

Without knowing more, I do still have some other questions:

Are these pins already handled in modem firmware or elsewhere in the SDK, or do they need to be supported by application code written by your users?  Is there source code that I can look at to help understand how the interface is used?

If already supported by code:

How is the interface enabled/disabled?

With COEX0, does a high input inhibit transmit by the LTE modem?

How is COEX1 intended to be used?  I don't understand what is meant by "Active high time mark pulse, which is synchronous to LTE system time.".

Thank you,

Erik

  • 0

    Hi Erik,

    For the nRF91 DK:

    The number of GPIO pins we have chosen between the nRF9160 and the nRF52840 on the DK is to give users flexibility in choice of IF, i.e. UART, SPI, 2wire with some extra interrupt ins. if needed.
    That means the user doesn't have to use 6 GPIOs, a simple UART IF would for example only need 2 GPIOs.

    When it comes to the coexistence interface this is mapped out to be up to 3 pins, aligning with what many other have in their coexistence interface.

    (However, at the moment we are only using one of the pins, basically a signal that goes active when the modem in nRF9160 goes active)

    The functionality of the COEX pins are handled by the modem firmware.

    • So for your design you currently need 1 COEX, but you should route 2-3 for future proofing.

    So basically you may choose to use only one pin in the coex interface, and for the data interaction you can use any of pins on both nRF91 and nRF52.

    Best Regards,

    Martin L.

  • 0 in reply to Martin Lesund

    So you have implemented COEX2, it sounds like.  Without COEX0, how does one ensure that the modem won't transmit while the BLE MCU is transmitting?

    Can you point me to an explanation of how the other pins might work?  You said it aligns to what many others have for LTE coex interfaces.

    Is there a "typical" or recommended encoding to use for data sent over the UART, from the external MCU, to be transmitted by the nRF9160?  A convenient approach, or is it best to tailor that to the particular data needing to be sent by the modem?

    Thanks

  • +1

    Hi Erik,
    So it's the COEX0 that's used in the LTE Sensor Gateway sample.

    The nrf52 uses the PA/LNA pin to say to the modem that it is using BLE to Transive/receive via the COEX0, so the modem won't be do any communication at that time.

    The other COEXs pins will behave like described here, but I will ask internally if there are any more details I can share with you about this.

    The protocol to use for sending data is more or less up to the user.

    e.g. 

    You get lower power consumption with SPI, but then you would have to sacrifice more GPIOs than UART.

    If you are wanting to use UART flow control would be adviced to have enabled.

    Please take a look at the LTE Sensor Gateway sample and see on how this is handled there.

  • 0 in reply to Martin Lesund

    Slightly confused with this at the moment.  You said that the only part of the LTE Coexistence being used is the output saying the modem is active.  Which I believe is COEX2 in the documentation.  However, you've now noted that the LTE Sensor Gateway example is using COEX0 as an input to the nRF91.  This is especially confusing because in another ticket I asked about coexistence with the LTE Sensor Gateway and was told that the sample app did nothing for coexistence:

    https://devzone.nordicsemi.com/f/nordic-q-a/46778/lte-sensor-gateway-sample-app

    However, it sounds like that's incorrect.  That's great, because it gives me something to look into.

    So, the modem firmware will not allow the modem to start to transmit if the COEX0 input is active?  Would I be correct in assuming that if the pin goes high during transmission that the modem would complete it's transmission and then be inhibited?

    I'm still trying to understand how eDRX and PSM work, but what would the implications be if COEX0 were active when it was given its chance to transmit?  Would it have to wait another cycle to transmit, or just delay the short time until the COEX0 input is inactive and then transmit?

    Thanks for all of the info!

  • 0 in reply to Martin Lesund

    Martin, why do you advise that HW flow control be enabled for the UART in this case?

Related