Lopy4 + Pytrack2 unsucessfull full comunication OTAA AU915 (Brazil). Which firmware + programming code works?

[Manuel Ricardo Alfonso Sanchez]

Hi. Greetings from Brazil.
Taking in account the local telecommunications regulators for each geographic region, information in this post is configured as follows:

I have two pairs of LoPy4 + Pytrack, they are working ok with the ABP, and with a MultiTech MTCDT LoRa Gateway configured to AU915. The problem appears, looking on the TTN Console where the green lightning indicator is. It means that my device sended a joint request?, it was recognized on the TTN, then was the next step?

I read about users downgrading the firmware to 1.13.0.b1, 1.14.0.b1 and taking in account the ESP32 oscillator because of the non high-accuracy. Is really necessary this?.
I really need to focus on my application firmware development and pull off this troubles. Thanks to the whole community.

[robert-hh]

@Manuel-Ricardo-Alfonso-Sanchez I do not see whther this was discussed already, but which TTN server do you have configured. There were people which had problems because the join accept message from the TTN server arrived too late at the gateway. And you have some TX messages in the server log which have been rejected being too late.
so you could try to use other server URLs.

[Gijs]

What @robert-hh refers to concerning the lora NVRAM usage, is listed in an example here: https://docs.pycom.io/tutorials/networks/lora/nvram/
In combination with setting the channels: (this works either before or after joining, the order there does not matter). In the example below, I remove all channels, and replace the ones that the Pygate (most gateways) support through te default configuration ( https://github.com/TheThingsNetwork/gateway-conf ). Looking at your gateway logs, they are very similar to the Pygate logs, making me assume you use a similar configuration. Im not sure if the channels 8-15 are the same as the ones listed below, you'd have to check.

#Do not transmit on the channels outside the Pygate scope
for i in range(0,64):
    lora.remove_channel(i)
    
lora.add_channel(0, frequency=903900000, dr_min=0, dr_max=3)
lora.add_channel(1, frequency=904100000, dr_min=0, dr_max=3)
lora.add_channel(2, frequency=904300000, dr_min=0, dr_max=3)
lora.add_channel(3, frequency=904500000, dr_min=0, dr_max=3)
lora.add_channel(4, frequency=904700000, dr_min=0, dr_max=3)
lora.add_channel(5, frequency=904900000, dr_min=0, dr_max=3)
lora.add_channel(6, frequency=905100000, dr_min=0, dr_max=3)
lora.add_channel(7, frequency=905300000, dr_min=0, dr_max=3)

From your gateway logs it seems the downlink message (the join accept packet from TTN) is not actually transmitted?

Let me know

Gijs

[Manuel Ricardo Alfonso Sanchez]

@jcaron Thank you. I install the 1.20.2.r4 firmware version, deleting the channels with next code and does not works.

    for i in range(0, 8):
        lora.remove_channel(i)
    for i in range(16, 65):
        lora.remove_channel(i)
    for i in range(66, 71):
        lora.remove_channel(i)

Next is the log of the packet forwarder file I take from the gateway:

0JSON up: {"stat":{"time":"2021-01-15 19:04:43 GMT","rxnb":0,"rxok":0,"rxfw":0,"ackr":100.0,"dwnb":0,"txnb":0}}
INFO: [up] PUSH_ACK received in 187 ms
INFO: [down] PULL_ACK received in 188 ms

##### 2021-01-15 19:05:02 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 0
# CRC_OK: 0.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
# RF packets forwarded: 0 (0 bytes)
# PUSH_DATA datagrams sent: 1 (113 bytes)
# PUSH_DATA acknowledged: 100.00%
### [DOWNSTREAM] ###
# PULL_DATA sent: 1 (100.00% acknowledged)
# PULL_RESP(onse) datagrams received: 0 (0 bytes)
# RF packets sent to concentrator: 0 (0 bytes)
# TX errors: 0
# TX rejected (collision packet): 0.00% (req:232, rej:0)
# TX rejected (collision beacon): 0.00% (req:232, rej:0)
# TX rejected (too late): 1.29% (req:232, rej:3)
# TX rejected (too early): 0.86% (req:232, rej:2)
# BEACON queued: 0
# BEACON sent so far: 0
# BEACON rejected: 0
### [JIT] ###
# SX1301 time (PPS): 2757333838 2
src/jitqueue.c:449:jit_print_queue(): INFO: [jit] queue is empty
### [GPS] ###
# GPS sync is disabled
##### END #####

[robert-hh]

@Vitor-Scardua said in Lopy4 + Pytrack2 unsucessfull full comunication OTAA AU915 (Brazil). Which firmware + programming code works?:

I'm a little bit confused about the order of calls, especially calling always lora.join(), and then setting the channels before the join is confirmed. Along the code structure, which I use, I would expect this section of the code to look like:

lora = LoRa(mode=LoRa.LORAWAN, region=LoRa.AU915)
lora.nvram_restore()

if(not lora.has_joined()):
    print("LoRaWan Join in manual mode...")

    app_key = ubinascii.unhexlify('XXXXXXXXXXXXXXXXXXXXXXXXXXX')
    dev_eui = ubinascii.unhexlify('XXXXXXXXXXXXX')
    app_eui = ubinascii.unhexlify('XXXXXXXXXXXXXXC')

    for i in range(8, 16):
        fq = LORA_FREQUENCY + ((i-8) * 200000)
        lora.add_channel(i, frequency=fq, dr_min=0, dr_max=LORAWAN_DR)

    lora.add_channel(65, frequency=917500000, dr_min=6, dr_max=6)

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

    while not lora.has_joined():
        time.sleep(2.5)
        print('Lora has not joined')

I nvram.restore() tells, that the device is joined, another join is not needed, and the channels settings should also be done.

[Manuel Ricardo Alfonso Sanchez]

Sure. Actually with the code it does not join to the TTN and shows the next message always.

========== LoRaWan Configuration ==========
LoRaWan Join in manual mode...
Not yet joined...
Not yet joined...
Not yet joined...
Not yet joined...
Not yet joined...

[jcaron]

@Manuel-Ricardo-Alfonso-Sanchez I recommend updating to a more recent version of the firmware as suggested by @Gijs, as there have been quite a few fixes here and there over time which may or may not be relevant.

If that doesn't solve the issue, can you share the settings and logs of your gateway? There are cases when the reply from TTN is not accepted by the gateway, so TTN sends the accept, but the gateway does not transmit it.

Also note that I believe you need to remove all channels but the ones you keep, and with OTAA you should only need to do that before the join (to make the join quicker). The network should reply with the correct set of channels to use.

[Gijs]

Could you again elaborate on the issue you are experiencing? Everything described in the code should work on the latest stable firmware (1.20.2.r4). I would not recommend using the beta version (1.20.3.b0) as that can behave unexpectedly.

Gijs

[Vitor Scardua]

@Gijs this is the code that @Manuel-Ricardo-Alfonso-Sanchez was trying to post. we are colleagues.
We are using the firmware 1.20.3.b0 and with the firmware 1.20.2.r4 as suggest wasn't send the request.

#LoPy4 + Pytrack2 hardware - PCB antenna
import gc
gc.collect()

from machine import Timer, RTC,
from network import LoRa, WLAN,
import binascii
import network
import machine
import socket
import struct
import pycom
import time
import os
import ubinascii

from pytrack import Pytrack
from L76GNSS import L76GNSS
from LIS2HH12 import LIS2HH12

LORA_FREQUENCY = const(916800000)
LORA_SF = const(9)
LORA_BW = LoRa.BW_125KHZ
LORA_CR = LoRa.CODING_4_5
LORAWAN_DR = 4
DEEPSLEEP_TIME = const(10)
START_COLOUR = const(0xFF0000)

gc.collect()
pycom.heartbeat(False)
pycom.rgbled(START_COLOUR)

lora = LoRa(mode=LoRa.LORAWAN, region=LoRa.AU915)
lora.nvram_restore()

if(not lora.has_joined()):
    print("LoRaWan Join in manual mode...")

    app_key = ubinascii.unhexlify('XXXXXXXXXXXXXXXXXXXXXXXXXXX')
    dev_eui = ubinascii.unhexlify('XXXXXXXXXXXXX')
    app_eui = ubinascii.unhexlify('XXXXXXXXXXXXXXC')

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

for i in range(8, 16):
    fq = LORA_FREQUENCY + ((i-8) * 200000)
    lora.add_channel(i, frequency=fq, dr_min=0, dr_max=LORAWAN_DR)

lora.add_channel(65, frequency=917500000, dr_min=6, dr_max=6)

while not lora.has_joined():
    time.sleep(2.5)
    print('Lora has not joined')

if lora.has_joined():

    lora_sock = socket.socket(socket.AF_LORA, socket.SOCK_RAW)
    lora_sock.setsockopt(socket.SOL_LORA, socket.SO_DR, 3)
    lora_sock.setsockopt(socket.SOL_LORA, socket.SO_CONFIRMED, True)
    lora_sock.setblocking(False)

    gc.collect()

    lpp = cayenneLPP.CayenneLPP(size = 100, sock = lora_sock)

    py = Pytrack()
    L76 = L76GNSS(pytrack=py)

    pycom.rgbled(0xFF7F00)
    gps = L76GNSS(py, timeout=10)
    coord = gps.coordinates()

    if (coord == (None,None)):
        pycom.rgbled(0xCC3299)
        print("Without GPS")
        coord = (-20.27262, -40.3068, 9.6)
        time.sleep(1)

    lpp.add_gps(coord[0], coord[1], 0, channel=2)

    LoRaWan_pkg = lpp.get_payload()
    gc.collect()

    lpp.send()
    seconds = DEEPSLEEP_TIME + (os.urandom(1)[0] & 0x0F)
    machine.deepsleep(seconds*1000)

[Gijs]

That is unfortunate, im not sure why it does that.. You should at least be able to paste the code using markdown code tags (the three backticks ``` at the begin and end). That will at least result in a nicely formatted codeblock

like so

[Manuel Ricardo Alfonso Sanchez]

@Gijs I tried to upload the file here and it was recognized as Spam. Tried with the code, the file, and the link of my GitHub...

[Gijs]

Hi,
First, its always useful to paste the code as text instead of images, using the ``` tags.

Next, ill separate the issues:

The problem appears, looking on the TTN Console where the green lightning indicator is. It means that my device sended a joint request?, it was recognized on the TTN, then was the next step?

The Yellow lightning bolt is a join request from your device, the green lightning bolt is a join accept from TTN. This means your join requests is received and has the correct credentials. This also suggests a working LoRa uplink. The next step is for your device to receive the join accept message and recognise it has joined (it should exit your while loop)

The second issue:

I read about users downgrading the firmware to 1.13.0.b1, 1.14.0.b1 and taking in account the ESP32 oscillator because of the non high-accuracy. Is really necessary this?.
I really need to focus on my application firmware development and pull off this troubles. Thanks to the whole community.

I really have no clue here. 1.13.0.b1 is from ages ago, and we do not really support it anymore. Currently, the latest version we have released 1.20.2.r4, I would suggest you use this one.

Best,
Gijs