Hello,
We want to develop SX1301 LoraWAN Gateway with ESP32, as our goal is to make self powered (using solar) gateway, and
ESP32 is seems to be a good candidate for this in terms of power consumption, cost and other factors.
We want to know your views regarding developing self powered SX1301 gateway with ESP32 instead of Raspberry Pi,
and have some query about it.
Why Raspberry Pi is perferred in SX1301 LoraWAN Gateway?
Is it reliable to use ESP32 instead of Raspberry Pi?
Is there be any performance issue or disadvantage of using ESP32 as compared to Raspberry pi for SX1301 Lorawan Gateway?
The TTIG indoor gateway runs on an ESP8266. The ESP32 can basically do everything an ESP8266 can, but with dual core, more RAM, better low power support, so theoretically it should be possible. I’m not sure if the TTIG also uses the sx1301 chip.
The main source of power consumption in a gateway is the multichannel LoRa receiver.
While a raspberry pi is a bad choice for field deployed or low power needs, and ESP32 is also a very constraining choice. Currently there is no open source software available to build a gateway around an ESP32 - pycom may release theirs at some point but no one has been able to find the code yet.
Currently the more basic and robust-due-to-simplicity gateways tend to use Linux router SOC’s booting from NOR flash. These are a little less flexible in the moment than a pi, but in concept are a similar software environment. In contrast and ESP32 is very distinctly fixed-function embedded development, more like a very large MCU with an RTOS than something with a conventional OS with concepts like processes, daemons, logs, etc.
Technically an ESP32 based gateway should be possible.
Whether it is practically feasible (and preferable) I can’t answer.
TTIG is based on ESP8266 which is much less powerful than ESP32.
TTIG is based on the open source BasicStation software. Unfortunately the implementation for ESP8266 / TTIG is not open. There is some hardware abstraction layer in BasicStation. The ESP8266 specific implementation is not open.
IIRC a major reason for keeping the ESP8266 implementation closed is that due to resource constraints some shortcuts / simplifications were implemented of which they don’t want to publish implementation details.
You may contact Semtech and check if they are willing to share some more details that can assist in building an ESP32 implementation.
(See BasicStation repo on GitHub).
Most likely, yes. A gateway actually needs to do very little, it is really just a channel between the radio card and the network server software, which here on the TTN forum would be either TTN’s servers, or an experimental independent install of the same software.
We have to develop Outdoor gateway with thousands of users.
Its possible your project is of large enough scope to make the effort of getting things working on the ESP32 worthwhile. But beware it is not a small project; you’re going to need someone experienced in real embedded software development, and they’re going to need to have a solid understanding of what a LoRaWAN gateway does.
Even doing a version based on a Linux SoC would involve substantial system engineering and productizing challenges.
Most likely you should get a gateway (product or kit) or two and start gaining some experience working with them before you pick a direction. It’s not even yet necessarily clear that LoRaWAN in general or this forum’s actual topic of TTN in specific, are suitable for your needs.
So, you need one (preferably three) gateways which need to handle thousands of nodes.
This isn’t DIY territory - if I had a geographical area I was thinking of deploying 1000’s of nodes in and was thinking of building my own gateway, I’d take myself out and have myself shot.
I would have two gateways from one vendor, another of a different fundamental platform, preferably from a different vendor, and a test gateway that can be deployed in a hurry if the three live ones goes down.
Then, once I’m coining it with all the 1000’s of nodes subscriptions, I may consider making my own gateway.
At least as long as you’re using TTN in an officially supported way, there really isn’t much difference in the number of nodes a gateway can handle.
The limitation is the radio card, and all gateways have essentially the same one, regardless of how sophisticated or minimal their computer is. A bad implementation of the software running on the computer could be limiting, but a good one isn’t going to be any better.
In theory the newer SX1302’s might do slightly better in busy circumstances, though it’s unclear if you’d notice.
Older designs where an FT2232 USB/SPI bridge is used rather than a direct SPI connection are known to do worse in busy circumstances.
In areas where more frequency sub bands are legally allocated, gateways with more than one concentrator card to cover more than 8 frequencies would work better on some other network but not with TTN where nodes would be re-instructed to use only the officially configured 8 channels. (The uplink to downlink mapping for other sub-bands is not officially supported either, though someone did claim it happens to work)
But really, what you have is not a gateway challenge, but on on-air contention one. A thousand nodes can work if they each transmit sufficiently rarely, making good randomized use of the available channels, hardly ever needing downlinks, and doing a good job of being on-time to receive those they do rarely need.
But makes the nodes transmit too often or with too much time alignment, or have a random channel selector which is unfair, or use downlinks in any sort of routine manner, or mis-implement LoRaWAN such that those required for network housekeeping keep having to be re-sent… get any of those things wrong, and no its not going to work well, as the nodes will keep interfering with each other…
I know the best way is to create using the native ESP-IDK, but I like the idea to have an Arduino library to communicate with the 8 channel gateway and create a super-duper node.
It’s not clear what you mean here.
The topic subject is about creating a LoRaWAN gateway with ESP32
and ‘node’ is an alias for ‘end device’ which is not a gateway.
Are you aware of ESP32 + Arduino framework + LoRaWAN/LMIC timing issues (see the ESP32 threads for more information)? These may probably play a role communicating with a concentrator board as well.
I’d suggest you spend some time working with the usual gear:
nodes based on single channel radios run by various embedded MCU’s (possibly albeit with some extra challenges an ESP32 under Arduino)
gateways based on an sx130x concentrator card and a conventional embedded Linux
When you have a bit more of an understanding of how these components work themselves and interact via LoRaWAN, you’ll start to realize how your earlier idea is just not meaningful.