No Join response - but no indication of a Join request either

[mderouss]

Hi folk,

for the last couple of weeks or so, I’ve been attempting to get an OTAA - provisioned LoRA node running with TTN. However, it’s failing consistently, and I’m out of ideas right now, and looking for help.

I’m using a TTGO T-Beam device, which has a ublox NEO6M but no OLED. The version info from the board says "TT22_V07 20180711’. I have two of these devices, and get the same problem on each.

The basic architecture is an LMIC event loop, based on the LMIC OTAA example. The LMIC variant I’m using is the MCCI Arduino version. I’m using PlatformIO as my dev environment.

The problem is that I appear to be failing to get any response at all from a Join. Neither EV_JOINED nor EV_TXCOMPLETE are received. The flag values reported in the log indicate timeout for both RX windows. Here is a typical log :

---

ets Jun 8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:1100
load:0x40078000,len:9232
load:0x40080400,len:6412
entry 0x400806a8
MAC Address : 84:45:B9:3A:7D:80
Starting, LORA tx interval (s) : 120
MAX_CHANNELS : 16
MAX_BANDS : 4
OSTICKS_PER_SEC : 62500
RXMODE_RSSI
Initialising sensors
Reading 0x1 not configured
Reading 0x2 not configured
Reading 0x4 not configured
Reading 0x8 not configured
Reading 0x10 not configured
Reading 0x20 not configured
Sensor or reading not valid 0x40
Sensor Failure
Sensor or reading not valid 0x80
Sensor Failure
Sensor or reading not valid 0x100
Sensor Failure
Valid readings 0x0
MAX_BUFFER_BYTES : 18
Reading 0x1 unavailable
Reading 0x2 unavailable
Reading 0x4 unavailable
Reading 0x8 unavailable
Reading 0x10 unavailable
Reading 0x20 unavailable
Reading 0x40 unavailable
Reading 0x80 unavailable
Reading 0x100 unavailable
Bits to write : 16
Bytes used : 3
Message ( hex bytes ) : 0,0,0
Job Send
320284: engineUpdate, opmode=0x8
320473: start joining 1
Packet queued
320686: EV_JOINING
320793: engineUpdate, opmode=0xc
748832: engineUpdate, opmode=0xc
748858: EV_TXSTART
748861: engineUpdate, opmode=0x88c
748928: TXMODE, freq=868500000, len=23, SF=7, BW=125, CR=4/5, IH=0
1065264: setupRx1 txrxFlags 00 → 01
start single rx: now-rxtime: 3
1065396: RXMODE_SINGLE, freq=868500000, SF=7, BW=125, CR=4/5, IH=0
rxtimeout: entry: 1065732 rxtime: 1065389 entry-rxtime: 343 now-entry: 4 rxtime-txend: 312596
1128052: setupRx2 txrxFlags 0x1 → 02
start single rx: now-rxtime: 4
1128184: RXMODE_SINGLE, freq=869525000, SF=9, BW=125, CR=4/5, IH=0
rxtimeout: entry: 1129480 rxtime: 1128177 entry-rxtime: 1303 now-entry: 4 rxtime-txend: 375384
1129498: processRx2Jacc txrxFlags 0x2 → 00
1129566: engineUpdate, opmode=0xc
4881254: engineUpdate, opmode=0xc
4881275: EV_TXSTART
4881277: engineUpdate, opmode=0x88c
4881343: TXMODE, freq=868100000, len=23, SF=7, BW=125, CR=4/5, IH=0
5197678: setupRx1 txrxFlags 00 → 01
start single rx: now-rxtime: 3
5197810: RXMODE_SINGLE, freq=868100000, SF=7, BW=125, CR=4/5, IH=0
rxtimeout: entry: 5198146 rxtime: 5197803 entry-rxtime: 343 now-entry: 3 rxtime-txend: 312596
5260466: setupRx2 txrxFlags 0x1 → 02
start single rx: now-rxtime: 4
5260598: RXMODE_SINGLE, freq=869525000, SF=9, BW=125, CR=4/5, IH=0
rxtimeout: entry: 5261894 rxtime: 5260591 entry-rxtime: 1303 now-entry: 4 rxtime-txend: 375384
5261912: processRx2Jacc txrxFlags 0x2 → 00
5261978: engineUpdate, opmode=0xc

The reason this is so puzzling is that there is a LoRA gateway located about 100m away ( ie. not far in LoRA terms ), which I used successfully for a few weeks to do something very similar ( again based on the LMIC OTAA example ) with the same board. Unfortunately the code for that experiment has been lost :(. This implies that I’m doing something wrong in this code.

I’ve added my own sensor handling code here, but no sensors are in use. They are configured out so that no attempt is made to initialise or read from them, hence all the log complaints, and for all sensors except the NEO6M they are not physically attached to the board. I did this in case initialisation of the sensors was having some sort of side effect, but it has not changed the Join behaviour.

The code is available on Github, on the ‘gpssensor’ branch of :

git@github.com:basingstoke-makerspace/AQMLoraTBeam.git

Many criticisms can certainly be made of the code, most of them by me, but right now it would just be nice to get over this particular problem.

Here are some of the things I’ve already tried :

1. I have physically connected the Lora1 pin to GPIO 33 https://github.com/matthijskooijman/arduino-lmic/issues/164. I tried connecting Lora2 to GPIO 32 as well, but it made no difference.

2. I’ve ‘fixed’ the SF value for RX2 to match TTN expectation ( SF9 ), but I’m not really expecting that RX2 will be used to send the Join response.

3. I’ve checked that the ostick period is within the range specified by LMIC - it is, just ( 16us vs LMIC lower limit of 15.5us ).

4. I have set the tx power to the maximum that I think LMIC will permit in this context ( 17 ), though I’m not able to measure the actual power output of the device. It didn’t have any effect.

5. I’ve checked TTN several times to see that the APPEUI, DEVEUI and APPKEY are correct. Just checked again now. I did notice one puzzling thing, which was that the ‘example code’ section showed the APPEUI and APPKEY as strings, rather than bytes. But I’ve assumed that the ‘{ 0x??, 0x?? … }’ representation that TTN provides can just be cut/pasted into the code.

6. TTN says that it has never seen the device. No downlink, no activation, no errors. 0 frames.

So, does anyone have any idea about what may be going on here, or even just potential avenues of investigation ? I don’t have access to physical layer tools to look at the actual radio transmission. I do have access, via the gateway owner, to gateway info - but I’m not certain what I’m looking for.

Thanks,
Mark de Roussier.

[kersing (Jac Kersing)]

For OTAA you should leave RX2 at SF12. The join response will take care of setting RX2 parameters.

When copy-pasting the keys, did you observe the byte order required?

The missing events could be caused by pin mapping issues.

Is there any stock code configured to run on your hardware you can use to validate the hardware?

[mderouss]

Hello Jac,

OK, I can revert the RX2, fixing it at 9 didn’t solve the problem anyway. But if, as I understood to be the case, TTN uses SF9 for RX2, and I know I will be using TTN, is there any positive benefit to starting it at SF12 and waiting for TTN to change it ? Does it somehow maximise the probability of receiving a Join response ?

Regarding byte order, I just took the TTN defaults ( i.e. you have the option in the interface to change the byte order, but I didn’t do that ). I’ll check that this is correct.

The pin mapping is taken from other discussions about using LoRA with this device, I’m pretty confident that it is correct ( or at least, it is what other people are using successfully ).

I’ll check the Lilygo github for examples. I tried to build TTNMapper for this purpose, but when I tried to build it, I hit compilation issues, and decided TTNMapper was overkill for this. As I noted, I did have this hardware working at one point, and I’m also seeing the same behaviour on 2 boards. So if it is a hardware issue, it’s one that is generic to the board, and is triggered in some way by the particular build that I’m now doing.

I still suspect that I am mis-configuring ( or failing to configure ) the system in some way, or I’m making some invalid assumption about LMIC behaviour.

Thanks,
Mark

[mderouss]

Ahhh, you were correct It was an lsb/msb issue. It’s not like there were no warnings in the code… when you actually read them :(. Anyway, now I will at least have some more interesting problems !

Thanks,
Mark

[kersing (Jac Kersing)]

@mderouss

But if, as I understood to be the case, TTN uses SF9 for RX2

TTN uses SF12 until OTAA join is successful. Hard coding SF9 is applicable to ABP only,