Node with ESP8266 and RFM95W

I just found these 2 items. They look like a match made in heaven (for this particular topic).
Does anyone have experience with this combination?

It is a ESP8266 in an Arduino formfactor with an Arduino-Lora-module.

A combination of:

(the version on Ali is already a newer version mine is 1.1)


1 Like

I was lucky enough to receive the first revision of the Dragino LoRa board: it simply works.

As it is basically an RFM95 breakout it should work together with the ESP, you might want to consider the V1.2 board as that is more flexible w.r.t. the breakouts. It was revised based on inputs from people on this forum to make it more flexible see the dragino wiki for the difference in appearance.

For ESP8266 LMIC stack see messages above.

That actually didn’t work for me.

Huh, turns out the lmic.cpp LMIC_disableChannel(u1_t channel) for CFG_us915 I got from is broken - for

struct lmic_t {
#elif defined(CFG_us915)
u2_t channelMap[(72+MAX_XCHANNELS+15)/16]; // enabled bits

that should be an array of 5 16 bit values (80 bits, to cover 74 total channels), which when initialized is:
LMIC.channelMap[0] = 0xFFFF 16
LMIC.channelMap[1] = 0xFFFF 32
LMIC.channelMap[2] = 0xFFFF 48
LMIC.channelMap[3] = 0xFFFF 64
LMIC.channelMap[4] = 0x00FF 72 bits

However, LMIC_disableChannel() for CFG_us915 is modulo 4???
LMIC.channelMap[channel/4] &= ~(1<<(channel&0xF));

should be 16. As it is, when you disable channel 4, you actually get 20!
4: channelMap[0]: ffff
channelMap[1]: ffef 1110 1111 wtf??

LMIC_disableChannel(8) turns off the bit for 40, etc. Changed it to:

LMIC.channelMap[channel/16] &= ~(1<<(channel&0xF));

in my little test file and got expected results - will try it out in the actual code later tonight.

See also Matthijs’ version, which also has some more documentation.

Verified it came from IBM like that!

Pretty sure that’s a bug from the source.

has the same bug:

void LMIC_disableChannel (u1_t channel) {
if( channel < 72+MAX_XCHANNELS )
LMIC.channelMap[channel/4] &= ~(1<<(channel&0xF));

That 4 should be a 16 to get the right byte of the array - only affects CFG_us915.


It looks like the 6 pin connector of the Lora shield might be right on top of the ESP module. Is that an issue or do the boards fit nicely?

Hi Jac,

You are right the connector for SPI is directly above (2mm) the ESP-antenna but they fit nicely.
It seems that I have to do a little bit resoldering of a few “jumpers” ( I have version 1.1 of the Dragino Board so no nice jumpers -bought it 6 weeks ago-)… but then it should fit the Wemos D1 like a glove.

I am taking small steps and at this moment I am trying to test the Dragino with an Arduino Uno first (afterwards I will resolder the jumpers on the Dragino)…

1 Like

Verified - fixed /4 changed to /16 in LMIC_disableChannel() for CFG_us915 and now it works, only sends on my single channel gateway frequency of 913.7:

Disabling channel: 53
Disabling channel: 54
Disabling channel: 55
Disabling channel: 56
Disabling channel: 58
Disabling channel: 59
Disabling channel: 60
Disabling channel: 61
Disabling channel: 62
Disabling channel: 63
Disabling channel: 64
Disabling channel: 65
Disabling channel: 66
Disabling channel: 67
Disabling channel: 68
Disabling channel: 69
Disabling channel: 70
Disabling channel: 71
Disabling channel: 72
Init done
Time: 0
Send, txCnhl: 0
Opmode check: ok
Event EV_TXCOMPLETE, time: 10
Time: 30
Send, txCnhl: 57
Opmode check: ok
Event EV_TXCOMPLETE, time: 40
Time: 60
Send, txCnhl: 57
Opmode check: ok
Event EV_TXCOMPLETE, time: 70
Time: 90
Send, txCnhl: 57
Opmode check: ok
Event EV_TXCOMPLETE, time: 101
Time: 120
Send, txCnhl: 57
Opmode check: ok


1 Like

This seems promissing:

(very small form-factor ESP-Wemos)

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.