SX1301 Lorawan Gateway with ESP32 instead of Raspberry Pi

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?

Thank You


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.

Take a look at PyGate, just add a WiPy and you have your ESP32 driven gateway without the need to develop your own hardware.

1 Like

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).

1 Like


Is there be any performance issue or disadvantage of using ESP32 as compared to Raspberry pi for SX1301 Lorawan Gateway?

We have to develop Outdoor gateway with thousands of users.
Is ESP32 capable of handling them compared to Raspberry Pi.

Thank You

Is that one gateway with thousands of devices?

Or you need thousands of gateways.

Either way, this is a serious project!

Why not look at using one of the OpenWRT based boards with a concentrator?

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.

1 Like

Sorry, Correction here
Lorawan gateway must be capable of handling thousands of Lorawan nodes.

Thank You.

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.

1 Like

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…


Last year before receiving the TTIG, I was thinking it is gonna be cool if has some ESP8266 with an 8 channel gateway and boom!

At the TTN conference, I gained one, and when I discovered it has an Esp8266! Where is the code I want to make my own!

But the esp8266 is not open =(

I tried some code to make the esp to communicate with a RAK831 with SPI and kinda works, but the
SX1301 uses a 32 bits SPI communication or something…

I used the base code.

I was not able to import the communication SPI to Arduino base, kind works but need some re factory.

Programming router firmware for ESP8266 or ESP32 should be done with native ESP-IDK but not with Arduino framework.

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.

1 Like

This truly makes no sense.

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.

1 Like

For anyone still dealing with this topic, look here:

I have found it miraculously using github search.