Node with ESP8266 and RFM95W

Made a shield for the ESP dev Board with the RFM module. Have some testing and soldering to do but should come in handy for small nodes.

1 Like

(it is this one: )

Yep is the same.

Hi all,

Tested the shield and works ok. Made it available on Oshpark. Shield can be used with ESP dev board. Needs two 8pin single row headers (not the ones on the picture;) 8pin headers and a 10K resistor.




Hi guys,
I see some reference to my github here, I’m glad of your intereset
For those interested I also done a WeMos ESP8266 shield for Microchip LoraWan RN2483 and WiFi terminal to talk to RN2483
You’ll find information here;
github board shield :
github firmware Serial/Proxy with websocket en HTML Terminal

And screenshot of whole working from browser


cswiger: Interested in your use of the inAir9b and WeMos D1. I have almost the same hardware but I can’t get it to work properly. The setup won’t boot up with CS connected to SS (GPIO15) on WeMos D1 R2 board. I can get it to boot up with inAir9b unplugged, When it is booted up the plug the inAri9b in and with works.
If I have CS connected to inAir9b then is doesn’t start at all, doesn’t matter what GPIO0&2 are doing.
Did you get this working with your WeMos D1 mini?
Can’t get even the simple Blinky program to work with the inAir9b plugged in with GPIO15 connected.
Anyone got an idea what the problem might be?

I think GPIO15 must be pulled low at startup…
(use pulldown resistor?)

Sure - I mainly followed this guide for the wemos d1 mini RFM95:

Just happened to be using a wemos/inAir9b setup last night to transmit dht22 temp/humidity from inside a thermoelectric cooler via TTN :smile:

Will post more details shortly after the warmup part of the chart has finished.

Indeed, on a bare ESP8266 a pulldown resistor on GPIO15 should help; see JP Meijers’ drawing. However, note that some boards already provide a pulldown, such as the Adafruit HUZZAH ESP8266 breakout (which also explains why). And it seems the WeMos D1 R2 and the D1 mini provide one too?

15 must be low and chpd 0 and 2 must be high for normal boot.

No pullup resistors in my rig - just a 4k7 for the DHT22 data pin, to D4 on the WeMos D1 mini.

WeMos                  InAir9B
D3   n/c
D2   -------------------   D1
D1   -------------------   D0
tx   n/c
rx   n/c
rst  n/c
A0   n/c
D0   n/c
D5   --------------------  CK
D6   --------------------  SO
D7   --------------------  SI
D8   --------------------  CS

There’s an unlabeled pin on the InAir9B between VS and SI that I have connected to 3v3, although it’s labeled ‘5v’ on their schematic, Modtronix says use only 3v3 :confused:

I have the 5v pin on the WeMos through an LM3671 to provide 3v3 for the InAir9B.

Pin mapping from the sketch - pins.dio can be confusing:

// Pin mapping
// XXX We have to see whether all these pins are really used
// if not, we can use them for real sensor work.
lmic_pinmap pins = {
  .nss = 15,        // Make D8/GPIO15, is nSS on ESP8266
  .rxtx = 2,        // D4/GPIO2. For placeholder only,
                    // Do not connected on RFM92/RFM95
  .rst = 0,         // Make D0/GPIO16, Needed on RFM92/RFM95? (probably not)
  .dio = {5, 4, 3}, // Specify pin numbers for DIO0, 1, 2
                    // D1/GPIO5,D2/GPIO4,D3/GPIO3 are usable pins on ESP8266
                    // NOTE: D3 not really usable when UART not connected
                    // As it is used during bootup and will probably not boot.
                    // Leave D3 Pin unconnected for sensor to work

Thanks for the contributions from you all. Arjan was correct the WeMos D1 R2 does have a pulldown on GPIO15. The extra clue from cswiger made the difference. I connected the pin between VS and SI to 3.3V and it booted after a delay of 10 seconds every time. I added another 10k pulldown in parallel and it the booted properly every time.

The Modtronix documentation around VS is confusing. Their circuit diagram is helpful to work out what the un-named pin is doing.

Thanks for the assistance. I’m still not able to send any messages to (my local Lorawan gateway). The same inAir9b works fine on my Arduino Mega, so there is something else strange about the setup. Maybe I’ll provide separate 3.3V like cswiger.

new ESP8285 spotted ?


Hi, I’ve managed to make a gateway using the LinkLab LoRa gateway. I have the ESP8266 running LMIC and sending packets to the gateway. I can see them at the gateway level or with netcat on the 1680 port.

My question is how about the down link to ESP8266. Did you managed to make it work ? I’ve tried the sudo ./util_tx_test -n 1680 -m LORA -s 7 -t 1000 -z 55 -x 10 to send 10 packets, but I don’t receive them at the ESP level. Having only one way is not LoRa compatible. I know that LMIC suppose to work in the RX2 window. On my gateway I am running (evaluating ) the sw. The TTN’s version will be for desert :slight_smile:

So the question is how to send downlink packets to the nodes ?

I know that LMIC suppose to work in the RX2 window.

As far as I know it should also work in RX1, but indeed TTN prefers RX2. Still then:

So setting the end node on SF9 will receive the downstream packets?

You don’t need to force your node to send using SF9, but indeed you will need to set it to use SF9 for RX2.

Apparently for LMiC this is needed for both ABP:

… and (currently) also for OTAA:

(And of course, the gateway must support downlinks too; most Single Channel test gateways don’t. As an aside, beware that downlinks will be very limited, one day.)

Yes, I have a true gateway ( a LinkLab Pi hat ) I moved from single channel gateway ( PI + ESP8266) to a truly gateway and I am aware of the air time ( 10 msg per day downlink is more then enough for me).

I’ve checked the lorabase.h so DR_DNW2 is set to DR_SF9

enum { DR_DNW2 = DR_SF9 };

and the LMIC.dn2Dr = DR_DNW2; in lmic.cpp in function lmicJustJoined. So, I guess I good with that.


./util_tx_test -n 1680 -m LORA -s 7 -t 1000 -z 55

is just enough to have a packet received in ESP ? I’ve seen the packets in gateway but not on ESP, no event EV_RXCOMPLETE is triggered.

You know that a node can only receive right after it has sent something? You can queue a downlink in the TTN dashboard or using ttnctl.

Off cource in one of the immediate windows RX1 or RX2.