Hi,
I am using the LoPy with GPS extension board to connect to TTN. All worked fine until a couple of days ago. The device is contacting the network as can be seen in the “data screen” where it shows up as activation. However, this is as far as it gets. for one reason or the other the device does not get beyond this point. The readout in the TTN console is in accordance with the therminal readout directly from the LoPy which shows indeed a ever-lasting retry to connect. The gateway, which is also LoPy based is sitting 4 meters away so signal strength cannot be the issue…
any help or suggestion is appreciated.
Nothing in the LoRa connection part I only made a small change in the “GPS” part .
As a test I also loaded a clean connection only code with the same resut…
Thinking about it a bit longer this might be the happening: The node contacts the network (I use OTAA) . This is registered by the network which responds by sending a handshake code. Apparently this code is not received or processed by the node so it sends a second request to the network. And so on…
tried to reset the frame counter to no avail.
This weekend a friend takes the node to his home which is close to three gateways. If the node connects to TTN then something is wrong with my gateway else the Lopy is faulty…
Sorry it took so long to come back to my issue…
My friend took the node to his home and had no problem connecting to ttn.
So I concluded the issue should be in the gateway. hat I see happening (also after a hrd reset and upload of the code) is that the gateway receives a join request from the node (at 868.1 MHz). The gateway sends back an acknowledge (at 868.0 MHz) which is not handeled by the node. sporadicly an acknowledment at 869.5 MHz is sent by the gateway to which the node responds and a connection is established.
Just as I am typing this however something strange happens: the gateway crashed with the following message:
“Guru Meditation Error of type LoadProhibited occurred on core 0.” Now the connection gets established at 868.0 MHz… Also after multiple restarts of the node the node gets connected…
restarting the gateway brings me back to where I started…
Who can help? what is the proven / latest lopy ttn gateway code I can try?
now I am going to bed…
The most recent code for Lopy, both (single channel) gateway and nodes can be found here.
Also, check to see if you got the most recent firmware. You can download that here.
I know it is one of those “have you tried turning it on/off?” kind of remarks, doing something on the node side of things should not influence the gateway but with lopy still being actively developed, updating firmware is not a bad thing.
The code on my LoPy single channel gateway is not the most recent (don’t know exactly when I last updated it) and it crashes often. It is something I use for testing, it is not a LoRaWAN compliant gateway.
Hi I tried all the suggestions but the situation is not improving. Still very seldomly a connection is made.
The one thing that I did not yet get an answer on is why I see a frequency of the send message (from the gateway) of 868.000 MHz instead of the 868.100 MHz. Could it be that the node every once in while picks up signal on the slightly different frequency and thus gets connected?
Today I will swap the two Pycom modules and investigate what happens…
For the node you need 2 files: config.py and either abp_node.py or otaa_node.py depending on whether you want to use ABP or OTAA.
ABP
If you are using the code in abp_node.py then the frequency for the node is fixed to config.LORA_FREQUENCY. The value of config.LORA_FREQUENCY is set in config.py (which should also be uploaded to the LoPy) and is set by defaul to 868.100 in line 20: LORA_FREQUENCY = 868100000
All you need to change in in the code for the node are the three lines with:
dev_addr = struct.unpack(">l", binascii.unhexlify(‘26 01 14 7D’.replace(’ ‘,’’)))[0]
nwk_swkey = binascii.unhexlify(‘3C 74 F4 F4 0C AE A0 21 30 3B C2 42 84 FC F3 AF’.replace(’ ‘,’’))
app_swkey = binascii.unhexlify(‘0F FA 70 72 CC 6F F6 9A 10 2A 0F 39 BE B0 88 0F’.replace(’ ‘,’’))
The values for these you get from the TTN console for the node. Note: if you reset the node using ABP, you will have to reset the “frames up” counter for the device on the TTN console, otherwise it will ignore all packages until the LoPy package counter has reached at least the counter in the console.
OTAA
If you don’t want to fuss with the counter, then best to use config.py + otaa_node.py for the node. Here, you need only change the values for
dev_eui = binascii.unhexlify(‘AA BB CC DD EE FF 77 78’.replace(’ ‘,’’))
app_eui = binascii.unhexlify(‘70 B3 D5 7E F0 00 3B FD’.replace(’ ‘,’’))
app_key = binascii.unhexlify(‘36 AB 76 25 FE 77 0B 68 81 68 3B 49 53 00 FF D6’.replace(’ ‘,’’))
Here also, config.LORA_FREQUENCY is used to set the frequency.
Gateway
The nano-gateway LoPY needs 3 files: main.py + config.py + nanogateway.py
In config.py you set the credentials for your Wifi network. The nodes don’t need access to wifi, but the gateway of course does.
As you can see in main.py, the gateway uses the exact same config.LORA_FREQUENCY variable to start the gateway.
So, the frequency of LoPy node and gateway should be identical if you didn’t change that in the config.py and used the config.py on both node and gateway.
If you did all that and it still doesn’t work, then I don’t know how to help you and I can only hope that @jmarcelino knows what else to try in that case.
Thanks for the help provided!
Did some swapping today: swapped the pycom modules from the expansion board 2.0 and the pytrack. The issue did not change… Then I decided to swap the functionallity so I now use the lopy on the pytrack board as gateway and the lopy on the expansion board as node. What changed is the following:
1: the gateway frequency as reported to the REPL changed from 868.000 to 868.100
2: the feedback to the REPL is more stable: I get all the logging while on the exp. board I did not: sometimes all the push etc messages, sometimes only the incomming connection request.
3: most importantly: the connection including handshake was established. also after repeatedly shutting down and starting up the node…
4: I then unplugged the gateway and put it to a usb charger. effect: no longer did the node connect. This was solved by resetting the gateway using the reset button. This pattern is reproducible: no connection after plugging in the USB connection (either pc or wallplug) to the gateway but good working after a reset button pushed.
5: the communication with the extension board 2.0 through the REPL / ATOM goes diificult. Updating the LOPY only succeeds by wifi-FTP
6: My conclussion 1: something is wrong with the/my expansion board 2.0!
7: My conclussion 2: Apparently the gateway does not recover reliably after a power cycle… maybe need some code to wait with executing the code to give the (internal) power regulator time to stabilize.
If you would change main.py by adding import time
and time.sleep(2)
at line 5, does that help? (it adds a 2 second delay before the gateway is initiated).
Tried your suggestion. It does not work…
I also have to come back at a previous conclusion: the pytrack and extension board have the same behaviour…
The only way to get the gateway to propperly work is to initiate an “upload” in the repl. This I tested numerous times. a reset using the reset button is no guarantee the gateway will work as is unplug/plug action.I tried this in all configurations I have at hand and this is repeatable…
It sounds to me like you’re dealing with too many problem variables.
I suggest starting from scratch. Clear the filesystem in both your LoPys with:
import os
os.mkfs('/flash')
Then make sure you’re running the same firmware on both (latest) using the Pycom Firmware updater.
Serial connection problems especially with the Expansion Board 2.0 are usually caused by bad quality microUSB cables, make sure you only use good quality, well tested, ones - if in doubt try a different one.
If the cable worked for the firmware update and you can upload the code again without issues from Atom you should be good to go.
Also when reporting problems please copy and paste the messages exactly as you see in the REPL. If you can also paste/screenshot the details from the TTN console that would also help. There are many details which we might miss if you’re just transcribing.
If you get really stuck at any point we can also schedule a Team Viewer session so I can have a look.
Look forward to helping you get a reliable connection!
Thanks for the feedback!
I did do the “start from scratch” exercise. Did do a firmware update on both Pycom modules and checked the firmware version afterwards. did clean the file system. The only thing I did not do is connecting the extension board to another USB connection to the computer. I did use three different USB cables…
If I find time week I will retry and post a copy of the REPL and TTN consoles and code.
Question: is there any way to monitor the traffic on the node instead of or in addition to the traffic on the gateway?