Node with ESP8266 and RFM95W

Looks interesting, you expect this to give the lowest power consumption? Indeed with ESP8266 it will probably be hard to reach very low power levels and run for months on 1 battery?. It seems the ESP32 will have some better low power features?

Besides low power consumption a low price is also interesting of course :blush:, in that regard an ESP8266 together with a SX127X board would probably beat most other combinations? (as you need a more powerful uP to implement the LoraWAN stack and need some GPIO ports for attaching sensors.

I’m still wondering how to use all these GPIO’s on the RN2483 in a usefull way. AFAIK you won’t be able to do anything like SPI, I2C, 1-Wire etc. So I guess it is mostly limited to reading on/off values and flashing LED’s or driving a single on/off output and you will need to have the more powerfull “protocol” ports of your uP to do things like that?

I am guessing microchip are thinking something like lets not try to be the cheapest solution but lets be the easiest whole cost solution. As a pre-verified module the RN2843 is probably going to save you a lot of money on the product RF verification stage, maybe it’s 5-10K savings. So they probably figure that’s a lot of sensors you need to catch up if you use a cheaper non-verified module where you have to implement and verify the stack. So that’s something like a 1000 sensors your going to need before you compete with their more expensive but ‘gold standard’ sensor.

By making the serial GPIO on the device you can just bind a very low cost microcontroller to add some application logic ( even a 10F family ) for just a few cents and use the GPIO on the RN2843 to read and write IO for “Sleepy” sensors. ie the low bandwidth sensors they consider to be their sweet spot.

In the future I wouldn’t be surprised to see them also allow programming of the onboard PIC18F46K22 - or even a flash upgraded version. I for one would very much like to see that.

1 Like

I agree with JamesC

The RN2483 offers a sleep mode in which it consumes the lowest power.
The max sleeptime is 4294967 mS = app. 49.7 days, after that it wakes up by itself.
So you can set an internal clock to wake up the module, let’s say every 24 hours, send some data and then go back to sleep.

However (I am in the middle of testing) you can force the module to wake up when some external condition is met.

Now compared to the ESP8266 … how do you achieve this ? you’ll need probably an external signal (clock) + MCU to wake up the ESP.

@JamesC, @Borroz I agree with both of you :wink: I was not saying that the Microchip RN2483 is too expensive, I think it is the best (only) bargain that gives you a complete LoraWAN stack and RF certification. I think it is just a challenge on its own to build the lowest cost node possible. And indeed that will only be useful for 2 groups: the tinkerers and the corporate people who expect to build 1000’s of nodes.

I guess that also with a RN2483 you still need some RF certification for your product? AFAIK you can still set the duty cycle of the RN2483 to a value that would be “illegal”?

@BoRRoZ About low power consumption: like I mentioned I think your approach is interesting and we won’t be able to achieve that with an ESP8266, I hope ESP32 will have the right low-power features to achieve real low power sleeep (It does have more low-power features but didn’t investigate this in detail yet). For certain nodes where very low power consumption isn’t the biggest issue a relative powerful but cheap uP like the ESP8266 might still be usefull?

Would indeed be great if the full power of the RN2483 embedded PIC18F46K22 would be usable (e.g. for serial protocols) the same way Espressif has done for their ESP8266. Then you could build a complete solution with the RN2483 only and no external uP would be required. As Microchip did provide a complete set of GPIO’s on the RN2483 it would indeed be a logical next step :smiley:

And nice links from @IOT_Marco, looks very interesting!

1 Like

The Arduino port of the IBM LMiC works on the ESP8266 with only minor modifications. Using the RN2483 might be simpler though.

I have ESP node running since yesterday based on Wemos D1-mini board and RFM95 (and the LoRa shield of Ideetron). It is based on a port of the LMIC-v1.5 source base with changes to hal.cpp and others for this architecture.

git: https://github.com/things4u/LoRa-Thing

The code is a copy of my sourcetree so do not forget to include the LMIC-v1.5 library from the libraries directory.

And please remember this is work in progress. So although the sensor transmits its hello world message, the ESP is known to be difficult so use at your own risk.
Mine will stay on the bench/breadboard for a few days until it has proven to be stable. Will than probably work on energy efficiency (like to run it on a battery).

Cost for this one:

  • Wemos D1-mini $ 4.00 Aliexpress
  • RFM95 $8.00
  • Shield Euro 7.45 (ex VAT0
  • Antenna Euro 5.39 (ex VAT)

But when shield and antenna are not used (make your own) it is possible to make a really cheap powerful node so it seems.

Maarten

5 Likes

I added a DS18B20 (Dallas/OneWire) temperature sensor (Sketch on github). With MQTT I route the value of the sensor (and my other sensor which does temperature/humidity) to my home automation system (see 2 dials on the right)

And in trend graph

1 Like

Hey platenspeler, Nice work!

Could you tell me how to connect the RFM95 to the ESP. Which pins did you use and where are they defined?

Thanks!

René

1 Like

René,

Please have a look at the documentation page: things4u.github.io
Look at the two pages documentiing the hardware setup.
Please let me know whether this is what you are looking for or information is still missing

Maarten

2 Likes

Thanks, will do!

Rene

Hi Maarten,

Trying to create a nice esp8266 node but keep getting “library lmic-v1.5 claims to run on [avr] architecture(s) and may be incompatible with your current board which runs on [esp8266] architecture(s)”. Did put your lmic library in arduino folder but still. Must be something stupid i do;)

error on esp:
wdt reset
load 0x4010f000, len 1264, room 16
tail 0
chksum 0x42
csum 0x42
~ld
Starting
hal_init: ESP architecture
FAILURE
C:\Program Files\Arduino\libraries\lmic-v1.5\src\lmic\radio.cpp:657

Ewoud

Hi Ewout, I get the first warning as well, but ignore this as I know that ESP8266 should be able to run this software. You see in the output that the ESP architecture is recognized (I put that Serial in a a debug).

The second watchdog reset message is something I do not get. From doing other things with the ESP8266 I know that I get that if the ESP8266 needs time to process its WiFi stack procesing and it does not get enough time to do it as it is working on user programs.

  • I do run the library not in that location but in my sketch directory together with my other libraries.

Are you only running the lmic stack, or also doing WiFi or other work?

I see that after the wdt that the stack resets again, and see that it tries to read somehing from the rfm95 chip. Maybe re-check connections to the RFM95.

Hi @Ewoud - just to let you know you’re not alone :smile: I have a NodeMCU ESP8266 wired up to a bare SX1276 and get a very similar error. Have to triple-check my wiring and try another module just to make sure it’s no hardware snafu.

wdt reset
load 0x4010f000, len 1264, room 16
tail 0
chksum 0x42
csum 0x42
~ld
Starting
DALLAS #:1
FAILURE
C:\Users\MyUser\Documents\Arduino\libraries\arduino-lmic-v1.5-master\src\lmic\radio.cpp:659

Cheers, JW

Oh oh …

I did check the connections again and they are the same as in things4u.github.io is mentioned …

What ESP8266 mcu are you using?

Seems like the code is expecting a sx1272 radio and not the sx1276/RFM95.
Can you please check you used the correct radio type in config.h?

I started with a generic Ali* NodeMCU ESP8266 but also tried a Wemos D1 mini with the same results.

My config.h looks sensible:

#define CFG_eu868 1
//#define CFG_us915 1
//#define CFG_sx1272_radio 1
#define CFG_sx1276_radio 1

Comparing the RFM95 and SX1276 I do notice there are RXEN/TXEN pins I haven’t wired in. I hard wired them to switch to RX mode to wake the chip up, but to no avail.

All my wiring checks out OK, so may need to wire up the other bare SX1276 I have lying around.

/JW

In radio.cpp line 659 is executed only when CFG_sx1272 is defined. And as you defined CFG_sx1276 in config.cpp this is strange.

Hi Maarten,

Could check only now. I am using a sx1276 (nicerf) but not the rfm95 (will check setup with the rfm later to see if this fixes it). In config.h checked if it is setup ok;
#define CFG_eu868 1
//#define CFG_us915 1
//#define CFG_sx1272_radio 1
#define CFG_sx1276_radio 1

Will make a library setup within sketch dir and test also with the rfm95 later on. maybe its wiring with the nicerf module (or the module itself) thats not working.

Ewoud

Hi Maarten,

Used a RFM95 instead of the nicerf (not so nice after all;) and boots up now;
hal_init: ESP architecture
os_init() finished
LMIC_reet() finished
LMIC_setSession() finished
LMICsetAddrMode() finished
Init done
Time: 0
Send, txCnhl: 0
Opmode check: ok

looks ok.

cheers

Hi Maarten,

So if I read your diagram correctly should it be connected like this?
(DIO3 and GPIO3 should not be connected right?)

Connect:
DIO1 <–> GPIO4
DIO0 <–> GPIO5
MISO <–> GPIO12
MOSI <–> GPIO13
SCK <–> GPIO14
NSS <–> GPIO15
RESET<–> GPIO16

And leave open:
DIO3 <–> GPIO3

Thanks!

Rene