Can't join TTN

I have been trying to connect my node to TTN for a couple days but can’t get it to work.

TTGO T3 v2.1 _ 1.6 (esp32) (LilyGO TTGO T3 LoRa32 868MHz V2.1.6 ESP32 - LILYGO-H240-01)

First of all some rookie questions:
I can just connect my node without needing my own gateway, right?
On TTN mapper if my location is not in a purple zone, does that mean I don’t have coverage?

I have tried a lot of different programs including the pax counter one where I select “ttgov21new.h” as my device. (GitHub - cyberman54/ESP32-Paxcounter: Wifi & BLE driven passenger flow metering with cheap ESP32 boards) As far as I understand, I don’t need to bridge any physical pins with eachother to make it work. I have checked my keys a dozen times (LSB/MSB).

The code seems to be running fine on the device but it has never recieved a join response using OTAA. ABP doesn’t seem to work either.

I have never used LoRa nor LoRaWAN before so I could be overlooking some basic stuff. Does anyone have experience connecting this transceiver to TTN or know how to help me out?

I hope this is the right category. Thanks in advance!

That’s the ultimately idea, in practice today you probably do need your own.

On TTN mapper if my location is not in a purple zone, does that mean I don’t have coverage?

Most likely.

Also, even if you do have coverage, getting things working with a build-firmware type of setup is much easier if you have access to the raw feed from a gateway that’s either yours, or controlled by someone nearby who is willing to help you debug.

In gateway shopping, be careful to only get a “true” LoRaWan gateway, eg, based on an SX1301, SX1302 or SX1308 chip. There are some products on the market that are not LoRaWan gateways but mislead unwary buyers - something made from node radios with only one or two channels cannot do the job, and is not allowed to be connected to TTN as a gateway, even if it was (or worse still is) falsely marketed for such use.

The thing about TTN is that gateways are shared, so your data might go through someone else’s gateway, and someone else’s data might go through yours.

As such, it’s not a question of what is good enough for you, but rather what is good enough to be represented to TTN as a gateway.

Things that mislead the network and other people’s nodes into believing there’s a gateway in a particular location can cause nodes to go into a short range mode for efficiency, preventing them from using more distant proper gateways.

For that matter, turning a gateway on and off frequently is problematic, too, as it can take days for things to fall back to accommodate its loss.

This is where things get… unpleasant.

In theory an SPI interfaced “concentrator card” hanging off something like a raspberry pi isn’t a bad starting point. The modern ones however use SPI via a non-standard pinout on an mPCIe connector, so you need not only the card, but something to put it in that either directly fits on your pi, or allows you to make the needed connection with short jumper wires.

There’s an attempt at a simple gateway appliance called the TTIG that has a nice price point, but it’s had some real reliability problems and unlike almost everything else and despite being promoted for the open TTN network, its operating software is super secret (and has no open source alternative), so nobody can fix what’s wrong with it.

Pycom has a really cheap concentrator on the market, but there aren’t a lot of people with experience using those yet, and you’re likely to spend more in frustration than the difference between that and a more conventional solution.

ST micro has a development kit, but its gateway has a different serious flaw - it has the proper concentrator chip to receive, but it can only transmit quite weakly (orders of magnitude more weakly than even a node!), which similarly misleads the network into disfunction, so that shouldn’t really be used on TTN either.

Of course, I didn’t think about that.
Anyways, Thank you for your extensive response, I’ll take those things into consideration