No login success with TTGO T3 v1.6 PCB and OTAA TTN example?

(Sorry for posting such a basic question once more, but I read most of the topics and projects which cover all kind of aspects, but I didn’t managed to get it working. I tried differrent pin mappings, different gateways, double-checked byteorder and keys, … but it doesn’t work. And because I’m new to Lora(WAN) and Arduino and don’t know if I need to solder some wires, change mapping, … I need advice of more experienced devs)

Hi there,

to getting started with TTN, I bought a Lilygo TTGO board, that is labeled “T3 v1.6”. Then I used the LMIC OTAA example code, with IBM LMIC v 1.5 arduino2 lib. I also enabled the serial logging.
I changed the pin mapping, but I’m not sure if this is the right one:

iconst lmic_pinmap lmic_pins = {
.nss = 18, 
.rxtx = LMIC_UNUSED_PIN,
.rst = 12,
.dio = {/*dio0*/ 26, /*dio1*/ 32, /*dio2*/ 33} 
};

I checked it against the paxcounter mapping for TTGO 2.1 pcb 1.6 (new), so I think it’s ok?

Of course I also created an test TTN app and personalised the LoraWAN parameters, checking LSB/MSB:

static const u1_t PROGMEM APPEUI[8]={ 0x21, 0xC4, 0xxx, 0xxx, 0x7E, 0xD5, 0xB3, 0x70 };
void os_getArtEui (u1_t* buf) { memcpy_P(buf, APPEUI, 8);}

static const u1_t PROGMEM DEVEUI[8]={ 0xC1, 0xF9, 0x87, 0xxx, 0xxx, 0x8F, 0x58, 0x00 };
void os_getDevEui (u1_t* buf) { memcpy_P(buf, DEVEUI, 8);}

static const u1_t PROGMEM APPKEY[16] = { 0x77, 0xEB, 0x59, 0x76, 0xxx, 0xxx, 0xxx, 0xC5, 0xE0, 0x22, 0x95, 0xxx, 0x63, 0x13, 0xAA, 0x94 };
void os_getDevKey (u1_t* buf) {  memcpy_P(buf, APPKEY, 16);}

While the code compiles fine and is sucessfull transfered, I see only the login attempt and changing to different frequencies, but no EV_JOINED nor a different opmode:

16:20:03.600 -> 396223: engineUpdate, opmode=0xc
16:20:17.012 -> 396262: TXMODE, freq=868300000, len=23, SF=7, BW=125, CR=4/5, IH=0
16:20:22.054 -> 712724: RXMODE_SINGLE, freq=868300000, SF=7, BW=125, CR=4/5, IH=0
16:20:23.116 -> 778200: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0
16:20:23.281 -> 788465: engineUpdate, opmode=0xc
16:21:23.224 -> 4535771: engineUpdate, opmode=0xc
16:21:23.257 -> 4535804: TXMODE, freq=868500000, len=23, SF=7, BW=125, CR=4/5, IH=0
16:21:28.301 -> 4852267: RXMODE_SINGLE, freq=868500000, SF=7, BW=125, CR=4/5, IH=0
16:21:29.329 -> 4917742: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0
16:21:29.495 -> 4928006: engineUpdate, opmode=0xc
16:22:31.753 -> 8818243: engineUpdate, opmode=0xc
16:22:31.786 -> 8818276: TXMODE, freq=868100000, len=23, SF=8, BW=125, CR=4/5, IH=0
16:22:36.858 -> 9138050: RXMODE_SINGLE, freq=868100000, SF=8, BW=125, CR=4/5, IH=0
16:22:37.918 -> 9203430: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0
16:22:38.084 -> 9213694: engineUpdate, opmode=0xc
16:24:30.822 -> 16261262: engineUpdate, opmode=0xc
16:24:30.855 -> 16261296: TXMODE, freq=868300000, len=23, SF=8, BW=125, CR=4/5, IH=0
16:24:35.963 -> 16581070: RXMODE_SINGLE, freq=868300000, SF=8, BW=125, CR=4/5, IH=0
16:24:36.990 -> 16646451: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0
16:24:37.156 -> 16656714: engineUpdate, opmode=0xc

Of course also no data at the application console…
While trying different 4…5 different pin combinations and other locations ~1km close to the next gateway, I must confess, that I don’t have a idea, whats the problem? How can I debug, if a transmission is really send or if it’s a problem of the gateway / backbone / …?

Any help appreciated :blush:

Before seeing data, you should see an orange “Activation” icon in the device’s or application’s Data page in TTN Console, assuming you have TTN Console open at the time that the device transmits. When not seeing that, then either the Join Request was not received by any gateway, or TTN did not accept it due to the wrong configuration.

Try outside, with the device as high as possible, maybe even with clear line of sight to a gateway if possible. Also, try with a much higher SF. (Or wait until it tries a higher SF itself. Your log already shows that it changed from SF7 to SF8. This takes time.)

If it keeps failing then it would really help to know if the device transmitted and some gateway received it, so: get in touch with your local communities. Maybe you can get a gateway owner to temporarily add you as a collaborator of their gateway…

(If you would see an orange Activation icon in the Data page but the device still did not join, then you’d know that TTN did accept it, but the Join Accept downlink was not received by the node. And aside: LoRaWAN has no concept of “logging in”. When using OTAA, a registered device is activated using an OTAA join. Also: which LMIC are you using? As far as I know, https://github.com/mcci-catena/arduino-lmic is best maintained.)

1 Like

Maybe not:

Now, I’ve no idea how this versioning works, but you might want to read that post.

Well this mapping is considered as new(!) and esp for v1.6 and higher. (Sorry added the new hint to the label).

Will work with local communty next week to check it from GW perspective. Good to hear, that there seem to be no obvious bugs :wink:

That remark was for LilyGO’s pinout-diagram for the TTGO LoRa32 V2.1 which they have now replaced. I just checked. (I dont have the original V2.1 pinout anymore).

LilyGO has replaced the pinout document for version V2.1 of the board (about a week ago).
The pinout now says “LILYGO T3 V2.1.6” but also says “TTGO-LoRa32-V2.1” while the PCB contains the label “T3_V1.6”.
Actually T3 V2.1.6 may be the most correct, but no-one (except LilyGO) will know what it means thanks to their utterly confusing marketing and now things are confused again by using the ‘LILYGO’ label instead of ‘TTGO’. Can it be complicated even further?

The naming of these boards has been a real mess and is unclear since the beginning. The same holds for their documentation and pin-layouts. I have not seen a single TTGO pinout for the TTGO LoRa32 boards without errors. Even the latest release has errors.

Because of the naming mess I call this version TTGO LoRa32 V2.1 release 1.6 which at least makes clear what we are talking about (and someone reading the V1.6 label on the PCB can understand).

I just noticed that LilyGO have replace the LoRa32 V2.1 pinout by a version that is for V2.1 release 1.6 only. It still contains errors and they appear to have removed any previous versions without notice (no version management) complicating things for users of older versions of their product.

If you check their current pinout-diagram you can see at least the following errors:

  • pin labeled IO0 on the PCB but labeled GND in the diagram.
  • pin labeled IO4 on the PCB but labeled 5V in the diagram.

How hard can it be to get things like this correct and (let) check that the diagram is correct?

Due to above unreliabilities I have removed the link to the V2.1 pinout-diagram from the ESP32 topic.

2 Likes

Thanks for the details. How can we know, if the pins are connected, or if you need to solder a separated wire?

Sad, but I still have no success :frowning:

Thanks to my local community I learned, that all GWs were offline, but one operator restarted his, not to far away from me (~1km): https://www.thethingsnetwork.org/community/rostock/
But while it’s online, he didn’t noticed any TTN packages passing trough.

Also my node is still listed as “not seen”. It does not have any events that might occur and seems just send, but I’m not sure if this is all that has to happen, or if I should get some more feedback if the packages success:

13:45:18.067 -> 172111: TXMODE, freq=868300000, len=23, SF=7, BW=125, CR=4/5, IH=0
13:45:23.105 -> 488573: RXMODE_SINGLE, freq=868300000, SF=7, BW=125, CR=4/5, IH=0
13:45:24.132 -> 554049: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0
13:45:24.298 -> 564314: engineUpdate, opmode=0xc
13:46:24.624 -> 4334534: engineUpdate, opmode=0xc
13:46:24.657 -> 4334567: TXMODE, freq=868500000, len=23, SF=7, BW=125, CR=4/5, IH=0
13:46:29.695 -> 4651029: RXMODE_SINGLE, freq=868500000, SF=7, BW=125, CR=4/5, IH=0
13:46:30.756 -> 4716505: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0
13:46:30.921 -> 4726769: engineUpdate, opmode=0xc
13:47:39.740 -> 9028642: engineUpdate, opmode=0xc
13:47:39.773 -> 9028675: TXMODE, freq=868100000, len=23, SF=8, BW=125, CR=4/5, IH=0
13:47:44.844 -> 9348450: RXMODE_SINGLE, freq=868100000, SF=8, BW=125, CR=4/5, IH=0
13:47:45.905 -> 9413830: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0
13:47:46.071 -> 9424093: engineUpdate, opmode=0xc
13:49:46.457 -> 16948222: engineUpdate, opmode=0xc
13:49:46.490 -> 16948255: TXMODE, freq=868300000, len=23, SF=8, BW=125, CR=4/5, IH=0
13:49:51.562 -> 17268029: RXMODE_SINGLE, freq=868300000, SF=8, BW=125, CR=4/5, IH=0
13:49:52.623 -> 17333409: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0
13:49:52.788 -> 17343673: engineUpdate, opmode=0xc
13:52:06.299 -> 25689085: engineUpdate, opmode=0xc
13:52:06.331 -> 25689118: TXMODE, freq=868500000, len=23, SF=9, BW=125, CR=4/5, IH=0
13:52:11.536 -> 26014877: RXMODE_SINGLE, freq=868500000, SF=9, BW=125, CR=4/5, IH=0
13:52:12.563 -> 26080064: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0
13:52:12.728 -> 26090331: engineUpdate, opmode=0xc
13:55:44.763 -> 39343063: engineUpdate, opmode=0xc
13:55:44.826 -> 39343097: TXMODE, freq=868100000, len=23, SF=9, BW=125, CR=4/5, IH=0
13:55:50.002 -> 39668854: RXMODE_SINGLE, freq=868100000, SF=9, BW=125, CR=4/5, IH=0
13:55:51.030 -> 39734042: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0
13:55:51.195 -> 39744306: engineUpdate, opmode=0xc

You could install thr paxcounter software, to be sure that you have coverage. If your board joins with paxcounter, you can compare against your code.

1 Like

So not even from one of their own devices? I’d assume that someone who has set up a community gateway would also have some test device? (If not: many kudos to them for providing a gateway!)

And what else did you try?

For TTGO LoRa32 V2.1.6 you need to specify 23 (GPIO23) for LoRa RST and not 12.
(The iconst must be a typo.)

Read the start post of Big ESP32 + SX127x topic part 3 for details.
I have updated it for TTGO LoRa32 V2.1.6 (aka T3 V1.6).

Also check the notes about manual wiring of DIO1.

When DIO1 is not wired or not properly mapped in the software then downlinks will not work and hence OTAA will not work.

I am not aware if DIO1 is already wired to GPIO33 on the PCB by default and if DIO2 is already wired to GPIO32 on the PCB by default or not.

I do not have the V2.1.6 board so I am unable to verify it. If you could check with a multi-meter (in resistance/Ohms setting) if these are already connected on the PCB and report the results here that would be nice.