Standardise Mote configuration using RFM69HW as RFM69W

[juan3211]

From this topic:

https://lowpowerlab.com/forum/rf-range-antennas-rfm69-library/standardise-mote-configuration-using-rfm69hw-only/

Code: [Select]

RFM DEFINITIONS
#define RFM69HW            // Indicate the use of a RFM69HW or a RFM69HCW transceiver
#define MODE_RFM69W         // Indicate that it should be configured as a RFM69W or RFM69CW power consumer   
#define NODEID      99
#define NETWORKID   100
#define FREQUENCY   RF69_433MHZ 

RFM69 radio();

void setup ()
{
...
radio.initialize(FREQUENCY,NODEID,NETWORKID);
//Check for the appropriate RFM settings (type if transceiver and power mode
#if defined (RFM69HW) && defined (MODE_RFM69W)  
{
  radio.writeReg (0x11, 0x5F);      // Configure the RegPaLevel mode 1 +13dBm 
  radio.writeReg (0x13, 0x1A);      // Configure the RegOcp For overlaid protection 95mA
                              // Note that RegTestPa1 and RegTestPa2 are using default values (0x55 and 0x70)
}
#else
  #ifdef RFM69HW
  radio.setHighPower();             // Set default High-Power Mode 3 (+20dBm)
  #endif
#endif
...
}

Hi, could this code be implement in radio.setHighPower(bool onOFF=true) function ?

Option 1. Rewrite the function -> bad for backward compatiblity
Option 2. Add optional parameter with default value: radio.setHighPower(bool onOff=true, bool HWasW=false)
Option 3. Change function to use a #define option -> not a good practice

What do you think guys? I am missing something about "division by 2".

I want to use this option to use RFM69HW as RFM69W in some cases, but always make my hardware with RFM69HW version.

I want also use ATC functionally, but I undersand that with this code, it can be use.

Code: [Select]

#define ENABLE_ATC
#define IS_RFM69HW
#define HWasW true

#ifdef ENABLE_ATC
  RFM69_ATC radio;
  #define ATC_RSSI -80  
#else
  RFM69 radio;
#endif

...
...

  if (!radio.initialize(FREQUENCY, ADDRESS, NETWORK_ID)) {
      Serial.println(F("RFM69 ERROR"));
  } else {
      Serial.println(F("RFM69 OK"));
      radio.encrypt(ENCRYPT_KEY);
      #ifdef IS_RFM69HW
        radio.setHighPower(true, HWasW);
      #endif
  }
  
  #ifdef ENABLE_ATC
    radio.enableAutoPower(ATC_RSSI);
  #endif

...
...

The new function will be something like:

Code: [Select]

virtual void setHighPower(bool onOFF=true, bool HWasW=false); // has to be called after initialize() for RFM69HW

void RFM69::setHighPower(bool onOff, bool HWasW) {
  _isRFM69HW = onOff;
  writeReg(REG_OCP, _isRFM69HW ? RF_OCP_OFF : RF_OCP_ON);
  if (_isRFM69HW) { // turning ON
     if (HWasW)  {
        writeReg(REG_PALEVEL, (readReg(REG_PALEVEL) & 0x1F) | RF_PALEVEL_PA1_ON);  // Configure the RegPaLevel mode 1 +13dBm. Enable only P1
        writeReg(REG_OCP, RF_OCP_ON);
     } else {
         writeReg(REG_PALEVEL, (readReg(REG_PALEVEL) & 0x1F) | RF_PALEVEL_PA1_ON | RF_PALEVEL_PA2_ON); // enable P1 & P2 amplifier stages
     }
  } else {
    writeReg(REG_PALEVEL, RF_PALEVEL_PA0_ON | RF_PALEVEL_PA1_OFF | RF_PALEVEL_PA2_OFF | _powerLevel); // enable P0 only
  }
}

Also we need to change the

void RFM69::setHighPowerRegs(bool onOff) {
  writeReg(REG_TESTPA1, onOff ? 0x5D : 0x55);
  writeReg(REG_TESTPA2, onOff ? 0x7C : 0x70);
}

function to work with RegTestPa1 and RegTestPa2 using default values (0x55 and 0x70) is HWasW is true, but it is easy to change.

What do you think about it?

Do these changes the neccessary ones to work also with ATC feature?

Please, tell me your opinions so I could write a pull request in the library so it will be backward compatible.

I think that it is a great advantage that with all your nodes with RFM69HW hardware, you could even choose in your sketch (configuration, jumper, eeprom value, even it will autoreconfigurate itselft if packets don't arrive by recording in eeprom and resettin itself...) what kind of "software RFM69" you need: RFM69HW as RFM69W or RFM69HW with full power.

Hope your answer.

[Felix]

Since the 2 variants are different in hardware, there is no way to make it "backward compatible". One way or another you have to tell the library this is a HW or not.
People mostly use the HW/HCW these days because it has the extra power which is handy in most cases. For ease of use maybe we can do it HW by default but that could cause confusion for people already using it as it is now with CW - since they would have to specifically make a call for CW instead of HCW - so I dont think this approach will work.

There was a topic by joelucid I believe who suggested that there is a way to probe the output power of a module on its own by how much it heats up.
https://lowpowerlab.com/forum/rf-range-antennas-rfm69-library/hot-or-not-identifying-if-hw-or-w-in-software/

I think that is a more valid approach, BUT I have not tested that method and perhaps there are some possible problematic implications depending on many factors.

IMO I think people should simply choose a standard and follow up with that.
I suggest the HCW format, it's smaller, has the 20dBm, it's the most popular, and it's footprint compatible with LoRa RFM95/96.

[juan3211]

as always, thanks a lot for your explanations.