Fipy with OTAA node - Nano Gateway - TTN (not join)

[philip_teoph]

Re: FiPy with LoRaWAN using AS923 channel plan

SETUP
I have 1 fipy with nano-gateway firmware (COM7) installed and 1 fipy with otaa firmware (COM6) installed.

The forward end-to-end communication (i.e. OTAA node to Nano Gateway to TTN) seems ok, but the backward end-to-end communication (i.e. Nano Gateway to OTAA) not successful.

PROBLEM

1. OTAA node appears to be unable to join, therefore unable to received message back.

2. Device Addr appears in TTN changes everytime I reset the OTAA Node, it is correct?

Please advice. Thanks.

MORE INFORMATION

OTAA Node and LoRa Nano Gateway

1. Both Nano Gateway and OTAA node updated with latest firmware release 1.16.0.b1.

1. The OTAA node unable to join (PROBLEM)

Source Code (modified)
config.py (for both LoRa OTAA and Nano Gateway)
Using AS923 Frequency,
LORA_FREQUENCY = 923200000
LORA_GW_DR = "SF10BW125"
LORA_NODE_DR = 2

main.py (OTTA node only)

for i in range(3, 16):
lora.remove_channel(i)

lora.add_channel(0, frequency=config.LORA_FREQUENCY, dr_min=0, dr_max=4)
lora.add_channel(1, frequency=config.LORA_FREQUENCY, dr_min=0, dr_max=4)
lora.add_channel(2, frequency=config.LORA_FREQUENCY, dr_min=0, dr_max=4)

nanogateway.py
RX_PK = {
'rxpk': [{
'time': '',
'tmst': 0,
'chan': 0,
'rfch': 0,
'freq': 923.2,
'stat': 1,
'modu': 'LORA',
'datr': 'SF10BW125',
'codr': '4/5',
'rssi': 0,
'lsnr': 0,
'size': 0,
'data': ''
}]
}

TTN

1. Though I am using same fipy as my otta node, when I press reset button on the fipy, I received different device addr at TTN, it is correct? (PROBLEM)

[robert-hh]

@apiwize after the join worked, the TTN server will send a list of frequencies to use. The node will uses these in a random matter. Unfortunately the nanogateway can listen only to one of these three frequencies, meaning that you will miss 2 of 3 messages. That is not related to timing.
The best option then is to switch to abp mode, copying over from the TTN console the values for device address, network session key and app session key.
See the discussion at this thread about 10 days ago.
https://forum.pycom.io/topic/2728/lopy-and-nanogateway-example-inaccurate-timing-prevent-otaa-join

[apiwize]

@robert-hh Hi Robert, sounds to work fine now. I'll try to improve the time windows (I lose about 2 message / 3 for the moment). Anyway, many thanks for your help !

[robert-hh]

@apiwize In the initial post, you were using 923MHz frequencies. Now you are at 868.1. Which region are you in?

[robert-hh]

@apiwize The timestamps look ok now for a join message. The differences is 4994 ms (5 seconds - 6 ms compensation). in the rx message, microseconds are shown, in the TX message it's seconds. Could be aligned better. You could vary the window_compensation a little bit, like setting it to 0 or -3000. The steps do not have to be too fine.

[apiwize]

@robert-hh Hi Robert, here is the result :
(sysname='FiPy', nodename='FiPy', release='1.17.3.b1', version='v1.8.6-849-83e2f7f on 2018-03-19', machine='FiPy with ESP32', lorawan='1.0.2', sigfox='1.0.1')

Additionnally, after firmware update + back to 6000 ms windows compensation, I obtained, with no payload sent to TTN :
[ 441.622] Received packet: {"rxpk": [{"data": "AOGzANB+1bNwtK98lknVs3AHN+Adc+8=", "time": "2018-04-02T08:43:10.304316Z", "chan": 0, "tmst": 168393914, "stat": 1, "modu": "LORA", "lsnr": 6.0, "rssi": -61, "rfch": 0, "codr": "4/5", "freq": 868.1, "datr": "SF7BW125", "size": 23}]}
[ 441.691] Push ack
[ 445.707] Pull rsp
[ 446.714] Sent downlink packet scheduled on 173.387, at 868,100,000 Hz using SF7BW125: b' ^\xac\xf3\x93\x91\xec\xcc\x97o\xcf\xe7\x07\x8a\xb4AG#\x81\xef\x0b\x9e\xc3\x7f\xac\xef\xf2`.\xe3\xdc\x95g'
[ 455.324] Pull ack
[ 460.337] Push ack
[ 471.644] Received packet: {"rxpk": [{"data": "AOGzANB+1bNwtK98lknVs3C3/zKOlqs=", "time": "2018-04-02T08:43:40.326154Z", "chan": 0, "tmst": 198392668, "stat": 1, "modu": "LORA", "lsnr": 6.0, "rssi": -62, "rfch": 0, "codr": "4/5", "freq": 868.1, "datr": "SF7BW125", "size": 23}]}
[ 471.704] Push ack
[ 475.747] Pull rsp
[ 476.707] Sent downlink packet scheduled on 203.386, at 868,100,000 Hz using SF7BW125: b' \x9a\x81\x82\x95#\xac\x91\x081H^\xe4\xfb\xa6\xdf\x08ML\x81*1\xd3\x82|T_U[\x1a\xcb1!'
[ 480.352] Pull ack
[ 505.342] Pull ack
[ 520.331] Push ack

[robert-hh]

@apiwize The timestamps in you log message are inconsistent. Please check again in your gateway:

import uos
uos.uname()

Remark: the window compensation values should be negative, since the gateway is normally a little bit too late.

[apiwize]

@robert-hh : Firmware should be OK, I apdate again. I had 1 "result" (but no "join) on the currnt config by turning ther self window compensation (line 189) to 10 000. But just once, see enclosed :

[robert-hh]

@apiwize I see. Are you sure that you updated the firmware of the gateway to v1.17.3.b1? Other wise the driver for the sx127x chip and the nanogateway script use different timers.

[apiwize]

@robert-hh Well... I don't receive any "sent downlink" notification. My router should be ok, with port forwarding (1700) on gateway, I am to check in deep if there is no tric on firewall...
/////////////
Serial port COM6 opened
[ 3356.303] Pull ack
[ 3362.082] Received packet: {"rxpk": [{"data": "AOGzANB+1bNwtK98lknVs3As4NAlkvU=", "time": "2018-04-02T07:56:59.867743Z", "chan": 0, "tmst": 3244603296, "stat": 1, "modu": "LORA", "lsnr": 6.0, "rssi": -60, "rfch": 0, "codr": "4/5", "freq": 868.1, "datr": "SF7BW125", "size": 23}]}
[ 3362.138] Push ack
[ 3366.168] Downlink timestamp error!, t_us: 1748657865
[ 3366.175] Pull rsp
[ 3366.323] Push ack
[ 3381.325] Pull ack
[ 3392.077] Received packet: {"rxpk": [{"data": "AOGzANB+1bNwtK98lknVs3BWv1/hxjA=", "time": "2018-04-02T07:57:29.863851Z", "chan": 0, "tmst": 3273498056, "stat": 1, "modu": "LORA", "lsnr": 6.0, "rssi": -60, "rfch": 0, "codr": "4/5", "freq": 868.1, "datr": "SF7BW125", "size": 23}]}
[ 3392.144] Push ack
[ 3396.158] Downlink timestamp error!, t_us: 577930084
[ 3396.165] Pull rsp
[ 3406.303] Pull ack
[ 3422.076] Received packet: {"rxpk": [{"data": "AOGzANB+1bNwtK98lknVs3ASxvFISZM=", "time": "2018-04-02T07:57:59.862767Z", "chan": 0, "tmst": 3302392157, "stat": 1, "modu": "LORA", "lsnr": 6.0, "rssi": -61, "rfch": 0, "codr": "4/5", "freq": 868.1, "datr": "SF7BW125", "size": 23}]}
[ 3422.134] Push ack
[ 3426.177] Downlink timestamp error!, t_us: -593913532
[ 3426.184] Pull rsp
[ 3426.330] Push ack
[ 3431.322] Pull ack

[robert-hh]

[ 46.132] Received packet: {"rxpk": [{"data": "AOGzANB+1bNwtK98lknVs3CYfmhRlw8=", "time": "2018-04-02T07:01:43.918247Z", "chan": 0, "tmst": 46124070, "stat": 1, "modu": "LORA", "lsnr": 8.0, "rssi": -37, "rfch": 0, "codr": "4/5", "freq": 868.1, "datr": "SF7BW125", "size": 23}]}
[ 46.199] Push ack
[ 50.209] Downlink timestamp error!, t_us: -1955412445
[ 50.216] Pull rsp
After this line the should be a starting with "Sent downlink packet". Could you include that too in your log?

[apiwize]

@robert-hh Here it is :
[ 1.731] Starting LoRaWAN nano gateway with id: b'30AEA4FFFE2D00B0'
[ 6.103] WiFi connected to: xxx
[ 6.108] Syncing time with pool.ntp.org ...
[ 6.213] RTC NTP sync complete
[ 6.228] Opening UDP socket to router.eu.thethings.network (52.169.76.203) port 1700...
[ 6.240] Setting up the LoRa radio at 868.1 Mhz using SF7BW125
[ 6.248] LoRaWAN nano gateway online
[ 6.252] You may now press ENTER to enter the REPL
[ 6.295] Push ack
[ 31.286] Pull ack
[ 46.132] Received packet: {"rxpk": [{"data": "AOGzANB+1bNwtK98lknVs3CYfmhRlw8=", "time": "2018-04-02T07:01:43.918247Z", "chan": 0, "tmst": 46124070, "stat": 1, "modu": "LORA", "lsnr": 8.0, "rssi": -37, "rfch": 0, "codr": "4/5", "freq": 868.1, "datr": "SF7BW125", "size": 23}]}
[ 46.199] Push ack
[ 50.209] Downlink timestamp error!, t_us: -1955412445
[ 50.216] Pull rsp

//////////////////////////////////////////////////
On the TTN side :

{
"time": "2018-04-02T07:05:03.966259338Z",
"frequency": 868.1,
"modulation": "LORA",
"data_rate": "SF7BW125",
"coding_rate": "4/5",
"gateways": [
{
"gtw_id": "eui-30aea4fffe2d00b0",
"timestamp": 241458720,
"time": "2018-04-02T07:05:03.908999Z",
"channel": 0,
"rssi": -37,
"snr": 6
}
]
}

[robert-hh]

@apiwize That's strange. I'm using a lopy as gateway.
Can you show the part of the gateway's log when it gets and sends the OTAA join messages, like you did above.

[apiwize]

@robert-hh Hi, and many thanks for your input. Unfortunately, doesn't work on fipy / fipy. I'll try this week with lopy / fipy combination, and look for alternative timings on fipy / fipy. Any suggestion welcomed ;-)

[robert-hh]

@apiwize You should use V1.17.3.b1 and could try my variant of the nanogateway code here:
https://github.com/robert-hh/pycom-libraries/blob/nanogateway/examples/lorawan-nano-gateway/nanogateway.py
It works for me with a fipy node/lopy gateway and AFAIK works for @shishir with a lopy4 node/lopy4 gateway.

[apiwize]

Same problem with Fipy node / Fipy gateway.
The Gateway registers well on TTN, the node try to connect and is seen by TTN, but never joined. I tryed updated firmwares as well as 1.15.0.b1, no result...
I found informations about Rx timing on such Lopy concerns, but no "simple" solution (there was something about performing changes in the firmwares...) I don't know how to do, and I won't. Hey, Pycom guys, anything to propose ?

[robert-hh]

@philip_teoph I made the same experience. It joined ONCE in four days od testing. Some of my observations are here: https://forum.pycom.io/topic/2676/abp-mode-and-frame-counters/13
The title is a little bit misleading.
The fact that I mentioned 1.15.0 is more a hint to Pycom, that it worked in earlier versions.

[philip_teoph]

@robert-hh I would prefer to run on 1.16.0.b1 or above instead, since I needs to work on AS923 channel plan in my country as suggested by above by https://forum.pycom.io/topic/2423/fipy-with-lorawan-using-as923-channel-plan.

For your info, I just managed to get it join once. BUT, after I power off both Fipy (OTAA node and Nano Gateway) and try again, I CANNOT get it to join again (see INFORMATION).

Are there anyone that found solution that fix the same stability problem?

Thanks.

INFORMATION

OTAA Node : FiPy
Nano Gateway: FiPy
Firmware : 1.16.0.b1

main.py (OTAA only)

'# remove all the non-default channels
for i in range(3, 16):
lora.remove_channel(i)

'# set the 3 default channels to the same frequency (must be before sending the OTAA join request)
lora.add_channel(0, frequency=config.LORA_FREQUENCY, dr_min=0, dr_max=5)
lora.add_channel(1, frequency=config.LORA_FREQUENCY, dr_min=0, dr_max=5)
lora.add_channel(2, frequency=config.LORA_FREQUENCY, dr_min=0, dr_max=5)

'# join a network using OTAA
lora.join(activation=LoRa.OTAA, auth=(dev_eui, app_eui, app_key), timeout=0, dr=config.LORA_NODE_DR)

'# wait until the module has joined the network
while not lora.has_joined():
time.sleep(2.5)
print('Not joined yet...')

print('Connected!')

[robert-hh]

@philip_teoph I have the same problem & fighting with it since days.
Node: FiPy
Gateway: Lopy
Firmware 1.16.0.b1
ABP mode works more or less. Uplink messages are delivered, dowlink messages rarely.
OTAA join DOES NOT WORK AT ALL.
However, downgrading the FiPy node to Firmware 1.15.0.b1 made the OTAA join succeed. Only then messages from the node to the gateway are not received in about every second case.
So, there is much room for improvement.

I think it is normal that device addresses are re-assigned, becase OTAA handles this dynamically.