ESP32 Heltec as 1ch Gateway- problem

I have an ESP32 Heltec Wireless stick operating as a gateway based on the sketch of Maarten Westenberg version for ESP8266 Version 5.3.3. In addition I have a similar ESP32 acting as a node and based on LMIC.

The gateway appears to be communicating with TTN because when I reset the node the TTN console for the application shows a message that recognises the node’s EUI etc.

However, then everything seems to hang. With DEBUG = 2 the gateway’s Serial window shows that connection to my router and TTN is fine but then shows the following:

Blockquote

A readUdp:: NTP msg rcvd
rxPkt:: t=13:42:02, f=0, sf=7, a=D001DBD5, flags=50, addr=0, len=23
RXDONE in dT=57008174: I=RXDONE HEADER , F=0, SF=7, E=0, S=RX , eT=57009352, dT=57010481
G addLog:: fileno=0, rec=2: 1 4 B4 0 3C 71 BF FF FF 6B 75 B0 {“rxpk”:[{“tmst”:57011385,“chan”:0,“rfch”:0,“freq”:868.099975,“stat”:1,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“lsnr”:9,“rssi”:-61,“size”:23,“data”:“ANXbAdB+1bNwumC2lKwabQC5LMHLo8w=”}]}
T sendPacket:: ERROR: data is NULL
A readUdp:: Error: PKT_PULL_RESP sendPacket failed
Guru Meditation Error: Core 1 panic’ed (StoreProhibited). Exception was unhandled.
Core 1 register dump:
PC : 0x400d3f2a PS : 0x00060a30 A0 : 0x800db4d5 A1 : 0x3ffb1f00
A2 : 0x00000000 A3 : 0x00000000 A4 : 0x3ffc1f08 A5 : 0x3ffbeca7
A6 : 0x00000003 A7 : 0x00060423 A8 : 0x00000000 A9 : 0x00000000
A10 : 0x00000022 A11 : 0x00000000 A12 : 0x3ffc1f08 A13 : 0x3ffbeca7
A14 : 0x00000000 A15 : 0x3ffb0060 SAR : 0x0000000e EXCCAUSE: 0x0000001d
EXCVADDR: 0x00000000 LBEG : 0x400014fd LEND : 0x4000150d LCOUNT : 0xfffffff3

Backtrace: 0x400d3f2a:0x3ffb1f00 0x400db4d2:0x3ffb1f20 0x400dd977:0x3ffb1f50 0x400ddc00:0x3ffb1f90 0x400e9765:0x3ffb1fb0 0x40088611:0x3ffb1fd0

Rebooting…

Blockquote

I’d be grateful for any help in understanding what’s happening here.

Further info to the above - the node is stuck at ‘Joining’ so presumably it is not receiving a response from the gateway. When the node is reset the gateway receives the ‘joining’ request and passes it to the TTN server and then reboots.

Mike

This is true only if you are using OTAA: if ABP, it does not wait for responses. I remember to have seen similar errors due to wrong wiring of DIO pins.

I have now changed my node to ABP and everything works fine - I’m getting messages received by TTN and displayed on the console. Unfortunately my node changes frequency every time it transmits cycling through the three frequencies 868.1, 868.3 and 868.5 MHz which means that only every fourth message is recognised by the gateway (which is listening on 868.1 MHz.

That is expected behavior for a LoRaWAN compliant node. Your gateway is not standard compliant so you need to adapt your node to become non compliant as well. Check the forum on how to disable the other channels.