I would like to use FiPy Lorawan-Nano-Gateway with LiPo battery and solar panel. Presumably LTE connection takes more power than solar can charge during a day time (especially in the winter), so the gateway should be put to deep sleep for most of the time. In order to know how much time the gateway can be awake I need to know the battery voltage.
I set up lorawan-nano-gateway (currently using wify) that forwards data from node. In main.py I start a new thread using _thread.start_new_thread(th_func()) and elsewhere define th_func() which makes battery voltage measurement and supposedly should send packets to TTN using socket with already opened connection. How should I authenticate using app_eui and app_key? Thanks
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.
2 Likes
The project is about monitoring environmental parameters in a wetland that is 15-25 km away from potential users. The area is at the edge and beyond of cellular network (cause there are no people) and the aim is to use long range radio to bring the signal closer. And batteries are needed because there are only transit high power lines, no chance to connect to mains. I’m afraid bears and birds don’t care if the gateway is not always on.
You are right, likely it is in conflict with LoRaWan idea and using just LoRa radios could work, too. In conditions where clocks on nodes are not very accurate sequential communication might mean longer up time of nodes and gateway. But on the other hand, knowing the battery voltage of gateway (the original question) would allow perhaps longer up time and who knows may be indeed someone would like to benefit from this.
It’s not likely, it’s a fact.
It would still be non-LoRaWAN compliant. You’re not getting an answer here: Single Channel Packet Forwarders (SCPF) are obsolete and not supported. And please don’t connect this to TTN: you simply do not know what other true LoRaWAN devices are around, now or in the future.