Problem using RFM69HCW with a YUN (Generation 1) using SS on D9

Wireless & IoT
1

I have the SparkFun RFM69 Breakout working on two Arduino Unos using this guide: https://learn.sparkfun.com/tutorials/rf … w-it-works

Now I want to add a third node using an Arduino Yun Generation 1, but I can only barely get it working.

One problem is that the header pins IO10-13 in the ATmega324U are not mapped to SPI. The only place I can access the SPI lines is from the ICSP header.

A second problem is that for SS I am using port 9 because for some reason IO 10 (the default SS on the RFM69 library) doesn’t work (even though this pin seems to be totally free on the Yun (i.e. nothing to do with SPI SS)).

Here is the schematic for the Yun: https://www.arduino.cc/en/uploads/Main/ … ematic.pdf

And this is the reference one for Uno: https://www.arduino.cc/en/uploads/Main/ … ematic.pdf

To solve that problem I just subclassed the lib like so:

RFM69_YUN.h

#include <RFM69.h>

#define RF69_SPI_CS_YUN             9

class RFM69_YUN : public RFM69 {
  public:
    RFM69_YUN(uint8_t slaveSelectPin=RF69_SPI_CS_YUN, uint8_t interruptPin=RF69_IRQ_PIN, bool isRFM69HW=false, uint8_t interruptNum=RF69_IRQ_NUM) :
    RFM69(slaveSelectPin, interruptPin, isRFM69HW, interruptNum)
    {
    }
};

Using this works but everything is like in slow motion, not sure if it’s related to my class extension above (I don’t think so, but comments welcome!)

The problem seem to be that the code running on the ATmega32U is running so slow that radio.sendWithRetry is not able to receive the ACK. Here is some example debug output from both nodes. Node 1 is the Yun and Node 2 is a plain old Uno (FYR I have the same test between 2 Unos and ACK works perfectly):

Node 1 debug output

sending to node 2, message [HELLOW WORLD]
no ACK received
TX LED
sending to node 2, message [HELLO WORLD]
no ACK received
TX LED
sending to node 2, message [HELLO WORLD]
no ACK received
TX LED

Node 2 debug output

Node 2 ready
received from node 1, message [HELLOW WORLD], RSSI -25
ACK sent
received from node 1, message [HELLO WORLD], RSSI -32
ACK sent
received from node 1, message [HELLO WORLD], RSSI -25
ACK sent
received from node 1, message [HELLO WORLD], RSSI -20
ACK sent

I think the main reason is that it all seems to be running VERY slow on the ATmega32U. From the time I call radio.sendWithRetry from the YUN side, it takes about 1 second or more to see the LED on Node 2. I’m running the demo code from the RFM69 tutorial.

The main question is, does anyone have any idea why the code seems so slow on the ATmega32U? I have a guess that it’s something to do with SPI conflicting somehow but looking at the schematics it seems that only

TIA,

ALex

2

Here are some timings. It’s taking about 3 seconds to return radio.sendWithRetry to return:

Node 1 ready
sending to node 2, message [HELLO WORLD] 86024
no ACK received 89253 (3229)
TX LED
sending to node 2, message [HELLO WORLD] 108647
no ACK received 111873 (3226)
TX LED
sending to node 2, message [HELLO WORLD] 118424
no ACK received 121653 (3229)
TX LED
3

Here is some additional information. It turns out that the problem is that Node 1 (the Yun node) does not receive at all! I took the radio circuitry and tested on another Uno and works perfectly, but when on the Yun it does not receive. I hacked a version of sendWithRetry to do some internal timings (besides uncommenting some debug timings that I found in the lib’s code). The default values are 2 retries and 40 ms and for these logs I used 10 retries and 100 ms. The send function takes almost exactly 1 second in each retry so not sure why the default values take 3 seconds for sendWithRetry to return.

sending to node 2, message [HELLO WORLD 10 TRIES 100 MS] 4018640
Send time:1001
 RETRY#1
Send time:1000
 RETRY#2
Send time:1001
 RETRY#3
Send time:1001
 RETRY#4
Send time:1001
 RETRY#5
Send time:1001
 RETRY#6
Send time:1000
 RETRY#7
Send time:1000
 RETRY#8
Send time:1000
 RETRY#9
Send time:1001
 RETRY#10
Send time:1000
 RETRY#11
no ACK received 4031302 (1133)
TX LED

And on Node 2:

received from node 1, message [HELLO WORLD 10 TRIES 100 MS], RSSI -10
ACK sent
received from node 1, message [HELLO WORLD 10 TRIES 100 MS], RSSI -27
ACK sent
received from node 1, message [HELLO WORLD 10 TRIES 100 MS], RSSI -27
ACK sent
received from node 1, message [HELLO WORLD 10 TRIES 100 MS], RSSI -27
ACK sent
received from node 1, message [HELLO WORLD 10 TRIES 100 MS], RSSI -27
ACK sent
received from node 1, message [HELLO WORLD 10 TRIES 100 MS], RSSI -27
ACK sent
received from node 1, message [HELLO WORLD 10 TRIES 100 MS], RSSI -27
ACK sent
received from node 1, message [HELLO WORLD 10 TRIES 100 MS], RSSI -28
ACK sent
received from node 1, message [HELLO WORLD 10 TRIES 100 MS], RSSI -28
ACK sent
received from node 1, message [HELLO WORLD 10 TRIES 100 MS], RSSI -27
ACK sent

Bottom line it seems the root problem is that on the Yun there is no reception whatsoever. I wonder if there is some interference with the WiFi chip which sits below the RFM69 Break out (I amounted the RFM69 on a prototyping shield), or if the problem is related to SPI. Not sure what else to try or debug to figure out what is going on. Any ideas welcome!!

4

I just found this old post and it’s almost identical to mine. The author also begs the question if it’s SPI or radio interference and seems a little bit of both. I wonder if someone can point me where or how to hack the SPI lib. I am also going to construct an improvised shielding with cardboard and aluminium foil to see if it helps.

https://dorkbotpdx.org/blog/paul/rfm69_ … ack_wanted

https://forum.pjrc.com/threads/25897-Ad … c-software

5

I have been able to solve several things. For one, I got rid of the slowness by getting SS to work on pin 10 and I moved the interrupt pin to pin 9 which is int 5. I modified the library code for the Yun’ G1’s case and it’s mostly working except for reception.

There is absolutely no reception and I am guessing it’s because the interrupt is not triggered called hence the ISR is not being called. I will confirm this with a scope tomorrow.

Anyway, if there are other Yun G1 users here are some of the changes that are working so far:

#define RF69_SPI_CS            10
#define RF69_IRQ_PIN            9
#define RF69_IRQ_NUM            5

Hopefully with the scope I will be able to better determine why the Rx part is not working.

6

Solved!

Please disregard my previous post. No need to hack the RFM69 library.

To get it working:

  1. Connect SPI lines MISO, MOSI and CLK from the ICSP header to RFM69BOB pins O,I and C respectively. Do not use pins 11-13 as the tutorial for the Uno)

  2. For Slave Select use Yun Digital Pin 10 (i.e. connect RFM69BOB pin S to Yun pin D10)

  3. For the Rx Interrupt use Pin 3, not Pin 2 as in the Tutorial (look at RFM69.h ifdef for AVR_ATmega32U4 to understand why)

In your code set the slave select pin like so:

// Initialize the RFM69HCW:
radio.setCS(10);
radio.initialize(FREQUENCY, MYNODEID, NETWORKID);
radio.setHighPower(); // Always use this for RFM69HCW

That’s it. The Yun/ATMega combo seems to be a bit slow on sending the ACK so for your other radios you should use a bit more time and retries if you want ACK to work. I am currently using:

radio.sendWithRetry(TONODEID, sendbuffer, sendlength, 5, 100)

Hope this helps other Yun Generation 1 users that want to mess with RFM69 and use the Yun as the IoT gateway.

7

The SparkFun RFM69HCW Breakout and a Arduino Uno R3 combo is not working for me.

Please see topic

https://forum.sparkfun.com/viewtopic.php?f=13&t=48531