Gateway TR Switching time in general and SPI vs. USB etc

LoRa gateways receive but also occasionally transmit downlink message to nodes - OTAA joins, ADR tuning, etc in addition to application downlinks. While premium models with diplexers do exist, it’s well known that an ordinary gateway has to stop receiving while it transmits.

But how quickly can a gateway start receiving a packet again after it has transmitted? In a location with a lot of nodes, this would be key to scaling, because any delay there increases the “cost footprint” of sending a downlink even beyond the duration of the downlink packet itself.

  • I’ve heard concerns about the RF stages themselves possibly taking time to switch modes or the receiver to recover to full sensitivity. Anyone know if this is in fact an issue, and typical recovery times?

  • Semtech deprecated support for concentrator chips interfaced by way of a USB-SPI bridge, under the correct argument that this adds extra latency around all SPI operations. But how much impact does this have? Does anyone have figures for recovery time with an FT2232 vs native SPI interface? Does this latency also complicate the JIT operations the newer Semtech packet forwarder does to model the gateway’s timestamp counter and manage the queue of packets to be sent? (Although the FTDI code is gone from the Semtech repos, there are 3rd party forks that put this back in, my impression is that the packet forwarder with jit will try to run on top of them, though unclear how well it manages to).

  • SPI interface can run at different speeds, say 1 - 10 MHz. A few designs are constrained to the lower end of that range (for example the RAK2247 has a slow and unecessary level translator chip). Is it known what impact the utilized SPI speed has on turnaround time?

If no one knows the answers to these, I could sit down and write code to run actual tests, and may ultimately do that anyway - but as they say “two months in the lab will save you a half hour in the library”. Several searches for this information here and on the web in general haven’t found it, but thought I’d ask before I actually start coding up tests.

I am one of the people adding the USB support back in to support the first generation MultiTech LoRaWAN concentrator cards with MP forwarder. The JIT enabled forwarder will run happily with it the USB concentrator, however you will have problems with timing if the card needs to send two messages with little time in between as the second message might not make it to the concentator in time (due to the bit bang overhead)
From my tests and the feedback I’ve got over the last few years using USB will hurt in busy locations where many packets arrive in short amounts of time and the USB overhead makes it hard for the software to get all data from the concentrator card without loosing data. Locations with a lot of downlink traffic (which is a problem by itself) are impacted as well.
Using slow SPI connections will have the same result, the question is at which speed it will be noticeable.