Author Topic: [Update] RFM69 Library for ESP8266 - Moteino Compatible!  (Read 32395 times)

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: [Update] RFM69 Library for ESP8266 - Moteino Compatible!
« Reply #60 on: June 02, 2016, 11:54:26 PM »
@fgomes
Strange.  Is your setup any different than the photo Joe posted in reply #3?

fgomes

  • Jr. Member
  • **
  • Posts: 65
Re: [Update] RFM69 Library for ESP8266 - Moteino Compatible!
« Reply #61 on: June 03, 2016, 02:21:02 AM »
@WhiteHare

As far as I can see in the photo Joe posted, the setup is similar, but in my case the module is the RFM69HW, so the pinout is not the same. Nevertheless,  if I change the MCU to an atmega, it works, and the signals look OK on the oscilloscope.  I will try a few more variants powering both modules with separate power supplies.

Best regards

Fernando

joelucid

  • Hero Member
  • *****
  • Posts: 867
Re: [Update] RFM69 Library for ESP8266 - Moteino Compatible!
« Reply #62 on: June 03, 2016, 02:58:48 AM »
Quote
Can you share the exact RFM69.cpp/RFM69.h that you are using with the ESP8266 in order to be sure I'm not missing anything else?

I think the attached files worked for me. I'm using a different library now, but this should work.

fgomes

  • Jr. Member
  • **
  • Posts: 65
Re: [Update] RFM69 Library for ESP8266 - Moteino Compatible!
« Reply #63 on: June 03, 2016, 09:19:06 AM »
@Joe Lucid

Thank you very much for the sources. i have compared them with the ones I'm using and they are the same (so they are the RFM69 last version from GitHub). In your version I didn't saw the correction you said is necessary,

#define RF69_IRQ_PIN          D2
#define RF69_IRQ_NUM          D2

Can you confirm that this is the good version?

Thanks again for your help

Best regards

Fernando

joelucid

  • Hero Member
  • *****
  • Posts: 867
Re: [Update] RFM69 Library for ESP8266 - Moteino Compatible!
« Reply #64 on: June 03, 2016, 09:24:35 AM »
Quote
Can you confirm that this is the good version?

Very weird. You're right this is the wrong version. I must have made an error, let me try again.


fgomes

  • Jr. Member
  • **
  • Posts: 65
Re: [Update] RFM69 Library for ESP8266 - Moteino Compatible!
« Reply #65 on: June 03, 2016, 10:11:13 AM »
@Joe Lucid

Thanks again :-)

This version has many differences, so it should be some versions earlier. Now I understand what you said about the code that swill block if the RFM69 didn't answer :-), in the recent versions it has a timeout, and it continue even if the RFM69 is not there, so the sketch should test the initialize return code (and in the examples it doesn't). I'll test it later, but since the problem in my setup occurs in the initialization, I don't see any major difference between the one you are using and what I'm using, but I'll post here the results.

Best regards

Fernando

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: [Update] RFM69 Library for ESP8266 - Moteino Compatible!
« Reply #66 on: June 03, 2016, 10:33:17 AM »
@Fernando
If you continue to remain stuck, I suggest you post photos of your setup.  If it's just plain vanilla, it should be working, and if it isn't plain vanilla, you might want to start with that.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: [Update] RFM69 Library for ESP8266 - Moteino Compatible!
« Reply #67 on: June 03, 2016, 01:01:19 PM »
Hi WhiteHare,

Thanks for the tip,it is convenient, really!

In the meantime I tested with a lab power supply (30W) and the results are the same. I said before that the MISO didn't change, but I have now placed a pull-up resistor and now it moves almost together with the SS signal, as can bee seen in the attached picture. So now MISO goes low and stays low while the SS is low, but during that period it doesn't move, so it is replying with all zeros to the master. With the ATMEGA I don't have any pull-up and the MISO signal works, is the pull-up necessary with the ESP8266? What SPI frequency are you using, are you using the SPI clock divider as SPI_CLOCK_DIV2, SPI_CLOCK_DIV4,...? I've tested with different clock dividers but the result were similar. I'm getting out of ideas...

Best regards

Fernando

I suggest you add a 10K or greater pullup on your MISO line and re-run your test.  If it stays LOW, then you may have a short.  If it stays HIGH, it may not be connected all the way through to your ESP8266 (maybe a faulty solder joint).  If you're using the v1.0 nodemcu, you shouldn't need it though. 

Also, MISO is GPIO12, so maybe you're connected to the wrong pin.  e.g. if you're connecting to SD0, thinking that it's MISO (and I can understand why because of the pinout labelling), it won't work.  The MISO you want is HMISO.  I haven't looked into it, but I suspect SDO may be a distinctly different MISO, for its flash memory or something.   Again, this is where photos of your setup would maybe reveal a faulty assumption.

Here's a pinout for nodemcu v1.0:
https://arduining.files.wordpress.com/2015/08/nodemcudevkit_v1-0_io.jpg

I'm mostly using ESP13's.  I tell the Arduino IDE that it's a WeMo D1 Mini, however, so that the IDE uploads at 921600 baud using my CP2102 handy tool (above).  After the initial upload, though, all it requires is 3.3V power, because the ESP8266 can subsequently update wirelessly and transparently directly from the Arduino IDE.  I haven't yet gotten the wireless serial debug working  (I didn't try very hard, so I'm not sure if it isn't yet fully implemented or if I'm just not doing it right), so for now I do still connect using my handy tool for serial debugging purposes.  Eventually, though, I'd expect the wireless debug console will work, and that will be very nice indeed.  The ESP8266 doesn't seem to have as many free pins as a Photon would, but for $2 I'm not complaining.   

Of course, it goes without saying that Moteino's are still the winning choice for low power battery applications.  :)  In that context, the ESP8266 is just a gateway or a pipe to a gateway.
« Last Edit: June 03, 2016, 02:03:19 PM by WhiteHare »

fgomes

  • Jr. Member
  • **
  • Posts: 65
Re: [Update] RFM69 Library for ESP8266 - Moteino Compatible!
« Reply #68 on: June 05, 2016, 02:14:05 PM »
@WhiteHare, I'm using moteino and other similar nodes with the RFM69HW due to their power consumption and range characteristics, I just want to add the ESP8266 (that I'm using in other projects), as gateway, as you said.

@JoeLucid and @WhiteHare, let me thank you again by your support, the mystery is solved. In order to figure out what was going on I replaced again the ESP by an Atmega, and started having intermittent results also with the ATMEGA, so it was easier to figure out that the problem was a bad contact, on the MOSI connection to the RFM69 module. Solving that (almost all) the problem were solved. I started using the latest RFM69 lib, just with this small change in the .h file in order to introduce Joe change for the ESP:

// INT0 on AVRs should be connected to RFM69's DIO0 (ex on ATmega328 it's D2, on ATmega644/1284 it's D2)
#if defined(__AVR_ATmega168__) || defined(__AVR_ATmega328P__) || defined(__AVR_ATmega88) || defined(__AVR_ATmega8__) || defined(__AVR_ATmega88__)
  #define RF69_IRQ_PIN          2
  #define RF69_IRQ_NUM          0
#elif defined(__AVR_ATmega644P__) || defined(__AVR_ATmega1284P__)
  #define RF69_IRQ_PIN          2
  #define RF69_IRQ_NUM          2
#elif defined(__AVR_ATmega32U4__)
  #define RF69_IRQ_PIN          3
  #define RF69_IRQ_NUM          0
#elif defined(__arm__)//Use pin 10 or any pin you want
  #define RF69_IRQ_PIN          10
  #define RF69_IRQ_NUM          10
#elif defined(ESP8266)
  #define RF69_IRQ_PIN          D2
  #define RF69_IRQ_NUM          D2
#else
  #define RF69_IRQ_PIN          2
  #define RF69_IRQ_NUM          0 
#endif

But even then I had intermittent problems that disappear if I put my hand around the cables between the ESP and the RFM modules (I was using long dupont cables, about 15cm long). It seems that the problem is EMC, since they are long cables and SPI is running at some speed, and also there is some RF around from ESP and RFM modules. I was only able to solve this second issue in two ways, shielding the cables, or slowing down the SPI, so now I am using the SPI with the clock divided by 8 instead of divided by 4, replaced

SPI.setClockDivider(SPI_CLOCK_DIV4)

by

SPI.setClockDivider(SPI_CLOCK_DIV8)

So now it is running, once again thanks for your help!

Best regards

Fernando

joelucid

  • Hero Member
  • *****
  • Posts: 867
Re: [Update] RFM69 Library for ESP8266 - Moteino Compatible!
« Reply #69 on: June 05, 2016, 03:42:23 PM »
Great that you got it to work! Btw I've found that this setup works progressively better as you move from breadboard via perfboard to custom pcb.

fgomes

  • Jr. Member
  • **
  • Posts: 65
Re: [Update] RFM69 Library for ESP8266 - Moteino Compatible!
« Reply #70 on: June 05, 2016, 05:00:15 PM »
@Joe, I'm sure you are right about that, I have noticed a change in its behavior only by changing the length of the SPI wires, but of course I'm stretching it a bit over the edge, using 15cm wires at a frequency of 2MHz or 4MHz, in the middle of two RF transmitters :-)

We should consider short connections and good ground planes, so a PCB is a must for reliable communications... But at least for a quick prototype the wires are enough, now I'll add the remaining functionality before designing the PCB :-)

Best regards

Fernando

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: [Update] RFM69 Library for ESP8266 - Moteino Compatible!
« Reply #71 on: June 05, 2016, 06:38:07 PM »
The nice thing about a dipole is that, AFAIK, there's no ground plane requirement.  If you plug it into a wall outlet as wart for power, then the ground antenna (is there a more proper name for it?) can hang below while the regular wire antenna rises in the usual way.  It's not intrusive, though, because the footprint is small.

fgomes

  • Jr. Member
  • **
  • Posts: 65
Re: [Update] RFM69 Library for ESP8266 - Moteino Compatible!
« Reply #72 on: June 10, 2016, 06:54:38 PM »
After solving the previous issues with your help, I have sensors reporting to a gateway node running the RFM69 library on the ESP8266. In the meantime I have made a sniffer sketch to monitor the 'air' traffic, and noticed that the ACK from the ESP8266 takes about 140ms after the message from the sensor. As the sensors are battery powered, this means they must be awake more 100ms with the radio listeningg when compared to the gateway running on an ATMEGA328 chip (with the ATMEGA328 running the gateway I see less than 40ms for the ACK, with the ESP I get between 140 and 150ms). Did you saw a similar delay in your setup? My ESP is based on a nodeMCU (has a ESP12E module).

Best regards

Fernando

joelucid

  • Hero Member
  • *****
  • Posts: 867
Re: [Update] RFM69 Library for ESP8266 - Moteino Compatible!
« Reply #73 on: June 11, 2016, 09:19:35 AM »
The esp8266 definitely does have some latency sometimes since it manages the wifi connection in the background. But not this order of magnitude. I'd recommend measuring millis on the gw between receiving the packet and sending the ack to see where exactly you lose the time.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: [Update] RFM69 Library for ESP8266 - Moteino Compatible!
« Reply #74 on: June 11, 2016, 11:30:40 AM »
After solving the previous issues with your help, I have sensors reporting to a gateway node running the RFM69 library on the ESP8266. In the meantime I have made a sniffer sketch to monitor the 'air' traffic, and noticed that the ACK from the ESP8266 takes about 140ms after the message from the sensor. As the sensors are battery powered, this means they must be awake more 100ms with the radio listeningg when compared to the gateway running on an ATMEGA328 chip (with the ATMEGA328 running the gateway I see less than 40ms for the ACK, with the ESP I get between 140 and 150ms). Did you saw a similar delay in your setup? My ESP is based on a nodeMCU (has a ESP12E module).

Best regards

Fernando

That doesn't sound right.  IIRC, the example gateway and node sketches that accompany the library would timeout long before 140ms  and say "Nothing..." rather than "OK!" for the ACK reception.  Yet, I didn't see that.  All I saw were  "OK!"'s.  What is it that you're seeing when you try running those example sketches?
« Last Edit: June 11, 2016, 01:42:43 PM by WhiteHare »