RF noise and LoRaWAN join issues

[berni]

After some frustration yesterday (https://forum.pycom.io/topic/1074/lopy-node-sends-join-requests-and-my-nano-gateway-tries-to-forward-it-but-no-sccessful-join/15) I arrived home and kept testing... and all of a sudden everything worked OK! I got quick and solid join acceptances on the two nodes I was testing, overnight data LoRaWAN packets every 5 minutes... sweet!

Then, this morning arrived back to the office and back to the join issues: continuous join requests listened by the nano gateway, forwarded to TTN and accepted, but never listened by the nodes.

So, I'm wondering. Is there any chance that it could RF noise? Doesn't make too much sense to me as the gateway listens to the nodes, is just the gateway-to-node communication which is not working. Nodes are 2-5m apart, tested longer distances without any improvement.

Is there any way to check for the noise in the channels used by default in the nanoGateway sample code? Unfortunately I don't have a spectrum analyser.

[Chad]

@berni

I would like to add my name to the list of people having the same problem with join issues.
Incidentally I have another Node using an Arduino LoRaWan shield on the same nano gateway that joins successfully every time so I would tend to exclude noise issues with the Pycom OTAA / Nano Gateway example. It looks like software or firmware issues in the node to me.
Hope this helps.

[athtest800]

I have the same issue. I get an endless "Not joined yet..."

[berni]

@jmarcelino you were right! it's a timing issue and the packet arriving late to the node.

Adjusting the offset for the uplink alarm from 5000us to 8000us definitely made a difference.

elif _type == PULL_RESP:
                    self.dwnb += 1
                    ack_error = TX_ERR_NONE
                    tx_pk = json.loads(data[4:])
                    tmst = tx_pk["txpk"]["tmst"]
                    t_us = tmst - time.ticks_us() - 8000
                    if t_us < 0:
                        t_us += 0xFFFFFFFF
                    if t_us < 20000000:
                        self.uplink_alarm = Timer.Alarm(handler=lambda x: self._send_down_link(binascii.a2b_base64(tx_pk["txpk"]["data"]),
                                                                                               tx_pk["txpk"]["tmst"] - 10, tx_pk["txpk"]["datr"],
                                                                                               int(tx_pk["txpk"]["freq"] * 1000000)), us=t_us)

Not sure what should be the ideal value there, though. I guess it depends on the complexity of your program and what other things the LoPy is doing in the background.

Anyway, I hope it helps others with similar LoRaWAN joining issues.

[berni]

@jmarcelino Thanks for the SDR links, definitely worth a try.

Also thanks for the clue on the packet timing. Does the timeout parameter in the join function has any effect on that timing?

lora.join(activation=LoRa.OTAA, auth=(dev_eui, app_eui, app_key), timeout=0)

All the examples that I've seen have 0 as the default value and the lora.has_joined() loop. I tried different values with no luck.

[jmarcelino]

@berni
The cheapest way to check RF noise is using a Software Defined Radio (SDR): I use an HackRF but you can do the same with a cheap RTL-SDR dongle (RTL2832U-based DVB TV USB sticks) and for example the GQRX software.

That said I suspect the OTAA join issues with TTN aren't related to noise though but packet timing. TTN sends responses very very late, almost exactly at the time when the transmission is due. If your Internet is slower or your LoPy is doing something else it may miss the receive window. But for now it's just my suspicion, I've not tested this properly so don't take it as truth.