Pointer to configuring TTN with TTGO T3_v1.6 (ttgov21new.h)

[rhbroberg]

I have a working TTN account which other LoRa boards (not using paxcounter) successfully join and talk to the gateway.

I have not had any luck in configuring a ttgo board to talk to TTN using ttgov21new.h, even though it looks just like the picture of a board in your README. TTN doesn't have a 'brand' menu item which matches the board, so I chose 'manually' with the frequency plan which matches my gateway (United States 902-928MHz, FSB 1), and the LoRaWAN version of 'MAC V1.0.3', and left the LoRaWAN class capabilities class B and C support disabled. It's in OTAA mode. Gateway is raspberrypi/4 with the RAK2287 hat.

This is the board I'm using:

ttgo

I have checked the devEUI, AppEUI, and AppKey many times: they're entered correctly in loraconf.h in MSB format.

In the TTN gateway console, I see the JoinEUI message, but there is never an accept, so the data never gets to my application.

I'm surely doing something wrong - can you provide a pointer of where to look for configuring the TTN and/or the paxcounter settings so that they can talk to each other?

Thanks

[cyberman54]

If you see the join request but not the join accept message while OTAA joining, most common reason is that the downlink is not working.

• Did you edit lmic_config.h and set your country (probably CFG_us915)?
• Are you sure your purchased board hardware matches your frequency plan (915 MHz)?
• If yes, did you try the same board with some other kind of TTN node software, to check the hardware?

[rhbroberg]

The lmic_config.h is set to the correct value (CFG_us915). The purchased board says 915 on the label in the box it came in, so I feel pretty certain about that as well. I haven't tried a different TTN project, which is what I'll try next.

I have a number of these boards (all from the same vendor, however), and I've tried 3 so far with the same results, which is failure. The curious part about this is that the TTN gateway console never shows it trying to accept or send a downlink message, which makes me think that there's something incompatible with the handshaking which is happening in the JoinEUI.

Can anybody here confirm that they've gotten this hardware to work with TTN?

[cyberman54]

I have some of these boards in operation with TTNv2 and v3, with paxcounter and other software. But it's the EU868 MHz version and configuration, not US915.

With hardware purchased from aliexpress dealers, you never can be 100% sure that versions are really identical and specs are valid.

A common failure reason for "no downlink" is, that DIO1 signal from SX127x chip is missing or not properly wired/configured. Then downlinks can't work, because in LMIC the state TX_COMPLETE is never reached.

[rhbroberg]

I'm not sure how to determine if the version is 915MHz vs 868MHz - I assume there must be some lmic (or other api) call I can make which answers that? A pointer for that would be great for me to verify. Since you have some of these boards which work, can you confirm that the TTN choices I made for 'manual' device entry are correct?

I'm inclined to think that the RF configuration is correct, since the gateway is getting my JoinEUI. To confirm what you're saying, the JoinEUI could be received by the gateway, but TTN may never move to 'accept' due to a hardware/pinout issue on the device side? Here is the gateway console output:

The ttgo device running paxcounter is the one doing the join; the newer line than that is a Heltec running something else which is successfully talking to the gateway. My (limited) experience when TTN drops the JoinEUI on the floor without forwarding it, it's because the AppKey doesn't line up - yet I've checked that string many many times.

According to the pinout on the part I have, the SX127x chip DIO is 26, which lines up with ttgov21new.h for LORA_IRQ (which is what's assigned to the DIO), so at least the part's documentation seems correct (I can't speak for the board wiring until I try another program on it). Is there a way I can log out that TX_COMPLETE has been reached to verify?

[rhbroberg]

I discovered that the other LoRa device I had which was working correctly was using ABP; when I configured an identical device to use OTAA it would not complete the join handshake on my gateway. My gateway predated the conversion to V3 of TTN, so I created it from scratch and re-joined it to my TTN account. Now the non-PaxCounter device successfully joins using OTAA (and ABP).

I now see traffic going to my device on TTN console for my gateway and my application and my device, and it's getting farther - however it's not quite completing the join still. Using the stock antenna it came with (I have verified that it is a 915Mhz antenna), I'm getting an RSSI of -110 or so, when I'm 3m from the gateway. When I'm a few rooms (and 6m) away, the signal doesn't reach at all.

Am I correct in assuming that TTN won't complete the handshake with such a weak RSSI? I se the "Successfully processed join" and "Schedule join-accept for transmit" and so on, in my device console on TTN. But I'm still not getting data forwarded to TTN from the PaxCounter firmware. 'JOIN WAIT' appears on the OLED display as it cycles through the status values

Any ideas are appreciated, thanks

[cyberman54]

This still points to that your downlink is not working. -110 rssi is a very weak value. Are you sure your gateway is working? Your device could see another gateway, which is too far away.

This does not look like a paxcounter related problem. Check your LORAWAN setup. Go to another gateway / location to verify your board is working and properly configured.