I am having no luck with OTAA. About a year ago I activated a TTN gateway and bought several Lopy 1 modules, but then things got busy and this is my first chance to get back to it. Gateway has been powered (and working, I believe, the whole time). It has received 49 messages and transmitetd 3. Still a noob, so bear with me. I read all the examples I could find and I believe I understand the process.
First I upgraded my units:
No problem.
I created an app and registered my devices, using cut and paste:
My gateway appears to be reporting in just fine:
I think I am using the correct code:
# main.py -- put your code here!
from network import LoRa
import time
import binascii
lora = LoRa(mode=LoRa.LORAWAN)
app_eui = binascii.unhexlify('70B3D57ED0017149')
#print('Joining black module')
#app_key = binascii.unhexlify('B18CBC14B7CD3D032D8DA37D940BC476')
print('Joining green module')
app_key = binascii.unhexlify('DE27959ACA592EF7E6CB7A5DE151150E')
lora.join(activation=LoRa.OTAA, auth=(app_eui, app_key), timeout=0)
# wait until the module has joined the network
while not lora.has_joined():
time.sleep(2.5)
print('Not joined yet...')
print('Network joined!')
I have two modules, green and black and both give the same result- just ‘Not joined yet…’ repeated every 2.5 seconds.
Just to be sure I brought the gateway into the same room as the nodes, to rule out an RF link problem, it makes no difference.
I saw a reference to waiting for a “downlink window”. How long do you have to wait? I have left the node script running for hours, it doesn’t do anything.
In the console the status of both devices is “Never seen”. The Application Data is blank. My gateway has 4 blue LEDs lit steadily.
I haven’t located anyone locally who can help me debug, hence the appeal to the forum. I have seen similar questions on the forum and then they just suddenly they start to work. Hopefully my problem can be similarly resolved! I have a great site for Northern Colorado, my horizon from the north through the east to the south is about 100km away, and I am about 200m above average terrain on the side of a hill.
I am using Atom with Pymakr on a Windows 10 machine, seems to interact just fine with the Lopys.
I think I am on the trail here. Using a spectrum analyzer, I see my nodes transmitting as soon as I run the script. But I never see a transmission from my gateway. Is it damaged or is there some setting I am missing? Is there some way to debug it?
No, no activity in the data tab. I have hooked up to the serial port and I can see debug traffic, but I am not really sure what it means! During the setup I do see what appears to be the setup of the Microchip Module.
This is the beginning, I am not sure if this is the latest firmware:
**************************
* The Things Network *
* G A T E W A Y *
**************************
Firmware name: AmazingAckermann, type: 0, version: 1.0.5, commit: fa89b993, timestamp: 1531815112
Bootloader revision: 1, commit: 7167873a, timestamp: 1496411298
Build time: Jul 17 2018 08:12:51
Reboot reason: 0x03
BOOT: (persisted info) 6F 72 72 65 01 03 6F 6E 46 65 73 B8 44 12 39 AD
That DevEUI does not match? Are you sure you need the value of LoRa MAC for the TTN DevEUI? (I doubt that, as it’s in the registered/purchased range of TTN AppEUIs.)
I think my gateway is bad. I used a directional coupler and spectrum analyzer. When it boots up, I see two transmissions, one at 903.7 MHz, the other at 905.3 MHz, so down at the bottom of the band. They are very low in level, -25dBm. Since the output is supposed to be more in the +30dBm range, this is getting on for a million times too low in power… And that is really all I see.
I checked all the cables, right to the PCB, so it included the U.FL connector, and they are all okay. I guess it must be the Microchip module.
Why would you even expect any transmission? A LoRaWAN gateway only transmits when the backend server tells it to: for downlinks, including OTAA Join Accept messages. You should see it transmit a Join Accept 5 seconds (RX1) or 6 seconds (RX2) after the node has sent its Join Request. But then you should also see that information in TTN Console.
I really don’t know! I don’t see anything when the node does it’s join request. But every time the gateway boots I see those two transmissions at the bottom of the band. The lower one about 2-5 seconds after power up, the other one after about 30 seconds, and then nothing. Doesn’t the node need timing information? I guess I need to find out more about the physical and link layer stuff!
Nope. LoRaWAN is really about low power: a node transmits an uplink when it wants to, then goes into a lower power state and after a delay of RX1 (typically 1 seconds) tries to detect a downlink. If detected, it listens for the full downlink, if not it delays until RX2 (typically 2 seconds) and tries to detect a downlink again. If received or none detected, it goes to sleep (if your code is smart enough) until it wants to transmit again. More details at https://www.thethingsnetwork.org/docs/lorawan/
For OTAA, it sends a Join Request (uplink), hopes one or more gateways receive it and forward it to the TTN backend, and then expects a Join Accept response (downlink) after either RX1 (5 seconds for OTAA) or RX2 (6 seconds). Only if the backend has received and accepted the Join Request it will tell one of the gateways that received the Join Request to transmit such Join Accept.
For Class A devices, there are no other radio transmissions except for uplinks and optional downlinks at a specific interval after such uplinks.
Be sure to leave at least a few meters between node and gateway.
Yes, I left some space between them! I am not sure what to do next. If there was another gateway around, I could test with that, but I am a ways off from anywhere out here. When I received the gateway, about a year ago, I tried very hard to get it going, and had these sort of problems, so put it aside and I am only getting back to it now. I thought initially it was my lack of understanding, but maybe the gateway has been bad all this time.
I guess a lot of folks are at the conference right now, so not a good time! I’ll have to think for a while if I want to put out $$ for a second gateway… Looked around a bit, but I did’t see a source for the Microchip module.
Thanks for all the suggestions.
Just to be sure: you looked at the gateway’s Traffic tab in TTN Console? (That’s different from the application/device’s Data tab.)
You’ll want two browser windows open, for both the application/device’s Data tab (which if TTN accepted the DevEUI, AppEUI and AppKey should show the Join Request, plus the assigned DevAddr, with an orange icon), and the gateway’s Traffic tab (which should show the Join Accept along with a green icon). If you see any output, clicking an item will show more details.
The gateway’s serial port output should also show things like:
LORA: Accepted packet
MQTT: Sending UPLINK OK
…and for the OTAA Join Accept, in the gateway that has been selected to transmit it:
MQTT: Received DOWNLINK
Or failures like:
LORA: Packet dropped! Bad CRC
(Which might certainly happen for radio packets from some other device.)
There must be something intermittent- it just started working:
And I now see huge transmit signals from it on my analyzer. I happened when I moved it from one bench to another- I had left the node running it’s join script. I did nothing except power the gateway down, move it, and power it up again- so all the EUIs etc were correct. It had to be something physical.
If you’re in the US, thats backwards. The node should be down around 904-905MHz and the gateway should be around 923-928Mhz. This is the channel layout for US915:
Ah, were node and gateway very close to one another earlier? That could cause problems too (including receiving a single Join Request multiple times on different frequencies, where TTN might choose the wrong one for the Join Accept); keeping them a few meters apart is usually recommended.
@afremont: Yes, I was just coming to that conclusion too. I wrongly assumed the higher level one was from the gateway! In fact I believe the power output from the gateway is very low. As you can see from the spectrum, some 40 dB or so less than the node. It should be at least 20dB more, I think. I think a lot (most?) of my problems over the last year have been due to the poor RF performance of the gateway.
I don’t see anything on the forum or the web more generally about getting the gateway repaired. I also could not find a source for the Microchip RF module that is in there, I assume it is the problem. So I guess if I want to continue on with this, I will have to put out the $$ for another gateway. The question is whether to risk another TTN gateway or go for a more expensive one… It seems Element 14 has the TTN gateway in stock.
I wonder if there is a simple procedure somewhere for verifying that the RF performance of a gateway is what it should be? Something like set up the gateway and node with standard whip antennas vertical, separate them by 100m with nothing in between them, and try to connect. Can the node report signal strength? Otherwise you need a spectrum analyzer with another antenna. Knowing the distances, one can calculate what the signal strengths should be. Is there a way to change the “Fair use policy” for commissioning/test purposes? Especially in an area with little activity.
Hopefully, you aren’t a victim of SMA vs SMAr connector issues. Not all SMA connectors are as simple as male vs female. Power down your gateway and remove the antenna. Make sure that you have a pin that is mating into a hole with the center connection. It’s possible that the antenna and gateway are without a pin meaning that it’s not actually making a connection, or that both have pins that are jamming into each other and creating a short with ground.
