Usint the RFM69HW RF transceiver

First, is this the best place to discuss this device? I have an arduino uno and a mega each wired to a RFM69 transceiver. They do not communicate. I downloaded the software from the Sparkfun site that I thought should work. The software is relatively simple and demonstrates encryption, and Acknowledgement. The software compiles and loads and then the communication does not work.

Since the RFM69 does not have any debug capabilities that I know of, I am at a loss as to where to start. Is the problem the software, the RFM69 itself (either one of them), the wiring, that I have checked carefully or what.

Anybody here have experience with this device?

Are you using the board directly or the breakout version?

Have you accounted for the different voltage levels between the Arduinos and the RF69?

Are you using the correct SPI pins? They are not the same on an Uno and a Mega.

In general, if you're using example code as supplied then problems are usually in the circuit.

I am using the RFM69 on a breakout board from Sparkfun

The Arduino has a 3.3 volt pin tht I am using to power the RFM69. There is a wiring diagram on the hookup guide I am following.

I am following the hookup guide that shows the different pins I should be using for the Uno and the Mega.

I am using the sample code and have downloaded the RFM69 library and using the SPI library.

Everything compiles and loads with no errors on both the Uno and Mega.When the program starts it displays, "Node 1 ready" or "Node 2 ready" as expected. When I enter and send a short message, I get a display saying " Sending xxx" for example. Both units operate the same. No message is received at the other end.

I have ACK enabled. When I send, one would think I would get a "no ack received" very quickly. Sometimes I get it after a few seconds, maybe 15, and sometimes never. One would think this would be consistent and relatively quick even if the RFM is not working or even disconnected.

It seems like I will have to get out the oscope and start looking for signals.

You may have damaged both RF69 boards as the signal voltage is 3v3 and the Arduinos are using 5v0. I did not find in the spec sheet where the RF69 is 5v0 tolerant.

Also, the TX current is higher than the 3v3 pin can supply.

If both boards are working then you should get an Ack fail after the last retry.

I suggest the Adafruit breakout board since it has a 3v3 regulator with 5v0 input and level shifters for the logic pins.

Here’s the link to the 915MHz breakout. I would also recommend the SMA edge connector and one of the many commercial antennas.

The RFM hookup guide shows the RFM power supply connected to the 3.3v output of the Arduino and this is what I have done. I checked the voltages and they are correct. You are correct in that 5VDC is excessive and I have been careful not to exceed the 3.3 volt level.

My hookup guide shows using a 3 inch antenna and this is what I have done.

I have an arduino uno on one computer and an arduino mega on the other a few feet apart.

I see a clock signal of about 3 MHz. The clock is bursty in that I see 8 clocks in a 2 usec time then there is a pause of about 1 usec then another clock burst. I would have thought the clock would be continuous. Perhaps the clock is on when sending and is then turned on when an interrupt is received. It is a bit difficult to see what is going on with my scope.

I see action on the I and O pins of the RFM. The voltage swings are about 3.3 volts. I have also used an external power supply for the Arduino and there is no change in voltages.

The clock line only needs to be active when data is being transferred.

A 1/4 wave at 915MHz in free space is 3.23 inches. For an antenna, use 3.125 as there is a wire diameter effect that shortens the length.

The RF69 board draws up to 130mA at full power, 20dBm. The Uno and Mega2560 are only capable of 50mA on the 3v3 pin. Unless you drop your power level considerably, you will be overloading the 3v3 regulator. Watch the 3v3 line and see if it sags for a short time when tramsmitting.

It is also possible to overload the receiver by having too much power and too close a proximity. When I test my Adafruit boards, I use a 10dB SMA attenuator and eliminate the antenna.

Without a level shifter, a 3v3 signal from the RF69 to the Arduino will not guarantee a logic 1. The unknown range for an input is 0.25 * Vcc to 0.75 * Vcc. Usually, it works but not guaranteed.

Maybe I can set the power level much lower to reduce the power drain and the receiver overloading. In the RFM69.h are the statements..

virtual void setHighPower(bool onOFF=true); // has to be called after initialize() for RFM69HW
virtual void setPowerLevel(uint8_t level); // reduce/increase transmit power level

My setup example sets the power high.

What should I input instead of "uint8_t level" to set the level to say 0 dB or even less?

You can set the power to the lowest level. I'm working on my RF69 at this moment and have the following code. Put this in your setup() routine so you don't need to change the .H file.

    if( IS_RFM69HCW ) 
        radio.setHighPower();       // Only for RFM69HCW & HW!, comment out for low power !!!!!!!!!!!!
    radio.setPowerLevel( PWR_LVL ); // Power output ranges from 0 (5dBm) to 31 (20dBm), presently 0

You can use the RSSI number as an indicator and reduce power so that it reads to about -50

My example code sets the power level to high so I just added a line that set the power level lower as below...

radio.setHighPower(); // Always use this for RFM69HCW
radio.setPowerLevel(0); // I added this line to lower the power level

Unfortunately, this has not as yet solved my problem.
When I start up, I get...

Node 1 ready

Then I enter a few characters and get....

sending to node 2, message [qqqq]

Then nothing. I would expect to get a "noAck" . Sometimes when I wait long enough I get the message but not consistently.

I will continue to probe.

Swap the two RF69 boards and see if the problem moves with it.

I'm using the Adafruit board and the same example sketch and it worked first time.

I assume you have two copies of the IDE open and each with the appropriate sketch and monitoring the correct serial port.

I have swapped the boards and get the same results.

I am running the same IDE on both computers and the same ino software on both and using the same libraries as far as I can tell.

I assume that the RFMs are working in packet mode.
When I first start either module, the clk pin is quiet, the ss pin is high, the miso is low, and the mosi is high. There is no activity and this seems normal since I have not sent any data.

Oh, I disabled the Ack and Encrypt (I think) by setting the defines to false.

So now, I would expect to see a single burst of data at each send then the control lines should go quiet. Unfortunately this is not the case. I will have to investigate why this is happening. Also, the longer the message, the longer the ss line should be low. There is some problem here.

I hope I am using the correct libraries.

I downloaded the sample code from the Adafruit site. The code compiles and loads OK. But there is still something wrong. I will have to continue tomorrow.

The sketch and library may not correctly account for differences in pin numbers on the Mega. My setup uses Pro Minis at both ends. Temporarily change the Mega to an Uno or some other board using the 328P chip.

I have a Uno and a Mega. I think I have accounted for the pin differences at lest according to what I see in the documentation. Here is a puzzling item.

I have turned off the Ack and Encryption. So, if I send a message of say 10 characters, then I would expect a burst of about 10X8 + a few extra bitrs for a total of around 100 bits. So I would expect a single burst of data of about 100 X clock period or about 25 usec. This is not what I am getting. What I see on my scope is totally different.

When I first start the program, the clk, msio, mios, and ss lines are quiet. Once I sent any message there is activity that doesn't stop. This is the case on both units. So, this makes me think there is a software problem.

I will continue to investigate.

You could turn Ack back on but set the retries to a low value, say 2. The scope should then show only two bursts going out. Continuous activity would not make sense with Ack off as that should disable retries.

One suggestion is to search on the Sparkfun forum for problems with that particular breakout.

Another idea is to inspect the two boards with a magnifier as there may have been an assembly problem in that particular group.

I agree with whawt you say about using two acks.

Think about this. If the arduino were set to "no acks" then you could just remove the RFM and the software should work. One would expect to see the clock burst and data burst on the mosi and clk lines. The only input from the RFM that would not be there would be the interrupt line on D0. I don't know if this interrupt is a level or edge triggered interrupt so with no connection, there might be a continuous interrupt or not. The interrupt could be disabled by setting the D0 to either high or low. Now, what you see on the mosi and clk lines should be a burst that has a length depending on the message length.

I must admit that it is a bit fun trying to figure out what is going wrong.

Without the RFM connected, the initializing would fail so the behavior thereafter is unknown.

With only the sender connected and Ack set to false, you should still see outgoing data in accordance with the message. With Ack and retries set then the burst should be repeated that number of times.

I would also compare the wiring instructions from Sparkfun compared to Adafruit. A discrepancy would indicate a possible problem. I have two Adafruit units working with their wiring and example so that's at least a word of encouragement.

"Without the RFM connected, the initializing would fail so the behavior thereafter is unknown."
The way I understand the SPI interface, there is no feedback as to whether or not the RFM has received any initialization commands. For example, if the Arduino sends a "setHighPower" command, there is no feedback from the RFM to indicate that this has happened as far as I know. If there is a status check, then the Arduino software should say that communication with the RFM is bad and I don't think this will happen.

I think I am going to totally reinstall my RFM69 library. Maybe there is something wrong here. This is a long shot because the compilation always goes with no errors.

Get the latest from the Adafruit link. It's the RadioHead library which covers several types of radio boards.

Did you mention which IDE version your are using? I've used both V1.6.5-r5 and V1.6.9.