brocaar / chirpstack-network-server

ChirpStack Network Server is an open-source LoRaWAN network-server.
https://www.chirpstack.io
MIT License
1.49k stars 546 forks source link

LoRa reply to a FSK packet #232

Closed tommas-factorylab closed 6 years ago

tommas-factorylab commented 7 years ago

Hi,

I think I have found a bug. When a FSK message is received and requires a reply, the command issued to the gateway does not contain a code rate. This causes the gateway to not send the reply. This is most likely due to the fact that FSK messages do not have a code rate (as far as I know) and thus a line like the following would fail: reply.coderate = receivedPacket.coderate

MQTT log: `gateway/???/rx {"rxInfo":{"mac":"*","time":"2017-08-22T10:57:55.693913Z","timestamp":787458244,"frequency":868800000,"channel":9,"rfChain":1,"crcStatus":1,"codeRate":"","rssi":-43,"loRaSNR":0,"size":???,"dataRate":{"modulation":"FSK","bitRate":50000}},"phyPayload":"???"}

gateway/???/tx {"txInfo":{"mac":"*","immediately":false,"timestamp":793458244,"frequency":869525000,"power":14,"dataRate":{"modulation":"LORA","spreadFactor":12,"bandwidth":125},"codeRate":"","iPol":null},"phyPayload":"???"}`

Please note that this only occurs when using FSK and confiruing the server either sends in RX2 or when RX1DrOffset >= 1.

I am not sure what the solution is, as the LoRaWAN specification does not state anything about the code rate to use. Any device is free to choose their code rate as far as I know, but any reply should use the same code rate. As FSK does not work with code rates and the most common code rate is "4/5", I think that "4/5" would be the best choice. I believe the code rate used in transmitted in the PHY_HEADER of any LoRa packet and thus does not have to be matched with the receiving device.

I hope this helps. Thanks in advance.

brocaar commented 7 years ago

Thanks for reporting. You're right, LoRa Server uses the codeRate of the uplink for the downlink, which causes the above situation (blank code rate). I also have to dig a bit deeper into this to find out what code date must be used in the above situation.

tommas-factorylab commented 7 years ago

I think the issue is also present when replying with a FSK message as it contains the codeRate value. MQTT log: gateway/???/tx {"txInfo":{"mac":"???","immediately":false,"timestamp":1385557694,"frequency":868800000,"power":14,"dataRate":{"modulation":"FSK","bitRate":50000},"codeRate":"","iPol":null},"phyPayload":"???"}

The code rate is removed by the bridge, the packet forwarder receives the following: JSON down: {"txpk":{"imme":false,"tmst":206996899,"freq":868.8,"rfch":0,"powe":14,"modu":"FSK","datr":50000,"fdev":25000,"ipol":false,"size":???,"data":"???"}}

I do not receive the packets on my end device. The RN2483 does not receive them either. I do not detect the packets on my spectrum analyzer, but always have had difficulties detecting FSK messages (as they are transmitted very fast, and my spectrum analyzer is quite slow). The statistics of gateway do indicate that it transmits these packets: RF packets sent to concentrator: 3 (36 bytes) TX errors: 0 TX rejected (collision packet): 0.00% (req:24, rej:0) TX rejected (collision beacon): 0.00% (req:24, rej:0) TX rejected (too late): 0.00% (req:24, rej:0) TX rejected (too early): 0.00% (req:24, rej:0)

I am unsure if these FSK downlink packets are transmitted. Have you tested this?

Thanks in advance

brocaar commented 6 years ago

Sorry this took a while but it should be fixed now :-)