RFM69 library port to Beaglebone or RaspberryPi

[Explorer]

Is there a plan to port the RFM69 library to Beaglebone or RaspberryPi?  (for python for instance).  I was considering it as a base station for my new Moteino sensors.  I found a few searching the Web but each as limitations and not the full set of functions (RSSI for instance).

Also related how does the RFM69 library compare to the one from Radiohead? http://www.airspayce.com/mikem/arduino/RadioHead/

[Felix]

Hey Explorer,
The RFM69 lib is meant for atmega328 type microcontrollers. In my mind it doesn't make sense to use them on a Pi because I'd rather keep all that stuff on a Moteino and let it deal with the RF since it can do that best and quickly, and let the Pi or BBB do other things they do best (like web interfacing, database etc).
Hence no plans to try to port them, not even sure where I'd start with that. Another reason is Moteinos are so cheap it's almost impossible to justify the effort trying to port and then deal with breaking out the radios to the Pi/BBB (which is an added cost anyway).
I have not really used RadioHead and so can't compare. I'll let others fill in here if they have experience with RadioHead.

[bauderline]

Is there a plan to port the RFM69 library to Beaglebone or RaspberryPi?  (for python for instance).  I was considering it as a base station for my new Moteino sensors.  I found a few searching the Web but each as limitations and not the full set of functions (RSSI for instance).

Also related how does the RFM69 library compare to the one from Radiohead? http://www.airspayce.com/mikem/arduino/RadioHead/

Someone has had a go for the RPi, it's not perfect but it seems functional, I am using it with my project and the results seem good so far...

http://rdepablos.merlitec.com/mixed/rfm69-library-for-raspberry-pi

To my mind if I have implemented a gateway / interface on the pi to handle incoming requests from the internet it doesn't make any sense to have that extra step of sending the data to a gateway moteino and then on to a node moteino, it would seem to me to add complexity for not any particularly good reason...

BR Peter.

[Felix]

Cool, but I still think that's not really saving much, on the contrary. Now your Pi is tied up polling the transceiver directly.

[ColinR]

Why would you do this? Talking to the Moteino on TX/RX works great, and I'd rather offload all of the radio and processing code to the micro. Plus you get more IO and ADCs!

Colin

[bauderline]

Cool, but I still think that's not really saving much, on the contrary. Now your Pi is tied up polling the transceiver directly.

Not sure what you mean tied up ? I have a program running in the background as a process, listening on a given port for incoming commands from various clients, can be a web server, can be a telnet session, can be a smart phone app like netio, once we have a command we send that directly out to the node moteino, grab the response and fire that response off to the client app... simplez....

Whilst that program is running away in the background I can be doing umpteen other things with the RPi... So I don't see how the RPi is "tied up".... maybe I am missing something...


Oddly enough I also had a nordic RF24 hanging out of the same RPi for a while and a Moteino/RF12 connected via I2C, the simple app I wrote could direct/proxy commands from a client to any one of these comm devices and happily run quietly in the background.....

The RF24 is now gone.... its pants compared to the RFM69 capabilities....

P.

[ColinR]

It's still a load of grunt work on SPI and lots of data in and out. I'd rather have a micro handle it and present only the data I need/want into my serial queue so I can process it at my leisure.

Besides this, at the other end of my Pi gateway will be another RF unit, where I do want a micro, for the sake of power consumption on a battery-powered node. So I can either have one node using a Pi-ported RF library and another using the micro RF library, or they can both use the same code, issues above aside.

C

[bauderline]

It's still a load of grunt work on SPI and lots of data in and out. I'd rather have a micro handle it and present only the data I need/want into my serial queue so I can process it at my leisure.

Besides this, at the other end of my Pi gateway will be another RF unit, where I do want a micro, for the sake of power consumption on a battery-powered node. So I can either have one node using a Pi-ported RF library and another using the micro RF library, or they can both use the same code, issues above aside.

C

I suppose it's down to preference, in terms of processing load you would need to be talking about a lot of traffic to present any significant I/O load for the RPi. In reality for most projects this is not going to make one jot of difference either way. Having said that if a long career in IT has taught me one thing it's that 9/10 simplicity is always the best policy...

[ColinR]

I suppose it's down to preference, in terms of processing load you would need to be talking about a lot of traffic to present any significant I/O load for the RPi. In reality for most projects this is not going to make one jot of difference either way. Having said that if a long career in IT has taught me one thing it's that 9/10 simplicity is always the best policy...

I'd agree on both counts, that it is preference and that simplicity is a first principle.

For me, simplicity is using a library that is well-developed, used, and supported, and using the same code on my gateway and remote nodes. YMMV.

I have enough background processes already to not want to worry about missing messages on a high-speed protocol, although it is kernel-supported now. Truth be told, I am actually already using SPI on my gateway for indicators with shift registers, and the other SPI is wired to a panel plug for other IO. I use it for an SPI thermocouple quite regularly.

Anyway, carry on!
C

[bauderline]

I suppose it's down to preference, in terms of processing load you would need to be talking about a lot of traffic to present any significant I/O load for the RPi. In reality for most projects this is not going to make one jot of difference either way. Having said that if a long career in IT has taught me one thing it's that 9/10 simplicity is always the best policy...

I'd agree on both counts, that it is preference and that simplicity is a first principle.

For me, simplicity is using a library that is well-developed, used, and supported, and using the same code on my gateway and remote nodes. YMMV.

I have enough background processes already to not want to worry about missing messages on a high-speed protocol, although it is kernel-supported now. Truth be told, I am actually already using SPI on my gateway for indicators with shift registers, and the other SPI is wired to a panel plug for other IO. I use it for an SPI thermocouple quite regularly.

Anyway, carry on!
C

Indeed.... It sounds like you have a very specific use case / requirements for what you want to do / achieve, so the auxiliary node dedicated to comms maybe makes sense for you.

I need to run a process anyway to capture incoming comms from the 'net, so it's one half a dozen or the other for me.

Happy Hacking !

P.

[Explorer]

FYI:
I decided to work on the port to BBB with Python and the Adafruit GPIO library (which works on Pi and BBB).
All the "work" is in the setup.  There is no polling as the RFM69 creates an interrupt when data is received (note: the RFM69 does all the heavy lifting on RF data processing so what is passed to the BBB is simply a buffer of the data).

Beaglebone Black is very fast so even the IRQ service routine that gets the data is done quickly: 1GHz AM335x ARM® Cortex-A8 processor.

I think that this is the best solution since there is no need for a RX/TX connection and the interrupt service is all that needs to work in the background process.  Data then can be appended to a file and/or used by other Linux processes.

[ColinR]

Code?

[Explorer]

Still in the early stages.  Nothing for a while (newbie here)

[Charly86]

Hi Guys,

Itead studio has released a SDK for Raspberry PI, it permit to compile Arduino program to raspberry PI (may be with some tweak), I did not tried but worth it to test because it seems very promising and it support interrupts.

https://github.com/itead/SDK
http://www.raspberrypi.org/forums/viewtopic.php?f=45&t=77060
http://wiki.iteadstudio.com/ITEAD_SDK

[abouillot]

Hi Guys,

I've ported the RFM69 library from LowPowerLab to Raspberry.

You can find it, embedded in my project at https://github.com/abouillot/HomeAutomation/tree/master/piGateway

The code have been set up to be an exact 1:1 match of the original one, so integration of coming fixes should be straightforward.

This rely on WiringPi in order to access SPI and interrupts.

I'm certain some parts still need ironing, but I have it running @ home.

Thanks for your feedback.