Author Topic: setPowerLevel(...) bug? [nvm, solved]  (Read 236 times)


  • Newbie
  • *
  • Posts: 1
  • Country: de
setPowerLevel(...) bug? [nvm, solved]
« on: January 31, 2017, 05:40:39 PM »

I had a look at the method setPowerLevel(...) and it left me puzzled as to why this function was implemented the way it is for the RFM69HW.

The method in question:
Code: [Select]
void RFM69::setPowerLevel(uint8_t powerLevel) /* 0...31 */
  _powerLevel = (powerLevel > 31 ? 31 : powerLevel);
  if (_isRFM69HW) _powerLevel /= 2;
  writeReg(REG_PALEVEL, (readReg(REG_PALEVEL) & 0xE0) | _powerLevel);

So if i call setHighPower(true), PA1 and PA2 are enabled, PA_BOOST is disabled.

Now, this happens in the method setPowerLevel(...):
  • 1. Clamp and set _powerLevel to user given value in range: [0...31]
  • 2. _powerlevel is halved: [0...31] -> [0...15]
  • 3. REG_PALEVEL = {U,U,U,_powerlevel} //U => UNCHANGED

This results in PA1 and PA2 still being enabled, which is good, but the maximum value represented by bits 0 to 4 is, in this case, 15 instead of the expected 31.

The semtech datasheet says the following:

Code: [Select]
/*If PA1 and PA2 are enabled, but not the boost setting*/
Pout = -14 + OutputPower[dBm]

If we use this formula on our constrained value range for _powerlevel which is [0...15]:

Code: [Select]
Pout = -14 + [0...15] = [-14...+1]dBm

This does not seem right to me, shouldn't the resulting power range be +2 to +17 (bottom cut off?) instead of this out of spec power range?
Funny thing is, the default for REG_PALEVEL is {1,0,0,1,1,1,1,1} which means that if you initialize the library as usual with the setHighPower(true) option, but without setting the power-level explicitly, the output power will be +17dBm.

Am i missing something? Does the SX1231H in PA1+2 mode interpret a powerlevel-register value of 15 as an effective 31 (WTF) or what's the concept behind this?

This library for example seems to do it the right way, just like the datasheet says:

::) EDIT: Found this article:
« Last Edit: February 01, 2017, 04:20:00 PM by VaTTeRGeR »