Skip to main content

You are here

RF12Mesh library

12 posts / 0 new
Last post
RF12Mesh library

Hy all, I was wondering if this Library is still in progress. Will it be abailable for testing? I am looking since ages for some mesh usage. Thanks

Link to the project

best regards Thomas


well thank for the links i was allready reading through those posts. the thing is the description of the rf12Mesh library sounds really promissing and the manual sounds like it is already usable as it describes how to set it up. that was the reason for me to wonder if this library would be available. so anybody know anything about this. will it be open source?

best regards thomas


Well it seems to me this library will not be available. that kind of sucks. Well it was worth a try thou. Thanks all. Maybe I will find the time to write a similar one. Even though I believe it is inefficient to reinvent the wheel. I will let you know if i do so.

regards thomas


You sound a bit disappointed, but isn't the (at this moment actively-developed) Arduinode library very similar to the one described in the cafe?


Yes you are right but the thing is this library is just unidirectional. I want to mainly address a master node but it must be possible to address anynode in the network. so routing must be possible in all directions. I had a look at his code but I think it would be more work to adapt this library than to rewrite it by myself. Well thanks anyway.

regards thomas


Hi Thomas,

I'm also still looking for something myself. I do have some ideas but I'm far from working code. The simple (static?) hierarchical routing is one of the downsides of Arduinode but it's already proven code, a big advantage. As you could read in the referenced threads above I'm still gathering requirements and sorting through some ideas. This protocol looks promising:

I also found some papers online describing a simple flooding mechanism where multiple nodes send the exact same packet at the same time. If this works using RFM12B's this could be an easy, very fast way to synchronize clocks. I'm currently working on the RFM12B driver itself and didn't have had time to start testing such stuff.

If you start to design a library yourself, please let us discuss requirements and also technical details here.

regards Thomas


@tht, Ello' fellow mesh developer. If you are debating routing protocols take a look at BATMAN. To be honest I am not overly familiar with the finer details of the protocol, but I just recently implemented my impressions of it (based on the concept presented in the reference link) in an unfinished project. Outdated and messy, but functioning, source code is available here.


@expelledboy: Thanks for the link! BATMAN looks like a nice solution for meshes with a lot of nodes on weak hardware where most of the nodes are communication with many others.

But that's not what I'm looking for. On-Demand-Routing does only build a route where a route is needed. So much smaller routing tables. Currently I'm looking into DYMO and DYNMO-low. DYMO-low could be a good base, maybe enhanced with some features from DYMO.

Because of this on-demand-routing the first packet travelling a route will be delayed quite a bit but all further packets should be fast until the route breaks. This is great for mostly static networks what I'm targeting for.


I see. I am guessing you want to limit the routing table size?

Using my implementation of BATMAN I achieved this quite simply by ignoring originators from nodes I didn't want to talk to. The code in github actually has a simplified version where nodes only see the originators from a "master" node.


Exactly. The smaller the better. So how do you decide which nodes you'll have to talk to? What happens when you have to send a packet to a destination you ignored before? For me it looks like quite a restriction when not every node is able to talk to every other.

As far as i can tell there are two completely different concepts:

Calculate all routes all the time: Requires many control-messages which flood the network. Every node knows how to route to all other nodes because of a (more or less) complete view of the mesh on every single node. Very good for fast changing topologies and meshes where everyone talks to everyone.

Calculate routes on demand: No control-messages but a delay for each connection when used for the first time or when a topology change breaks a route. Good for slow changing topologies when sending packets is expensive (battery power) and resources (memory, cpu) are rare.

You've clearly choosen the first approach, I'm preferring the second.

I scanned over your code to find out how you handle the problem with multiple nodes repeating a message at the same time. Looks like you do a simple random wait there. I'm not happy with this one but can't find a much better solution too.

There are quite some libraries out there but is one really used? I don't want to attack anyone here but for me it often looks more like a proof-of-concept code than something which went through a real design process. Here are some of many questions which should be answered before writing a single line of code:

  • Do we need a synchronized time? If yes, how do we distribute it? Does a simpler Lamport Clock work too?

  • Proactive or on-demand routing?

  • How do we prevent overlapping transmissions?

  • ACKs?

  • How do we support edge-nodes which are not full mesh nodes? Do we support battery-powered nodes which are forwarding?

  • Do we support sending data TO battery-powered nodes which are mostly sleeping?

  • How do we integrate other mediums like Ethernet-links?

  • The wireless bootloader (as soon as it's released by jcw) has to work!

It's a very interesting topic, too bad I don't have enough time to dive into it right now.

Please let us continue mesh-related discussion here:



Okay I will have a read through the thread and continue there.

Premium Drupal Themes by Adaptivethemes