I have 2 The Things Indoor Gateways
I don’t have anything to test them with so how can I test them by making them talk to each other?
You cant, gateways with TTN are configured to listen for device transmissions and can reply to them, gateways don’t talk to each other.
With a normal gateway, you are usually able to do this, by pointing it at your own system which implements the applicable protocol rather than at TTN’s servers. The legacy Semtech UDP protocol is not very hard to implement in python, and offers a handy “immediate” timing mode if you just want to send a packet soonish rather than at a particular timestamp of the gateways clock counter. Typically in LoRaWAN uplink and downlink settings differ, so you’ll have to take that into account too in crafting your transmit command.
It then becomes a question if the gateway’s configuration file permits it to transmit on the frequencies on which it (or its neighbour) receives - in some regions these are the same, in others such as US915 they are different parts of the band, and the gateway configuration may restrict transmission to the usual part of the band for downlinks. But on a normal gateway you can change the global_conf.json…
The Semtech LoRa Gateway HAL repository also includes some test programs which will transmit raw packets, aside the usual purpose to build an interface library for use by the packet forwarder repository. These take all their settings on the command line without using a configuration file, so transmission frequency range would be that of the hardware.
Unfrotunately, this question is not about a “normal” gateway but rather about the TTIG. And the TTIG is sadly unique in three quite unfortunate ways:
- you cannot fix implementation bugs in its software
- you cannot really change it to point to anything other than the TTN servers without doing odd network hacks
- you cannot change its configuration
So the answer is practically “no” for the TTIG, but practically “yes” for just about every other sort of gateway.
And in fact gateway-to-gateway pings are a useful tool for understanding the infrastructure you’ve deployed in the field. I don’t believe TTN employs them, but several other LoRaWAN implementations do.
But with a TTIG… you’re better off just getting a node, unless you feel like taking your TTIG apart and starting the overdue task of creating an open source firmware for it, or throw away its ESP and wire the concentrator SPI and reset lines into some other embedded computer able to run the usual open source Semtech stack.