How should I wire an RFM95 to an ESP8266/WeMos D1 mini?

Hi Folks,

I just received several RFM95 boards in the post today and I would like to use some of my WeMos D1 mini board (without wifi) as an arduino to control the device as a node. I have been studying the code at https://github.com/matthijskooijman/arduino-lmic.

How should I be handling the wiring? Below is an image of both modules in addition to the mappings that might make sense.

D1Mini - RFM95
3V3 -> 3.3V
G -> GND
D6 (GPIO12)->MISO
D7 (GPIO13)->MOSI
D5 (GPIO14)->SCK
D0(GPIO16)->NSS

There is also some code that looks like it handles GPIO mappings for SPI.

// Pin mapping
const lmic_pinmap lmic_pins = {
.nss = 6,
.rxtx = LMIC_UNUSED_PIN,
.rst = 5,
.dio = {2, 3, 4},
};

Has any body ever tried this configuration?

Thanks,

Mark

Thanks Arjan. I started reading this rather long thread before posting but found it was meandering a bit. Will take the time to review the thread in detail and see if I can pull out the bits of information I need.

Thanks,

Mark

I linked to a specific post in that thread. That post links to other information which eventually gets you to, for example:

http://things4u.github.io/HardwareGuide/ESP8266/ESP-Sensor/esp-lora-sensor.html

You can see Wiring also here, with a dedicated shield for RFM95

Also a version of LMIC without DIO needed to be connected

1 Like

I got it working in the end. Two bits of key information:

PIN Connections

WeMos D1Mini -> RFP95

D8 (GPIO15) -> NSS
D5 (GPIO14)->SCK
D7 (GPIO13)->MOSI
D6 (GPIO12)->MISO
D1(GPIO5)->DIO 0
D2(GPIO4)->DIO 1

In the Arduino sketch, the lmic must be as follows. Note that the GPIO port number should be used and not the WeMos port numbers.

const lmic_pinmap lmic_pins = {
.nss = 15,
.rxtx = LMIC_UNUSED_PIN,
.rst = LMIC_UNUSED_PIN,
.dio = {4, 5, LMIC_UNUSED_PIN},
};

I hope this helps anyone else trying to get the same configuration running.

Mark

1 Like

A couple of TTNers have asked me more about this build offline. Here is more detail on the BOM and configuration:

The BOM for this configured as a node or a 1 channel gateway includes the following:

Here are the pinouts in markCAD:

If you want to keep thing simple and you can also use order this shield on PCBs.io (4 for $5.30)

Schematics and description here, depending on what you want to do, minimal wiring could be just RFM95 and 2 diodes.

1 Like

Can it be bought with components already soldered? I mean resistances and capacitors, not the RFM92

In its most basic form you do not need all those components to make it work, just the RFM chip

Good to know it. Thanks.
However, I’m wondering if someone would mass produce it. It would be a supercool shield to use out of the box with full functionality

1 Like

I’m on to it. Trying to get ESP8266 and LoRa on a single board.

me too :wink:

Why would you nowadays want to combine ESP8266 and SPI LoRa module on a single PCB and not use an ESP32 (or different 32-bit MCU) instead?

ESP8266 is very limited in terms of available IO ports when using it with an SPI LoRa module. Several of the non-SPI ports have limitations related to pull-up or pull-down requirements which limits their usability. Automatically waking up from deep-sleep by RTC timer will take another one of the available IO ports.

True. I felt the same. Let me do it with ESP32

done… RFM95 LoRa (866MHz) and ESP32 on same board…
Have a look… I have done it on wishTree board that I have developed.
Here is the youtube link. LoRa_circuit.pdf (144.6 KB)

The circuit and code works on any ESP32 module. I tested with WROOM32… cheers…

D8 (GPIO15) -> NSS
D5 (GPIO14)->SCK. (!!! GPIO14, NOT 4)
D7 (GPIO13)->MOSI
D6 (GPIO12)->MISO
D1(GPIO5)->DIO 0
D2(GPIO4)->DIO 1

Good find. At least the D5 was already correct.
I have fixed the typo in the original post.

doing my best to contribute something useful to this forum as well :))

plus: if you use the wemos lora shield suggested above:

NSS is connected to GPIO16

1 Like

Thanks for this addition.

When GPIO16 is used for NSS it will be impossible to automatically wake-up from deep-sleep because that requires GPIO16 to be connected to ESP8266 Reset.
(Manufacturers sometimes make strange choices.)