FSK downlinks do not seem to be transmitted

adriansmares commented 2 years ago

Background

While working on https://github.com/TheThingsNetwork/lorawan-stack/pull/5727 I've also tested how The Things Stack behaves while using the standard channel (SF7BW250) and the FSK channel in the EU868 band. I did not have any issues with the SF7BW250 channel - bidirectional traffic seems to work just fine via BasicStation. For the FSK channel, downlinks do not seem to work somehow - I cannot fully isolate if they are not emitted by the gateway, or the end device does not demodulate them at the right time.

Test setup

End device firmware - LoRaMac-node 5.0.0 - using the periodic-uplink-lpp sketch
End device hardware - LR1110DVK1TBKS, with LR1110 being flashed with the transceiver firmware lr1110_trx_0x0307
Gateway hardware - MultiTech MTCDTIP-266A
Gateway firmware - Official 6.0.0 - this firmware has station 2.0.6

Test run itself

End device is switched to data rate 7 on frequency 868.8 - it starts sending uplinks on this data rate
The NS starts asking the end device to switch to data rate 5 via LinkADRReq (sticky until explicitly accepted / rejected)
The downlink is scheduled via the gateway, station itself reports a dntxed for that downlink, but the end device does not report receiving any downlink, and of course does not report a LinkADRAck

There are many moving parts here - the end device, the end device firmware, the LNS, the gateway hardware and firmware. I've ran the same test with the same hardware, but changed the forwarder to the UDP packet forwarder: the downlinks were received by the end device (I checked via serial, and this was also visible in the LinkADRAck being sent immediately and the end device switched the channel).

I'm inclined to say that this is either a station bug, or at least the way The Things Stack interacts with station is not correct.

Configuration and logs

station.conf

{
    "SX1301_conf": {
        "lorawan_public": true,
        "clksrc": 1,
        "pps": true,
        "device": "/dev/spidev0.0",
        "radio_0": {
            "type": "SX1257",
            "rssi_offset": -166.0,
            "tx_enable": true,
            "antenna_gain": 0
        },
        "radio_1": {
            "type": "SX1257",
            "rssi_offset": -166.0,
            "tx_enable": false
        }
    },
    "station_conf": {
        "routerid": "<WILL-BE-AUTO-REPLACED-WITH-LORA-EUI>",
        "euiprefix": "::0",
        "log_file": "/var/log/station.log",
        "log_level": "XDEBUG",
        "log_rotate": 0,
        "log_size": 10000000
    }
}

station.log

beitler commented 2 years ago

Hi @adriansmares,

thanks for posting this well structured issue. From the logs that you posted it does not seem that the station core is failing to schedule FSK downlinks systematically. The DR handling/mapping seems fine. My feeling is that we should look closer at what the HAL is doing. For that it would make sense to engage the GW vendor as many GW vendors have their own 'patched' versions of the HAL. Did you reach out to MultiTech about this issue? ~Is FSK downlink working with the packet forwarder?~ (Sorry, you mentioned that)

adriansmares commented 2 years ago

Is FSK downlink working with the packet forwarder?

Yes, the downlinks are properly demodulated and the MAC layer also receives them.

Did you reach out to MultiTech about this issue?

Not yet, I wanted to double check that I am not missing something obvious.

Some new hardware tests:

The Things Indoor Gateway - `2.0.4(minihub/debug) 2020-05-07 16:03:52`

FSK downlinks do not reach the end device, while using station.
Cannot test with UDP packet forwarder for obvious reasons.

Dragino LPS8 - `2.0.6(mips-openwrt/dragino) 2021-07-29 07:22:03`

FSK downlinks do not reach the end device, while using station.
UDP packet forwarder works correctly for FSK downlinks.

Laird Sentrius RG1xx - `2.0.5(laird/std) 2021-12-17 17:55:43`

FSK downlinks do not reach the end device, while using station.
UDP packet forwarder does not work correctly for FSK downlinks.

On the Sentrius I actually have transmission failures:

Aug 29 18:00:55 2022-08-29 18:00:55.028 [S2E:WARN] ::1 diid=272 [ant#0] - unable to place frame
Aug 29 18:00:55 2022-08-29 18:00:55.028 [S2E:VERB] ::1 diid=272 [ant#0] - class A has no more alternate TX time
Aug 29 18:00:55 2022-08-29 18:00:55.028 [S2E:ERRO] ::1 diid=272 [ant#0] - radio layer failed to TX - trying alternative
Aug 29 18:00:55 2022-08-29 18:00:55.028 [RAL:ERRO] lgw_send failed
Aug 29 18:00:55 2022-08-29 18:00:55.028 [S2E:VERB] ::1 diid=272 [ant#0] - starting TX in 13ms971us
Aug 29 18:00:54 2022-08-29 18:00:54.353 [AIO:XDEB] [6|WS] > PONG
Aug 29 18:00:54 2022-08-29 18:00:54.353 [AIO:XDEB] [6|WS] < PING ()
Aug 29 18:00:53 2022-08-29 18:00:53.834 [S2E:DEBU] ::1 diid=272 [ant#0] - next TX start ahead by 1s208ms
Aug 29 18:00:53 2022-08-29 18:00:53.833 [AIO:XDEB] [6|WS] < {"msgtype":"dnmsg","DevEui":"00-00-00-00-00-00-00-01","dC":0,"diid":272,"pdu":"6044190026807000012c79df826b","RxDelay":1,"RX1DR":7,"RX1Freq":868800000,"priority":25,"xtime":70650219325143523,"rctx":0,"MuxTime":1661796053.83364}
Aug 29 18:00:53 2022-08-29 18:00:53.077 [AIO:XDEB] [6|WS] > {"msgtype":"updf","MHdr":64,"DevAddr":637544413,"FCtrl":128,"FCnt":6435,"FOpts":"","FPort":1,"FRMPayload":"6D","MIC":1332314245,"RefTime":1661796053.076807,"DR":5,"Freq":867500000,"upinfo":{"rctx":0,"xtime":70650219324160868,"gpstime":0,"fts":-1,"rssi":-60,"snr":6.5,"rxtime":1661796053.077433}}
Aug 29 18:00:53 2022-08-29 18:00:53.077 [S2E:VERB] RX 867.5MHz DR5 SF7/BW125 snr=6.5 rssi=-60 xtime=0xFB00000A1EBB64 - updf mhdr=40 DevAddr=260027DD FCtrl=80 FCnt=6435 FOpts=[] 016D mic=1332314245 (14 bytes)
Aug 29 18:00:53 2022-08-29 18:00:53.076 [any:XDEB] RX mod=LORA f=867500000 bw=125 sz=14 dr=2 40DD270026802319016D8580694F
Aug 29 18:00:51 2022-08-29 18:00:51.846 [AIO:XDEB] [6|WS] > {"msgtype":"updf","MHdr":64,"DevAddr":637544260,"FCtrl":128,"FCnt":4932,"FOpts":"","FPort":1,"FRMPayload":"8C","MIC":931420412,"RefTime":1661796051.845343,"DR":5,"Freq":867900000,"upinfo":{"rctx":0,"xtime":70650219322916612,"gpstime":0,"fts":-1,"rssi":-60,"snr":8.5,"rxtime":1661796051.845951}}
Aug 29 18:00:51 2022-08-29 18:00:51.845 [S2E:VERB] RX 867.9MHz DR5 SF7/BW125 snr=8.5 rssi=-60 xtime=0xFB00000A0BBF04 - updf mhdr=40 DevAddr=26002744 FCtrl=80 FCnt=4932 FOpts=[] 018C mic=931420412 (14 bytes)
Aug 29 18:00:51 2022-08-29 18:00:51.845 [any:XDEB] RX mod=LORA f=867900000 bw=125 sz=14 dr=2 4044270026804413018CFC588437
Aug 29 18:00:50 2022-08-29 18:00:50.044 [AIO:XDEB] [6|WS] > {"msgtype":"updf","MHdr":64,"DevAddr":637540676,"FCtrl":144,"FCnt":981,"FOpts":"","FPort":2,"FRMPayload":"55139245C88AB1","MIC":1977097225,"RefTime":1661796050.043660,"DR":7,"Freq":868800000,"upinfo":{"rctx":0,"xtime":70650219321143523,"gpstime":0,"fts":-1,"rssi":-40,"snr":0,"rxtime":1661796050.044281}}

I can try to contact the gateway manufacturers, but given that even the TTIG's cannot send FSK downlinks, is there something else that we can try to rule out ?

beitler commented 2 years ago

Thanks for the analysis, @adriansmares. We will try to reproduce and come back to you.

Did you use the same end-device hardware/firmware in these tests?

adriansmares commented 2 years ago

Did you use the same end-device hardware/firmware in these tests?

Yes. The gateway used was only thing changed between tests - everything else is as in the original setup.

beitler commented 2 years ago

Hi @adriansmares,

indeed the issue lies in the fact that basics station does not attach the CRC to FSK downlinks. LoRa-modulated downlinks don't require a CRC, while FSK-modulated downlinks do. This is something we overlooked. A fix is on its way with the next release.

As a work around the LNS could explicit set the CRC to be added in the dnmsg structure by setting the addcrc field to true: https://github.com/lorabasics/basicstation/blob/ba4f85d80a438a5c2b659e568cd2d0f0de08e5a7/src/s2e.c#L1448-L1450

Of course, in the next version, the LNS will not have to do that work around, as the design principle of basics station aims at encoding all phy level parameters in the single DR field.

Could you try explicitly setting the addcrc field and verify that the downlinks are correctly received? Thanks in advance!

yannickgagne commented 2 years ago

Just want to say that I'm experiencing the same behavior on my gateway running on RPi+RAK Hat+RAK2287. If I can help in any way, I'm here.

beitler commented 2 years ago

Thanks for confirming @yannickgagne . Indeed, this issue will be addressed in the upcoming release.

lorabasics / basicstation