Skip to main content

You are here

rfm12b mesh network libraries

25 posts / 0 new
Last post
rfm12b mesh network libraries

I have found some libraries for the rfm12b and rfm22 that implements some mesh capabilities. Probably they were mentioned in the past but just in case I post some links here:

broadcast and peer discovery (for NRF24L01)

multihop packet routing, dynamic id allocation, collision avoidance/lost message re-broadcast

multi routing and multi hop


I once played with the arduinode and protothreads. The pt's are very nice to use to create independent program flows. I found it difficult to integrate them with interrupts though.

The problem is however that once you start using them, none of the examples and work done here for the JeeNodes are usable anymore.


@Mars, Did the arduinode libraries work for you? How many nodes did you try this with? Any particular topology?



Yep, it did work, but the RFM12B extenstion was a hack and it seems there has been no further development in the last year...

I did some testing with three JeeNodes, one on each floor in the house. It seemed to work ok, but I have good receiption at home, so no real need for this software. Add to this the incompatibility issue and the fact that no further development seems to be done and you might understand that I did not use it anymore. I'd rather, if needed, make a fixed relay per floor that takes care of this...

Besides that, I already have to use adapted sketches since my nodes are connected to HomeSeer, and hence use a different protocol: sensors on the JeeNodes announce themselves intially (automatic configuration of HomeSeer devices), some thing s are configurable, etc....

I would love to see the node and pt library to be used standard on JeeNodes, but I have no time to do that, and I guess not many others do...


Interesting. Well the next question I have is what does this library offer that is not already available in jeelib? I wonder if there would be a way to extend jeelib to be able to take on the functionality seen in the arduinode library. I know that we can do relays, but I for one would love to see something which allows the features which arduinode has such as: multi hop packet routing, dynamic id allocation, collision avoidance and rebroadcasting of lost messages...


Doesnt the jeelib already have collision avoidance?

Im looking to setup a mesh network with jeenodes atm. Ill have a read through arduinode source sometime and see if anything can be pulled in easily.

Im more interested in incorporating Joost Hoozemans work in the short run.


Hmm that article is quite new, but I guess you will have to wait for Joost software to be completed or released. I cannot see any link or progress updates. Remember also that things works differently in university departements and research. :-)


@robomotic: What are your plans? I start to think about a mesh myself too. I do have quite bad reception and such a project sounds very challenging/interesting.

Most likely I'll base it on Teensy 3.0 instead of JeeNodes. My plan is to have some Teensys connected by a mesh network and/or Ethernet. The JeeNode (sensor nodes) should be able to send a message as broadcast. One of the MeshNodes gets it and forwards the message to a central collection point. The other way also has to be possible, so every node actually has to have a way to send to any other node. Not only broadcasts but also unicast.

I did search for existing projects but was not very successful. Many people use XBee or do have completely different requirements. That's why I'm quite sure that I'll have do write my own to get what I need/want).

As I wrote, I know it's a challenging task but that's what I'm looking for. So if you're still in this topic and you do have the skills to develop something like this we should try to do so together.


That looks more like a hub. Imagine a receiver per floor that relays messages back and forth to the central node, or via multiple nodes...


Floor 1: receives all JeeNodes with nodes 1-10 Floor 2: receives all JeeNodes with nodes 11-20 Floor 3: receives all JeeNodes with nodes 21-30, is also the central node or JeeLink.

Floor 1 and 2 relay all messages to floor 3.

This is the easiest mesh I can think off that doens't require many changes in existing nodes.


Actually a mesh is always only a network consisting of nodes which are able to froward messages of others. The important point is the dynamic building up of the routing tables. I did simplify my example a little bit too much. Most likely it'll happen that more than one of the mesh nodes sees the incoming message. It's also possible that a edge node travels around. So it's not always the same meshNode who is responsible for this edgeNode.

But basically you're right :-)


Have you considered swithcing to 2.4 GHz, there is a good implementation of a meshed network working with the Nordic series or the Norduino (an adapted Jeenode). Please have a look at this project info: maniac bug, git code, some pictures with norduino. I know that 2.4 GHz will give you less penetration for walls but you will have an already tested stack for mesh network and software that works with the same Jeenode sensor ports. Cheers.


I didn't know about this project, thank you for this interesting links. Looks like the routing is based on the "static" addressing. So not really a "Mesh". Don't know the exact definition but I'm quite sure the dynamic part is important. If I do something myself I should follow this road as routing in such a system is trivial. For me it's not a option to switch to 2.4GHz as there is too much traffic already at this frequency.

I'm only getting very poor range from all my JeeNodes. The building-structure kills the signals. It's almost impossible to go through more than two walls with a JeeNode. The windows are even worse. First I assumed a problem with my JeeNodes but WiFi is the same. This high thermal isolated and noise isolated three-layer glass is very nice but a pain with every kind of RF technology. So one node per floor is unrealistic at my place. This is the main reason why I'm investigating in mesh networks.

I probably should switch to XBee but that looks too easy :-) and I don't like the power consumption of these modules. I know that mesh-routing needs nodes which are always listening. This is why I'm looking for a way to build kind of a backbone of always receiving MeshNodes where the existing JeeNodes connect to. The other feature I'ld love to have is a network which is extensible over Ethernet. That's the only way to include some more remote locations like the basement as there are some other apartments in between. And if Ethernet is implemented, why not use the Internet as backbone?

I could not yet find anything which looks like it's able to fulfill my requirements and is open software. I'll continue to search the web but I'm not that optimistic here. This is a nice project for a student with a lot of time. I do not have the time required for this but would love to implement something as challenging as this. It started snowing today – maybe if there are many cold and dark winter days I'll start to do something myself…


Hello to you all, my name is Jan and i am the developer of arduiNode mesh networking library. I have put a lot of work into the project the last weeks and the driver for the rfm12 is now fully integrated and everything works so far. I have a new buffer concept and new configure options. The new code will be on the project page in the next days due to some strange svn problems. i would be very glad to work together with interested people on this fascinating topic and/or to hear your suggestions. any input is greatly appreciated! thx, jan


Hallo Jan

I'm very interested in something like this and sure will give arduiNode a try. Do you have any technical (how it works, high-level view) documents? I only found this one here:

  • On first sight it looks like you built up a tree to all nodes starting from the Master. This, of course, allows easy routing to the master but how do you do the other way around? Does the master have a full routing table to all nodes? Do you integrate the link quality in the routing decision? I prefer to involve one more node but get the link with better signal strength. How about using Ethernet as a backbone?

  • What happens if there's more than Master in the network?

  • What's the reason for RTS and CTS?

Sorry for all these questions… if this is answered somewhere, please give me a link. I'm planning to implement something like this on Teensy 3 and so I'm looking for good ideas myself. If it works out we could try to make it compatible.

Und ich bin auch gerne für eine Kommunikation in Deutsch zu haben…



Hi Thomas, thank you for your interest. I will continue to write in English for the forum so anyone interested can follow.

to your questions:

Routing you are right, a node tree is build, this was the easiest way to implement routing from the nodes to the master node. however i plan to add communication to the slaves and i have different concepts for that, i.e. with discovery packets. the link quality is currently not integrated, only the hops to the master node. however if a communication attempt fails, the unresponsive node is deleted from the node table. could be implemented and configured as an option.
how would you determine link quality?

Master nodes the system fails if there is more than one master in the net. packets would be routed to one or another master and loops could occur.

RTS CTS rts means ready to send and is used to help implement better collision avoidance. if node 'c' sees node 'b' but not node 'a' it will still intercept the cts answer of node 'b' and thus not interfere with the data communication of node 'a' to node 'b'

your questions are welcome and a library compatible with teensy would be great! much more space and a bigger user base. i have to work on the documentation in my wiki, so if you have further questions go ahead!



I'm following this.


i have written some basic information to the arduiNode protocol which you can find here:


Thank you Jan.

Feedback for Routing: I'm still in a very early stage of defining my requirements. The link quality is actually available as rough estimate using the drssi bit, see here. One important requirement is support for "edge nodes" which are not full members of the mesh. These are very low-power battery-powered devices. These nodes wake up, send a message to '0' (aka broadcast) and go back to sleep. Some of them require an ack bot not all. Mesh nodes should be able to pick up these packets (send an ack without interfering each other) and route these packets to the master.

Master nodes: I don't like the idea of a single point of failure but it helps keeping things a bit simpler. Most likely I'll give up on this requirement.

RTS CTS: I see... But there is a chance 'c' starts sending while 'a' is sending RTS to 'b' so you don't solve a problem but make it more unlikely. It helps for larger packets, but not for small ones.

To be fair, I don't know anything about your project. How mature is it? How many developers, how many installations? Or is it more a private project? Looks like you're using protothreads which makes it incompatible with all existing JeeNode sketches... :-(

For me one of the most important parts of JeeNode sensors is this very low power consumption. I got one down to 1.8µA @3.3V while still handling external interrupts and a wakeup-timer. Such a node has to be able to communicate using the mesh as backbone. The mesh nodes will most likely be mains powered as they have to have the receiver enabled all the time.

What do you think about these topics? What were your requirement when you designed ArduiNode?


Thomas i read your post about the rssi hack and i like the idea a lot! i will implement this feature and add the option to save the value in the node table. could be used in the future to dynamically adapt the tx power to save some energy maybe. based on your experience how would you let rssi value affect routing?

for the "edge nodes" i see no problem, as long as they dont broadcast beacon frames they wont get bothered with data packets. they will be invisible for other nodes but could address them.

for the master node i see no other solution at the moment, a fall back system could be implemented however.

the handshake via rts, cts, data, ack is pretty common in networking and thus i adopted it. shorter packets could be sent without it you are right, this could be made optional.

for energy optimization i was thinking of a time sync mechanism to put the whole net into sleep states and wake up at fixed intervals to route packets and then go back to sleep. this would be state of the art and a very interesting work!

you asked about my background: i started arduiNode 2 years ago in my spare time, first based on infrared communication, then moved to radio. i read a lot of papers and books about wsn and the idea fascinated me, so i began my own research. i finished university in the meantime and work full time so i have less time but i am determined to finish this work! and there are no arduiNode installations besides that on my desk ;) but i like the idea that people could easily build powerful wsn and come up with great ideas.


Hi Jan,

So it looks like you're looking for the same as I do – a nice challenge in a very interesting area of research. It's always the same with these jobs eating up all the time for these personal challenges. Same problem here…

I think the RSSI value could play an important rule in routing, just as the # of hops to the master. Maybe preferring routes with more hops but better link quality could improve overall stability. The link quality could be propagated together with the # of hops to the master. Maybe the quality of the worst part in between is enough but this will not always find the best path. So every node uses two dimensions (# of hops and wors link quality on path) to decide which route to take.

I see one problem with these edge nodes. Some of them rely on a reliable connection to report important stuff like "window opened". These window sensors run on a coin cell battery and should switch off the receiver as soon as possible. Doubling the time the receiver is on almost halves the battery life. So the window sensor sends a packet and waits for an ack. But who sends this ack back? The nodes which are full members of the mesh should know which one of them has to send the ack back to not interfere each other or wait to long for a specific time slot.

You are talking about a TDMA system. A very good idea for anything sharing a single medium (aka air). Problem is timing. It's very hard to get an accurate timing on these low-power devices. The edge nodes will never have an accurate timing and even for the others it's hard to stay in sync (as jcw proofed in blog posts some days ago). It does work but is hard to do correctly. As I only have very short packets with minutes in between TDMA looks like a bit too much.

I'm sorry. You've already done so much of that hard work and I just see problems everywhere. Maybe I'm looking too much for perfection here… Did you see this document about SimpleMesh? It's not much of a technical description. This protocol is based on routes between two nodes which are discovered on the fly and stay active until the route breaks. I like the idea as it does not need much resources and does not rely on regular transmissions or the aging of routing entries. But it also does not solve the problems mentioned before.

I thought about extending this SimpleMesh idea to a master node like the one in your protocol. If one of the mesh nodes get a packet from an edge node they don't do anything. If there is no ack the edge node will send the data once more and the mesh node will report the edge node-id and link quality to the master and wait for an answer. The master may receive multiple such requests and sends an info back to the one with the best link quality. This one then feels responsible for this particular edge node from this moment on. The next time the edge node sends a packet this responsible mesh node immediately sends back an ack which should prevent another discovery.

I don't know in which direction it'll go. But there is more stuff I would like to implement or at least to plan for it in the early stages. Like a way to combine multiple meshes over Ethernet…


Hi everybody, i finished the work on arduiNode but as i am not working with the arduino IDE directly but use make to build my stuff i now have big problems with the #include definitions of my projects header files.. i didnt find the bug yet, and to be honest i dont understand the problem. seems as my make file includes in another order as the arduino ide does. anybody any ideas on that?

how do you build your projects?

and thomas i will try to add rssi and tdma when i have soled that problem. i think tdma should be possible when i.e. you wake the receiver up every minute (or 10) for a couple of seconds, then wait for a tolerance compensation time, then send your data, do a fresh time sync and go to sleep again. dont you think so?


Hi Jan, I actually use Arduino but I don't like it. I've planned to replace it as soon as EmbedXcode supports Teensy 3.0.

I had my own fights with Arduino too. As far as I know it compiles all the .ino and .cpp files independently and links them together. So you can't have files which should not be compiled inside an Arduino Sketch. But it's different for Libraries. There are also some differences how *.ino and *.cpp files are handled inside Arduino.

Currently I have my libraries I'm working on in the libraries folder and edit them using an external editor. Inside Arduino is only the small Sketch which uses the library.

TDMA: What are you trying to use TDMA for? Communication between the mesh nodes or from mesh node to edge node? The edge nodes have a very poor sense of time. Easily 5-10% off. The ones running on coin cell batteries are even worse they have absolutely no idea what time it is when they get an interrupt. So no chance to use TDMA there. The communication between the mesh nodes has to be much more frequent. More like 10/1s than 1/10min. But every time a edge node sends a message the corresponding mesh node has to be awake. Which actually prevents sleeping of the mesh nodes altogether. So there's one possibility for TDMA left. Assign one time slot to every mesh node and they're only allowed to send during this time but have to receive all the time. This could prevent nodes from interfering each other completely (no more RTS, CTS) but there have to be synchronized clocks. This is a very important concept in high-traffic networks but do we need it to send one packet per minute?

Another point is the delay in the network. I think we should keep the delay as low as possible. It doesn't matter for environment sensor data like temperature but just assume someone who tries to switch on a light when there's movement or kind of a remote control for something. People don't like to wait seconds until the light goes on. The mesh needs to be able to forward packets in much less than 1s.

Do your nodes have an accurate sense of time? Maybe a 32kHz crystal? I actually like the idea of synchronized clocks but I'm not sure if it's worth the trouble. If we go into this direction there has to be an accurate, reliable local clock like a 32kHz crystal.

SimpleMesh solves some of these problems. No synchronized clocks necessary, no central master node, no "i'm-still-here" packets. If there is a connection needed, discover it on the fly and keep it until it breaks. Sounds like a very nice idea for mostly static installations. Using a connection for the first time is slow but every following packet gets through very fast with no additional overhead.

I also had a quite different idea. Currently every node sends out a broadcast or directly addresses one other node. What if the data should go to more than one target? Let's go back to our motion sensor connected to a light. The light should receive the packet and a central node which reports motion or just keeps track of stuff going on should receive it too. What if these two receivers are not connected to the same mesh node? Currently there is only a broadcast which allows for something like this. But broadcasts in a mesh network are bad ;-). So why not look at it from a different perspective? Why not address it like a bus with publisher and subscriber? Edge nodes would mostly be publishers. Full mesh nodes publisher and subscriber as every subscriber has to have RX enabled all the time it doesn't really matter. So publishers send not to a specific node but to a topic. Every node registered to this topic receives the message. Actually I don't have an idea about how routing should work in this kind of network. It's much more complex as it moves more intelligence into the network itself. But it allows the mesh doing more stuff on its own. Like Reporting power consumption to a display and the server in the basement or a working motion sensor/light even when the central server is down.

Moving intelligence in the network itself would require more updates of the remote nodes (rule changes). So this mesh has to be able to deliver code over RF as well. I'm looking forward for jcw publishing some more details about his wireless bootloader.

This is clearly my longest post to date ;-)


Hi Thomas, me too i write with an external editor to develop my library. otherwise it would be big pain.. EmbedXcode needs osX i think, i use Linux, do you know if it is possible to use it there?

for the TDMA problem, i think cheap edge nodes will be as primitive as possible, maybe even running without crystal. then 5-10% off are realistic. however with a standard crystal things look better. including a RTC chip which can generate an interrupt would be an elegant solution. chips could sleep until rtc wakes them up.

how many nodes do you have at the moment? delay would be interesting, at the moment i work a 9600 baud thats the number one delay parameter i think.

i hope to find time next week to solve this #include problem so i can upload the new version. alternativly i could upload hex files for the board to test!


Jumping in here. I have already developed a mesh network using my take on the BATMAN protocol. Ill get to discussing that later, but I post some thoughts on what I have read before I forget them.

My one concern I had with synchronized time was power consumption, which shouldn't have been. A DS1307 can run for 9 years off a Lithium coin cell battery (CR1225 41mAh)! However I decided that using synchronized time was only adding another point of failure to the system.

One thing I would like to add to keep in mind is that while the clocks on the AVR are inaccurate in the long run they can be used to switch on devices on the second so long as they are synced on the hour.

The problem with being pro-active is that it consumes power. The problem with being on-demand is network delays. My solution, as yet unimplemented in my code is to do both. Be pro-active while the node is unsure of its situation. Essentially gain confidence in routes. If nothing changes (eg. good connection between a set of permanently powered units) then network administration is reduced to nothing. As soon a new node is introduced its lack of confidence in the network spreads. Similarly if a node cant contact a neighbor it starts doubting the node connection is still present, which again propagates.

Overlapping transmissions was a big concern of mine. However I decided it was an issue I could tackle later, and just added a random delay to transmissions that could collide. Even with as much traffic as I have (rfid mesh with 20+ jeenodes) it seems to work out fine 99% of the time. And if you dont receive an ack just resend!

Acks are a must! Even between two nodes with a good connection, and no other rf traffic in that frequency, you will get packets that do not reach their destination.

"Edge-nodes" are actually very similar to my "rfid tags". They communicate with the mesh, but they arent relays. One idea I had, which I feel is very important, was to allow nodes to implement their own protocols, which is what I call net commands. My implementation is something horrific, but I am not a c++ developer. While they have their own protocol they can still implement partial or full support to communicate with any other node.

I have to get to work, so I will have to end this here.


Also while RSSI does play a huge role in link quality, it doesnt necessarily mean it is the most stable route to take. I think it should be used more as a minimum threshold to filter bad hops, than as something integral to determining the route.

Premium Drupal Themes by Adaptivethemes