Still stuck at EV_JOINING

End Devices (Nodes)
1

Hello Community,

I’m trying to setup a single-channel-gateway and a node which is using OTAA, but no matter what I configure… the node is still stucking at EV_JOINING. I will report what I’ve done so far. Maybe you could see any mistake or help me, what I’m doing wrong…

I’m using the following Hardware:

One board is the Gateway with the following Code:

The other board is the Node using OTAA with the following Code:

I’ve correctly changed the Keys in the Node-Code:

static const u1_t PROGMEM APPEUI[8] = { 0x2E, 0x94, 0x01, 0x**, 0x**, 0xD5, 0xB3, 0x70 };

static const u1_t PROGMEM DEVEUI[8] = { 0x80, 0xFB, 0x98, 0x**, 0x**, 0xE3, 0x50, 0xCC };

static const u1_t PROGMEM APPKEY[16] = { 0x42, 0x75, 0xE7, 0x**, 0x**, 0x**, 0xC5, 0x59, 0x65, 0xAB, 0x6A, 0x55, 0x7A, 0x08, 0xC8, 0x4D };

Then I start running the Gateway and in the TTN Console of the Gateway I see it is online. That seems to be working so far.
After that I start running the Node and in the TTN Console of the Gateway (-> Traffic), I see the Gateway is receiving a Join Request and sending back a Join Accept like in the picture:

2019-03-27%2009_48_49-Window

And in my Application Data of the device I see the Activation like in the following picture:

2019-03-27%2009_51_20-Window

But I can not see the “Hello, world!” !!!

The Console of the node shows following:

2019-03-27%2009_55_39-Window

Could you guys please tell me what I’m doing wrong? Is the node not receiving any Join Accept from the gateway? Or is the gateway not sending any Join Accept to the node?
Why can’t I see the “Hello world” message in the Application Data?

If you need any more information please let me know. I just wanted to keep the post as short as far.

2

try ABP first

3

Hello BoRRoZ, thanks for your reply. I’ve tried the ABP using the following code:

I changed the lines:

static const PROGMEM u1_t NWKSKEY[16] = { 0x47, 0xBA, 0x**, 0x**, 0x**, 0xDF, 0x56, 0xC4, 0x38, 0x68, 0x9A, 0x0B, 0xAC, 0x10, 0x9D, 0xC9 };

static const u1_t PROGMEM APPSKEY[16] = { 0xD5, 0xB1, 0x**, 0x**, 0x**, 0x38, 0x7E, 0x53, 0x51, 0x84, 0x5D, 0x87, 0x62, 0xB4, 0xE0, 0x61 };

static const u4_t DEVADDR = 0x26****DB ; // <-- Change this address for every node!

I get the following on my Gateway Traffic:

2019-03-27%2010_14_29-Window

And I get the following in my Application Data:

2019-03-27%2010_18_19-Window

The payload “48 49” stands for “HI” so that seems to be working… but in the Node serial console I get the following:

2019-03-27%2010_19_48-Window

There is no “EV_Joining” or so… and the code from the example should transmit every 60 seconds the payload “HI” but the payload is only send once and there is no feedback in the serial console of “EV_Joinig” or “EV_Joined”.

Is it working correctly so far, or is there still a issue on transmitting/receiving?

4

Seems to me that your single-channel test gateway does not support downlinks:

  • Your uplink (when using ABP) seems to be a confirmed uplink, which expects a downlink with an acknowledgment. You can see the 14 bytes downlink (blue downwards icon) in TTN Console, but apparently the node is not receiving it. LMIC is likely re-trying the uplink at some later time, but it’s then probably using a frequency or spreading factor that your single-channel test gateway is not listening to.

  • OTAA needs a downlink for the OTAA Join Accept. Again, you seen it in TTN Console, but apparently the node is not receiving it.

5

arjanvanb thanks for your reply.
Do you think this is rather a hardware or a software issue?

I’ve done a second test with the ABP and that’s what it looked like. I think the device got now a downlink? But again: only sending once… the TX_Intervall = 60 doesn’t seem to work. There is no second payload without resetting the board on the RST button manually.

2019-03-27%2011_41_10-Window 2019-03-27%2011_41_20-Window

Any ideas how I could get this working?

6

You cannot tell from TTN Console if the device received it. You only know that TTN wanted a gateway to transmit it. (Might also be another gateway if your uplink was received by multiple gateways.)

Again: your device is waiting for the downlink, but not receiving it.

Some single-channel test gateways do support downlinks, so one could say it’s the software of your gateway.

(Also, your device should not ask for a confirmation for each uplink, see Fair Use Policy explained)

7

Try to insert LMIC_setClockError (MAX_CLOCK_ERROR * 10 / 100); to incrise the size of the RX window.
This single channel gateway usualy don’t send the downlink on the right time.

1 Like
8

@ arjanvanb this is the only gateway far and wide. There is no other gateway in range for my location.

@ ricaun Where do I have to insert this line of code? In the node-code in the setup() part? If yes: then this line of code doesn’t change anything for me - unfortunately.

I’ve read somewhere in this forum here, that the distance between the Node and the Gateway should be > 3m, so I’ve placed the gateway outside my room. (should be about ~ 15 - 20 meters away now from the node).

Here I have a screenshot from the Gateway WebServer which will be setup if you use the follow code (https://github.com/vpcola/ESP32SingleChannelGateway/tree/master/ESP-sc-gway). Maybe this helps you guys to read some more information about my problem

2019-03-27%2013_29_49-Window

9

You’re using a single channel gateway.
This won’t work with OTAA.

Use only LoRaWAN specs compliant gateways, like the best buy TTIG, to avoid such trouble.

10

While true that single-channel test gateways are troublesome and certainly not compliant, some do support downlinks (and the screenshot shows this one does too), and hence also support OTAA.

Yes, before the OTAA Join is started. (When the join is not explicitly started in your code, then the first uplink will make LMIC first trigger the join, so then anywhere around the end of setup will do.)

You could try larger values, like MAX_CLOCK_ERROR * 20 / 100. After the OTAA Join succeeds, you’ll have to limit the channels to the one supported by your single-channel test gateway, as an OTAA Join Accept in EU868 will include network settings that (rightfully so) expect a proper gateway. See Can LMIC 1.6 be set up to use a single channel and SF? - #11 by arjanvanb

So, all said, @Verkehrsrot is right.

11

I’ve an update:
First I ordered a The Things Gateway. I’ve done the setup, the activation and it is working fine with the gateway. So the Gateway side seems to be working correctly now (no more single-channel gateway).

But my Node is still sending only 1 message and then stucks at OP_TXRXPEND, not sending

Here is the log of my Node (WiF LoRa 32(V2)):

Starting
RXMODE_RSSI
3195: Scheduled job 0x3ffbfce0, cb 0x400d0e44 at 3753194
3229: engineUpdate, opmode=0x808
3237: Uplink data pending
3242: Considering band 0, which is available at 3189
3468: Considering band 3, which is available at 0
3746: No channel found in band 3
3929: Considering band 0, which is available at 3189
4222: No channel found in band 0
4406: Considering band 1, which is available at 3189
4699: Airtime available at 3189 (channel duty limit)
4993: Ready for uplink
5153: Updating info for TX at 3237, airtime will be 3856. Setting available time for band 1 to 388837
5706: TXMODE, freq=867100000, len=25, SF=7, BW=125, CR=4/5, IH=0
Packet queued
9572: irq: dio: 0x0 flags: 0x8
9584: Scheduled job 0x3ffbfd08, cb 0x400d1648 ASAP
9591: Running job 0x3ffbfd08, cb 0x400d1648, deadline 0
9651: Scheduled job 0x3ffbfd08, cb 0x400d1350 at 71433
71433: Running job 0x3ffbfd08, cb 0x400d1350, deadline 71433
71560: RXMODE_SINGLE, freq=867100000, SF=7, BW=125, CR=4/5, IH=0
3753194: Running job 0x3ffbfce0, cb 0x400d0e44, deadline 3753194
OP_TXRXPEND, not sending
3753202: Scheduled job 0x3ffbfce0, cb 0x400d0e44 at 7503201
7503201: Running job 0x3ffbfce0, cb 0x400d0e44, deadline 7503201
OP_TXRXPEND, not sending
…

But what does this logfile say to me? I can see OP_TXRXPEND, not sending, this means my Node does NOT get an acknowledge back from the Gateway? The TXRX is not complete. But my TX is what I see in the TTN Console:

2019-04-12%2014_23_53-Window
2019-04-12%2014_23_53-Window1057×212 7.04 KB

Does this mean, that the RX is not complete?

Do you guys have any idea, why I stuck in OP_TXRXPEND, not sending ?
Do I have to connect some wirers on my WiF LoRa 32(V2) ?
I’ve already tried using LMIC_setClockError(MAX_CLOCK_ERROR * 20 / 100); but this seems not to solve the issue.

12

Okay, finally it’s working. For all readers of this topic who have the same Problem:

The WiF LoRa 32(V2) has another pin-mapping. The user saglettn faced the same issue and posted a comment into this topic: Big ESP32 + SX127x topic part 3.
If you used the pin-mapping from this post: Big ESP32 + SX127x topic part 2 and you are using WiF LoRa 32(V2) you have to change the pin-mapping to:

// Pin mapping
const lmic_pinmap lmic_pins = {
    .nss = 18,
    .rxtx = LMIC_UNUSED_PIN,
    .rst = 14,
    .dio = {26, 34, 35},
};

I did not found this in a topic. It seems that the V1 Version of the Heltec LoRa 32 is using .dio = {26, 33, 32}.

2 Likes
13

Looks like DIO1 signal from LoRa chip is missing.
You should check if it is wired and that you have correct pin mapping.

14

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.