RFM69 range issues

[executivul]

@mihai-aldea I've bought the same modules from the same supplier.
Initially I had the same problems you mention.
My advice: start with the simple lowpowerlab library and their sender/receiver sketches. Use some form of ground plane directly under the module, I've ended up with small pieces of metal sheet under the modules, otherwise I had no reception. Or use a diploe as pictured earlier.
By the way try touching the antenna at different points maybe you will get reception. The antenna length must be tuned to the circuit, I ended up with 96mm for one particular 868Mhz module, either the tuning circuit is flawed or my circuit messes up the antenna tuning.
You can also check the interrupt gets triggered or simply use polling by calling the interrupt handler function inside the receiveDone() function to be sure you don't miss received packages (I work with Mega2560 which are not configured correctly in the library for pin2/int4).
And please use some level shifters :)

[mihai.aldea]

I don't have the skill level of an RF engineer, but being also a licensed ham radio operator, I know a thing or two about RF signals and atennas.
I believe your statements, yet here I am testing a prototype using a radio module that's supposed to beat the RF24 by a mile, but for this to happen I need use dipoles, ground planes, and who knows, maybe design, build and tune some magnetic loop antenna or some antenna tuning circuit for the RFM69 modules to work at 20-30 meters. For God sake, even with an improper length random wire antenna they should be able to work at 20-30m.
There are people reporting good signal at distances of 13km with a bitrate of 55.5kbps. The LowPowerLab sets the default bitrate at 4kbps. That may take the distance to over 20km. But all I managed to squeeze out of my 433MHz HW modules is 3 meters. That can't be right.
I contacted HopeRF and asked them about clarifications. First I need to know if their RFM69HW-V1.3.pdf is compatible with the RFM69HW REV 2.0 board (as depicted on the back of the module). I also contacted the supplier asking if they received any other complaints for those modules.
What kills me is that while everything points to faulty modules, they were bought 6 months apart from the same supplier, they have different frequencies and power output and they behave the same :confused:
As for the register levels, luckily I had some 3.3V Arduino Pro Mini to which I hooked a pair of factory sealed modules (to rule out any malfunction due to the improper usage with 5V I/O).
Thanks to Felix's excellent library I was able to pull the complete list of registries:

1 - 10 - 10000
2 - 0 - 0
3 - 2 - 10
4 - 40 - 1000000
5 - 3 - 11
6 - 33 - 110011
7 - 6C - 1101100
8 - 40 - 1000000
9 - 0 - 0
A - 41 - 1000001
B - 40 - 1000000
C - 2 - 10
D - 92 - 10010010
E - F5 - 11110101
F - 20 - 100000
10 - 24 - 100100
11 - 7F - 1111111
12 - 9 - 1001
13 - F - 1111
14 - 40 - 1000000
15 - B0 - 10110000
16 - 7B - 1111011
17 - 9B - 10011011
18 - 8 - 1000
19 - 42 - 1000010
1A - 8A - 10001010
1B - 40 - 1000000
1C - 80 - 10000000
1D - 6 - 110
1E - 10 - 10000
1F - 0 - 0
20 - 0 - 0
21 - 0 - 0
22 - 0 - 0
23 - 0 - 0
24 - D3 - 11010011
25 - 40 - 1000000
26 - 7 - 111
27 - D8 - 11011000
28 - 0 - 0
29 - DC - 11011100
2A - 0 - 0
2B - 0 - 0
2C - 0 - 0
2D - 3 - 11
2E - 88 - 10001000
2F - 2D - 101101
30 - 64 - 1100100
31 - 0 - 0
32 - 0 - 0
33 - 0 - 0
34 - 0 - 0
35 - 0 - 0
36 - 0 - 0
37 - 90 - 10010000
38 - 42 - 1000010
39 - 0 - 0
3A - 0 - 0
3B - 0 - 0
3C - 8F - 10001111
3D - 13 - 10011
3E - 73 - 1110011
3F - 61 - 1100001
40 - 6D - 1101101
41 - 70 - 1110000
42 - 6C - 1101100
43 - 65 - 1100101
44 - 45 - 1000101
45 - 6E - 1101110
46 - 63 - 1100011
47 - 72 - 1110010
48 - 79 - 1111001
49 - 70 - 1110000
4A - 74 - 1110100
4B - 4B - 1001011
4C - 65 - 1100101
4D - 79 - 1111001
4E - 1 - 1
4F - 0 - 0
50 - 13 - 10011
51 - 45 - 1000101
52 - 88 - 10001000
53 - 8 - 1000
54 - 0 - 0
55 - 0 - 0
56 - 1 - 1
57 - 0 - 0
58 - 1B - 11011
59 - 9 - 1001
5A - 55 - 1010101
5B - 80 - 10000000
5C - 70 - 1110000
5D - 33 - 110011
5E - CA - 11001010
5F - 8 - 1000
60 - 0 - 0
61 - F - 1111
62 - 0 - 0
63 - 0 - 0
64 - 0 - 0
65 - F - 1111
66 - 70 - 1110000
67 - 0 - 0
68 - 12 - 10010
69 - 16 - 10110
6A - 19 - 11001
6B - 1C - 11100
6C - 0 - 0
6D - 4 - 100
6E - C - 1100
6F - 30 - 110000
70 - 18 - 11000
71 - 0 - 0
72 - 0 - 0
73 - 0 - 0
74 - 0 - 0
75 - 0 - 0
76 - 0 - 0
77 - 0 - 0
78 - 0 - 0
79 - 0 - 0
7A - 0 - 0
7B - 0 - 0
7C - 0 - 0
7D - 0 - 0
7E - 0 - 0
7F - 0 - 0
80 - D - 1101

I had to use a minor tweak to extend the limit of registries pulled out above the initial limit of 0x4F. They are test registers and internal test registers. Not sure if they're of any help.

[mihai.aldea]

Well, here's some new developments. I used the Struct_send and Send_receive examples from LPL RFM69 lib.

Struct_send

#define RF_PALEVEL_PA0_OFF
#define RF_PALEVEL_PA1_ON
#define RF_PALEVEL_PA2_OFF

#include <RFM69.h>
#include <SPI.h>
#include <SPIFlash.h>

#define NODEID      99
#define NETWORKID   100
#define GATEWAYID   1
#define FREQUENCY   RF69_433MHZ //Match this with the version of your Moteino! (others: RF69_433MHZ, RF69_868MHZ)
#define KEY         "sampleEncryptKey" //has to be same 16 characters/bytes on all nodes, not more not less!
#define LED         13
#define SERIAL_BAUD 115200
#define ACK_TIME    30  // # of ms to wait for an ack

int TRANSMITPERIOD = 1000; //transmit a packet to gateway so often (in ms)
byte sendSize=0;
boolean requestACK = true;
SPIFlash flash(8, 0xEF30); //EF40 for 16mbit windbond chip
RFM69 radio;

typedef struct {
  int           nodeId; //store this nodeId
  unsigned long uptime; //uptime in ms
  float         temp;   //temperature maybe?
} Payload;
Payload theData;

void setup() {
  Serial.begin(SERIAL_BAUD);
  radio.initialize(FREQUENCY,NODEID,NETWORKID);
  //radio.setHighPower(); //uncomment only for RFM69HW!
  radio.encrypt(KEY);
  char buff[50];
  sprintf(buff, "\nTransmitting at %d Mhz...", FREQUENCY==RF69_433MHZ ? 433 : FREQUENCY==RF69_868MHZ ? 868 : 915);
  Serial.println(buff);
  
  if (flash.initialize())
    Serial.println("SPI Flash Init OK!");
  else
    Serial.println("SPI Flash Init FAIL! (is chip present?)");
}

long lastPeriod = -1;
void loop() {
  //process any serial input
  if (Serial.available() > 0)
  {
    char input = Serial.read();
    if (input >= 48 && input <= 57) //[0,9]
    {
      TRANSMITPERIOD = 100 * (input-48);
      if (TRANSMITPERIOD == 0) TRANSMITPERIOD = 1000;
      Serial.print("\nChanging delay to ");
      Serial.print(TRANSMITPERIOD);
      Serial.println("ms\n");
    }
    
    if (input == 'r') //d=dump register values
      radio.readAllRegs();
    //if (input == 'E') //E=enable encryption
    //  radio.encrypt(KEY);
    //if (input == 'e') //e=disable encryption
    //  radio.encrypt(null);
    
    if (input == 'd') //d=dump flash area
    {
      Serial.println("Flash content:");
      int counter = 0;

      while(counter<=256){
        Serial.print(flash.readByte(counter++), HEX);
        Serial.print('.');
      }
      while(flash.busy());
      Serial.println();
    }
    if (input == 'e')
    {
      Serial.print("Erasing Flash chip ... ");
      flash.chipErase();
      while(flash.busy());
      Serial.println("DONE");
    }
    if (input == 'i')
    {
      Serial.print("DeviceID: ");
      word jedecid = flash.readDeviceId();
      Serial.println(jedecid, HEX);
    }
  }

  //check for any received packets
  if (radio.receiveDone())
  {
    Serial.print('[');Serial.print(radio.SENDERID, DEC);Serial.print("] ");
    for (byte i = 0; i < radio.DATALEN; i++)
      Serial.print((char)radio.DATA[i]);
    Serial.print("   [RX_RSSI:");Serial.print(radio.readRSSI());Serial.print("]");

    if (radio.ACKRequested())
    {
      radio.sendACK();
      Serial.print(" - ACK sent");
      delay(10);
    }
    Blink(LED,5);
    Serial.println();
  }
  
  int currPeriod = millis()/TRANSMITPERIOD;
  if (currPeriod != lastPeriod)
  {
    //fill in the struct with new values
    theData.nodeId = NODEID;
    theData.uptime = millis();
    theData.temp = 91.23; //it's hot!
    
    Serial.print("Sending struct (");
    Serial.print(sizeof(theData));
    Serial.print(" bytes) ... ");
    if (radio.sendWithRetry(GATEWAYID, (const void*)(&theData), sizeof(theData)))
      Serial.print(" ok!");
    else Serial.print(" nothing...");
    Serial.println();
    Blink(LED,3);
    lastPeriod=currPeriod;
  }
}

void Blink(byte PIN, int DELAY_MS)
{
  pinMode(PIN, OUTPUT);
  digitalWrite(PIN,HIGH);
  delay(DELAY_MS);
  digitalWrite(PIN,LOW);
}

Struct_receive

#define RF_PALEVEL_PA0_OFF
#define RF_PALEVEL_PA1_ON
#define RF_PALEVEL_PA2_OFF

#include <RFM69.h>
#include <SPI.h>
#include <SPIFlash.h>

#define NODEID      1
#define NETWORKID   100
#define FREQUENCY   RF69_433MHZ //Match this with the version of your Moteino! (others: RF69_433MHZ, RF69_868MHZ)
#define KEY         "thisIsEncryptKey" //has to be same 16 characters/bytes on all nodes, not more not less!
#define LED         13
#define SERIAL_BAUD 115200
#define ACK_TIME    30  // # of ms to wait for an ack

RFM69 radio;
SPIFlash flash(8, 0xEF30); //EF40 for 16mbit windbond chip
bool promiscuousMode = true; //set to 'true' to sniff all packets on the same network

typedef struct {    
  int           nodeId; //store this nodeId
  unsigned long uptime; //uptime in ms
  float         temp;   //temperature maybe?
} Payload;
Payload theData;

void setup() {
  Serial.begin(SERIAL_BAUD);
  delay(10);
  radio.initialize(FREQUENCY,NODEID,NETWORKID);
  //radio.setHighPower(); //uncomment only for RFM69HW!
  radio.encrypt(KEY);
  radio.promiscuous(promiscuousMode);
  char buff[50];
  sprintf(buff, "\nListening at %d Mhz...", FREQUENCY==RF69_433MHZ ? 433 : FREQUENCY==RF69_868MHZ ? 868 : 915);
  Serial.println(buff);
  if (flash.initialize())
    Serial.println("SPI Flash Init OK!");
  else
    Serial.println("SPI Flash Init FAIL! (is chip present?)");
}

byte ackCount=0;
void loop() {
  //process any serial input
  if (Serial.available() > 0)
  {
    char input = Serial.read();
    if (input == 'r') //d=dump all register values
      radio.readAllRegs();
    if (input == 'E') //E=enable encryption
      radio.encrypt(KEY);
    if (input == 'e') //e=disable encryption
      radio.encrypt(null);
    if (input == 'p')
    {
      promiscuousMode = !promiscuousMode;
      radio.promiscuous(promiscuousMode);
      Serial.print("Promiscuous mode ");Serial.println(promiscuousMode ? "on" : "off");
    }
    
    if (input == 'd') //d=dump flash area
    {
      Serial.println("Flash content:");
      int counter = 0;

      while(counter<=256){
        Serial.print(flash.readByte(counter++), HEX);
        Serial.print('.');
      }
      while(flash.busy());
      Serial.println();
    }
    if (input == 'D')
    {
      Serial.print("Deleting Flash chip content... ");
      flash.chipErase();
      while(flash.busy());
      Serial.println("DONE");
    }
    if (input == 'i')
    {
      Serial.print("DeviceID: ");
      word jedecid = flash.readDeviceId();
      Serial.println(jedecid, HEX);
    }
  }

  if (radio.receiveDone())
  {
    Serial.print('[');Serial.print(radio.SENDERID, DEC);Serial.print("] ");
    Serial.print(" [RX_RSSI:");Serial.print(radio.readRSSI());Serial.print("]");
    if (promiscuousMode)
  {
      Serial.print("to [");Serial.print(radio.TARGETID, DEC);Serial.print("] ");
    }
  
    if (radio.DATALEN != sizeof(Payload))
      Serial.print("Invalid payload received, not matching Payload struct!");
    else
    {
      theData = *(Payload*)radio.DATA; //assume radio.DATA actually contains our struct and not something else
      Serial.print(" nodeId=");
      Serial.print(theData.nodeId);
      Serial.print(" uptime=");
      Serial.print(theData.uptime);
      Serial.print(" temp=");
      Serial.print(theData.temp);
    }
    
    if (radio.ACKRequested())
    {
      byte theNodeID = radio.SENDERID;
      radio.sendACK();
      Serial.print(" - ACK sent.");

      // When a node requests an ACK, respond to the ACK
      // and also send a packet requesting an ACK (every 3rd one only)
      // This way both TX/RX NODE functions are tested on 1 end at the GATEWAY
      if (ackCount++%3==0)
      {
        Serial.print(" Pinging node ");
        Serial.print(theNodeID);
        Serial.print(" - ACK...");
        delay(3); //need this when sending right after reception .. ?
        if (radio.sendWithRetry(theNodeID, "ACK TEST", 8, 0, 50))  // 0 = only 1 attempt, no retries; wait up to 50mS
          Serial.print("ok!");
        else Serial.print("nothing");
      }
    }
    Serial.println();
    Blink(LED,3);
  }
}

void Blink(byte PIN, int DELAY_MS)
{
  pinMode(PIN, OUTPUT);
  digitalWrite(PIN,HIGH);
  delay(DELAY_MS);
  digitalWrite(PIN,LOW);
}

As you noticed both sketches start with

#define RF_PALEVEL_PA0_OFF
#define RF_PALEVEL_PA1_ON
#define RF_PALEVEL_PA2_OFF

so I can play with the PA's.
Also the

  //radio.setHighPower(); //uncomment only for RFM69HW!

is commented out because they appear to hear eachother fine. Well, almost fine.

Here's the Struct_send output:

Transmitting at 433 Mhz...
SPI Flash Init FAIL! (is chip present?)
Sending struct (10 bytes) ...  nothing...
Sending struct (10 bytes) ...  nothing...
Sending struct (10 bytes) ...  nothing...
Sending struct (10 bytes) ...  nothing...
Sending struct (10 bytes) ...  nothing...
Sending struct (10 bytes) ...  nothing...
Sending struct (10 bytes) ...  nothing...
Sending struct (10 bytes) ...  nothing...
Sending struct (10 bytes) ...  nothing...
Sending struct (10 bytes) ...  nothing...
Sending struct (10 bytes) ...  nothing...
Sending struct (10 bytes) ...  nothing...
Sending struct (10 bytes) ...  nothing...
Sending struct (10 bytes) ...  nothing...
...........

But here's the most interesting output after I changed bool promiscuousMode = false; to bool promiscuousMode = true; I was suddenly able to make them talk to each other even with both PA's disabled and the radio.setHighPower(); commented out.
Here's the Struct_receive output:

Listening at 433 Mhz...
SPI Flash Init FAIL! (is chip present?)
[212]  [RX_RSSI:-68]to [189]  nodeId=10767 uptime=3895142702 temp=ovf
[212]  [RX_RSSI:-66]to [189]  nodeId=10767 uptime=3895142702 temp=ovf
[212]  [RX_RSSI:-66]to [189]  nodeId=10767 uptime=3895142702 temp=ovf
[138]  [RX_RSSI:-66]to [69]  nodeId=25167 uptime=755652493 temp=10.40
[138]  [RX_RSSI:-66]to [69]  nodeId=25167 uptime=755652493 temp=10.40
[138]  [RX_RSSI:-66]to [69]  nodeId=25167 uptime=755652493 temp=10.40
[6]  [RX_RSSI:-66]to [95]  nodeId=28423 uptime=3186857133 temp=-0.00 - ACK sent. Pinging node 6 - ACK...nothing
[6]  [RX_RSSI:-66]to [95]  nodeId=28423 uptime=3186857133 temp=-0.00 - ACK sent.
[211]  [RX_RSSI:-67]to [113]  nodeId=-15141 uptime=657118850 temp=28713.76 - ACK sent.
[211]  [RX_RSSI:-68]to [113]  nodeId=-15141 uptime=657118850 temp=28713.76 - ACK sent. Pinging node 211 - ACK...nothing
[18]  [RX_RSSI:-68]to [211]  nodeId=14750 uptime=987840321 temp=-0.00
[18]  [RX_RSSI:-66]to [211]  nodeId=14750 uptime=987840321 temp=-0.00
[18]  [RX_RSSI:-67]to [211]  nodeId=14750 uptime=987840321 temp=-0.00
[133]  [RX_RSSI:-66]to [167]  nodeId=-16647 uptime=1764550266 temp=ovf
[133]  [RX_RSSI:-67]to [167]  nodeId=-16647 uptime=1764550266 temp=ovf
[133]  [RX_RSSI:-66]to [167]  nodeId=-16647 uptime=1764550266 temp=ovf
[50]  [RX_RSSI:-66]to [109]  nodeId=19370 uptime=3957555244 temp=0.00
[50]  [RX_RSSI:-66]to [109]  nodeId=19370 uptime=3957555244 temp=0.00
[50]  [RX_RSSI:-66]to [109]  nodeId=19370 uptime=3957555244 temp=0.00
[131]  [RX_RSSI:-66]to [229]  nodeId=12568 uptime=2848342087 temp=ovf
[131]  [RX_RSSI:-66]to [229]  nodeId=12568 uptime=2848342087 temp=ovf
[131]  [RX_RSSI:-66]to [229]  nodeId=12568 uptime=2848342087 temp=ovf
[255]  [RX_RSSI:-66]to [168]  nodeId=7355 uptime=659277296 temp=0.00
[255]  [RX_RSSI:-66]to [168]  nodeId=7355 uptime=659277296 temp=0.00
[255]  [RX_RSSI:-67]to [168]  nodeId=7355 uptime=659277296 temp=0.00
[186]  [RX_RSSI:-67]to [20]  nodeId=-17448 uptime=273311279 temp=-13989.21 - ACK sent.
[186]  [RX_RSSI:-68]to [20]  nodeId=-17448 uptime=273311279 temp=-13989.21 - ACK sent.
[186]  [RX_RSSI:-68]to [20]  nodeId=-17448 uptime=273311279 temp=-13989.21 - ACK sent. Pinging node 186 - ACK...nothing
[26]  [RX_RSSI:-68]to [43]  nodeId=2128 uptime=2142532543 temp=ovf
[26]  [RX_RSSI:-67]to [43]  nodeId=2128 uptime=2142532543 temp=ovf
[26]  [RX_RSSI:-67]to [43]  nodeId=2128 uptime=2142532543 temp=ovf
[193]  [RX_RSSI:-67]to [152]  nodeId=32722 uptime=2146611939 temp=-0.00 - ACK sent.
[193]  [RX_RSSI:-68]to [152]  nodeId=32722 uptime=2146611939 temp=-0.00 - ACK sent.
[193]  [RX_RSSI:-67]to [152]  nodeId=32722 uptime=2146611939 temp=-0.00 - ACK sent. Pinging node 193 - ACK...nothing
[128]  [RX_RSSI:-68]to [153]  nodeId=-32702 uptime=4189638721 temp=-130171.57 - ACK sent.
[128]  [RX_RSSI:-67]to [153]  nodeId=-32702 uptime=4189638721 temp=-130171.57 - ACK sent.
[128]  [RX_RSSI:-68]to [153]  nodeId=-32702 uptime=4189638721 temp=-130171.57 - ACK sent. Pinging node 128 - ACK...nothing

Do you noticed the to column? And how the ack destination node is never the same? So it seems to me that the packets are corrupted either at source or at destination. I'm not sure if the sender is mangling it or if the receiver is parsing it wrong. But it's obvious that the one way communication works just fine. The problem is with the "full duplex" communication.

[executivul]

RFM69HW can not work with PA disabled, you must use radio.setHighPower(), otherwise unpredictable results may occur.
try spacing them at least 1 meter apart and use radio.setPowerLevel(0) instead.

[mihai.aldea]

@executivul said:

RFM69HW can not work with PA disabled, you must use radio.setHighPower(), otherwise unpredictable results may occur.
try spacing them at least 1 meter apart and use radio.setPowerLevel(0) instead.

While RFM69W has only PA0 installed, RFM69HW doesn't have it but has PA1 and PA2. So I'm not sure if there's a problem with enablin PA0 on the HW version but I left it disabled anyway. After trying with the fresh new models, I was too far with my experiments, and drifted a lot from the standard libraries config. So obviously they weren't working. But with with a back to basics approach, I got them to work. I'm not sure what their range is because I haven't had time to make a field test, but the HW's work just fine with all PA's disabled and with a couple of brick walls between.
So guys, thank you very much for your support, but my conclusion is that the first modules weren't working because I was applying them with 5V logic. I will check them and see if they're damaged or work fine with the proper 3.3V.
Since I got them to work, I did found a couple of problems but that's another topic which I'll open as soon as I'll get a consistent conclusion and a replicable scenario.

[scalz]

@mihai-aldea
that's why it's always better to tell which hardware you're using, and logs. If i knew you were using 5v logic, i would have told you it couldn't work, and save time ;)

About promiscuous mode, you can think about it as a sniffer mode.

Great to hear you finally found your answer :)

[mihai.aldea]

@scalz said:

@mihai-aldea
that's why it's always better to tell which hardware you're using, and logs. If i knew you were using 5v logic, i would have told you it couldn't work, and save time ;)

About promiscuous mode, you can think about it as a sniffer mode.

Great to hear you finally found your answer :)

Yeah, I know I was a bit of a jackass for not reverting back whatever I was doing and provide you with logs from the MySensors lib. But I used lots of libs, some of them with various tweaks, the test setup was bit complicated and I knew that whatever logs I could see during the initial stages were not very helpful.
And speaking of helpful logs. I would've loved to see more verbose logs. Is there a way to increase the verbosity level?
As for the promisc mode, I know very well that that is, is just that it seemed strange how is it that the node ID's were all messed up.

[scalz]

@mihai-aldea
yeah i can understand, no problem, was just an humble remainder for future :)
the new rfm69 driver we are working on, will be better (i hope) with more verbose, for registers and state machine too. and you'll get atc feature which is cool. i'm not sure if i'll have time to finish listenmode though (for the moment it's very basic)..let's see

I hope you'll get your thing running as you want ;)

[mihai.aldea]

Is the new driver a fork of some other or you're building it from scratch?
One suggestion though: If it's aiming to provide excellent support for the battery powered nodes, it would be great if you'd expose some of the advanced settings that allow faster TX times. I'm currently testing the awake cycle time aiming for the lowest possible values. For instance I chose the fast Si7021 instead of the slooooow DHT22. This one is supposed to have a total converesion time of 22.8ms but the fastest working library is Adafruit's which pulls the maximum resolution values within 50-55ms. But on top of that, the TX time takes another 70ms with the current driver. That means a total of ~125ms (with ack disabled).
125ms isn't bad. But maybe one would come to the conclusion that they'd want to trade range or bandwidth for TX speed (not bitrate). I'm not talking about the bulky 2xAA battery packs or large lithium cells users but the ones who'd put a CR2032 coin battery inside of a door sensor for instance and expect it to last at least a year.

[scalz]

mainly inspired from Lowpowerlab at the beginning.
But now it looks like other Mysensors radio drivers. for harmonization, and better support.
So, the base flow implementation for instance, is from tekka (structure, and spi handling).
It should be faster, and memory efficient compared to the old one (lowpowerlab version) which was c++ etc..
Compilation with all features (atc, listenmode) takes now less memory than with the previous lowpowerlab version. Even with some nice addition from tekka like a version number+sequence number in the header.
And, marceloagno is also checking the linux part.
etc..
Also, regarding tx times, we still use packetmode with automatic sequencer if this is what you're talking.
for a door contact switch, depending of its purpose, signing (and so ack) may be needed to have "security" and reliable delivery packet.
As it's rf, i'm trying to find a way to have this reliable delivery by adding a random delay (optional feature) before talking. the Listen Before Talk to avoid for instance to have two node waiting for free channel and startng to send at send time..not often implemented in libs though.

[mihai.aldea]

Souds great. I took a short pause because believe it or not, I was back to square one with the issues. A couple of days and one Adafruit Feather RFM69 plus one Sparkfun RFM69HCW breakout board later I still have no conclusion to what leads to the problems, at first I thought of bypassing the MySensor's directive and call the RFM69 drivers directly. It worked until it didn't, with no explanation whatsoever.
So I started from a couple of sketches I knew worked and slowly build up the correct configuration that's now working (partly but more on that in a separate topic). The most useful debug tool was an RTL-SDR stick so I could actually hear the nodes whisper :grin:
So, it appears that in order to use the 433/868/915 W/HW modules with MySensors, it's best to add theses at the top of your sketches:

// Select the RFM69 radio type
#define MY_RADIO_RFM69
// Enter your model's frequency
#define MY_RFM69_FREQUENCY RF69_433MHZ
// If you're using RFM69HW / RFM69HCW modules, they won't work until this is set.
// Leave it commented for the normal power modules.
#define MY_IS_RFM69HW
// Your network ID
#define MY_RFM69_NETWORKID 100

The library is pretty much preconfigured for RF24 so using the RFM69 modules is possible but with a bit of trial and error until all things are set.

[scalz]

sure! you have to set all your defines for your node. before the mysensors include.
for the possible defines you can take a look at docs
https://www.mysensors.org/download/sensor_api_20
i also have an rtl-sdr. can be useful. cool :)

[DavidZH]

I find it very strange you experience these kind of problems. I have been using the RFM69 (both W and HW) since I started with MySensors a year ago.
The only time I had trouble with the range (or any transmission at all..) was when I used double sided perf-board to build my circuits on. Somehow the extra exposed copper reflects the RF energy in an unpredictable way so the radio will not send at all.

Can you post a picture of your setup? Maybe we spot a tiny little thing that eff's up your testing.

[mihai.aldea]

I believe this one is on me. It wasn't clear to me that MySensors is actually wrapper of the original LowPowerLab's RFM69 lib and you can't mix #define's from MySensors and the embedded RFM69 driver.
MySensors is really plug&play if you're using the NRF24L01+ modules, follow the guides, upload the sketches and fire up the gateway, but if you want to use RFM69, I at least, needed some serious trial and error.
Maybe it's just my hectic style of trying new setups, or maybe because I found no concise guide on how to switch from RF24 to RFM69 or maybe something in between :yum:

[mfalkvidd]

@mihai.aldea great that you got it working. I believe many people would find such a guide useful. Would it be possible for you to summarize your experience? That summary could then be the base for a guide that we can add to the MySensors documentation.

[mihai.aldea]

@mfalkvidd I will definitely do that. I'll tinker with them for a while just to be confortable with stating the facts and I will compile such a guide. It'll take me no more than a couple of days.

[mfalkvidd]

@mihai.aldea great!

[maman]

I configure the ESP8266 MQTT gateway using RFM69HW.

I define as follows

#define MY_RADIO_RFM69
#define MY_RFM69_FREQUENCY RF69_433MHZ
#define MY_IS_RFM69HW
#define MY_RFM69_NETWORKID 100
#define RF69_IRQ_PIN 4
#define RF69_SPI_CS 15
#define MY_RF69_IRQ_PIN RF69_IRQ_PIN
#define MY_RF69_SPI_CS RF69_SPI_CS

For node side, I use Promini ATMEGA328
#define MY_NODE_ID 7
#define MY_PARENT_NODE_ID 0
#define MY_RADIO_RFM69
#define MY_RFM69_FREQUENCY RF69_433MHZ
#define MY_IS_RFM69HW
#define MY_RFM69_NETWORKID 100
#define RF69_IRQ_PIN 2
#define RF69_SPI_CS 10
#define MY_RF69_IRQ_PIN RF69_IRQ_PIN
#define MY_RF69_SPI_CS RF69_SPI_CS

But, the node (Promini) can not communicate with the gateway

1487370 !TSM:FPAR:NO REPLY
1487372 TSM:FPAR
1487503 TSF:MSG:SEND,7-7-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
1489510 !TSM:FPAR:NO REPLY
1489512 TSM:FPAR
1489643 TSF:MSG:SEND,7-7-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
1491650 !TSM:FPAR:FAIL
1491652 TSM:FAIL:CNT=7
1491654 TSM:FAIL:PDT

Is there any hint to do ?

[Yeitso]

@maman Try to downgrade to 2.0.0 if you are using any newer lib.
The newer libs over 2.0.0 does not work for my esp8266 mqtt gateway either.

[maman]

@Yeitso Thanks, I will try to downgrade the mysensors library.

Can you share the #define script that working on ATMEGA328 and ESP8266 board ?

Thanks for your help.

Regards,
Maman