RFM69 range issues

[mihai.aldea]

@scalz Many thanks for updating the docs.
I was thinking about testing them with a battery as well but even if the remote sensors may be just fine with battery power, I still need the gateway radio to be fed with a constant 3.3V voltage from either the Arduino's 3.3V rail, or using a an external regulator. And so far neither worked.
I feel like there's something wrong with the radio modules. What ar the odds of those particular modules not to work with MySensors 2.0?

[mihai.aldea]

@scalz said:

what if you directly connect a 82mm monopole wire directly on the radio ant pad?

I used a 17cm random wire for the 433MHz modules and 9cm wire for the 868MHz ones. Then coiled up the 17cm wires into a diy helical with 6-7 turns (not sure exctly)

[scalz]

for testing, perhaps better test with straight wire.
For 868Mhz, it's 82mm or it detune the radio. Also coil is nice for compact thing in box, but it decrease the range.
I hope you'll get it working, i've never got bad radio modules on my side, not yet!
With logs we could see if you get lot of fail, too, meaning bad range

[mihai.aldea]

Some guides mention 87mm, others 82mm. As for the helical I will have to test and see. PCB antennas are also an option, but I'd hate to have my nice boxed sensors with wires hanging out.
As for the bad radio modules, that's one other reason I am focusing on the RFM69. I started experimenting with the cheap eBay NRF24L01+ modules, the black ones, only to later find out that about 1 out of 10 fails after sometime and doesn't enter the deep sleep mode, using about 2mA instead of about 60uA, obviously killing the battery after a day or so. I read about one guy who ordered 2000 or so and most of them had the exact same problem.
And since I am using rather expensive CR123 or 14250 batteries I don't want take that chance.
The green NRF24L01+ modules however, worked flawlessly so far but they're a bit too bulky for my projects.

[scalz]

oki. i know for the 86mm, it also depends on the calc if i remember, that's why you can find both. but you said 9cm ;)

for your test, you should use straigth wire to be sure.
No stranded wire. Only one core inside.

It's good to know, as rfm69 need an external ant, it requires more care for the anntenna sensitivity, for noise etc.. its emplacement, orientation, shape also matter etc.. so then it's sure it's compromise between acceptable range and compact devices.
Near a computer can also increase noise etc..
If everything is ok for ant, ok with defines in Mysensors, then it's probably on your HW. In this case, you may see some errors in your logs when you try. packet ack failed etc.. some logs ??

[mihai.aldea]

So... more tests performed:
I assumed that my moronic rush fried the modules power amps. I didn't carefully read the guide and hooked their I/O pins to a 5V Arduino pins (but connected the VCC pin to the 3.3V rail). So I pulled the last two factory sealed RFM69HW 433MHz I had stashed, soldered them with dupont cables and proper antenna (0.8mm copper single core 17cm long) and hooked one module to a 3.3V Arduino (the gateway to be) and the other one on a breadboard ATmega328 (the basic remote sensor architecture) powered by a 14250 battery.
The exact same thing :rage:
The LowPowerLab works for ranges up to 1m, the Radiohead library doesn't report anything on the serial interface and leds I used for basic debug shows that the sensor node sends packets but the gateway doesn't receive them.
So I got to a point where I'm very frustrated because there must be something I'm missing. I am using two module types at different frequency and power output, purchased from a trusted source, six months apart.
However, some further reading lead me to this page:
https://www.andrehessling.de/2015/02/07/figuring-out-the-power-level-settings-of-hoperfs-rfm69-hwhcw-modules/
This guy compiled a very thorough review of the modules in which he's playing with settings by enabling/disabling the radios power amps using writing registers. But I am totally clueless on how can this be done, if the MySensors has the proper settings preconfigured or if they're accessible and if so then where. It's not clear to me either if these registers are persistent across various sketches involving various libraries or if the used library has to have support for them and they need to be declared in every sketch or inside the library. This registry thing is pretty much where my expertise hits a wall :grin:
It's really strange that this 1m range is very consistend across a lot of setups I made. Maybe the power amps are disabled and they "hear" eachother while being very close, maybe by some sort of harmonics.

[scalz]

regarding the power level registers, they are set at full power when doing
#define MY_IS_RFM69HW
In the upcoming release, there will be autoadjustements of the power level.

Like i said above, i'm running a local beta version with the new driver, but the one included actually gave me good results with rfm69hcw (same as HW) and my nodes are using rfm69cw (same as W).
Lowpowerlab lib works ok with mine. I'm not sure if i tried radiohead with them, but it was ok with rfm95..

So that doesn't come from the lib. Unfortunately, it's consistent with your hardware&environment..that's not cool, i agree.
Also, i always noted that using wire between radio and breadboard, give more ack failed (using custom pcb, i don't notice this). because it can acts as sort of "ant" and add noise. But you should get more than 1m..

What if you put them, says, 5meters apart, and plug power. Does it work?
So i would bet on lot of missed packets if you can't get more than 1m.

• Do you have logs to see if you get some ack failed?
• Could you show a pic of your stuff, perhaps with two pair of eyes could help..

I'm missing ideas

[mihai.aldea]

Exactly, I've exhausted all my ideas as well. It must definitely be the hardware. As for your questions, I'm not sure they can even talk at a full 1m distance, more like 0.5m.
I have the custom PCB design ready for production but I don't want to submit it until I do some thorough testing. I looked for alternatives on the local market but I can only find breakout boards and besides their unfeasable cost, they're too bulky to fit inside my sensor cases.
I found that Anarduino sells custom modules with integrated RFM69(H)W (http://www.anarduino.com/miniwireless/) that look exactly like the one I have and the one depicted the guide here: https://www.mysensors.org/build/connect_radio
Adafruit's Feather, as well as the Sparkfun's breakout board are using a different looking module (the same found on eBay or Aliexpress)
Anarduino has an old RFM69 library but I'm struggling with Arduino IDE versions since the latest version throws a bunch of errors when compiling while 1.6.5 works just fine. But the funny thing is that even they recommend using the RadioHead library :laughing:

Anyway, here's a bunch of pictures but I'm not sure if they're of any help.
http://imgur.com/a/yICkw

[Chester]

I have had the same issues as you with the RFM69 modules.

First ones that I bought were marked as RFM69HCW 433mhz, and when I put them together as required, I couldn't get range of more than around 40cm. After that, the reception dropped off a cliff. One thing I did note was that the modules looked different from all the images I could see on this site, which led me to ponder whether I just had crummy modules or not. Also, given the size of the antenna, I was a bit loath to continue with 433mhz radios.

so I decided to up and pick up a new batch of radios, and change over to the RFM69HW (without the C), 868mhz. These ones, when I soldered them up, give me range of around 30m through the entire length of the house, through every wall.

So the only thing I could put my effort down to was that I just had a crummy radio module batch first, and a proper set later, so not sure I can put too much more knowledge into things here.

[mihai.aldea]

@Chester said:

I have had the same issues as you with the RFM69 modules.

First ones that I bought were marked as RFM69HCW 433mhz, and when I put them together as required, I couldn't get range of more than around 40cm. After that, the reception dropped off a cliff. One thing I did note was that the modules looked different from all the images I could see on this site, which led me to ponder whether I just had crummy modules or not. Also, given the size of the antenna, I was a bit loath to continue with 433mhz radios.

so I decided to up and pick up a new batch of radios, and change over to the RFM69HW (without the C), 868mhz. These ones, when I soldered them up, give me range of around 30m through the entire length of the house, through every wall.

So the only thing I could put my effort down to was that I just had a crummy radio module batch first, and a proper set later, so not sure I can put too much more knowledge into things here.

What you're saying makes perfect sense, crappy batches can hit the market sometimes. But what doesn't make any sense in my situation is that I first puchased 5x 868MHz RFM69W modules but as I had other ongoing projects they stayed on shelf for about half an year. Then I considered tinkering with 433MHz RFM69HW to test the longest possible range of RFM69x line.
Anyway, I absolutely need to use bare modules for my sensors so I will order a few from eBay and hopefully those ones will work.

[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.