I have been developing a sensor and actuator network for a while now using HopeRF’s cheap RFM69 HW modules. These modules use the licence-free ISM and SRD frequency bands (433 MHz resp. 868 MHz) to send and receive packets and they cost around 5€ per module. HopeRF sells them in two different flavours: RFM69W and RFM69HW (RFM69CW and RFM69HCW also available in a different form factor).
The main difference between these two types is the maximum output power. While a RFM69W module can “only” output from -18 dBm to +13 dBm, the maximum output power of a RFM69HW module is +20 dBm (=100 mW). They are really great indoors because of their range and low attenuation compared to WIFI frequencies of >2 GHz.
There is a downside however: The datasheet is kind of… sketchy regarding some important information. Much better than the datasheet of the previous generation of RF modules (RFM12 for example), but still hard to understand in some parts. I will try to figure out the power level settings of +20 dBm RFM69HW modules in this post while comparing them to the regular RFM69W modules. Of course the datasheet contains information about setting the output power, but there are some ambiguities and contradictions. But more on that later…
First of all, it is worth noticing that the high power modules have two power amplifiers on board (PA1 and PA2). The regular RFM69W modules only have one power amplifier PA0. It is a fact that PA0 can only be used with the regular modules while the high power modules can only use PA1 and PA2, probably due to hardware components fitted/not fitted.
In order to set the output power of high power devices, you have to enable PA1 or PA1 together with PA2 first. Then you can set the power level in register 0x11 from 0 to 31. Depending on the enabled PA combination, you get two different relationships between power level (register value) and output power [dBm]. The following table (taken from the datasheet) gives an overview.
Sound easy, right? Well, it isn’t…
If you look at the power ranges and the formulas, you notice that (except for PA0) the OutputPower must have an offset of 16 for the formula to actually make sense and match the given power range. Later in the datasheet this is explained in a footnote: “Only the 16 upper values of OutputPower are accessible [if you use PA1 or PA1+PA2].” Okay, understood.
Then there is also another possibility: You can switch on the “high output power +20dBm settings” by writing special values in two registers. According to the datasheet you have to do this to really get the +20 dBm output power. Otherwise (with PA1+PA2 enabled) you “only” get +17 dBm. It would be interesting to know what really happens behind the curtains when these high power settings are enabled. Just by looking at the formula and power range, you notice a +3 dB difference between these settings. So maybe the output power is just doubled?
There is also another interesting plot in the datasheet:
Using PA0 with a RFM69HW module is pointless, you get no output. So the PA0 measurement results are probably made with a regular RFM69W module. It is also interesting that according to the curves you get around 2-3 dBm more output vs. programmed power if you only use PA1. Using PA1+PA2 the output power seems to be more precise. PA1+PA2 with high power settings is only used for output powers greater than +17 dBm. But looking at the table before, you could also go down to +5 dBm with this setting.
So let’s say we want to set an output power of +7 dBm. Which setting do we use? There are 3 possibilities (only PA1 enabled, PA1+PA2 and PA1+PA2 with +20 dBm high power settings). Does it matter which setting we use? What could be advantages or disadvantages?
Personally I use these modules in low power battery applications, so the amount of current consumption is interesting to me. I don’t want to have more output power than needed for a given range between sender and receiver. And I don’t want to consume more power while sending packets than I need because of battery life.
So to answer these questions I made an experiment. I put one RFM69HW module at the one end of my flat and another one at the other end, covering a distance of about 10 meters with some walls and doors between them. One module just receives packets and logs the RSSI value during reception. A STM32 controller fetches the packets and transmits them to my PC. The other module (also in connection with a STM32) is configured as a sender, it iterates over every register power level from 0 to 31 and every PA setting (that is: PA1 enabled, PA1+PA2 enabled and again both tests with +20 dBm high power settings enabled). During every iteration 5 packets are sent out in short intervals to average the results. Every packet payload contains the current power setting, so the receiver knows the current sender configuration and can correlate the measured RSSI value with the power setting. I repeated the same test with a regular RFM69W on the sender side to get results with PA0.
Another thing which interested me: What is the current consumption while sending these packets? Again, iterating over some (not all) power constellations, I switched on the unmodulated TX carrier and measured with an amperemeter. I may have violated the 1% duty cycle rule during this test, but it’s for a greater cause, right? 😉
Now to the results… I put all the received packets and RSSI values in a CSV file and produced an Excel sheet with some plots. There are a few surprises.
First let’s look at the measured RSSI value vs. power level (register value from 0 to 31):
The first surprise is that if using PA1 and PA2 together, you DO get output for power levels smaller than 16. An ascending power level from 0 to 15 leads to an ascending RSSI value, then it drops and again ascends from 16 to 31. This is a contradiction to the footnote saying that only the upper 16 values are accessible. At least that seems to be valid if only PA1 is enabled. I do not know what really happens for power levels <16, and since the datasheet kind of prohibits these values, I give them no further thought. It is interesting that PA1 with the highest power setting leads to an RSSI value which is comparable to that of the +20 dBm setting with PA1+PA2 enabled. PA1 with “+20 dBm high power settings enabled” (yellow) performs quite badly and this constellation is not even considered in the datasheet, so no further thoughts here either. Keep in mind that there are different output formulas for the PA constellations, so this plot may be confusing. PA1+PA2 vs. PA1+PA2 (HP) actually perform quite the same.
This plot here takes the different formulas into consideration:
Again, ignore the values of PA1+PA2 before the drop because these are the “forbidden” power levels from 0 to 15. You see that the curves of PA1+PA2 and PA1+PA2 (HP) nearly overlap except for the highest power settings. It is interesting that the highest power setting of PA1+PA2 leads to a greater RSSI than PA1+PA2 (HP). You can also see that the calculated output powers of PA1 do not match the ones of PA1+PA2 when the same RSSI value is considered. This confirms the plot of the datasheet as shown earlier. The experiment also confirms that using only PA1 you can get lower power settings than using PA1 and PA2 together. If you want to bridge only short distances, use RFM69W devices (only PA0) because you can reduce the output power significantly compared to the high power modules.
As earlier announced I also examined the current consumption of the RFM69 modules while sending with different power settings. Correlating these findings with RSSI values on the receiver end leads to the following plot:
To sum it up: PA1 (orange) seems to perform best and gives the best current vs. RSSI relation. PA1+PA2 and PA1+PA2 (HP) play in the same league but looking more carefully PA1+PA2 performs slightly better when looking at the current consumption. Only when output powers greater than +17 dBm are needed, PA1+PA2 (HP) should be used.
PA0 (RFM69W) looks quite disappointing compared to PA1 (RFM69HW) when the current consumption gets to around 25 mA: PA1 seems to be performing better. Of course the minimum current consumption is smaller in RFM69W modules because of their smaller minimum output power.
At last a plot showing the current consumptions vs. different calculated output power settings according to the formulas in the datasheet.
There are also the “forbidden” power levels from 0 to 15 included, so you can ignore those. PA1+PA2 and PA1+PA2 (HP) are nearly the same. PA1 is always some milliamperes below the other two PA constellations which of course is good. Considering the earlier findings where I said that the calculated output power is actually below the real output power (also according to the datasheet), this is even better.
So again my conclusion for now:
If you use RFM69HW modules, enable PA1 (and only PA1!) for output powers less than +13 dBm. Combine PA1 and PA2 for powers between +13 dBm and +17 dBm. And only if you need more power, use PA1+PA2 with high power settings to get more than +17 dBm.
RFM69HW modules seem to perform slightly better than regular RFM69W devices while keeping the output power constant. Since they only cost a little bit more, I would recommend these high power modules in nearly every application. Of course, if the distance between sender and receiver is only very small, go for RFM69W modules.
I developed a library written in C++ where these findings are taken into account. You can find the relevant blog post here.
If someone is interested in the raw data:
- Excel sheet with received packets, RSSI values and current consumption
- Excel sheet with current consumptions
That’s it for now. 😉
This is a very good summary. Thank you for posting! I do have one comment, however, and that pertains to your findings at the highest power levels. I suspect, given your results, that you did not have AGC disabled in the receiver (via RegLNA). Having AGC enabled (which is the default and is recommended) will tend to flatten the high end if the signal levels are strong enough and this would be the case with your test setup. In cases where I’ve run similar tests, I disabled AGC and set the receiver gain to -48dB to synthesize a large distance between receivers.
Again, good article, thank you for posting.
Thanks for your comment!
You are absolutely right. The AGC setting was not touched which means it was still enabled. That indeed would explain the flattened results in the high power region.
Kind regards,
André
Amazing work! You really did an extensive and hard work on testing the difference of both modules and operations modes. Thanks!
Regards,
Diego.
Andre, You mention about switching on unmodulated TX carrier. Is there an option for RF69 chips to do that directly?
Right now I am thinking on using packet mode with “unlimited” payload size in packet mode transmitting only zeroes or ones via SPI to disable/enable unmodulated carrier (remembering not to use any data whitening/Manchester).
This will allow not only power measurements but also a very simple antenna matching by checking the current drawn by the module.
Hi art,
yes you can absolutely do this directly.
Fortunately the chip supports OOK mode (on-off-keying) which is a special form of amplitude modulation. You can look it up in the datasheet.
To cut it short:
What you basically have to do is you switch from packet mode to continuous mode (without SYNC) and change the modulation type from FSK to OOK.
This will turn on/off the carrier according to the DIO2 pin state. If you force the DIO2 pin to HIGH (3.3V), the unmodulated carrier remains switched on.
You can also use my library or look into the source code if you want to know the right register settings. For example:
_rf->setMode(RFM69_MODE_STANDBY);
_rf->setFrequency(434000000); // 434,00 MHz
_rf->setPower(31); // +20dBm
_rf->setDataPin(RFM69HW_DATA_PORT, RFM69HW_DATA_PIN);
_rf->setOOKMode(true);
_rf->setDataMode(RFM69_DATA_MODE_CONTINUOUS_WITHOUT_SYNC);
// ...
// set DIO2 pin to HIGH
_rf->setMode(RFM69_MODE_TX); // turn interface on
Hope this helps!
Kind regards,
André
Thank You André.
I will have an opportunity to check the RF module behaviour with spectrum analyser. If anyone would be interested I can try to leave more information on this after it’s done. A quick scope revealed undesired side band transmission that I will have a closer look at soon. Also I have noticed a frequency shifted versus expected (register set values) of carrier. This may mean that Fstep=61Hz declared in datasheet is not necessarily an exact value.
BTW The internet does not seem to show too much information on so-to-speak “laboratory measured performance” of the module or I am a poor researcher. This makes Your post even more valuable.
Regards, art.
Correction: Fstep should be FOSC/2^16
2^19, Sorry for messing.
Hi art,
I and probably a lot of others would be very interested in your findings.
Concerning the exact value of the carrier frequency: You are right, the values given in the datasheet are typical values. I don’t know what specific crystal oscillator HopeRF uses (apart from the fact that the nominal frequency is 32 MHz) but since the modules are so cheap, I don’t think that the oscillator is very precise. Another thing would be the temperature dependency of the crystal which (probably) also has a great impact on the stability of the carrier frequency…
That’s why they implement methods like AFC (automatic frequency control).
Hi André.
I have few updates after calibrated laboratory measurements of RF module.
First of all the power emitted to radio channel is very poor for helical lambda/4 antenna. For programmed (and confirmed with peak detector on dummy resistor 50 Ohm load) 25mW/17dBm the laboratory says the module emits ERP -4.3 dBm (power measurement according to ETSI EN 300-220-2 and ETSI 301-489-3:2002).
Using the laboratory measured unit I try to reference other units experimenting with different antennas using one module as RSSI measurement: on tested units I switch to different antennas and switch on carrier. The RSSI measure is performed on one module which continuously restarts RX mode and sends RSSI_value (==-RSSI_value/2) via UART to PC – nicely “sees” the the transmitting unit has carrier switched on (while the noise figure in office/urban area is about -100..-95 dBm). Seems like the RSSI will not go higher than -26dBm even while connected to transmitter with coaxial cable (of course remembering not to exceed max. allowed RF input power) and this seems like an indicator limit not mentioned in any data sheet. For half meter distances I get approx. -40dBm RSSI on receiving unit. But still the RSSI value reacts very nice (i.e. realistic) while distances or angles are changed.
Never the less I still get 100m open space distance with this configuration which seems comparable to web-described experiments. I just do not want to agree loosing more than 20dB (17dBm vs -4.3dBm) right on the module-antenna-air path. I keep on working on the proper antenna match.
If I may ask You to try if You also get this -26dBm ceiling while doing RSSI measurements even with few centimetres distance I would be grateful for any feedback. Could You also check what RSSI reading You have with few of open space meters distance?
Let me know if I could supply You with any info useful for You.
Hi art,
thank you for reporting back! Very interesting findings. I agree, the loss of >20 dB is more than disturbing.
I did some tests as you requested, but my test setup is not ideal. I get a -33 dBm ceiling when two devices are placed beneath each other with only two wires of lambda/4 length as antennas.
With proper antennas I would probably also get closer to your -26 dBm ceiling. I cannot do open space experiments right now but I have placed two devices some meters apart in the house.
The RSSI reduces to around -52 dBm.
Good analysis… The RFM69 module is a great little toy! I normally design my projects to survive if 1% or 2% of messages are lost, so don’t need to implement message re-try neither use the highest TX power. Also interesting, this link show some current draining in different TX power modes: https://bitbucket.org/talk2/whisper-node-avr/overview
Interesting experiments. Somebody mentioned about impedance matching, so I wonder whether combining pa1 w pa2 yielded lower rssi and higher consumption due to increased antenna impedance mismatch…
Also, RFM69hw is avail for 868 MHz frequency range, where it’s not tested whether your conclusions for 433 MHz device are still valid.
Andre
Thanks for your work it has given me some good data for writing my power setting routine. I am curious though since you use these devices in battery powered setups if you have a sense of how to set the OCP trim. The data sheet says to make the appropriate adjustment when using high power but gives no indication on what appropriate levels are. Is this nothing more than staying below some specification dictated by the battery manufacturer?
Hi Mike,
I have not played with the OCP trim value yet, but you are right: it is used for protecting the battery powered setup.
Consider for example a battery which has a high output impedance… A short but powerful TX burst results in a surge current which might drop the battery voltage to a critical value which might reset the whole circuit/application.
Therefore it is wise to check the battery specification for values like output impedance or maximum drain current. Or just measure the battery voltage during transmissions with different power settings.
Kind regards,
André
Dear André,
well great article , thanks to share your tests !
i’m actually playing with an RFM69HW.
if i just setting x9F to RegPaLevel (0x11), then it work … with a small distance between TX and RX (maybe 5 meters), but i’m pretty sure that i have some trouble with my PCB antenna (un-matching).
that seem that only PA0 is enabled and output power is +13dBm.
so i don’t understand your advise when you say “using PA0 with RFM69HW is pointless, you get no output” (just after the figure 5)
ps : i notice this same advise on another blog or forum (can’t remember where exactly) …
but for me, that seem working !
do you have any news about this point since you write the article in 2015 ?
thanks, best regards
Phil
Hi Phil,
thanks for your comment.
Maybe my statement that “PA0 only with RFM69HW is pointless because there is no output” is not entirely correct but the outcome is quite the same. Using the boost option requires a special matching network which means that the internal PA_BOOST pin of the chip will be connected to the antenna during transmission. While receiving, the antenna is connected to the RFIO pin (which is also used for transmissions in the lower power RFM69W modules where PA_BOOST is left floating). There is actually really a switch which is used on the high power modules. You can also take a look at this fine reverse engineering approach, this should clarify things. You can see that only the PA_BOOST pin is connected to the antenna while TX is active.
Coming back to your findings… You have _some_ output (5 meters with +13dBm setting), but that’s very bad. You probably observe a parasitic effect where some wireless energy is transmitted via the PCB traces, which leads to the very small distance. I am sure that when you use PA1+PA2 with your module (or only PA0 with a RFM69W module), the transmission distances will be much better – assuming the antenna is matched correctly.
I hope that helps.
Kind regards,
André
Andre, thanks for your really fast reply !
concerning my poor distance with only PA0, i think i haded some code error, because now it’s working really better (even with my antenna not matched !)
my requirement is to set the best setting while consuming the less power (battery powered).
TX module may be placed near or far the RX side (but not moving, fixed location).
so i need the maximum flexibility possible.
if i limit to -2dBm, that may be in often too much !
boost option will be enable only on far module. in the best case, i would like to set the lower power level.
here it is a link where the guy say as you, that -18dBm is not possible with the RFM69HW : http://www.electrobob.com/rfm69-output-power/
he provide some interesting schematic !
and he say “This means that only PA1 and PA2 reach the antenna, and never PA0, during transmission.” …
more and more confuse on my side , because i’m sure that 0x9F in the RegPaLevel (0x11), is working !
so using only PA0 is possible !.. doing now some test with 0x80 in 0x11 register .. (that mean -18dBm with only PA0) => working (RX and TX are only 1 meter distance)!
if you have any more explanation .. do not hesitate !
best regards
Phil
Hi Phil,
I believe you and it actually does not surprise me that PA0 also works with the high power RFM69HW modules. But I don’t think that the efficiency is very good, but that of course depends on the use case. If PA0 with -18 dBm works in your configuration (with the small distance) and you get the lowest power consumption in this case, then nothing speaks against this usage.
If the schematic is correct (and I believe it is), then the PCB traces to the RFIO pin probably work as a small antenna which explains the low distance with the PA0 setting. But if it works in your set-up, then everything is OK. 🙂
Kind regards,
André
this article https://bitbucket.org/talk2/whisper-node-avr/overview
show that under -3dBm, the consummation don’t decrease proportionally… the current is more or less the same from -18dBm to -3dBm .. so maybe i will just allow stetting from -2 to +20dBm !
regards
Hi Andre,
I have RFM69HCW and I try to use it for replace TX6001.
RFM69HWC has a continuous mode and theoretically allows replacing the transmitter module TX6001. Can you write what parameters should be set and for which registers?
Hi Slawek,
I have not worked with the TX6001 yet, but looking at the datasheet, the RFM69 chip should be compatible in some parts. But only if the other application with the TX6001 uses the (slower) OOK mode.
OOK means “on-off-keying” which is a special form of ASK (amplitude shift keying). The former mode is also supported by the RFM69 chip, but the more general form ASK is AFAIK not possible with the RFM69.
You can check the code of my library for register details:
https://github.com/ahessling/RFM69-STM32
Look for the function RFM69::setOokMode to enable OOK mode. To set the continuous mode, see RFM69::setDataMode with option RFM69_DATA_MODE_CONTINUOUS_WITHOUT_SYNC.
Then you can use the DATA pin of the RFM69 module to send/receive modulated signals. The other registers can be found in the constant rfm69_base_config. You also have to adapt the carrier frequency to your needs, but you can also use a function of my library to help calculate the register values.
I hope that helps!
Kind regards,
André
Just spent a long time wondering why I was transmitting at such low levels with RFM69HCW. I finally realized that pa0 doesn’t exist on the H version and went from -100RSSI to -40 using pa1+pa2. I looked this up after to make sure someone else had written about this topic because it is really not clear from the datasheet given. Great journal! Thanks.