Adapter board RFM69W radio for Teensy 3- Also diagnostic software...

Status
Not open for further replies.
We're beginning to work with the RFM69 (SX1231) software tool for testing optimal error rate settings for various tools. To replace the ones now in use in RadioHead.

Is the SX1231 software tool generally available to everyone?
 
yes. Both Semtech and HopeRF publish it. (RFM69-specific)
I've only looked at it for an hour or so. Then I passed it to Mike et al on the RadioHead forum. Mike spent more time with it and improved some of the 20 register setting choices for the RFM69. But there are still problems with others. The tool unfortunately presumes a depth of knowledge of the RFM69 that few would have.
I have the action to work more with Semtech to correct the register settings tables.

I've been busy with the network layer software over the air reprogramming, node discovery, and socket driver concept with port numbers and port listeners, similar to that in IP.
It's working pretty well on Windows, Linux, RPi (Mac too?, I have no Mac) in Python, and the C++ code for AVR and Teensy is working well. Runs on Teensy 3 (but can't do OTAR w/Teensy), and OTAR works with AVRs and a new bootloader I wrote.
 
Steve, do you know if Mike ever merged my patches to use SPI transactions?

If not, maybe he'll be more receptive now that Arduino 1.6.0 is published, with SPI transactions officially supported on all Arduino boards.

The copy of RadioHead which Teensyduino installs has the SPI transaction patches.
 
Paul,

Do I need to connect the RFM69W with your Rev3 (with the 74HC02 logic hack on the SCK line) or will it work without now?

Thanks, Ben
 
Transactions... I didn't see it in the release notes or code. But I'm two revisions back in RH code releases. I just searched the revision history document... no mention.

The 74HC02... used with the RFM69H radio-- I've not needed it with T3 or AVR - but I avoid using the same SPI port for the radio and some other device simultaneously in time. The people use the MapleLeaf didn't need it either. The issue arose for Paul when the radio's IRQ latency was lengthened significantly.

One can briefly turn off the radio's receive mode and tuis it won't interrupt. Then you can use the SPI port for some other peripheral, then reenable the receiver. Not ideal, but it avoids the need for SPI Transactions and the risk that some other device will cause a long latency for the radio's ISR. That latency has to be at most a few hundred microseconds - which is OK for most SPI devices - SD cards and maybe high duty cycle SPI work.
If the receiver is off when a message arrives, and if it's using the normal reliable datagram, the sender will retransmit to correct.

This all presumes that SPI DMA is not used.
 
Last edited:
RFM69 bug free?

I'm really starting to wonder if the RFM69 has some sort of hardware issue, where SCK activity while NSS is inactive causes trouble?

Paul, we have had RFM69 receive issues with our project. We have found that the RFM69 receives fairly well MOST of the time, but misses Rx blocks randomly. Are you convinced that the RFM69 is bug free yet? Are you receiving blocks very reliably now? Andrew Gray, Avtec.
 
Hi,

I am having very similar issues, although not with a Teensy. The RFM69 works flawlessly with Arduino Unos but does not receive when mounted on an Arduino Yun (first gen). I too was wondering if it's an SPI issue or radio interference and it's probably a bit of both. I think the "slow motion" aspect could be caused by SPI issues but the reception problem is probably due to radio intereference because of the proximity of the chips and the antennas. I am trying to shield the RFM69 circuitry and antenna to see if I can get at least some reception. As for SPI hacking I am not sure if it's actually a problem. AFAIK the SPI communication between the Carambola 2 module and the ATmega32U is only for programming the AVR. So I am leaning more towards radio interference.

Check out the info I've posted on the Sparkfun forum for more details: https://forum.sparkfun.com/viewtopic.php?f=13&t=48345&p=199739

Thanks in advance for any help, pointers or ideas...

Alex
 
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:

Code:
#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.
 
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 Yun ICSP header to RFM69 pins O,I and C respectively. (Do not use pins 11-13 as you would for the Uno)
2) For Slave Select use Yun Digital Pin 10 (i.e. connect RFM69 pin S to Yun pin D10)
2) For the Rx Interrupt use Pin 3, not Pin 2 as you would with an Uno (look at RFM69.h ifdef for AVR_ATmega32U4 to understand why)

In your code set the slave select pin like so:

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

That's it!

Note that 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:

Code:
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.
 
Status
Not open for further replies.
Back
Top