Using SparkFun's RFM69HCW and Bi-Directional Logic Level Converter with Teensy 3.2

Status
Not open for further replies.

bugeye60

Active member
Hello,

I'm a newbie that has successfully tinkered with a couple of simple projects until now - using Sparkfun's RFM69HCW radio module (915 MHz version).

I've followed the hookup guide and incorporated the Bi-Directional Logic Level Converter as prescribed. I am using SPI communication with the four available channels on the Bi-Directional Logic Level Converter.

Pin-outs are as follows:

Teensy 3.2 ---------- Converter ---------- RFM69HCW
VIN ----------------> HV
3.3V ---------------> LV
3.3V --------------------------------------> 3.3V
GND ---------------> GND (high)
GND ---------------> GND (low) -------> GND
CS (pin 10) --------> HV1
----------------------- LV1 ---------------> S (CS)
DOUT (pin 13) ----> HV3
----------------------- LV3 ---------------> I (MOSI)
DIN (pin 12) ------> HV4
---------------------- LV4 --------------> O (MISO)
SCK (pin 13) ------> HV2
----------------------- LV2 --------------> C (SCK)

I am using the SFE_RFM69HCW_example (text file attached) from LowPowerLab.com modifed for RFM69HCW in the SparkFun repository: https://github.com/sparkfun/RFM69HCW_Breakout. It references RFM69.h. I've copied the RFM69 folder that contains the .h, .cpp, and other files into my local Arduino/libraries folder.

From prior posts, I learned that RFM69.h needs modified, changing

From:
#define RF69_SPI_CS SS
To:
#define RF69_SPI_CS 10

From:
#define RF69_IRQ_PIN 2
To:
#define RF69_IRQ_PIN 0

The modified code (RFM69.h) is attached.

My initial problem is that although the sketch compiles without warnings or errors, nothing happens when it is loaded into the Teensy. The 'void setup()' portion of the sketch shows that the COM port should at least print the node number, but even that does not happen.

Thanks in advance for you help!
 

Attachments

  • RFM69HCW_Example_Sketch_Node1.txt
    4.9 KB · Views: 185
  • RFM69.h
    7.2 KB · Views: 185
Those bidirectional converters are terrible for SPI. Don't use them!

Teensy 3.2 and RFM69 are both 3.3V signals, so no converted is needed anyway.
 
Thank you, Paul - for the fast reply and recommendation! I'll remove the converter and report back. It will be nice to simplify the breadboard.

-Russ
 
I removed the bidirectional converters and now have the following connections:

Teensy 3.2 ---------- RFM69HCW
3.3V ---------------> 3.3V
GND ---------------> GND
CS (pin 10) -------> S (CS)
DOUT (pin 11) ----> I (MOSI)
DIN (pin 12) ------> O (MISO)
SCK (pin 13) ------> C (SCK)

(A wire antenna is also connected to each RFM69HCW board in the "A" pin.)

I still do not see the initialization messages from void setup() in the COM ports but the messages I attempt to send from one radio to the other are printed in the parent COM port. For example:

From the COM port for node #1 I attempt to send "test" to node #2. The COM port for node 1 shows:

sending to node 2: [test]
no ACK received :(

I can see the Teensy's LED light when the send is being attempted and before the 'no ACK' is printed. Node 2 never prints the message from node 1, so obviously the recipient node isn't receiving the message and also not acknowledging it.

I'm still using the attached (modified) RFM69.h file and the attached sketch.

Do you have any clues why the radios are not receiving the messages being sent? As mentioned before, I'm a newbie so perhaps I've missed something obvious.

Thanks,
Russ
 
Edit your setup to something like this to make sure Serial is online before printing so you can see your messages:
Code:
  Serial.begin(9600);
  while (!Serial && (millis ()  <= 8000))
  Serial.println("Hello World");
 
Thank you, defragster! Your two line addition enables me to see the see the "Hello World" statement and the "Node 1 ready" statement in the setup. (after adding a semicolon to the end of the 'while' statement)

I'm still open to suggestions on why the radios are not receiving the messages being sent. I suspect there is a problem in the library files.

-Russ
 
If it were me (and will be soon) as couple of days ago received two of these from Sparkfun to try out...

What I will do, is to first hook up the two boards and chips, make sure that my wire Antennae are of the correct length,

Then try out some simple test programs, to make sure hardware is working.

What I am planning on trying out first are some of the Example programs for the Radiohead library.
Radiohead->RFM69->rfm69_client and rm69_server to see if I can get the simple version working.

I would try something like that first with no AES or the like and see if the two talk to each other, then I know the hardware is working.

Then would go on to more advanced stuff, like the program you linked here.

Alternatively would look to simplify the current one, make sure both nodes have different IDs and that they are configured to talk to each other:
Code:
#define NETWORKID     0   // Must be the same for all nodes (0 to 255)
#define MYNODEID      1   // My node ID (0 to 255)
#define TONODEID      2   // Destination node ID (0 to 254, 255 = broadcast)
#endif
i.e. the MY node of each Teensy needs to be different and the TO for each needs to point to the others MY...
I would turn off encryption...

Good luck - Will be trying some of this out myself in the next few days!

Kurt
 
Some tips from my side:
  • If you have an SDR dongle (RTL2832U for example) you can use it to hear the data being sent, might help debugging.
  • If you disable the sequencer and put it into Tx mode, it should continuously emit the preamble.
  • Start with very short packets, the longer the more error prone the transmission will be.
  • Adding an electrolytic capacitor (for some more buffering) to the Teensy + RFM69 might help.
  • Reading the datasheet to have an idea of how the modules work can be useful.
  • When developing / working on new code; wire up the reset pin of the radio module and at the beginning of the setup function reset the radio module with this pin, This way modifications from your last program do not affect the new test.
Shameless plug: I wrote a library for this radio, but you're more likely to find answers to your questions for the more commonly used libraries... But the adapter board I made to attach the RFM69CW to the Teensy might be of interest to you.
These radios are very nice in my opinion, I hope they work well for you guys as well!

(Whoops, forgot to read carefully): As far as I can see the RFM69 library does not put the pin used for the IRQ signal into a certain pinmode. On Arduino I believe they start as inputs, but on the Teensy they start as disabled if I'm not mistaken; try putting pinMode(the_pin_you_use_as_irq, INPUT_PULLUP) in the setup.
 
Last edited:
Thanks for the help Kurt and iwanders. I do have the same network defined with two unique node numbers for the two radios. I also tried removing encryption and acknowledgement requests. However, the suggestion to step back and start more simply is definitely a good one. I'll also take a closer look at the datasheet to see if I can glean anything from it.

@iwanders:
Any suggestions for the capacitor size and implementation?
No worries about the plug and adapter board. I'm open to all suggestions.

Unfortunately I didn't have time to try anything new today, but should tomorrow. I'll report back what I learn...

-Russ
 
The SparkFun board looks to have a 10 uf cap in their schematic.

iwanders - thanks for sharing your tips and github link! I looked at github and remembered I bought a pair of HopeRF RFM95W LoRa Ultra Long Range that have the same castellated pinout, I may spend a couple bucks ($2.65) and order your two part PCB solution. Adafruit has a tutorial for their breakout of this rfm69 board.

From https://pcbs.io/ it is $2.65 with free shipping for 4 of each, turn around should be two weeks - supposed to be near a week after they get established. My first few orders all returned 6 boards - as they were making extras in case any failed.
 
This evening I tried using the code in the Adafruit tutorial referenced by defragster above. I commented out the LED/Blink lines since I'm using pin 13 as the clock. The transmitter appears to be transmitting ok, but my only signs of evidence are the "Sending Hello World" messages. The receiver prints the messages in the setup routine but then goes silent - no messages indicating receipt.

Don't know if it helps or not, but since I'm a newbie I've included a photo of the breadboard setup in case I've done something wrong there.

SparkFun_RFM69HCW.JPG

P.S. I have not tried *all* the suggestions above yet - not enough time in the day... (e.g. try putting pinMode(the_pin_you_use_as_irq, INPUT_PULLUP) in the setup)
 
Last edited:
@Bugeye60; About the capacitor, it does indeed look like it's already on board with Sparkfun's adaptor, so you should be alright there. Be sure to try setting the IRQ pin to input mode next time you work on this, because that is one of the major differences between Arduinos and Teensy 3 (see,this comment by Paul)

@Defragster: Cool! I didn't know those LoRa modules had the same pinout. I'm eager to hear about your experiences with those radios.
 
...
@Defragster: Cool! I didn't know those LoRa modules had the same pinout. I'm eager to hear about your experiences with those radios.

After browsing this thread and recognizing the device and seeing your adapter - I was excited to see matching pinout as well! eBay gave me a coupon if I spent money - and I wanted something to reach 500+ feet to my mailbox. I got them and stowed them - your adapter will make it easier to power them up when I get time. $2.65 for 8 boards shipped free seemed crazy so I held off on the order to see if there are other boards I might want to order. I've placed 3 orders now to https://pcbs.io/ and they look good so far.
 
Any luck yet?

FYI - Today, I hooked up my Sparkfun RFM69 (I don't believe HP), with one hooked up to T3.2 and the other hooked up to T3.5 beta board.
I am using default wiring:
+3.3 -> 3.3v
G -> GND
0 -> Digital 2
R -
S - 10
C - 13
I - 11
O - 12

In the RADIOHEAD example programs (rfm69_server and rfm69_client) test programs, I edited slightly to first wait a bit of time for Serial port.
I also edited frequency to be 915 in both programs.

I ran two different instances of arduino, such that I could have two Terminal windows open and in one:
Code:
got request: Hello World!
Sent a reply
got request: Hello World!
Sent a reply
got request: Hello World!
Sent a reply
...

In other window:
Code:
got reply: 
Sending to rf69_server
got reply: And hello back to you
Sending to rf69_server
got reply: And hello back to you
Sending to rf69_server
got reply: 
Sending to rf69_server
got reply: And hello back to you
Sending to rf69_server
got reply: 
Sending to rf69_server
got reply: 
Sending to rf69_server
got reply: 
Sending to rf69_server
got reply: And hello back to you
So I know that it at last works. Note: sometimes I find I need to restart the program... May now have to try other library.
 
Hello, thanks to each of you for continuing to post. So far I've had no luck, but feel a little dumb too. After reviewing KurtE's wiring I realized that I didn't have the interrupt pins hooked up! So now my wiring is exactly like KurtE's. I am using two Teensy 3.2s with two RFM69HCW boards.

I also added pinMode(2, INPUT_PULLUP); to my setup per iwander's guidance.

In my list of RADIOHEAD example programs I do not have rfm69_server or rfm69_client. Instead, I have rf69_server and rf69_client.

The workflow I'm using is:

Start an Arduino 1.6.8 instance with sketch my_rf69_server.
Plug a USB into Teensy #1.
Compile the server sketch.
Program Teensy #1.
Open the serial port (COM5) and read:
Code:
Hello World
rf69_server set up complete.

Start a new Arduino 1.6.8 instance with sketch my_rf69_client.
Plug a USB into Teensy #2.
Compile the client sketch.
Program Teensy #2.
Open the serial port (COM4) and read:
Code:
Hello World
rf69_client set up complete.
Sending to rf69_server

I've copied my sketches below:
Server:
Code:
// rf69_server.pde
// -*- mode: C++ -*-
// Example sketch showing how to create a simple messageing server
// with the RH_RF69 class. RH_RF69 class does not provide for addressing or
// reliability, so you should only use RH_RF69  if you do not need the higher
// level messaging abilities.
// It is designed to work with the other example rf69_client
// Demonstrates the use of AES encryption, setting the frequency and modem
// configuration.
// Tested on Moteino with RFM69 http://lowpowerlab.com/moteino/
// Tested on miniWireless with RFM69 www.anarduino.com/miniwireless

#include <SPI.h>
#include <RH_RF69.h>

// Singleton instance of the radio driver
RH_RF69 rf69;

void setup() 
{
  Serial.begin(9600);

  // Start of my additions:
  while (!Serial && (millis() <= 8000));
  Serial.println("Hello World");
  pinMode(2, INPUT_PULLUP);
  Serial.println("rf69_server set up complete.");
  // End of my additions

  if (!rf69.init())
    Serial.println("init failed");
  // Defaults after init are 434.0MHz, modulation GFSK_Rb250Fd250, +13dbM
  // No encryption
  if (!rf69.setFrequency(433.0))
    Serial.println("setFrequency failed");

  // If you are using a high power RF69, you *must* set a Tx power in the
  // range 14 to 20 like this:
  rf69.setTxPower(14);  // I uncommented this line.

 // The encryption key has to be the same as the one in the client
  uint8_t key[] = { 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08,
                    0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08};
  rf69.setEncryptionKey(key);
  
#if 0
  // For compat with RFM69 Struct_send
  rf69.setModemConfig(RH_RF69::GFSK_Rb250Fd250);
  rf69.setPreambleLength(3);
  uint8_t syncwords[] = { 0x2d, 0x64 };
  rf69.setSyncWords(syncwords, sizeof(syncwords));
  rf69.setEncryptionKey((uint8_t*)"thisIsEncryptKey");
#endif
}

void loop()
{
  if (rf69.available())
  {
    // Should be a message for us now   
    uint8_t buf[RH_RF69_MAX_MESSAGE_LEN];
    uint8_t len = sizeof(buf);
    if (rf69.recv(buf, &len))
    {
//      RF69::printBuffer("request: ", buf, len);
      Serial.print("got request: ");
      Serial.println((char*)buf);
//      Serial.print("RSSI: ");
//      Serial.println(rf69.lastRssi(), DEC);
      
      // Send a reply
      uint8_t data[] = "And hello back to you";
      rf69.send(data, sizeof(data));
      rf69.waitPacketSent();
      Serial.println("Sent a reply");
    }
    else
    {
      Serial.println("recv failed");
    }
  }
}

Client:
Code:
// rf69_client.pde
// -*- mode: C++ -*-
// Example sketch showing how to create a simple messageing client
// with the RH_RF69 class. RH_RF69 class does not provide for addressing or
// reliability, so you should only use RH_RF69  if you do not need the higher
// level messaging abilities.
// It is designed to work with the other example rf69_server.
// Demonstrates the use of AES encryption, setting the frequency and modem 
// configuration
// Tested on Moteino with RFM69 http://lowpowerlab.com/moteino/
// Tested on miniWireless with RFM69 www.anarduino.com/miniwireless

#include <SPI.h>
#include <RH_RF69.h>

// Singleton instance of the radio driver
RH_RF69 rf69;

void setup() 
{
  Serial.begin(9600);

  // Start of my additions:
  while (!Serial && (millis() <= 8000));
  Serial.println("Hello World");
  pinMode(2, INPUT_PULLUP);
  Serial.println("rf69_client set up complete.");
  // End of my additions
  
  if (!rf69.init())
    Serial.println("init failed");
  // Defaults after init are 434.0MHz, modulation GFSK_Rb250Fd250, +13dbM
  // No encryption
  if (!rf69.setFrequency(433.0))
    Serial.println("setFrequency failed");

  // If you are using a high power RF69, you *must* set a Tx power in the
  // range 14 to 20 like this:
  rf69.setTxPower(14);  // I uncommented this line.

  // The encryption key has to be the same as the one in the server
  uint8_t key[] = { 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08,
                    0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08};
  rf69.setEncryptionKey(key);
}


void loop()
{
  Serial.println("Sending to rf69_server");
  // Send a message to rf69_server
  uint8_t data[] = "Hello World!";
  rf69.send(data, sizeof(data));
  
  rf69.waitPacketSent();
  // Now wait for a reply
  uint8_t buf[RH_RF69_MAX_MESSAGE_LEN];
  uint8_t len = sizeof(buf);

  if (rf69.waitAvailableTimeout(500))
  { 
    // Should be a reply message for us now   
    if (rf69.recv(buf, &len))
    {
      Serial.print("got reply: ");
      Serial.println((char*)buf);
    }
    else
    {
      Serial.println("recv failed");
    }
  }
  else
  {
    Serial.println("No reply, is rf69_server running?");
  }
  delay(400);
}

Obviously the two radios are not talking to one another yet nor do I get any timeout messages.

Couple of questions:
Do I need to modify the RH_RF69.h file in any manner?
Do I need to modify "if (!rf69.setFrequency(433.0))" to be 915 instead of 433?
Any other suggestions??

Thank you...
 
I have not looked at these yet - they have I/O right ? Can you talk T_3.2 to a module and power an LED on an I/O pin to know you have the unit wired and talking right? I don't see ready examples for that? ADA says: "The radio's have another 5 GPIO pins that can be used for various notifications or radio functions. These aren't used for the majority of uses but are available in case you want them! "

SFUN NOTES:
IMPORTANT: You MUST attach an antenna to the board. Aside from not working without an antenna, transmitters can be damaged if they transmit without an antenna present.
-Adafruit actually provides suggested antenna length

I'm paging down the linked Adafruit setup page - code and 'Sertup' - I don't see a radio reset in your code?

The radio Hz is a legal compliance issue - as noted on Adafruit:
Uses the amateur or license-free ISM bands: 433MHz is ITU "Europe" license-free ISM or ITU "American" amateur with limitations. 900MHz is license free ISM for ITU "Americas"
So AFAIK in the US 900 band is free for unlicensed usage - 433MHz is a license required freq when transmitting.

SparkFun has a note about this with more detail : very roughly, 915 MHz is for use in the Americas and Australia, and the 434 MHz version is for use in Europe, Asia and Africa.
 
They generate their own freq - but the range is by the crystal attached (table p#12)- didn't read much of RFM69HCW datasheet but after the PLL notes p#16 says:
monitor the signal CLKOUT which will only be made available on the output buffer when a stable XO oscillation is achieved

This might be a way to see sign of life after reset and waiting for it to come online (uses more power)- but it isn't brought to a pin unless:
3.2.2. CLKOUT Output
The reference frequency, or a fraction of it, can be provided on DIO5 by modifying bits ClkOut in RegDioMapping2.

Does the library provide device commands for adjusting the mapping or reading the temp or anything to see it talk?

p#75 discusses reset. Last page #79 will let you confirm your 2 modules are freq compatible.
 
I have not looked at these yet - they have I/O right ? Can you talk T_3.2 to a module and power an LED on an I/O pin to know you have the unit wired and talking right? I don't see ready examples for that? ADA says: "The radio's have another 5 GPIO pins that can be used for various notifications or radio functions. These aren't used for the majority of uses but are available in case you want them! "
In theory this would indeed be possible... but imax (page 15) specifies 1mA, so you would hardly be able to see that the LED is lighted or not. In addition; even though one could probably create some register setting to create a constant output, perhaps reading the value of one of the registers after reset is better? to check whether that corresponds to the values they should be after power-on. More on this later...

I also added pinMode(2, INPUT_PULLUP); to my setup per iwander's guidance.
I thought we were using the LowPowerLabs library... I just checked, this line is already in the RadioHead library's init method, so you can leave this out :)

Do I need to modify "if (!rf69.setFrequency(433.0))" to be 915 instead of 433?
Yes, you will need to modify this. You can set the registers to any frequency output, even outside of the frequency band the actual module you use can create. So do modify this to match the frequency of modules you bought.

Does the library provide device commands for adjusting the mapping or reading the temp or anything to see it talk?
It does.. temperatureRead(), but perhaps the printRegisters() method is more suitable. Bugeye60, could you call the printRegisters method and check / post the output? It should definitely not be all zeroes... :)

p#75 discusses reset.
Yes, I recommend using that at the begin of your setup function, it is highly recommended by me as I've seen the radio module not having the right register settings after power on without it. Please connect the reset from the module to any of the digital pins on the Teensy and use it to reset the module, for example with the following function:
Code:
 void bareRFM69_reset(uint8_t pin){ // function to send the RFM69 a hardware reset.
    // p 75 of datasheet;
    pinMode(pin, OUTPUT);
    digitalWrite(pin, HIGH);
    delayMicroseconds(150); // pull high for >100 uSec
    pinMode(pin, INPUT); // release
    delay(10); //  wait 10 milliseconds before SPI is possible.
}
Be sure to do that reset at the very top of your setup, before the init method.
 
In theory this would indeed be possible... but imax (page 15) specifies 1mA, so you would hardly be able to see that the LED is lighted or not. In addition; even though one could probably create some register setting to create a constant output, perhaps reading the value of one of the registers after reset is better? to check whether that corresponds to the values they should be after power-on. More on this later...
...

Nice info - the output could go to a Teensy Pin if not an LED ... but reading the registers might be better.

Hopefully the provided valid reset will make it work.
 
Wow, you guys are great! I will try to implement suggestions later today and report back.

Note regarding RadioHead vs LowPowerLabs: I took an earlier suggestion to start simple and followed KurtE's RadioHead lead in an attempt to get out of the starting gate.

Thanks for all the help. I'll report back...
 
I am following this thread closely, as I am in the same situation for the most part. I grabbed 2 RFM69HCW boards off Digikey, and initially tried with one wired up to a T-LC and the other into a 5V pro-mini using a self made LL converter and buck converter. I was seeing the same issues you are and thought my adapter wasn't working as planned ( Bummer, as that CL-2025 chip was a bear). I made a trip to MicroCenter and ended up with another T-LC and a Adafruit feather 32u4 with a 900MHz rfm69 on it. I was worried the LC didn't have enough power for the transmitter, so I ran the RFM off a power supply @3.3V. That meant I had 3 wired up, with the 32u4 running a slightly different code, but all on the same network with different nodes.
The outcome was the same, but with the 32u4 transmitting a continuous "Hello world" with increment count, the LC received just fine. There was no RFM reset on the LC's and no additional line added for the IRQ. However, when the code was modified to receive packets on the 32u4, I got the same results as the OP. All 3 say the sent to node "x", but no ACK received. I did notice that the 32u4 has a slight delay between sending and "no ack", perhaps a second, while with the 2 LC's, there is virtually no delay between sending and "no ack"
This might jog a thought in someones head, but not mine. I'm new to this stuff. The last time I tried writing code was on a Commodore Vic-20. It didn't go over so well.
 
Sorry for the long radio silence (pun intended) from me. I've only now gotten a chance to try the suggestions. Unfortunately I still have no positive results to report, but I have implemented some suggestions and am looking for more.

Suggestions I implemented:
  • Commented out the pinMode(pin, INPUT_PULLUP); line per iwanders since I switched to RadioHead.
  • Connected the reset pin on the radio to digital pin 6 on Teensy 3.2 (both client and server boards)
  • Added reset coding to the top of the setup for both server and client
  • Changed frequency in the setup code from 433.0 to 915.0 to correspond to the RFM69HCW I'm using.

(By the way, I do have a 78 mm long wire antenna connected to each board.)

Here's my current rf69_server code:
Code:
// rf69_server.pde
// -*- mode: C++ -*-
// Example sketch showing how to create a simple messageing server
// with the RH_RF69 class. RH_RF69 class does not provide for addressing or
// reliability, so you should only use RH_RF69  if you do not need the higher
// level messaging abilities.
// It is designed to work with the other example rf69_client
// Demonstrates the use of AES encryption, setting the frequency and modem
// configuration.
// Tested on Moteino with RFM69 http://lowpowerlab.com/moteino/
// Tested on miniWireless with RFM69 www.anarduino.com/miniwireless

#include <SPI.h>
#include <RH_RF69.h>

// Singleton instance of the radio driver
RH_RF69 rf69;

void setup() 
{
  // Perform a hardware reset per iwanders.  The reset pin on the RFM69HCW is set to Teensy 3.2 digital pin 6
  pinMode(6, OUTPUT);
  digitalWrite(6, HIGH);
  delayMicroseconds(150);  // pull high for > 100 uSec
  pinMode(6, INPUT); //release
  delay(10); // wait 10 milliseconds before SPI is possible
  // end of reset

  Serial.begin(9600);

// Previously added delay may be unnecessary now:
  while (!Serial && (millis() <= 8000));
  Serial.println("Hello World");
//  pinMode(2, INPUT_PULLUP);  // Removed per iwanders
  Serial.println("rf69_server set up complete.");
  // End of my addition

  if (!rf69.init())
    Serial.println("init failed");
  // Defaults after init are 434.0MHz, modulation GFSK_Rb250Fd250, +13dbM
  // No encryption
  if (!rf69.setFrequency(915.0))  // Changed original line from 433.0 to 915.0
    Serial.println("setFrequency failed");

  // If you are using a high power RF69, you *must* set a Tx power in the
  // range 14 to 20 like this:
  rf69.setTxPower(14);  // I uncommented this line.

 // The encryption key has to be the same as the one in the client
  uint8_t key[] = { 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08,
                    0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08};
  rf69.setEncryptionKey(key);
 
#if 0
  // For compat with RFM69 Struct_send
  rf69.setModemConfig(RH_RF69::GFSK_Rb250Fd250);
  rf69.setPreambleLength(3);
  uint8_t syncwords[] = { 0x2d, 0x64 };
  rf69.setSyncWords(syncwords, sizeof(syncwords));
  rf69.setEncryptionKey((uint8_t*)"thisIsEncryptKey");
#endif


}

void loop()
{
  if (rf69.available())
  {
    // Should be a message for us now   
    uint8_t buf[RH_RF69_MAX_MESSAGE_LEN];
    uint8_t len = sizeof(buf);
    if (rf69.recv(buf, &len))
    {
//      RF69::printBuffer("request: ", buf, len);
      Serial.print("got request: ");
      Serial.println((char*)buf);
//      Serial.print("RSSI: ");
//      Serial.println(rf69.lastRssi(), DEC);
      
      // Send a reply
      uint8_t data[] = "And hello back to you";
      rf69.send(data, sizeof(data));
      rf69.waitPacketSent();
      Serial.println("Sent a reply");
    }
    else
    {
      Serial.println("recv failed");
    }
  }
}

Here's my current rf69_client code:
Code:
// rf69_client.pde
// -*- mode: C++ -*-
// Example sketch showing how to create a simple messageing client
// with the RH_RF69 class. RH_RF69 class does not provide for addressing or
// reliability, so you should only use RH_RF69  if you do not need the higher
// level messaging abilities.
// It is designed to work with the other example rf69_server.
// Demonstrates the use of AES encryption, setting the frequency and modem 
// configuration
// Tested on Moteino with RFM69 http://lowpowerlab.com/moteino/
// Tested on miniWireless with RFM69 www.anarduino.com/miniwireless

#include <SPI.h>
#include <RH_RF69.h>

// Singleton instance of the radio driver
RH_RF69 rf69;

void setup() 
{
  // Perform a hardware reset per iwanders.  The reset pin on the RFM69HCW is set to Teensy 3.2 digital pin 6
  pinMode(6, OUTPUT);
  digitalWrite(6, HIGH);
  delayMicroseconds(150);  // pull high for > 100 uSec
  pinMode(6, INPUT); //release
  delay(10); // wait 10 milliseconds before SPI is possible
  // end of reset

  Serial.begin(9600);

// Previously added delay may be unnecessary now:
  while (!Serial && (millis() <= 8000));
  Serial.println("Hello World");
//  pinMode(2, INPUT_PULLUP);  // Removed per iwanders
  Serial.println("rf69_client set up complete.");
  // End of my additions
  
  if (!rf69.init())
    Serial.println("init failed");
  // Defaults after init are 434.0MHz, modulation GFSK_Rb250Fd250, +13dbM
  // No encryption
  if (!rf69.setFrequency(915.0))  // Changed original line from 433.0 to 915.0
    Serial.println("setFrequency failed");

  // If you are using a high power RF69, you *must* set a Tx power in the
  // range 14 to 20 like this:
  rf69.setTxPower(14);  // I uncommented this line.

  // The encryption key has to be the same as the one in the server
  uint8_t key[] = { 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08,
                    0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08};
  rf69.setEncryptionKey(key);
}


void loop()
{
  Serial.println("Sending to rf69_server");
  // Send a message to rf69_server
  uint8_t data[] = "Hello World!";
  rf69.send(data, sizeof(data));
  
  rf69.waitPacketSent();
  // Now wait for a reply
  uint8_t buf[RH_RF69_MAX_MESSAGE_LEN];
  uint8_t len = sizeof(buf);

  if (rf69.waitAvailableTimeout(500))
  { 
    // Should be a reply message for us now   
    if (rf69.recv(buf, &len))
    {
      Serial.print("got reply: ");
      Serial.println((char*)buf);
    }
    else
    {
      Serial.println("recv failed");
    }
  }
  else
  {
    Serial.println("No reply, is rf69_server running?");
  }
  delay(400);
}

Results of the radio reset pin connection to pin 6 and the revised code above is still only:
Server, COM5:
Code:
Hello World
rf69_server set up complete.

and Client, COM4 (same computer):
Code:
Hello World
rf69_client set up complete.
Sending to rf69_server

At one point I did receive the message "No reply, is rf69_server running?" but was unable to duplicate it again. As KurtE mentioned previously, once in a while the COM port in which I expect to see the server message prints the client message, or vice versa. When debugging I usually unplug the USBs from both boards, connect the server and program it first, and then connect the client and program it second. Is this recommended procedure?

@iwanders: What is the correct way to include the printRegisters() method? For a start, I inserted rf69.printRegisters(); in the setup after line rf69.setEncryptionKey(key); and then attempted to compile. I received an error stating 'Class RH_RF69' has no member named 'printRegisters'.

@iwanders: You mentioned that the line pinMode(pin, INPUT_PULLUP) is in the RadioHead library's init method and therefore I don't need to include it in my setup. Since I'm new to this, would you please tell me specifically where I should find it?

Where exactly should the RH_RF69.h code be located? I found it on my machine in directory
C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\RadioHead\

The first time I compile the sketches, I receive the warning messages below. When I subsequently compile the same sketch in the same window again, I receive no warnings. Is this something I need to be concerned about?
Code:
C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\RadioHead\RHSoftwareSPI.cpp: In member function 'virtual void RHSoftwareSPI::begin()':

C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\RadioHead\RHSoftwareSPI.cpp:114:13: warning: variable 'delayCounts' set but not used [-Wunused-but-set-variable]

     uint8_t delayCounts;

             ^

C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\RadioHead\RHSoftwareSPI.cpp: In member function 'void RHSoftwareSPI::delayPeriod()':

C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\RadioHead\RHSoftwareSPI.cpp:162:39: warning: 'count' is used uninitialized in this function [-Wuninitialized]

     for (volatile uint8_t count; count<_delayCounts; count++)

                                       ^

C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\RadioHead\RH_ASK.cpp: In member function 'void RH_ASK::timerSetup()':

C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\RadioHead\RH_ASK.cpp:161:14: warning: unused variable 'nticks' [-Wunused-variable]

     uint16_t nticks; // number of prescaled ticks needed

              ^

C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\RadioHead\RH_ASK.cpp:162:13: warning: unused variable 'prescaler' [-Wunused-variable]

     uint8_t prescaler; // Bit values for CS0[2:0]

             ^


Sketch uses 24,600 bytes (9%) of program storage space. Maximum is 262,144 bytes.
Global variables use 4,960 bytes (7%) of dynamic memory, leaving 60,576 bytes for local variables. Maximum is 65,536 bytes.

Is there anything inside the RH_RF69.cpp or RH_RF69.h that I need to modify?

Considering tinman's statement about power, do I need to worry about having enough power from the 3.3V pin of the Teensy 3.2?
 
Considering tinman's statement about power, do I need to worry about having enough power from the 3.3V pin of the Teensy 3.2?
There is another new thread that had issues with the RFM and it has since been resolved. DavidThings was using a T3.2 and his issues came down to a couple code issues, which he said is resolved now. That leads me to believe the 3.3 is enough for the transmitter, but it would be nice to find out how much power it is good for.
You might check his thread and try his corrected code and see if your setup comes to life. I know I am going to.
 
@iwanders: What is the correct way to include the printRegisters() method? For a start, I inserted rf69.printRegisters(); in the setup after line rf69.setEncryptionKey(key); and then attempted to compile. I received an error stating 'Class RH_RF69' has no member named 'printRegisters'.
@iwanders: You mentioned that the line pinMode(pin, INPUT_PULLUP) is in the RadioHead library's init method and therefore I don't need to include it in my setup. Since I'm new to this, would you please tell me specifically where I should find it?
Where exactly should the RH_RF69.h code be located? C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\RadioHead\
Okay, I believe I have found a possible culprit... The hint was that the printRegisters() method is not available and the path you linked... The printRegisters functions is documented in the docs.... Somehow it is missing... so I checked which version is in the Teensy installation by default, that is version:
Code:
RadioHead.h,v 1.30 2014/07/01 01:23:58
Which matches with Paul's github mirror of the library at that same version. The newest version is at v1.60 and can be downloaded manually from the radiohead website.

One of the causes of this is probably that the developer of RadioHead doesn't use git and Paul has to retrieve new versions by hand instead of having the option of automatically pulling the newest version from a git repo. (Besides this, I wonder if any changes / additions / pull requests from contributors other than the original developer are actually in RadioHead, because the combination of dual licensing, GPL and contributors sounds like a legal minefield to me...). @PaulStoffregen, perhaps it's a good idea to update the RadioHead library, or perhaps remove it from the default Teensy installation now that the official RadioHead changelog seems to mention quite some Teensy specific changes.

Either way, perhaps the difference in library versions has been the culprit all along? I'm not sure about this really, I've never used RadioHead, I'm just trying to help out and get the RFM69 running ^_^.
 
Status
Not open for further replies.
Back
Top