Downlink is not sent on picocell gateway

[dcoati]

Hi,
I see that support for picocell gateway design was introduced in version 2.0.4 (as experimental) following issue #16.

I am using the same gateway as mentioned in the issue (https://www.n-fuse.co/devices/LoRaWAN-Concentrator-Card-mini-PCIe.html) and I am trying to upgrade to the basicstation from the old udp packet forwarder.

To validate the basicstation I am running tests with the https://github.com/lorabasics/basicstation/tree/master/examples/station2pkfwd example in order to avoid making changes on the network server side.

The basicstation works correctly by sending uplinks, but I cannot send any downlink to a lorawan C class device (a downlink not answering an uplink to avoid timing issues). The log of the station reports that the packet was sent correctly, but the lorawan device is not receiving any message.

Has anyone tested downlinks on a picocell gateway on the latest 2.0.6 basicstation release? What situation could cause the station to report that the packet was emitted correctly but effectively not send it?

Here is the log:

2022-05-09 08:40:30.351 [SYS:INFO] Logging : /etc/lora-basic-station/station_log (maxsize=10000000, rotate=3)
2022-05-09 08:40:30.354 [SYS:INFO] Station Ver : 2.0.6(linuxpico/std) 2022-04-29 09:35:36
2022-05-09 08:40:30.357 [SYS:INFO] Package Ver : (null)
2022-05-09 08:40:30.359 [SYS:INFO] mbedTLS Ver : 2.28.0
2022-05-09 08:40:30.362 [SYS:INFO] proto EUI : ::1 (station.conf)
2022-05-09 08:40:30.365 [SYS:INFO] prefix EUI : ::0 (station.conf)
2022-05-09 08:40:30.368 [SYS:INFO] Station EUI : ::1
2022-05-09 08:40:30.370 [SYS:INFO] Station home: ./ (builtin)
2022-05-09 08:40:30.373 [SYS:INFO] Station temp: /var/tmp/ (builtin)
2022-05-09 08:40:30.376 [SYS:WARN] Station in NO-CUPS mode
2022-05-09 08:40:30.584 [TCE:INFO] Starting TC engine
2022-05-09 08:40:30.585 [TCE:INFO] Connecting to INFOS: ws://192.168.100.78:6090
2022-05-09 08:40:30.594 [TCE:INFO] Infos: ::1 muxs-::0 ws://192.168.100.78:6092/router-::1
2022-05-09 08:40:30.595 [TCE:VERB] Connecting to MUXS...
2022-05-09 08:40:30.602 [TCE:VERB] Connected to MUXS.
2022-05-09 08:40:30.904 [S2E:WARN] Unknown field in router_config - ignored: config (0xF7A3E35F)
2022-05-09 08:40:30.904 [S2E:WARN] Unknown field in router_config - ignored: protocol (0xFD309030)
2022-05-09 08:40:30.904 [S2E:WARN] Unknown field in router_config - ignored: regionid (0xE6FFB211)
2022-05-09 06:40:30.906 [HAL:ERRO] [lgw_soft_reset:573] CONCENTRATOR UNCONNECTED
2022-05-09 06:40:30.906 [RAL:INFO] Lora gateway library version: Version: 0.2.2;
2022-05-09 06:40:30.926 [RAL:VERB] Connecting to smtcpico device: /dev/lora
2022-05-09 06:40:31.451 [RAL:INFO] [LGW smtcpico] clksrc=1 lorawan_public=1
2022-05-09 06:40:31.459 [RAL:INFO] RX/TX RF0: 868.475MHz rssi_offset=-166.0 type=2 tx_notch_freq=0
2022-05-09 06:40:31.469 [RAL:INFO] RX RF1: 869.2875MHz rssi_offset=-166.0 type=2 tx_notch_freq=0
2022-05-09 06:40:31.478 [RAL:INFO] [mSF] 0: 868.1MHz rf=0 freq=-375.0 datarate=126
2022-05-09 06:40:31.492 [RAL:INFO] [mSF] 1: 868.3MHz rf=0 freq=-175.0 datarate=126
2022-05-09 06:40:31.502 [RAL:INFO] [mSF] 2: 868.5MHz rf=0 freq= +25.0 datarate=126
2022-05-09 06:40:31.513 [RAL:INFO] [mSF] 3: 868.85MHz rf=0 freq=+375.0 datarate=126
2022-05-09 06:40:31.523 [RAL:INFO] [mSF] 4: 869.05MHz rf=1 freq=-237.5 datarate=126
2022-05-09 06:40:31.534 [RAL:INFO] [mSF] 5: 869.525MHz rf=1 freq=+237.5 datarate=126
2022-05-09 06:40:31.544 [RAL:INFO] channel 6 disabled
2022-05-09 06:40:31.548 [RAL:INFO] channel 7 disabled
2022-05-09 06:40:31.551 [RAL:INFO] channel 8 disabled
2022-05-09 06:40:31.554 [RAL:INFO] channel 9 disabled
2022-05-09 06:40:31.557 [RAL:INFO] SX130x LBT not enabled
2022-05-09 06:40:31.560 [RAL:INFO] Station device: /dev/lora (PPS capture disabled)
2022-05-09 06:40:46.781 [RAL:INFO] Concentrator started (15s217ms)
2022-05-09 06:40:46.842 [S2E:INFO] Configuring for region: EU868 -- 863.0MHz..870.0MHz
2022-05-09 06:40:46.842 [S2E:INFO] DR0 SF12/BW125
2022-05-09 06:40:46.842 [S2E:INFO] DR1 SF11/BW125
2022-05-09 06:40:46.842 [S2E:INFO] DR2 SF10/BW125
2022-05-09 06:40:46.842 [S2E:INFO] DR3 SF9/BW125
2022-05-09 06:40:46.842 [S2E:INFO] DR4 SF8/BW125
2022-05-09 06:40:46.842 [S2E:INFO] DR5 SF7/BW125
2022-05-09 06:40:46.842 [S2E:INFO] DR6 SF7/BW250
2022-05-09 06:40:46.842 [S2E:INFO] DR7 FSK
2022-05-09 06:40:46.842 [S2E:INFO] DR8 undefined
2022-05-09 06:40:46.842 [S2E:INFO] DR9 undefined
2022-05-09 06:40:46.842 [S2E:INFO] DR10 undefined
2022-05-09 06:40:46.842 [S2E:INFO] DR11 undefined
2022-05-09 06:40:46.842 [S2E:INFO] DR12 undefined
2022-05-09 06:40:46.842 [S2E:INFO] DR13 undefined
2022-05-09 06:40:46.842 [S2E:INFO] DR14 undefined
2022-05-09 06:40:46.842 [S2E:INFO] DR15 undefined
2022-05-09 06:40:46.842 [S2E:INFO] TX power: 16.0 dBm EIRP
2022-05-09 06:40:46.842 [S2E:INFO] 16.0 dBm EIRP for 869.4MHz..869.65MHz
2022-05-09 06:40:46.843 [S2E:INFO] JoinEui list: 0 entries
2022-05-09 06:40:46.843 [S2E:INFO] NetID filter: FFFFFFFF-FFFFFFFF-FFFFFFFF-FFFFFFFF
2022-05-09 06:40:46.843 [S2E:INFO] Dev/test settings: nocca=1 nodc=1 nodwell=1
2022-05-09 06:41:10.037 [S2E:VERB] RX 868.1MHz DR0 SF12/BW125 snr=7.5 rssi=-65 xtime=0x97000001E2C3DC - updf mhdr=40 DevAddr=0100000A FCtrl=80 FCnt=8 FOpts=[] 019AE49F..567E mic=-1704839958 (25 bytes)
2022-05-09 06:41:25.115 [S2E:WARN] RxDelay mapped to 1 as it was not present!
2022-05-09 06:41:25.115 [S2E:VERB] 58a0:cb00:c30:3300 diid=1536 [ant#0] - starting TX in 19ms762us: 869.525MHz 16.0dBm ant#0(0) DR0 SF12/BW125 frame=600A0000018008000A3A2E19B1012E94 (16 bytes)
2022-05-09 06:41:35.153 [S2E:INFO] TX 58a0:cb00:c30:3300 diid=1536 [ant#0] - dntxed: 869.525MHz 16.0dBm ant#0(0) DR0 SF12/BW125 frame=600A0000018008000A3A2E19B1012E94 (16 bytes)

[beitler]

Thank you, @dcoati, for submitting the issue. This issue has been brought to our attention recently.
Enabling full debug prints on the HAL shows that the HAL blocks for 10 seconds on reading the response to the lgw_send protocol command. 10 seconds happens to be the timeout on the picocell MCU firmware waiting for the TX_DONE interrupt from the radio.

This problem seems to be related to the n-fuse hardware as it does not occur on the Semtech picocell reference design. We are in contact with n-fuse to get this sorted out and will let you know in this issue tracker about the progress.

[dcoati]

Thank you, @beitler, for the quick feedback, glad to know that this is being worked on.

I was just wondering if you have anything else to share about the reason which makes the old packet forwarder (https://github.com/Lora-net/picoGW_packet_forwarder) work correctly even with the n-fuse hardware, I would be very interested to hear about it.

Thanks again.

[beitler]

Hi @dcoati,

the reason for the MCU timing out on the TX_DONE interrupt is most likely because the TX command is scheduled too late. In such a case the TX command is sent to the sx130x after the corresponding xtick already expired.

LoRa Basics Station keeps an internal queue of downlink jobs. The TX command to the sx130x is scheduled with a particular margin before the transmission time. This margin (called TX_AIM_GAP) needs to be calibrated to the speed of the interface with the sx130x. In the case of the n-fuse hardware, the interface is UART. Given that the TX command in the picocell reference design is 286 bytes long, the transmission of the TX command over a 115200 baud UART to the sx130x takes at least 20ms. By default TX_AIM_GAP in LoRa Basics Station is set to 20ms, which is based on the assumption of a faster SPI based interface. For UART based interfaces, TX_AIM_GAP needs to be adjusted. You can set TX_AIM_GAP via environment variable:

TX_AIM_GAP='"40ms"' ./station -p

This sets the TX_AIM_GAP to 40ms which should be good enough for a 115200 baud UART interface. The drawback of a large TX_AIM_GAP is that TX jobs cannot be packet as tightly and the overall downlink capacity of the gateway is reduced. Gateway manufacturers should be interested to implement fast interfaces to the sx130x in order to be able to guarantee high downlink capacity.

Here is an image that visualizes the effect of the TX_AIM_GAP on the TX command scheduling:

[dcoati]

Thank you for the explanation,

I tested with TX_AIM_GAP set to 40ms and it works correctly.

I find it worrying that this situation is not reported as an error, but I guess this is the picocell MCU firmware fault considering that it does not return any error in case of lgw_send timeout.

[beitler]

Thanks for your confirmation.

Please allow me to close the issue as a resolution was found. Thanks!