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/ (http://www.airspayce.com/mikem/arduino/RadioHead/)
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.
Quote from: Explorer on September 08, 2014, 04:59:10 AM
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/ (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.
Cool, but I still think that's not really saving much, on the contrary. Now your Pi is tied up polling the transceiver directly.
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
Quote from: Felix on September 08, 2014, 01:03:49 PM
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.
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
Quote from: ColinR on September 08, 2014, 05:50:53 PM
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...
Quote from: bauderline on September 08, 2014, 07:06:27 PM
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
Quote from: ColinR on September 08, 2014, 07:56:23 PM
Quote from: bauderline on September 08, 2014, 07:06:27 PM
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.
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.
Code?
Still in the early stages. Nothing for a while (newbie here)
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
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.
that's amazing ;D because I just started to work back on it last night with itead SDK, but if your works, I will use it
Thanks for sharing
I guess itead SDK allows you to run Arduino sketches. In my case, you will have to make some Linux dev instead.
Yes Itead provide the ability to compile Arduino files, but any type of file in fact.
When building the SDK, It provide low level libraries for SPI, I2C, DigitalWrite, Attach Interrupt, ... that you can call in C, C++ and they even made a Python Wrapper.
It add some kind of WiringPi but with full Arduino syntax. They already pushed some Arduino Lib such as NRF24L01 and as soon you got the library compiled, your C code will be linked with it.
I think it's a quick way to port Arduino Library, I wanted to try, but you done it, so may be on another lib if I need ;)
Nice going with the lib :) I'm amazed how well supported the Pi still is, considering its age... But it seems no viable replacement on the horizon.
FYI:
I finally did "port" the RFM69 to the Beaglebone Black using python but it did not work well.
Reason probably is that python was too slow to handle the interrupt so I ran into problems every so often.
I did make sure the interrupt was doing the minimum (quick read of the data).
Probably would work fine if ported as "C" code and compiled (I haven't tried that...)
**
Related - has anyone tried the pyBBIO library?
Hello all,
Sorry to bump an old thread, but I have been working on porting the RFM69 library to the Beaglebone Black. Currently I can receive packets (encrypted or clear) from a Moteino, but I am having difficulty sending the ack back. You will need some Linux experience to get this working, but it is not too bad.
The code is hosted here: https://github.com/wcalvert/rfm69-python
I have also ran the Moteino firmware on a Teensy 3.1, with minor modifications required (mostly related to dropping the SPI Clock if the F_BUS gets too high).
Thanks goes to Felix for writing very clean code and providing the Moteino and RFM69 modules at a very good price!
Quote from: wcalvert on January 10, 2015, 01:11:24 AM
Thanks goes to Felix for writing very clean code and providing the Moteino and RFM69 modules at a very good price!
Good work, and I need to say not everyone is of the same opinion :P
This is starting to have an excellent compatibility with lot of hardware. :)
Since it's always quite complicated to have library always "up to date" in the same time for all targets, and as Felix is the only maintainer what about to integrate modification on the master library ?
meaning just add on the include file some constant defining the target architecture ? except the fact that this add code adding some #ifdef blahblah, it does not hurt and it could be very cool to have the lib at only one place for Moteino (Arduino), Raspberry PI, beaglebone, Teensy and Spark Core (as soon as we stay in c coding of course).
Just an idea, and I agree, I will love it because it will remove me pain of multiple version not "up to date" and adding Felix's changes each time....
Quote from: wcalvert on January 10, 2015, 01:11:24 AM
Sorry to bump an old thread, but I have been working on porting the RFM69 library to the Beaglebone Black. Currently I can receive packets (encrypted or clear) from a Moteino, but I am having difficulty sending the ack back. You will need some Linux experience to get this working, but it is not too bad.
I'm using abouillot's C port of the RFM69 library on a Raspberry Pi, and while it is basically working fine, I have exactly the same problem of not being able to send an ACK back. Did you ever solve this, and if so, what was the cause?
I'd really like to get sendACK() working properly to be able to use sendWithRetry() on the Moteino nodes...
Quote from: Charly86 on January 19, 2015, 09:47:48 AM
This is starting to have an excellent compatibility with lot of hardware. :)
Since it's always quite complicated to have library always "up to date" in the same time for all targets, and as Felix is the only maintainer what about to integrate modification on the master library ?
meaning just add on the include file some constant defining the target architecture ? except the fact that this add code adding some #ifdef blahblah, it does not hurt and it could be very cool to have the lib at only one place for Moteino (Arduino), Raspberry PI, beaglebone, Teensy and Spark Core (as soon as we stay in c coding of course).
Just an idea, and I agree, I will love it because it will remove me pain of multiple version not "up to date" and adding Felix's changes each time....
I strongly support that idea -- the Raspberry Pi C port makes use of #ifdefs whereever needed already, and is already out of date compared to the original RFM69 library, so this would be a prime candidate for merging, and would greatly ease keeping it up to date.
Anyone can make contributions to the RFM69 lib. However they will get scrutinized before merging the main line code. I like to keep it lean and clean, so I will not merge any kind of changes.
Quote from: obstler42 on January 20, 2015, 10:37:32 AM
I'm using abouillot's C port of the RFM69 library on a Raspberry Pi, and while it is basically working fine, I have exactly the same problem of not being able to send an ACK back. Did you ever solve this, and if so, what was the cause?
I'd really like to get sendACK() working properly to be able to use sendWithRetry() on the Moteino nodes...
Yes it's been fixed. I had a very minor typo in the code. The repository that I linked to has been updated.
Regarding making my code part of Felix's library... it is not possible right now, since mine is Python. I do have plans and ideas of possibly creating a C or C++ version for the BBB but I would never attempt to submit that as a patch to Felix's library. I have maintained code with a million #ifdefs before and it is not fun. The current RFM69 library is simple enough, with few enough changes being pushed, that porting each change to my library would be easy.
Quote from: wcalvert on February 06, 2015, 12:06:27 AM
Quote from: obstler42 on January 20, 2015, 10:37:32 AM
I'm using abouillot's C port of the RFM69 library on a Raspberry Pi, and while it is basically working fine, I have exactly the same problem of not being able to send an ACK back. Did you ever solve this, and if so, what was the cause?
I'd really like to get sendACK() working properly to be able to use sendWithRetry() on the Moteino nodes...
Yes it's been fixed. I had a very minor typo in the code. The repository that I linked to has been updated.
Regarding making my code part of Felix's library... it is not possible right now, since mine is Python. I do have plans and ideas of possibly creating a C or C++ version for the BBB but I would never attempt to submit that as a patch to Felix's library. I have maintained code with a million #ifdefs before and it is not fun. The current RFM69 library is simple enough, with few enough changes being pushed, that porting each change to my library would be easy.
Hello, I am following the progress on integrating rfm69 to raspberry pi directly. I discovered Basti at hawkes blog https://www.the-hawkes.de/pymygw-a-simple-mysensors-gateway.html (https://www.the-hawkes.de/pymygw-a-simple-mysensors-gateway.html) has integrated mysensors-openhab using raspberry pi. He is using serial device to connect between arduino/radio network and raspberry pi. I am very little knowledge on programming but wanted to ask how difficult will it be to use your code instead of serial port?
I'm sorry, I really don't know. I am not familiar with that technology stack.