raspberry pi

[Onmt39]

Hey,
I don't know how to make c++ or python program that contain the RF24 and RF24Network library on the raspberry pi. I followed the setup and got both library examples to work and communicate with my arduino. So I tried making my own programs and compiled it with g++ and gcc, kept getting "undefined reference to" errors which I guess means it can't find the libraries. After this I tried using -I/location/of/library or -l/location/of/library to link them to my program. I found a pyRF24 folder which I think links c++ with python so you can use it with python? I tried building and installing the setup.py file but got:

running build
running build_ext
building 'RF24' extension
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -02 -Wall -Wstrict-prototypes -fPIC -I/usr/include/python2.7 -c pyRF24.cpp -o build/temp.linux-arm61-2.7/pyRF24.o
cc1plus: warning: command line option '-Wstrict-prototypes' is valid for Ada/C/0bjC but not for C++ [enabled bu default]
pyRF24.cpp:2:28: fatal error: boost/python/hpp: No such file or directory compilation terminated
error: command 'gcc' failed with exit status 1

I think the issue is I don't have boost/python installed. I tryed following the install process on http://www.boost.org/doc/libs/1_42_0/libs/python/doc/building.html but it just confused me.

I can get both RF24 and RF24Network library examples to work with my arduino. But I don't know how to run my own programs on the raspberry pi. I would preferably like to use python (using boost/python wrapper) as I am not familiar to C++. Can you please help me?

[TMRh20]

Well, if you are trying to compile your own programs in c, make sure you include the files using < like #include <RF24/RF24.h> and include them in the same order as the examples. For compiling, the easiest way is probably just to create it in the same folder as the examples, and add the name of your prog to the line in the Makefile: PROGRAMS = YOUR_PROGRAM_NAME gettingstarted gettingstarted_call_response transfer pingpair_dyn

For the python wrapper, do:

1. sudo apt-get install libboost1.50-all
2. build: ./setup.py build
3. install: ./setup.py install

Its usually best to see if there is a debian package whenever you are looking for libraries etc. for RPi.
Note: The python wrapper may still have a few quirks or bugs, but it seems pretty good from everything I've tested.

[Onmt39]

Thank you, I managed to get the program compiled and work. I'm just wondering is it C or C++,I'm not sure, I assumed cpp stood for C++?(so when I look on the internet for help I know what language to search) I've installed boost.python and managed to build and install the setup.py file. I'll try working with that next. Does the python wrapper include the network library as the setup.py file is only in the RF24 file? Also is there an example code for python?

[TMRh20]

Np, there is a pull request in for the python wrapper in RF24Network, but I have not had a chance to really test it at all, so am hesitant to commit it, but it is available in the other fork. The python example is um, in the examples folder. Search c++ or look here

[martin-mat]

Onmt39, I've been using python wrapper for RF24Network intensively and it seems to work fine; feel free to get it from my fork and report problems if there are any.

[Onmt39]

Thanks, Ill try your fork.

[TMRh20]

Sorry about the delay, but I do like to at least make sure things compile, and I've been in a zombie-like coding state, working on creating an RF24Ethernet library which adds a TCP/IP layer on top of RF24Network, but it's been taking every ounce of my time to try and understand the UIP TCP/IP stack.

[Onmt39]

Thank you for the help TMRh20 and mz-fuzzy. Your RF24Ethernet library, what does it do? I know it says it accesses your RF24Network from a web browser, but what can it be used for?

[TMRh20]

Well,it has a lot to do with standards. Using a standard protocol allows things that were previously time consuming and/or very technical, so it simplifies things quite a bit in many cases.

TCP is a fairly robust protocol, and was designed initially for operation over damaged or error prone networks, which is fairly well suited to a wireless network, and provides all of the features that you really need to manage data properly. From logging data directly to a database, or retrieving text-based information from a webserver, things are just so much easier to work with when you use such a common standard protocol.

Lets say that you have a sensor network, and you want some of your nodes to be able to get the current time or some sort of external information. Previously, you would have to write a bunch of code, to tell the sensor to talk to the master node, which would then talk back, or request the information from the internet.

With RF24Ethernet, for example, a RPi could be running a webserver, and a php script could return the current time, as the nodes connect, request data, and disconnect, or it could be a simple plain-text html file, updated at intervals, which the nodes retrieve.

You could also now, very easily, connect to a sensor node, input data from your phone or PC, and change settings etc. This could possibly be done before with RF24 or RF24Network, but it is much much easier with RF24Ethernet.

After doing some testing, and seeing how well the current infrastructure fits in with TCP/IP and Ethernet protocols, I could go on and on about the possibilities. If integrated with RF24Mesh, one would have a completely dynamic TCP/IP sensor network, and networks could be linked over the interenet and/or a SSH tunnel etc. etc. etc....

[martin-mat]

This sounds promising. Just to note that the name 'RF24Ethernet' is misleading as 'Ethernet' represents protocols on physical/link layer, meaning same layer as RF24. Maybe better RF24TcpIp or something like this :-)

[spaniakos]

That sounds promising Indeed .
But will this require DHCP from the master node ( raspberry ) and internal layer 3 addressing?

[TMRh20]

Thanks for the input guys.

I know the name is a bit odd, but I wanted to follow the same naming convention as the standard Arduino Ethernet lib and UIPEthernet because the API will be much the same, and I'm basing the code on UIPEthernet and SerialIP.

I'm not sure if RF24Ethernet all that misleading though, because the software literally creates a wireless ethernet network, using ethernet headers and ARP requests very much the same as any ethernet network. The RF24 radio addresses just become the MAC addresses for the ethernet layer (although they are masked by RF24Network to follow a simple pattern). The network itself knows nothing of IPs and TCP/IP, only ethernet, MAC addresses and external data.

The option for using DHCP is there, but is not really needed unless the nodes themselves move around physically, because the master node will be set to find the IP of any sensor nodes using ethernet protocols (ARP requests). In its current form, the network addressing etc. is exactly the same as with RF24Network, but the possibility is there to use RF24Mesh in conjunction, which provides protocols for dynamic address assignment for the RF24/Ethernet (MAC) layer.

[spaniakos]

That seems ok,
but i will have to ask, (probably i know the answer) :
the Ethernet layer would require the fragmentation/defragmentation of the messages?
is this ready? can we do anything to speed up the progress if not?
currentlly i am finishing my class creation for my peripheral sensors, and would jump into implement an optional AES cryptography class for Galileo / Raspberry pi OR RF24EEPROM class for hardcoded addressing OR fragmentation/defragmentation if its not ready yet ;)

The option for DHCP if to be used to automatic joining of sensors to the network by aw simple authentication request to the master node without hardcoding addreses to each device by hand, thow this would require one of the channel to be used for broadcasts and requests (something like the the TCP/IP broadcast reserved ip ex. 192.168.1.255)

[martin-mat]

no problem, it's just about terminology... Just to be precise terminology-wise, "wireless ethernet" is contradiction as ethernet is always via wires (10Base2, 10BaseT, 10Base5,...) . MAC or ARP is now nothing specific to ethernet, it's link layer used upon multiple physical layers including ethernet, wifi, bluetooth, tokenbus etc... It was introduced by ethernet, but now it's adopted also to other physical mediums.

Means:

• physical layer = NRF24l01 chip (same layer as Ethernet, wifi, bluetooth, ...)
• link layer = MAC/ARP... (equivalent to what we partly have in RF24) - this is what you refer as Ethernet as well, but it's not really, or at least it's not only in ethernet
• network layer = IP/ICMP/... (or it is also RF24Network, RF24Mesh)
• transport layer = TCP/UDP/SCTP...

[TMRh20]

@spaniakos

Yes, the fragmentation/defragmentation is working in the development library. The RPi also supports multicasting of fragmented messages, and the Arduino can receive them. I still have to do some testing the other way around, and for the multicast forwarding etc.

In the RF24Network-DEV lib, there is 1 address per node reserved for multicasting, thats how RF24Mesh works, and how the ARP requests find their way to the sensors. The nodes are also capable of unicast to any node in range. This allows the IP layer to be completely separate from the network layer, being able to assign any IP address to any node, via static or DHCP.

The RF24Mesh layer already provides a simple method of storing unique identifiers in EEPROM, but devices like Due or Teensy (ARM) do not have an eeprom, and ATTiny do not have eeprom libs included by default, so it can be a little complicated. I'm not sure what the best way to approach it is, but code size is always the main limitation to adding extra features. Encryption seems to be something everybody is talking about more and more, but I would just use SSH or some standard encrytion methods if connecting between linux devices. If you want to contribute, its a bit difficult right now, since I am using this as a way to learn more about the protocols etc. myself

@mz-fuzzy You will find that I use a lot of generalized terminology, so if you get caught up in details, your mind will blow up reading through any of my documentation etc. RF24Network does not use IP or ICMP or understand what that is. It functions completely using MAC addresses, with its own layer 4 addressing protocols for ping and address assignment, called RF24Mesh. TCP/IP and Ethernet frames are handled only in RF24Ethernet and RF24toTUN, which work on top of RF24Network and RF24Mesh. How to define it exactly is beyond my expertise.

[spaniakos]

@TMRh20
Ok then.
I will finish my sensor class libraries and will start adapting the
RF24Network_Dev library and mesh for Intel Galileo. And then I will see how
it goes and try to implement symmetric cryptography for the small devices
and AES for the stronger ones, after all I need to try to do that. Moreover
I will try to implement md5 and sha1 hash functions .
Plus I will try to create a simple authentication class for using hardcoded
passwords in order to establish the first connection in the network using
serial input in the master node or using nodejs.
If I have good results I will let you know.
On Nov 26, 2014 9:13 PM, "TMRh20" notifications@github.com wrote:

@spaniakos https://github.com/spaniakos

Yes, the fragmentation/defragmentation is working in the development
library. The RPi also supports multicasting of fragmented messages, and the
Arduino can receive them. I still have to do some testing the other way
around, and for the multicast forwarding etc.

In the RF24Network-DEV lib, there is 1 address per node reserved for
multicasting, thats how RF24Mesh works, and how the ARP requests find their
way to the sensors. The nodes are also capable of unicast to any node in
range. This allows the IP layer to be completely separate from the network
layer, being able to assign any IP address to any node, via static or DHCP.

The RF24Mesh layer already provides a simple method of storing unique
identifiers in EEPROM, but devices like Due or Teensy (ARM) do not have an
eeprom, and ATTiny do not have eeprom libs included by default, so it can
be a little complicated. I'm not sure what the best way to approach it is,
but code size is always the main limitation to adding extra features.
Encryption seems to be something everybody is talking about more and more,
but I would just use SSH or some standard encrytion methods if connecting
between linux devices. If you want to contribute, its a bit difficult right
now, since I am using this as a way to learn more about the protocols etc.
myself

@mz-fuzzy https://github.com/mz-fuzzy You will find that I use a lot of
generalized terminology, so if you get caught up in details, your mind will
blow up reading through any of my documentation etc. RF24Network does not
use IP or ICMP or understand what that is. It functions completely using
MAC addresses, with its own layer 4 addressing protocols for ping and
address assignment, called RF24Mesh. TCP/IP and Ethernet frames are handled
only in RF24Ethernet and RF24toTUN, which work on top of RF24Network and
RF24Mesh. How to define it exactly is beyond my expertise.

—
Reply to this email directly or view it on GitHub
#41 (comment).

[martin-mat]

Reading discussion about further development/contributions - what would be interesting for me to do: nRF24l01 usb stick working with RF24 lib on PC. It would look like: nRF24L01 + ATMega controller + vusb connection.
On ATMega - firmware based on RF24 lib which would listen to requests from vusb, proceed with actions on nRF24L01 and return results back via vusb. On PC side - RF24 library interface which would send serialized commands+parameters via usb to the stick and get responses from it.

Since RF24 interface would be kept as it is, SW written now for RPi+nRF24l01 on SPI+GPIO would run as well in PC/RPi+nRF24l01 usb stick.

Any opinion about usefulness/feasibility of that idea?

[henrikekblad]

We would be interseted in a stick like that over at www.mysensors.org.

Our usb-gateway would fit perfectly on the stick.

Best
Henrik

On Wed, Nov 26, 2014 at 9:45 PM, mz-fuzzy notifications@github.com wrote:

Reading discussion about further development/contributions - what would be
interesting for me to do: nRF24l01 usb stick working with RF24 lib on PC.
It would look like: nRF24L01 + ATMega controller + vusb connection.
On ATMega - firmware which would listen to requests from vusb, proceed
with actions on nRF24L01 and return results back via vusb. On PC side -
RF24 library interface which would send serialized commands+parameters via
usb to the stick and get responses from it.

Since RF24 interface would be kept as it is, SW written now for
arduino+RF24 on SPI+GPIO would run as well in PC+nRFl01 usb stick.

Any opinion about usefulness/feasibility of that idea?

—
Reply to this email directly or view it on GitHub
#41 (comment).

Mobile: +46 (0)720-23 35 00

[TMRh20]

Well, yes and yes.

@spaniakos
Encryption and cryptography is not something I have intimate knowledge of, but what you are suggesting sounds well, pretty cool. I've been pondering potential problems resulting from the lack of security, and the benefits of some sort of secure identification methods etc, but don't know enough about the subject at this point. I would be very interested to see what you could come up with.

@mz-fuzzy Also sounds very very cool, I think its just a matter of how far you want to take the idea, but def. sounds like something people would buy.

[mic159]

@mz-fuzzy There is hardware like that already, don't know if you can change the firmware on the atmega tho.
https://www.dx.com/p/nrf24l01-usb-gfsk-wireless-communication-transmission-module-green-silver-1-9-3-6v-218191

[martin-mat]

@mic159 thanks for the link; HW is easiest part of this idea, and there is no reason for spending such money for this stick, moreover with controller with 8k flash only which could be limiting. I was thinking rather about a cheap generic controller like atmega328 and vusb connection, very simple schematics. Most of the work there is about how to serialize RF24 api and how to push/synchronize via vusb.

Other option is to use something like this
with AT-command serial interface, but I did not find any info about commands supported.

[henrikekblad]

@Mr-Fuzzy

Go for it!

On Thu, Nov 27, 2014 at 8:52 AM, mz-fuzzy notifications@github.com wrote:

@mic159 https://github.com/mic159 thanks for the link; HW is easiest
part of this idea, and there is no reason for spending such money for this
stick, moreover with controller with 8k flash only which could be limiting.
I was thinking rather about a cheap generic controller like atmega328 and
vusb connection, very simple schematics. Most of the work there is about
how to serialize RF24 api and how to push/synchronize via vusb.

Other option is to use something like this
http://www.aliexpress.com/item/2pcs-lot-USB-Interface-2-4G-Wireless-Serial-Communication-Module-Compatible-with-NRF24L01P-FZ0769/1687938957.html
with AT-command serial interface, but I did not find any info about
commands supported.

—
Reply to this email directly or view it on GitHub
#41 (comment).

Mobile: +46 (0)720-23 35 00