Closed xatru closed 3 years ago
Hi,
The log from the serial monitor shows the following:
Event EV_JOINING. This means that the node sent a join request.
Later you see event EV_JOIN_TXCOMPLETE. This means that the node did not receive (not recognize) a join accept response in time. _When the join succeeds you should see event EVJOINED in the output.
A possible cause for joins to fail is that downlinks are not received/recognized by the node. A common cause for failing downlinks is when DIO1 from the LoRa radio is not connected to the correct GPIO port/pin or is mapped incorrectly in the software. On the Heltec Wifi LoRa 32 (V2) boards DIO0, DIO1 and DIO2 are already wired on the PCB (no manual wiring required).
Is your board really a 'Heltec Wifi LoRa 32 V2' or maybe the older V1 (boardid heltec_wifi_lora_32
) or even a completely different board? On the V2 board DIO1 and DIO2 are connected to different ESP32 GPIO ports than on the V1 board.
Using an incorrect boardid will cause failure. It may result in LMIC-node not working at all or just partially (e.g. uplinks working but downlinks fail due to incorrectly mapped DIO1). The boardid determines which BSF and what settings are used (including the pin mappings). Using the wrong boardid usually results in incorrect pin mappings.
Are you using a LoRaWAN complaint 8-channel gateway?
Is there sufficient distance between node and gateway (3m at very minimum, you may try more, e.g. 10+m).
but the only thing I can see on the TTB console is a "Accept join-request", after around one minute.
What does the TTS console Live data
show (enable verbose logging)?
From the start leave the whole thing running for some 10 minutes.
What does the serial monitor output show (you can disable LMIC debug logging to keep the log short)?
What do you see on the TTS console?
FYI:
The first part of your serial output is missing (it should start with "LMIC-node" followed by some header information). It is normally preferred to show the serial log from the start.
The best way to capture all serial output is do the following (as described in the Tips chapter), in VSCode:
After having the board connected, start the VSCode serial monitor. This will open the serial monitor window.
Upload the sketch from within VSCode. This will show the upload window, but after the upload it will automatically switch back to the serial monitor window.
This way you will not miss the first output sent to the serial monitor. (When you start the serial monitor after the node is already running then you will loose the first serial output.)
Another option is to press the reset button on the board while the serial monitor window is visible. (This will work with ESP32 boards but not with all other boards. On some boards this disconnects the serial USB connection and crashes the serial monitor. See Tips chapter in the docs.)
Hi lnlp,
and thanks for the quick response. At the backside of my board WiFi_LoRa_32_V2
is printed and at the other side also Heltec, so I guess it's really the correct board. The case were the board were delivered in looks like on this picture.
I also deleted the existing device in TTN and created a new one. Of course I updated the key-files, compiled again, started the console and uploaded the program. Here are the new outputs after approximately half an hour running the program.
Debug output:
LMIC-node
Device-id: wifi-lora-32-v2
LMIC library: MCCI
Activation: OTAA
Interval: 60 seconds
000000029360: Event: EV_JOINING
000000031403: doWork job started
000000310833: Event: EV_TXSTART
000000706088: Event: EV_JOIN_TXCOMPLETE
000003781403: doWork job started
000004446640: Event: EV_TXSTART
000004841932: Event: EV_JOIN_TXCOMPLETE
000007531403: doWork job started
000008919150: Event: EV_TXSTART
000009314442: Event: EV_JOIN_TXCOMPLETE
000011281403: doWork job started
000013585061: Event: EV_TXSTART
000013983614: Event: EV_JOIN_TXCOMPLETE
000015031403: doWork job started
000018781403: doWork job started
000021750815: Event: EV_TXSTART
000022149367: Event: EV_JOIN_TXCOMPLETE
000022531403: doWork job started
000026281403: doWork job started
000029609455: Event: EV_TXSTART
000030008008: Event: EV_JOIN_TXCOMPLETE
000030031403: doWork job started
000033781403: doWork job started
000036910466: Event: EV_TXSTART
000037314809: Event: EV_JOIN_TXCOMPLETE
000037531403: doWork job started
000041281403: doWork job started
000045031403: doWork job started
000048781403: doWork job started
000050682805: Event: EV_TXSTART
000051087151: Event: EV_JOIN_TXCOMPLETE
000052531403: doWork job started
000056281403: doWork job started
000060031403: doWork job started
000063781403: doWork job started
000065019602: Event: EV_TXSTART
000065423948: Event: EV_JOIN_TXCOMPLETE
000067531403: doWork job started
000071281403: doWork job started
000075031403: doWork job started
000078781403: doWork job started
000081516351: Event: EV_TXSTART
000081931001: Event: EV_JOIN_TXCOMPLETE
000082531403: doWork job started
000086281403: doWork job started
000090031403: doWork job started
000093781403: doWork job started
000097531403: doWork job started
000101281403: doWork job started
000105031403: doWork job started
000107776836: Event: EV_TXSTART
000108191530: Event: EV_JOIN_TXCOMPLETE
000108781403: doWork job started
000112531403: doWork job started
000116281403: doWork job started
000120031403: doWork job started
000123781403: doWork job started
000127531403: doWork job started
000131281403: doWork job started
000132690273: Event: EV_TXSTART
000133104969: Event: EV_JOIN_TXCOMPLETE
000135031403: doWork job started
000138781403: doWork job started
000142531403: doWork job started
000146281403: doWork job started
TTN console data:
You have not yet answered my questions about gateway and distance between node and gateway. Please do.
At the backside of my board
WiFi_LoRa_32_V2
is printed and at the other side also Heltec, so I guess it's really the correct board. The case were the board were delivered in looks like on this picture.
So it looks like it is a real Heltec Wifi LoRa 32 V2. I am not familiar with that packaging but things change and improve over time (my V2 packaging was different but is probably 2+ years old).
My V2 also has "WiFi LoRa 32 V2" and "Heltec" on the bottom side of the PCB and "V2" on top (see picture below):
Does your board look similar/identical?
Your serial log clearly shows that the OTAA join is failing and retrying but does not succeed.
The console shows that the join is accepted by the backend. The join accept downlink is not received by the node however.
You could try to use ABP activation instead of OTAA. This will allow you to test if you can send uplinks succesfully (ABP does not require downlinks to function for that). If you have uplinks working over ABP next step is to try a downlink (can be done from console, my docs also give some hints). If then the downlinks will fail the issue will be clearly identified (but not yet what causes it).
If you get stuck with any of these steps please ask for help on The Things Network forum. There is a wealth of information available and there are experienced users on the forum that may help you solve your problem.
For ABP you will have to create a new device in the console which for ABP can be a bit tricky because for V3 some advanced device parameters have to be manually added in the console. See here in issue #17 for links to some V3 and ABP related topics.
Are you using a LoRaWAN complaint 8-channel gateway?
Is there sufficient distance between node and gateway (3m at very minimum, you may try more, e.g. 10+m).
I am not sure about the gateway manufacturer, as it is hosted by one of my neighbors. However, he has already several LoRa applications running, most of them realized with the Octopusbaord. The gateway is around 800m away. The area here around me is still in good coverage.
Does your board look similar/identical? The board looks absolute identical.
I will try the ABP activation this afternoon. Let's see if that works. Again, thank for you help.
It is essential that the gateway is a normal 8-channel LoRaWAN compliant gateway. So called 'single channel packet forwarders' (SCPF) that some people use(d in the past) on V2 are not LoRaWAN compliant and will cause LoRaWAN joins to fail (will not work with LMIC-node).
However, he has already several LoRa applications running, most of them realized with the Octopusbaord.
LoRa or LoRaWAN applications? That is an essential difference.
The linked Octopus board itself does not have LoRa support and will require an external LoRa radio module for LoRa(WAN). What LoRa radio module and what software are used is not clear from the article and doesn't say anything about the gateway. The ESP8266 microcontroller listed in the Octopus board article has very limited GPIO ports available and is not commonly used as node (end device) for LoRaWAN applications.
No response, therefore closing the isssue.
Greetings,
and first of all thanks for that great project and the detailed description on the front page. I just startet to work with LoRa a few days ago and I still have many questions, but the documentation is quite good. Unfortunately, the example code does not work for me. The compilation and upload works fine, but the only thing I can see on the TTB console is a "Accept join-request", after around one minute.
The serial console of LoRa 32 (with debugging flag set to 2) shows the following:
What did I do? I installed Visual Studio code and PlatformIO. Then i cloned the GitHub repo and opened it as a project. I selected the board "heltec_wifi_lora_32_v2" in the
platformio.ini
and set the correct LoRaWAN keys inlorawan-keys.h
, which is a copy of the examples key file. I also added the uplink formatter to the TTN console. Compile and upload worked fine (dependencies installed on the first build). The display of the LoRa 32 shows the following:The event details for the join-request event are:
Any idea what's wrong here?
Thanks!