WeMos to RFM69 Gateway just can't get the radio working

[LCSteve]

I'm not a big poster on here as you can see but I have been a member for ~18 months and read a lot of the prior posts for solutions to avoid unnecessary posts when possible. I'm also a bit of a neophyte with Arduino, now thats not to say I've not made a number of things and don't reasonably know my way around sketches. I've been tinkering with Arduino now off and on for about 5 years. I've been brought hear some 2 years ago because of the project @blebson made for a tilt controller for blinds and sought help here: https://lowpowerlab.com/forum/rf-range-antennas-rfm69-library/struggling-with-the-basics-wemos-d1-mini-(esp8266)-rfm69-gateway/msg18623/#msg18623. Using the parts he produced on Tindie and a couple of Moteino R6's on the blinds themselves. Like him I'm using the WeMos D1 Mini Shield: https://github.com/hallard/WeMos-RFM69 with a WeMos D1 mini on it. I went back and forth over a year ago trying to get this to work with him and he was very helpful but could not ultimately get the whole process working so it got drawer'd. Well fast forward and many of us are stuck home from Covid so things like this get pulled back out. I'm still running into issues with it not working and I've narrowed some things down significantly (I feel).

The basic setup is a Wemos + RFM69 Shield communicating to different Moteino R6's which are using blebsons servo shield. Fully assembled I feel the R6+shield are working as I'm getting expected responses in the serial monitor. The Wemos starts a wifi connection and I'm able to update the wifi as expected, the unit also responds to web commands and outputs what looks like the correct serial information but the Moteino's never do anything. So I flashed the Moteino's with struct_send/receive sketches and saw good activity in the serial monitor. To be safe I dusted off my USB NESDR and using HDSDR I tuned into ~915MHz and watched the magic as the signals were clearly being detected. So I know the Moteino's appear to be sending and receiving fine. Trying multiple iterations with the Wemos/shield though have not once moved the needle in HDSDR (btw I always baseline with a Moteino first to ensure it is reading something).

So now I have a better idea of where to look and focus on the sketch(s) and RFM69.h files with a brief interlude checking all the hardware on the shield and ohming out all connections which seem fine. So I'm feeling like the RFM69.h file or library I'm using must have a flaw somewhere as that file is a modified version calling out different IRQ's and SS pins. From my neophyte viewpoint they look correct. From his modified file on Github:

https://github.com/blebson/Automated-Blinds/tree/master/Arduino-Code/Libraries

Code: [Select]

#ifndef RFM69_h
#define RFM69_h
#include <Arduino.h>            // assumes Arduino IDE v1.0 or greater

#define RF69_MAX_DATA_LEN       61 // to take advantage of the built in AES/CRC we want to limit the frame size to the internal FIFO size (66 bytes - 3 bytes overhead - 2 bytes crc)
#define RF69_SPI_CS             SS // SS is the SPI slave select pin, for instance D10 on ATmega328

// 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          D8  // needed for esp8266
  #define RF69_IRQ_NUM          D8  // needed for esp8266
  #define RF69_SPI_CS			D0  // needed for esp8266
  #define LED 				2   // LED on ESP12F is on GPIO2
#else 
  #define RF69_IRQ_PIN          2
  #define RF69_IRQ_NUM          0  
#endif

Specifically is changing to D8 and D0, which seem to map right on Hallards shield which go to DIO0 and NSS respectively on the RFM69 pins. When ever hooked up the lights come on with the shield but it just never seems to turn the radio on. The sketch I'm using on the Wemos is also listed n his Github page but I can post up here if someone wants it. I also tried many modified versions eliminating virtually all code not relevant for testing and even modified struct_send on the Wemos and got no radio signal.

So as I'm running out of idea's and would appreciate some more experienced opinions on where to look next.

Many thanks.
Steve

[Felix]

The latest library has some pins defined for ESP but are not tested by myself. At this time there is no support for ESP, only AVR and SAMD.
Ensure the pins are defined correctly and start with simple Send/Receive sketches to get to a point where those work. Or break down the big picture and isolate the problem. To try and get everything perfect and working is too difficult in 1 shot.

[LCSteve]

Thanks for the response to my inquiry. After spending another week trying everything I could think of I could not get the WeMos + shield to send or receive any signals on the RFM69 frequencies. Since I could not obtain another unit I ordered a Adafruit Feather ESP8266 and their Feather RFM69HW shield. After soldering it up I slapped a Struct_Send example on it (needed to fix the pins in RFM69.h to match the Feather) and viola it's communicating and has a clear signal on the NESDR. I'm thinking at this point the WeMos shield I have contains a dead RF chip on it. I'll test it later though as I bought some replacement RFM69HW chips I'll solder on the board.

My updated question comes in with the communication between the Feather and my Moteino R6's. They talk and ACK OK it seems but there is an issue with the number of bytes in the struct alignment similar to https://lowpowerlab.com/forum/rf-range-antennas-rfm69-library/rfm69-library-now-works-on-spark-core/msg9340/#msg9340. I tried the suggestion listed there and it didn't seem to work on mine. If I limit the struct to 1 item say the NODEID or the TEMP it actually comes across correct, it's when I have more than 1 payload item it skews the received data just like the link above and the # of bytes no longer matches. Based on that I am assuming that the issues are similar and likely have a similar solution. As I'm still learning much of this I was wondering if someone could point me to some potential areas I should start researching and testing solutions on. I tried looking at how the Feather compile operation works but I don't see anything on Adafruits site on that.

I appreciate any help or direction here.

[Felix]

Its more a coding/debugging question. The structs need to be identical. The struct examples, unmodified should work on LowPowerLab hardware, however I cannot support 3rd party hardware.

[LCSteve]

Thanks and I agree, after I posted it I considered closing this one and posing the same question in the coding section but was worried about double posting etc.

Regarding the struct, they are definitely the same as I'm using the "raw" struct examples for send/receive. I did narrow it down to

Code: [Select]

int    nodeID;

as the culprit. I tried uint8_t and 16 to no avail and ended up getting it working this morning by un-glamorously padding the int with bytes.

Code: [Select]

int    nodeID;
byte   fld1;
byte   fld2;

It's not sexy but it works, was hoping it was more of an encoding or compiling method that could fix it in the entire sketch as my real code will likely need a few of these as there are multiple sensors reporting back.

regards,
Steve

[Felix]

Did you have to do that for both nodes involved?

[LCSteve]

No just on the sending Moteino.

So it looks like I have more work ahead of me too as I started layering in the first sensor and I'm back to square one as all the sensors are using uint8_t and the packet size is different again between the sending Moteino and the shield. Now the Moteino has more 1 more byte. So I thought OK well let me remove one of my padding bytes from earlier and while that lets the receiving shield read the payload the new sensor seems to always be 0.

There just seems to be a difference in the way both units handle int & uint8_t being passed back and forth so I'll need to dig further into it and maybe rework the code to minimize the use of these if possible.

[Felix]

int and uint_8 are not the same.
How you cast variables makes a difference.