ESP32 test - connection seems to work, but no messaging

End Devices (Nodes) LMIC
1

I’ve been wrestling with trying to get an ESP32 to talk to TTN for a few days, and getting nowhere.

For my device, I have a TTGO ESP32 LoRa (v 1.1 I think). I connect to my TTN sandbox account as device in an application, and try to connect using Arduino LMIC library; specifically this example.

I don’t have my own gateway (well, I do have a couple of surplus RPis with RAK2287 hats but can’t get them to work as gateways - another issue). So I think I’m going through some local open gateway. That might be my issue. But the handshake works, so the gateway might not be the problem.

I set #define CFG_us915 2 in lmic_project_cfg.h because I understand that TTN works in block 2 of the US frequencies.

Then my device tries to connect via OTAA and things seem to almost work.

The console log of the ESP32 says:

9542103: EV_TXSTART
9885018: EV_JOINED
netid: 19
devaddr: 26xxxxxx
AppSKey: xx-xx-xx-xx..
NwkSKey: xx-xx-xx-xx..
9892765: EV_TXCOMPLETE (includes waiting for RX windows)
17392794: EV_TXSTART
Packet queued
17784180: EV_TXCOMPLETE (includes waiting for RX windows)
25284205: EV_TXSTART
Packet queued
25675591: EV_TXCOMPLETE (includes waiting for RX windows)
33175615: EV_TXSTART
Packet queued

And the console at TTN says:

17:30:42 Forward join-accept message
17:30:41 Successfully processed join-request
17:30:41 Accept Join Request

But the ‘hello world’ packets that this code sends out every 60s don’t get recorded; there’s the esp32’s EV_TXSTART but nothing to indicate receipt.

I think TTN should be getting my “hello world” and sending back an ACK that my esp32 console prints out.

Something is working, because the connection worked (and a matching device address appeared on both ends). But after the handshake, nothing.

I also try to generate a synthetic uplink message using TTN console’s ‘Messaging’ feature, but it never triggers the EV_RXCOMPLETE case in the esp32 code.

Does anyone have any suggestions what might be happening? Apologies for my cluelessness; this is all rather new to me.

2

One of the best examples to start with is Lmic-node.

Sending text is not one of the best practices for LoraWAN.

What doe you see in the application console?

3

In the Application console, I see 1 application with 1 end device (the esp32).

In the console, the message are:

17:30:19  eui-70b3d57xxxxxxxxxx Forward join-accept message
17:30:18  eui-70b3d57xxxxxxxxxx Successfully processed join-request
17:30:17  eui-70b3d57xxxxxxxxxx Accept join-request
17:30:02  eui-70b3d57xxxxxxxxxx Forward join-accept message
17:30:01  eui-70b3d57xxxxxxxxxx Successfully processed join-request
17:30:00  eui-70b3d57xxxxxxxxxx  Accept join-request

And those are the only TTN Application data messages I see. Once a join happens no more messages, unless I send synthetic ones from the console (and these don’t register on the esp32 serial console).

I assumed that for a TTGO ESP-v1 board I don’t have to bridge any pins, and that the initial connect wouldn’t happen if I did need to bridge pins. I also assumed that “Hello world” was OK, because it was in a canonical example, apparently designed for TNN, in the LMIC library, and because it was encapsulated in a LoraWAN packet.

I’ll look at the LMIC-NODE example.

4

One of the best examples to start with is Lmic-node.

I installed Visual Studio and PlatformIO and tried LMIC-NODE.

Same thing: a connection works, but messages fail. No message shows up on TTN console after connect.

The connection process can take a few tries, and both directions (request and ack) are unreliable.

My other identical ESP32 failed to connect entirely (maybe one JOIN request showed up at TTN), suggesting there might be an issue of marginal signal strength.

But I would imagine that if the connection is good enough to join, it should be good enough to get at least a few packets through, eventually, in at least the uplink direction.

Is it possible for the (unknown) public gateway I’m using to suffice for connection but not data packets, for reasons of signal strength, timing, or deliberate routing?

I guess I’ll have to try getting one of Rak PIs to route to TTN. So far, I’ve failed.

5

If you have the console open when the join request arrives you can check the RSSI and SNR and SF of that request by expanding the line (click on it). It’s all there in the json data.

Post it (format it using the tools at the top of the text entry box for readability) and we can advise.

6

Ah, I had looked for it, but didn’t realized it was in the ‘successfully processed’ line. Here are what I think the relevant bits are. Hope it’s OK to anonymize geography.

 "settings": {
      "data_rate": {
        "lora": {
          "bandwidth": 125000,
          "spreading_factor": 10,
          "coding_rate": "4/5"
        }
      },
      "frequency": "903900000",
      "timestamp": 3744854980,
      "time": "2024-01-08T00:12:28.279Z"
    },

"rx_metadata": [
      {
        "gateway_ids": {
          "gateway_id": "xxxx", /* I recognize this from TNN network map as being an open station about 1 km away on a hill,  but with a difficult line of sight */
          "eui": "xxxxxx"
        },
        "time": "2024-01-08T00:12:28.279Z",
        "timestamp": 3744854980,
        "rssi": -115,
        "channel_rssi": -115,   /* close to limit of -120, but still within range?  */
        "snr": -11,      /* above minimum of -20 */
        "location": {
          "latitude": xx.xx,
          "longitude": xx.xx,
          "source": "SOURCE_REGISTRY"
        },
        "uplink_token": "xxxxx,
        "gps_time": "2024-01-08T00:12:28.279Z",
        "received_at": "2024-01-08T00:12:28.301080495Z"
      }
    ],

  "received_at": "2024-01-08T00:12:28.343268245Z",
    "correlation_ids": [
      "gs:uplink:xxxxx"
    ],
    "device_channel_index": 8,
    "consumed_airtime": "0.370688s"
  },

edit: When I try to reboot the esp32 and rejoin, it fails, but multiple join packets are received, with RSSI=-132 to -108. No ack packets are seen on esp32 console. When I disconnect console USB cable from esp32 and walk around with a USB power brick to get a better line of sight from the street , I get no join packets at the TNN console (but then I don’t see what esp32 is doing). Either the power brick isn’t powering it (though LED is on), or (wild guess) the signal was feeding back through the USB to the power lines and the house was acting as a weak antenna. But whatever it is, it seems to be operating at the edge of feasibility, though it’s hard to understand why join sometimes worked and data didn’t.

edit2: now I looped the USB-brick-powered esp32’s antenna wire over a set of Xmas tree lights outside, as it had been when using the serial-USB connection, and I got a join signal to TTN. I’m betting the only reason I’m getting a signal is from using these external wires as some sort of a supplementary antenna. And the signal got stronger (RSSI=-105 / SNR=-5) when I intertwined the antenna wire more, and a join works right away but still no data packets on the TTN console.

7

You are at the edge of the universe with these levels :grinning:’

What antenna are you using?

What do you see exactly in the application console when the node joins?
Do you have a decoder in place?

8

You are at the edge of the universe with these levels

True, but that’s worst case; sometimes it’s -110.

What antenna are you using?

The same approx 5cm black stub antenna that is usually sold with esp32 boards.

What do you see exactly in the application console when the node joins?

I see

17:30:19  eui-70b3d57xxxxxxxxxx Forward join-accept message
17:30:18  eui-70b3d57xxxxxxxxxx Successfully processed join-request
17:30:17  eui-70b3d57xxxxxxxxxx Accept join-request

Eventually, this results in a connection diagnostic on the esp32 serial console, at which point the esp32 tries to send actual data packets. Otherwise, the above keeps repeating. When the esp32 shows that a connection has happened, the above stops repeating.

Do you have a decoder in place?

No, I was looking only for the presence of a data packet, not its content. I assume that if no decoder is in place, then an opaque payload object will appear in the TTN console.

9

Most probably not the best design antenna in the world.

Where you set the frequency plan up for your node, when you first register it, you are setting the frequency and SF the LNS are going to use to send the ‘Forward join-accept message’ to the node.

Your nodes SF is most probably at SF 11-12 to the gateway, as you are the edge, the LNS sends a at a higher SF, thus your node can’t interpret the signal.

I am not 100% sure about the US spec SF of the join request - “I need to read the doc, like you have to”

The data will be forwarded in the “uplink_message” if the node joined the network, irrespective of the decoder present or not.

I miss under stood you, I were understanding your node have joined the network, then the data will be present in the uplink message.

10

Your nodes SF is most probably at SF 11-12 to the gateway, as you are the edge, the LNS sends a at a higher SF, thus your node can’t interpret the signal.

OK, but I assume that my uplink messages (after successful join) should still get to TTN, even if a response cannot get back to me for the reason you gave.

The data will be forwarded in the “uplink_message” if the node joined the network

yes, and there were no uplink messages, ever. Just join messages that succeeded after a few tries.

At any rate, even though I don’t fully understand the details why no uplink packets made it to TTN, I now understand that I’m operating at the very edge of viability, and I need to fix this. The gateway is on a mountain, but houses, plus the curvature of the mountain, prevent a line of sight path. Any connection I have is marginal.

Thanks for helping me get to this point. I now have to figure out how to make my gateways work. I’m going to marked this as ‘solved’ for now.

11

First of all, please do NOT use extensive edits on an existing message. The forum will not send notifications for edits so they will go unnoticed for a lot of people. Any updates can be done in new messages.

These values are marginal for SF10.

The missing data packets might have several causes:

  • Data could be transmitted using a different SF. In case of SF9 or less it simply might not make it to the gateway
  • In the join accept your node could be instructed to use different frequencies resulting in it transmitting on a frequency the gateway is not listening on

When you get a gateway operational you need to make sure your node has at least 20 feet and a wall separation. Otherwise you will run into the ‘node is shouting in gateways ears’ issue that many experience (search forum if you want more information)