Of picaxes, wireless mesh algorithms and the smell of pizza

moxhamj

New Member
With all the talk about radio links, I wonder if I could ask for some input on the following problem:

I am putting together a picaxe wireless and wired mesh. Data packets need to go from any node to any other node, and ideally it would be great for the mesh to be self configuring and to function without a supervisory PC. A simple solution is for all data packets to be forwarded to all nodes but this incurs two costs – firstly it consumes battery power from wireless nodes, and secondly it consumes radio bandwidth. To quote a practical example if a driveway sensor detects a car and wants to tell a porch light to turn on, there is no need for that packet to also go off to the water tank and pump.

The problem thus is for the mesh to discover the shortest paths to get a packet between nodes. Consider the diagram with four radio nodes. A can talk to B and C, but A can’t talk to D directly. The shortest path is ABD or ACD, but there are also quite valid paths ABCD or even ABCABCD. For a human with our fantastic visual cortex, the answers seem obvious when seen in a drawing. But it is harder when looking at things from the perspective of node B which can only see the nodes around it and has a packet it needs to forward on.

So I am thinking laterally here – instead of designing this from a visual perspective, could this be designed from a smell perspective? Assume node D was brewing some really nice coffee, and the smell of that coffee was percolating through all the other nodes, with the smell decreasing the further it traveled. A data packet would just follow its nose. Node C might smell of baking bread. Node B might be the perfume your first girlfriend wore on your first date etc.

So each node first makes contact with nodes it can talk to directly. These are simply radio data packets and they are never forwarded on – only bounced back to the sender. Node B might establish it can talk to node A and C and D. Node A might establish it can talk to node D, but only 10% of the time so that link is flagged as unreliable and is discarded.

Once these links are established (which might take a minute or two from a node being turned on), each node releases its specific scent. Node A releases the wonderful smell of cooking pizza with 10000 molecules of smell (in practice, a data packet with the number 10000.) Node A can talk to node B and C, so it sends 5000 molecules to B and 5000 to C. Node B can talk to node C and D. Each time a node processes some smell it loses some (this is important) – it is a bit like the pizza smell in a room with the windows open. So 5000 molecules arrive at node B but only 1000 are available to pass on. 500 go to C and 500 go to D. Molecules bounce around from A to C to B to D etc as well. Some go from D back to B and C but a lot less than were sent.

So node D wants to send a packet to node A. It notes there was an equal smell of pizza from node B and C so it picks one at random (or maybe some random noise is added to the exact values). The packet goes to B. Now there is a smell of pizza coming from node C, but there is a much stronger smell coming from node A. So the packet ends up taking the shortest path.

If a node is at the end of a chain it doesn’t pass on the smell. Molecules bounce around till there are none left. Each node loses a few molecules along the way and this prevents strong false pathways developing between two nodes like B and C bouncing molecules back and forth.

There probably is a mathematical formula to define the attenuation rate at each node which probably relates to the number of possible paths. I picked 1/5th as I’m expecting most messages to only go through 3-4 nodes.

Questions – is this the best model? Are there other models? Is there a formal mathematical discipline that studies this?

I think it comes in the same class as the travelling salesman problem http://en.wikipedia.org/wiki/Traveling_salesman_problem and certainly that example includes the ant colony problem, which uses the analogy of pheromones which would follow similar rules to smell. The challenge is to get the rules to fit in a picaxe (18X), but then again, an ant trail behaves as a complex organism but the ants themselves are following fairly simple rules as they rub antennae with each other and exchange pheromones.

Input would be very much appreciated as this has real practical applications for wireless picaxe comms.
 

Attachments

stocky

Senior Member
a few random ideas - no real structure just ideas off the top of me head!

  • "ping" for available nodes
  • if using modules with RSSI - you can map which nodes have best signal
  • once you have that, request the nodes in decending order of signal to PING for the next node etc
  • could store available paths to eeprom for later retrieval?
still thinking.........
 

Dippy

Moderator
Well, a very interesting exercise.
I have no answers to the maths, but I have a question.
If all nodes are 'connected' or within range why bother?
The code/handshaking software would take up so much time as in "Anyone there?"," Yes, John" and "Yes,Bill". "Hang on while I see who has the stronger signal"... whirr... "Oh John is closer"... "OK John, I've got a message for Ted"... so the data goes to node John who will then repeat all the previous "Who's closest?" requests . All the nodes are going to spend a lot of time asking "who's there?"
If you have a truly self configuring system it would have to do this every time because a new node may be placed within the loop or a node may have been moved or battery gone flat.

Alternatively, you could ask this only once each time a new node is introduced to the loop and hope everything stays stable and batteries don't fail.

And, of course, many el-cheapo low-cost RF Modules don't have RSSI...

I'd be tempted to try a direct node to node first, then if I couldn't get a reply ask one of the other nodes to try as they may be within range.

But, very interesting and you can chew it over while chewing your pizza.... surgery must be quiet this morning :)
(Our UK GPs have to work all the hours God sends to earn their >£100K per year. yeah right).
 

moxhamj

New Member
Your crystal ball must be working again Dippy, the surgery was quiet today. Yesterday (Sunday) had to stitch up half a football team after they got into some sort of brawl, so nice to have a quiet day today!

The problem is that all nodes are not in range of each other. Packets may need to bounce between a number of nodes to get to the destination. If a typical property is a square shape and the omni distribution of a radio is a smaller circle, the best measure to avoid interference is to have lots of smaller circles that fit into one big square.

The handshaking would only take place intermittently. Maybe once a day. Maybe if a node hadn't heard from anyone for a day. Nodes should not go flat and would not be moving around.

I guess one design parameter is not to have too many variables that need to be set in the field. Eg you name a node back at base, program it to talk to other nodes, then take it out into the field and find it can't talk to some of those nodes. Ideally, if a node goes down, grab a new one with a new ID number, take it out into the field and replace the old one without having to program anything. Keep it simple for the installer (who might be working out in the rain/hail/snow etc).
 

moxhamj

New Member
Can zigbee do this? Last time I looked the mesh was in development but they probably do have it working by now. Also how far do they go (has anyone tested them)?
 

stocky

Senior Member
how far do you think 2mW of 2.4Ghz will go..... :(


and yes i realise there ARE high power versions available (with even more woeful power consumption figures!)
 

manuka

Senior Member
Yes- I did a good XBee workout several years back & managed just ~50metres around the property with the basic 1mW version. LOS ranges were to ~200-300metres but this was EXTREMELY subject to obstructions & even ones body would block signals. With ~12dB WokFi dishes each end we managed 3km LOS point to point across water. Naturally the 100mW pro version should better this considerably, but the $$($) of each station may daunt. Stan
 

moxhamj

New Member
A simulation of the above in VB reveals a need for some arrays of data - eg every node needs to have information about every other node. So node A needs to know what node B is storing about the data paths for other nodes. I think the ram requirements go up as N^2 where N is the number of nodes - and this is beyond an 18X. Time to move up to a bigger chip...

What I have got working tonight is the "store and forward" solution using a number of 18X boards. Stocky, of course, already has this sort of thing working with these Rolls Royce data radios that do store-and-forward and all sorts of other clever things and all at high RF power. I'm hoping that there is a medium price - medium range - medium power solution that could interface nicely with what Stocky has.
 

stocky

Senior Member
I wish I had as much time to spend on this stuff as you Dr_Acula! .
......and I *try* and do it for a living!

:p
 

hippy

Ex-Staff (retired)
I'd have said XBee too - someone's already done all the hard work to handle meshing, it just needs a PICAXE hanging off each end-node.

XBee power consumption may suck but what about traditional 433MHz systems ? Are those really any better ? Some real world figures would be useful. XBee can select its transmission power dynamically which a cheap 433MHz module cannot, it also supports RSSI whic 433MHz may not. There's a lot XBee does which has to be implemented in software when using 433MHz and for a PICAXE that's a lot of overhead.

Also agreed that XBee isn't a universal panacea but we'd need to know exactly what the system constraints are to say if a particular design fits or not. Are we talking mains powered or battery powered for a start ? What are the distances between nodes ? What transmitted power is required ?

The "follow one's nose" analogy and the loss of molecules along the way is probably no different to a Ping Request with Time To Live as used by ethernet to establish routings so just described a little unusually.

Prototyping and experimenting should be quite easy without a lot of cost. A network of PICAXE's can have their serials inputs diode mixed from all other node's serial outs and diodes removed to create out of range - some may only be out of range unidirectionally - and 'rogue PICAXE's' can be used to generate noise and interference to corrupt signals.

I'd personally model this using multiple PC's and diode-mixed serial ports, or more sensibly in VB or similar running multiple instances of the node in a Multi-Document Interface with a mechanism which simulated the serial links. I certainly wouldn't start building any RF network or spending a lot of money until I had the software proven.

Edit : Did it really take an hour writing that ? Dr Acula beat me to it in mentioning simulation.

An alternative to storing routing tables is for each node to try sending to every other node in turn and if it receives a response it passes that back, if no response comes back it doesn't respond to the one who contacted it. Nodes don't pass on any messages if already trying to pass one on.

It's a bit like a maze solving algorithm which uses silence to say wall there or cell is not adjacent.
 
Last edited:

manuka

Senior Member
Are you looking at this with tunnel vision? How much data do you wish to send, & how often, & at what rate? If transfer speed is not too crucial, "store & forward" repeating of a few variables is a doodle with just a 08M & a few lines of code => www.picaxe.orconhosting.net.nz/all3.jpg. Serial qualifiers readily ID messages of course. With an 18X, external RAM & suitable code you could just about run a packet radio digipeater setup.

More imaginative high bandwidth setups abound, such as "Flying mailboxes" LEO satellites,intended for island email etc. At the $ level, rural area store-and-forward VAN (Village Area Network) drive-by WiFi using a Mobile Access Point (MAP) fitted bus/taxi has enormous potential in off the beaten track locations - Google daknet. I can just see Dr_A fitting out his farm dog (or patients) to S&F run up the hill every few hours for a digital woof. Mmm- maybe I should extend that HopeRF article to cover pretty much this in fact- it'd certainly catch readers fancy!

Here's some great Daknet feedback - 1 Rupee (Rs.) is worth about US 3 cents, with a typical rural Indian earning ~100 Rs. daily
“We have two options for accessing the internet for sending emails. Either we go to Khurda which is 35 kms from here and which has some cyber cafes offering broadband connectivity @ Rs. 20 per hour. Second option is to access dial-up internet from one cyber café in Kalapathar, but the charges here are very high @ Rs. 40 per hour and composing and sending one email can take as much as 10 to 15 minutes, because of the slow speeds, costing us Rs, 15 to 20. Therefore, we feel that the DakNet email @ Rs. 1 per email and Rs. 3 per email with attachment which is now being offered in Kalapathar is a very good alternative.”
- Student in Kalapathar Village, Orissa, India commenting on United Villages DakNet Prepaid Services, Sept 19, 2006
 

Attachments

Last edited:

moxhamj

New Member
Thanks everyone for all the input. Lots of ideas to work with now. To answer Hippy's question - some nodes are solar and some are mains. An example might be getting a message to a pump shed - the shed has power, but there might be several intermediate radio nodes to get there due to obstructions. The aim is to have multiple pathways with redundant nodes so if a node or two get taken out then it isn't a "mission critical" situation (ie the installer - me or a commercial organisation doesn't have to rush to fix the problem).

I do have a software solution working now but each message is taking 15 seconds to be forwarded on as each node waits a random time before forwarding to avoid data clashes with other nodes. Am working on speeding this up with more definitive routing. Hope modules are highly relevant - the ones I am using are fine but they need several metres of coax and a dipole and a balun and it takes a few hours to build. The hope transceivers would save some build time.

Picture attached of the test setup. Am working on code now.
 

Attachments

inglewoodpete

Senior Member
Doc, From what I read from your original message, there were 2 angles to your query. The radio (transmission) part has been discussed.

Your communication issue of relaying messages to "remote" stations is a classic internet situation. You will need to develop a simple routing protocol.

At startup, and after that periodically (say, every minute), each station need the send out a "Hello" message. This can be broadcast (where every receiver will respond) or directed to each possible node. In this way, each node will know about its neighbours. Note that when responding to a broadcast massage, each node will need a different response delay so that the node originating the query is not swamped with more that one response at a time.

The response from each node would contain a table of all nodes that the respondent knows about (from it's own, previous, "Hello" message).

Depending on the extent of your network, you could have full 'routing' tables in each node but this may not be necessary or code effective. I imagine you will have a master node, that will need a full routing table so that it can direct data transmissions to specific intermediate nodes for relaying to the required destination.

Data packets directed at remote nodes would have two address fields: the known first (ie next) hop ID and the ultimate ID. The intermediate node(s) would replace its own ID with the next hop, taken from its own 'routing' table.

The complexity will be determined by how many hops are required to the farthest destination and how much redundancy is required for robustness should a single node fail.

Peter
 

moxhamj

New Member
Peter, that is a great explanation. One of the problems is the size of the routing table might grow, but realistically it shouldn't be more than 5 hops. The serout/serin can send 14 bytes in a packet and the number of spare bytes is pretty tight so it is just on the limit to have a packet contain its own route. Your explanation is very good - the question is whether it is better for a packet to contain its own route, or whether it is better for nodes to each contain full routing tables. The latter takes more memory. Hmm - I might look at I2C RAM...
 

hippy

Ex-Staff (retired)
As the nodes are static it should be possible to build a routing table as a one-off during setup and then tell each node the prefered order of nodes to pass on to. This can be held in Eeprom.

It doesn't matter if the routing isn't most efficient as long as the message gets through. It should be possible to flag a message as having not gone through the prefered route so faults can be identified and logged.

AS long as some node is easily connctable to a PC, that can be the master and initiate a re-build of the routing table which the PC can determine and then pass back to each node.

On packet headers, I think you only need who sent it and who it's to plus where the message originated and what it's final destination should be; a letter in an envelope in an envelope. That parallels with TCP/IP where the source and destination MAC cover local hops and the source and destination IP addesses cover originator and final receiver.
 

moxhamj

New Member
I like the logic, hippy! 18X chips don't have much ram but they have heaps of eeprom. And that eeprom has limited writes but unlimited reads. So as long as updates are infrequent (once a week?) then the eeprom will never wear out. So each node can find who is near it, forward this data on to a PC when asked, the PC builds the routing table and sends it back out to the node. Nodes can run on a "send packets to everyone" protocol until they get their routing table.

So if I am node 5 and I get a packet and it originated from node 2 and addressed to node 7, I would look up a table first looking for a match for 2 at the beginning of an array and 7 at the end, and I might get a list of numbers 2 - 4 - 5 - 1 - 7 and if 5 is in that list, then I know who to send the packet to.

The PC can work out the clever algorithms for the paths. Either using the "smell" algorithm, or possibly with a small number of nodes, a Monte Carlo technique.

I've got three boards running and an LCD display and it is very nice watching messages propogate through the system. It has been a real challenge building a board that watches four serin lines at the same time without getting stuck in a hang. The trick has been to put a 100ms pulse before each packet and then search for pulses that are only between 50ms and 150ms, and only then go into a serin. Plus there is a watchdog 08 that can do a master reset if the 18X is inactive for more than 45 seconds but I've been watching it all for an hour and the watchdog hasn't run yet. I'll publish the code once this is all written.
 
Last edited:
Top