search

pycom / pycom-libraries

MicroPython libraries and examples that work out of the box on Pycom's IoT modules
330 stars 379 forks source link

Nanogateway downlink issues US915 #124

Open r4ph431dc opened 4 years ago

r4ph431dc commented 4 years ago

What are the steps to reproduce this issue?

  1. I send a tx with confirmation with 915.2MHz
  2. TTN receives ok and shows the frequency downlink wrong (869.525MHz)

What happens?

I'm testing Nanogateway with a Lopy4. I'm using US915. In ABP with unconfirmed tx, works. But with a confirmed tx, TTN receive, but the downlink is a wrong frequency and the nanogateway stop work. As a device node i'm using RN2903 transmiting only in 915.2MHz. The nanogateway is configured at the same channel, 915.2MHz. abp cnf falha

What were you expecting to happen?

I was expecting to see a correct frequency downlink.

Any logs, error output, etc?

[ 2.881] Starting LoRaWAN nano gateway with id: b'3C71BFFFFE8752C0' [ 7.355] WiFi connected to: velox ap 303 [ 7.363] Syncing time with pool.ntp.org ... [ 7.521] RTC NTP sync complete [ 8.045] Opening UDP socket to router.eu.thethings.network (52.169.76.203) port 1700... [ 8.062] Setting up the LoRa radio at 915.1999 Mhz using SF10BW125 [ 8.073] LoRaWAN nano gateway online [ 8.079] You may now press ENTER to enter the REPL [ 42.936] Received packet: {"rxpk": [{"data": "gGIbAiYAHwAB4phJHYzX", "time": "2020-06-28T19:27:11.396648Z", "chan": 0, "tmst": 42915710, "stat": 1, "modu": "LORA", "lsnr": 8.0, "rssi": -37, "rfch": 0, "codr": "4/5", "freq": 915.2, "datr": "SF10BW125", "size": 15}]} [ 43.199] Push ack [ 47.389] Received packet: {"rxpk": [{"data": "gGIbAiYAHwAB4phJHYzX", "time": "2020-06-28T19:27:15.851636Z", "chan": 0, "tmst": 47371232, "stat": 1, "modu": "LORA", "lsnr": 8.0, "rssi": -38, "rfch": 0, "codr": "4/5", "freq": 915.2, "datr": "SF10BW125", "size": 15}]} [ 47.672] Push ack [ 51.802] Received packet: {"rxpk": [{"data": "gGIbAiYAHwAB4phJHYzX", "time": "2020-06-28T19:27:20.263653Z", "chan": 0, "tmst": 51783563, "stat": 1, "modu": "LORA", "lsnr": 8.0, "rssi": -37, "rfch": 0, "codr": "4/5", "freq": 915.2, "datr": "SF10BW125", "size": 15}]} [ 52.165] Push ack [ 56.228] Received packet: {"rxpk": [{"data": "gGIbAiYAHwAB4phJHYzX", "time": "2020-06-28T19:27:24.690616Z", "chan": 0, "tmst": 56209946, "stat": 1, "modu": "LORA", "lsnr": 8.0, "rssi": -37, "rfch": 0, "codr": "4/5", "freq": 915.2, "datr": "SF10BW125", "size": 15}]} [ 56.492] Push ack [ 58.339] Pull ack [ 58.373] Downlink timestamp error!, t_us: 4294790082 [ 58.383] Pull rsp [ 58.417] Downlink timestamp error!, t_us: 4281450966 [ 58.428] Pull rsp [ 58.461] Downlink timestamp error!, t_us: 4285862809 [ 58.472] Pull rsp [ 58.507] Downlink timestamp error!, t_us: 4290229674 [ 58.517] Pull rsp [ 60.652] Received packet: {"rxpk": [{"data": "gGIbAiYAHwAB4phJHYzX", "time": "2020-06-28T19:27:29.114448Z", "chan": 0, "tmst": 60633939, "stat": 1, "modu": "LORA", "lsnr": 8.0, "rssi": -37, "rfch": 0, "codr": "4/5", "freq": 915.2, "datr": "SF10BW125", "size": 15}]} [ 60.915] Push ack [ 62.132] Pull rsp Unhandled exception in callback handler Traceback (most recent call last): File "nanogateway.py", line 426, in File "nanogateway.py", line 363, in _send_down_link ValueError: frequency 869525000 out of range

Any other comments?

I'm using no board. Only a ftdi with lopy4. The same issue happens with a join OTAA.

What versions of software are you using?

robert-hh commented 4 years ago

TTN changed it's habit to change the downlink frequency for SF10 and up. Then they send the downlink with SF9 at 869.525 MHz. That's something the Pyccom firmware rejects. For the US regions it expects the frequency in the range 902-928 MHz. I'm not sure if that is a bug at TTN or an omission of PyCom. You can try to avoid that by using a lower (=faster) spreading factor, like SF7. Besides that, I'm surprised that it uses that frequency in the US region. The other problem I see in the logs are these downlink timestamp errors. These happen, when the downlink packet arrives too late at the gateway. That is typically cause by a slow network. Besides that, using the Pycom Development modules as gateway is a very limited set-up.

robert-hh commented 4 years ago

Looking at the TTN site, it may be that you configured your gateway for the wrong frequency plan. 869.525 MHZ is only used for the EU868 plan. The frequency plan is selected in the settings tab of the gateway at the TTN console.

r4ph431dc commented 4 years ago

TTN changed it's habit to change the downlink frequency for SF10 and up. Then they send the downlink with SF9 at 869.525 MHz. That's something the Pyccom firmware rejects. For the US regions it expects the frequency in the range 902-928 MHz. I'm not sure if that is a bug at TTN or an omission of PyCom. You can try to avoid that by using a lower (=faster) spreading factor, like SF7. Besides that, I'm surprised that it uses that frequency in the US region. The other problem I see in the logs are these downlink timestamp errors. These happen, when the downlink packet arrives too late at the gateway. That is typically cause by a slow network. Besides that, using the Pycom Development modules as gateway is a very limited set-up.

Hi. I'm from Brazil. Here, the frequency plan is 915MHz. US or AU frequency plan. Maybe the AU frequency plan be more correct. The only thing that i changed in code was in config.py LORA_FREQUENCY = 915200000. I'm using an SDR to see the specter of transmitions. I see the RN2903 transmition in 915.2 and the donwlink in 923.3 with a gateway raspberry. But this 869.525 i can't see in SDR. Looks like the lopy4 don't send RF. freq plan

robert-hh commented 4 years ago

As far as I can see from the logs, the TTN server tells the gateway to send the downlink message at 869.525 MHz. Since that is not in the AU915 range, the firmware raises an exception and the nanogateway stops. That is proper error handling. But I see that the LoPy4 firmware is pretty old. So maybe you should update that one first.

r4ph431dc commented 4 years ago

As far as I can see from the logs, the TTN server tells the gateway to send the downlink message at 869.525 MHz. Since that is not in the AU915 range, the firmware raises an exception and the nanogateway stops. That is proper error handling. But I see that the LoPy4 firmware is pretty old. So maybe you should update that one first.

I updated the lopy4 firmware to most recent, but no worked. So i downgraded to another version that worked. I'll try tomorrow again with the most recent firmware with the code that i'm using.

robert-hh commented 4 years ago

Reading a little bit more in the TTN forum, the behavior could be caused by the set-up of the nanogateway in config.py, using the ttn.eu router 'router.eu.thethings.network'. Try using the router for as US or AU region, like "router.us.thethings.network" or "thethings.meshed.com.au"

r4ph431dc commented 4 years ago

Reading a little bit more in the TTN forum, the behavior could be caused by the set-up of the nanogateway in config.py, using the ttn.eu router 'router.eu.thethings.network'. Try using the router for as US or AU region, like "router.us.thethings.network" or "thethings.meshed.com.au"

How i didn't see that? It's really corrected the downlink frequency. Now i can see the frequency 923.3 in my SDR device. Now, the RN2903 can get the response sometimes. Still not good enough, but is something.

Thanks so much. I gonna continue my tests here. Thanks again.

robert-hh commented 4 years ago

Since the nanogateway operates only on a single frequency, you have to set up your nodes to use only that single frequency.

r4ph431dc commented 4 years ago

Since the nanogateway operates only on a single frequency, you have to set up your nodes to use only that single frequency.

Yes. I do that. RN2903 is transmitted only in 915.2 and the nanogatway is in the same frequency. Downlink channel in RN2903 i belive that is not possible let only one enabled.