Single channel radios such as this are not able to correctly implement the role of a LoRaWAN gateway, with the result that they cause disruption to the operation of other people’s nodes in the shared network. Their use is strongly discouraged, and they are not supported on this forum.
That is not compatible with the design of LoRaWAN either. LoRaWAN gateways must receive continuously so that a battery-powered node can wakeup at a random unpredictable time and transmit. A gateway which frequently went in and out of operation would also be quite detrimental to other people’s nodes in the shared network, as it would confuse the adaptive data rate algorithms when they took the gateway’s presence into account, only to have it then disappear again.
Since what you are trying to do is in pretty much all ways in conflict with the design of LoRaWAN and TTN, you should probably look to other network schemes. You might for example take a look at the strategies BLE uses in trying to support having battery power and a single channel radio at both ends of the connection. Note that you can still use LoRa radios to implement network schemes other than LoRaWAN - the conflict you face is with how LoRaWAN as a network layer is optimized for battery powered nodes at the cost of effectively requiring mains-powered gateways with always-on power-hungry, more expensive multi-channel/multi-SF gateway class radios.
There may well be quite a lot of merit in a different non-LoRaWAN scheme operating LoRa radios in a different way for your project (it’s an idea I contemplate from time to time, too) but it’s well outside the scope of this forum which is specific to the LoRaWAN network called TTN.