Automatic switch between RFO and PA mode on SX127x modules & partly different dBm values then in datasheet

[serialrf433]

I have read as far as possible through the docs, issues and discussions.

I was expecting the same like this person here:
#1022 (reply in thread)

Quote:

The board in question has a single ANT pin, which I believe is switched between RFO and PA automatically (i've tried 17dB (RFO) and 20dB (PA)) separately to avoid issues here with no behaviour difference.

(yes, i know that 17dBm is PA-only mode and the person was wrong at this)

On my case, i like to use values lower then 2. To keep it simple and because you like to see code, i used for this issue report the code on the example:
https://github.com/jgromes/RadioLib/blob/master/examples/SX127x/SX127x_Transmit_Blocking/SX127x_Transmit_Blocking.ino

The only line i change is this one:
int state = radio.begin();

i change it to https://github.com/jgromes/RadioLib/wiki/Default-configuration#sx127xrfm9x---fsk-modem

int state = radio.beginFSK(434.0, 4.8, 5.0, 125.0, 1, 16, false);

Now compile, upload to device and you see just error at serial output:
SX1278.cpp:299 and SX1278.cpp:58

Its from the software side i expect possible to just make it work. This would make this part more user friendly when it should just work and the people do not care if its RFO or PA mode.

I by the way did not understand why you are using the PA mode with so low dBm values. To my understanding of the datasheet of the SX127x is more efficient when using the RFO mode as long as possible and only when you need more then 14dBm, only then switch to the PA mode.
And here is the next thing i could not find any explanation for are values in this commit: 9d38071

In the SX1272.cpp you set the values to:
if(useRfo) {
RADIOLIB_CHECK_RANGE(power, -1, 14, ERR_INVALID_OUTPUT_POWER);

Those are the values also for the SX1276,77,78,79 like written in the datasheet.

But in the same commit you are changing the SX1278.cpp to
if(useRfo) {
// RFO output
RADIOLIB_CHECK_RANGE(power, -3, 15, ERR_INVALID_OUTPUT_POWER);

Why are you selecting values outside the datasheet? -3 and +15 are both outside the values for the RFO mode.
For example the datasheet on Page 109 say at RegPaConfig (0x09) for PASelect that 0->RFO pin. Output power is limited to +14 dBm.

Based on my understandings, the PA_HF and PA_LF are those 2 additional antenna connectors on the SX127x developer boards from Semtech themself. Those are in general not found in ready products like a ttgo t-beam. Did i understand that correctly?

Maybe you have the number 15dBm for max RFO mode from page 83 at the datasheet where they talk about the PA_HF and PA_LF on RFO_HF or RFO_LF. There they talk about up to 15 dBm, but on the low side there they go to negative 4 dBm instead of the nehative 3 dBm you wrote in the code.

At summary: What i propose here based on my understandings that RFO is more efficient then PA:
Power values set between -1 and 14 are RFO, 15, 16, 17 and 20 dBm are used with PA_BOOST.

This would make this line functional:
int state = radio.beginFSK(434.0, 4.8, 5.0, 125.0, 1, 16, false);
But also this line should work as the lowest possible power that could be set on a SX127x:
int state = radio.beginFSK(434.0, 4.8, 5.0, 125.0, -1, 16, false);

In general this should rise the efficiency and also the user friendliness not forcing users to have to deal with setOutputPower ( int8_t power, bool useRfo ) when they want to set values -1, 0 or 1 dBm for power.

[jgromes]

Lot to unpack here, so I will go step-by-step.

Now compile, upload to device and you see just error at serial output:
SX1278.cpp:299 and SX1278.cpp:58

You have not posted this error, but given the context, I will assume it is RADIOLIB_ERR_INVALID_OUTPUT_POWER. Though if it is not, it invalidates this entire conversation, so it would be good to have that checked.

This would make this part more user friendly when it should just work and the people do not care if its RFO or PA mode.

You very much need to care about that. SX127x have two possible RF output ports: RFO and PA_BOOST. If you send power into an unconnected port, you will burn the PA.

To my understanding of the datasheet of the SX127x is more efficient when using the RFO mode as long as possible and only when you need more then 14dBm, only then switch to the PA mode.

Again, you need to select the output that corresponds to your hardware. If you have antenna connected to the PA_BOOST output, you have no choice in the output stage. If you select RFO, you will send power to an unconnected pin.

And here is the next thing i could not find any explanation for are values in this commit:

That commit is more than 3 years old, so I really don't know. It is possible the ranges are off by 1.

Why are you selecting values outside the datasheet? -3 and +15 are both outside the values for the RFO mode.

The datasheet itself is inconsistent. See Table 33 at page 83:

Based on my understandings, the PA_HF and PA_LF are those 2 additional antenna connectors on the SX127x developer boards from Semtech themself. Those are in general not found in ready products like a ttgo t-beam.

I don't know, I haven't examined every single SX127x board in existence to determine which is more common. But I would not make this assumption. In my experience, Chinese manufacturers always chase the biggest numbers, because bigger number = good, so they select the version that allows them to put the highest output power into their product description. PA_BOOST in this case, since that allows them to claim +20 dBm output.

What i propose here based on my understandings that RFO is more efficient then PA

Probably, but that doesn't mean you are free to use it. If your board only has PA_BOOST output, you have to use that. That's why the setOutputPower allows you to force RFO usage and otherwise it uses PA_BOOST.

I went through the datasheets and you are correct in that the lower range of the SX1278 RFO should be -4 dBm and not -3. Other than that, your issue (I think) is that you are setting 1 dBm in begin which is not possible with PA_BOOST (as that is what's getting used by default). But nothing is preventing you from leaving in the default value (10 dBm), and then later call setOutputPower(1, true) to use RFO. If we were to change the default to use RFO instead of PA_BOOST, the problem would not go away, it would just flip - now users that want to use high power in begin would have issues.

[serialrf433]

Thanks! In the last days some tests have been done.
This is the typical SX1276

and there is the RF96 that is known to be sort of a SX1276 renamed chip

There is also an other PCB i plan to do measurements onto.

Both PCB designs above from the pictures have not connected pin 22 (RFO_HF) and not connected pin 28 (RFO_LF).

So yes, you are right. It wont be a good idea to have RFO output with max possible power (14 or 15 dBm) enabled by default.

But nothing is preventing you from leaving in the default value (10 dBm), and then later call setOutputPower(1, true) to use RFO.

I am interested now in the RFO output and because there are not that much available PCB's out there that make use of the RFO pins, i plan to solder a antenna cable to the pins to make some measurements.

If we were to change the default to use RFO instead of PA_BOOST, the problem would not go away, it would just flip - now users that want to use high power in begin would have issues.

I think my idea got misunderstood. But i would like to update my idea because of the new research.

Things can break when a relevant amount of RF is getting out from a unconnected pin. 1dBm and lower is not a relevant amount of RF and it does not matter that much if its connected to a antenna or not.

So my updated idea is:
Could you change the code that values from -4 to 20 are possible in
int state = radio.beginFSK(434.0, 4.8, 5.0, 125.0, 1, 16, false);
?

Values of 2 to 20 are PA_BOOST (like they are now, no change).
Values set 1 or lower are RFO and based on the frequency it takes the HF or the LF pin. Yes, they are in most cases not connected. But that wont hurt anything at such low rf values.

People who know that the RFO_LF or RFO_HF pins are connected to some antenna, can manually set higher power output with for example setOutputPower(12, true).

It would be great to have those 'RF-whisper' capabilities in the radio.begin() command. You can not break anything with 1dBm or lower without a connected antenna.

I plan to post some measurements with soldered antenna cable to RFO pin's and then connected to a lab equipment to find out what is getting out of the pins.

[jgromes]

OK, this took a bit more effort but I think I understand now. Essentially what was needed was to make the useRfo flag into forceRfo which is false by default and add some more logic. Now the SX127x::setOutputPower methods accept anything in the supported power range (-4 to +20 dBm for SX1278), and will automatically choose RFO output for +1 dBm or less (which is where the PA_BOOST range starts). Output when iterating over the entire -4 to +20 dBm range looks like this:

useRfo = 1 pwr = -4, 0
useRfo = 1 pwr = -3, 0
useRfo = 1 pwr = -2, 0
useRfo = 1 pwr = -1, 0
useRfo = 1 pwr = 0, 0
useRfo = 1 pwr = 1, 0
useRfo = 0 pwr = 2, 0
useRfo = 0 pwr = 3, 0
useRfo = 0 pwr = 4, 0
useRfo = 0 pwr = 5, 0
useRfo = 0 pwr = 6, 0
useRfo = 0 pwr = 7, 0
useRfo = 0 pwr = 8, 0
useRfo = 0 pwr = 9, 0
useRfo = 0 pwr = 10, 0
useRfo = 0 pwr = 11, 0
useRfo = 0 pwr = 12, 0
useRfo = 0 pwr = 13, 0
useRfo = 0 pwr = 14, 0
useRfo = 0 pwr = 15, 0
useRfo = 0 pwr = 16, 0
useRfo = 0 pwr = 17, 0
useRfo = 0 pwr = 18, -13
useRfo = 0 pwr = 19, -13
useRfo = 0 pwr = 20, 0

[serialrf433]

Awesome! At the same time you made this change, a hardware build was created like promised. The PA circuit on the board used was for 868Mhz. To be able to compare it at its best, that is why a SMA pigtail got soldered to the RFO_HF pin (and of course also the pigtailshield got connected to ground). Now the efficiency(PA vs RFO) at 868Mhz can be compared between both pins and this commit can be tested in detail.
The RFO_LF pin is still floating and i can also play around with this and thanks to one connected and one floating, i can check if the switch between HF and LF pin when using RFO rf output is working like it should.

The development speed of RadioLib is great. Its keeping the motivation up!