Yes, a most interesting thread. This is a real conundrum - there are so many parameters that need to be juggled.
For instance, if you run off solar and batteries, you need to take into account the self discharge rate of batteries, eg NiMh lose about 1% a day, which for a 2400mAH battery is about 1mA. So there isn't much point in trying to get the current much lower than that.
Hope modules use about 20mA. I'm wondering about running at a 1:20 duty cycle eg on for 100ms, off for 2secs. A picaxe would be in charge of that. Another picaxe would listen for a sequence of letters - if no valid sequence then it all goes back to sleep again. This means you could wake up specific nodes.
I'm also pondering data formats. Serial is fine for modules like the Hope, but wherever that serial data goes will hang a picaxe. If a picaxe is listening to a serial signal it will be hanging. If it then sends to another picaxe, that one will be hanging too. How do you do a "fan in" where you listen to several lines at the same time? I'm working on a very simple protocol which could work for wireless and for wired connections. A 'low' is a short high pulse and then a short low pulse. A 'high' is a long high then a long low. If you send a binary 01010101 the receiving unit can work out the length of the high and low pulses using pulsin and then the system is tolerant of different frequencies, different clock rates, and can run at any arbitrary clock rate. It also satisfies the manchester coding principle for wireless where the low and high times are equal.
The other criteria is that the software on a node has to be upgradeable easily, ideally over the network itself. I've now got some CP/M boards working and these do have enough smarts to run a network. So picaxes will handle the lower level stuff like wakeup and sleep and turning on the main board. And CP/M (running compiled basic) can handle upgrades of software and local discovery of nodes and reliability of links.
Three systems could be used for the wireless - raw modules, Hope modules or friendcom. I think the smartest solution is to design a system that can run on all three.
I've also been thinking about a mathematical model to describe a wireless mesh. Think of a wired model. A picaxe with a pin that can be an input or output eg pin2 on an 08M. Ground that pin with 100k. Also, run that pin via a variable resistor 0-1M to a common point. Now build 10 of these and join them all up at that common point. Now inject white noise into that common point via a 10k resistor.
Set two of them with their resistors at 1k. These two nodes are 'near' each other in a wireless sense. When they are transmitting, they definitely move that common point high or low. They easily swamp the noise which is coming in via 10k.
Now let's have a node with 20k into the common point. This node is far away. It's signal is still audibile, but the noise is swamping it.
I think this illustrates two things. Firstly, the point is now how it works when signals are good - but rather how it fails when signals are bad. Signals might be white noise, but worse, they could be partial packets picked up from a node some distance away. Any mesh has to have some sort of filtering - either in the form of a picaxe or the Hope onboard micro. The second point this model illustrates is that only one node can be talking at once. Maybe some nodes won't interfere with others, but it is safest to assume they all interfere with each other. So you need some rules about how to talk. Eg a few bytes to say 'I want to talk'. Everyone else then listens. Then a few more bytes 'I want to talk to x'. All but x go to sleep for a bit, because there is no point being on and wasting power listening to a message that is not for you.
At a higher level, I am thinking about a system which can run various programs (as CP/M can). Eg there are nodes 1, 2 and 3. Node 1 wakes up node 2. Node 1 runs a 'bridge' program on node 2 that routes all messages to node 3. Node 1 talks to node 3. Then node 1 stops the bridge program.
Also you can automatically update software. I use a similar system in some practice management software that runs my surgery. Each program running on 8 computers has a version number. Every few minutes it checks with the server to see if the version number matches. So if you update just the server, it then automatically sends the updated version to all the other computers. Upgrades are thus easy and automatic.
You can do this with CP/M too. But you can't do it with picaxe, so picaxes will have to just do the low level stuff which is unlikely to change.
Another point is that I worry about being locked into proprietory systems. I think this should all be open source. Sure, people can use it in 'for profit' applications, but the system should still be open source.
In the last week, I've got all the jigsaw pieces working. CPM is working. Picaxe to CPM is working. Wireless is working. Picaxe to PC (and hence the internet) is working.
Now it is a matter of building the software with the appropriate network smarts. I don't know how it will look but I know it will evolve and I think it is possible to code it so it can evolve. Eg, at the simplest level, if you can copy a program to a remote node and run it, you can do anything. That program can copy to another remote node. It can copy files back. So the basic two things are just copy and run. And telling nodes to go to sleep.
Then one can write the code to, say, send a message to node 1,4,6,3 in that order, and for all other nodes to go to sleep. 1 wakes up 4. Sends message. 6 knows it is next so it only sleeps a short time. 3 only got garbled data so it will wake up in 2 secs time. Node 2 got the message and knows it is not part of the route so it goes to sleep a long time. Messages goes from 1 to 4. 1 now goes to sleep for a long time. 4 sends to 6. And so on.
I like the DTMF idea. In fact, with the 64k of program space of CPM, one can think of quite complex programs. Eg when a fax machine first turns on it tries increasing the baud rate till the data doesn't go through. It then backs off a bit so it finds the most efficient baud rate for the noise on that particular line. So one could try RS232. If that doesn't work, fall back to the dual frequency system described above. And if that doesn't work, fall back to DTMF. A lot of this could be software coded too, though I'm not so sure about a DTMF receiver in software. DTMF chips are still out there though - I got some quite recently (albeit in surface mount). But both picaxe and CPM can do serial, and tones and variable pulse widths etc. Maybe even some rudimentary DSP (I had a FFT running in compiled C on a CPM computer once).
For instance, if you run off solar and batteries, you need to take into account the self discharge rate of batteries, eg NiMh lose about 1% a day, which for a 2400mAH battery is about 1mA. So there isn't much point in trying to get the current much lower than that.
Hope modules use about 20mA. I'm wondering about running at a 1:20 duty cycle eg on for 100ms, off for 2secs. A picaxe would be in charge of that. Another picaxe would listen for a sequence of letters - if no valid sequence then it all goes back to sleep again. This means you could wake up specific nodes.
I'm also pondering data formats. Serial is fine for modules like the Hope, but wherever that serial data goes will hang a picaxe. If a picaxe is listening to a serial signal it will be hanging. If it then sends to another picaxe, that one will be hanging too. How do you do a "fan in" where you listen to several lines at the same time? I'm working on a very simple protocol which could work for wireless and for wired connections. A 'low' is a short high pulse and then a short low pulse. A 'high' is a long high then a long low. If you send a binary 01010101 the receiving unit can work out the length of the high and low pulses using pulsin and then the system is tolerant of different frequencies, different clock rates, and can run at any arbitrary clock rate. It also satisfies the manchester coding principle for wireless where the low and high times are equal.
The other criteria is that the software on a node has to be upgradeable easily, ideally over the network itself. I've now got some CP/M boards working and these do have enough smarts to run a network. So picaxes will handle the lower level stuff like wakeup and sleep and turning on the main board. And CP/M (running compiled basic) can handle upgrades of software and local discovery of nodes and reliability of links.
Three systems could be used for the wireless - raw modules, Hope modules or friendcom. I think the smartest solution is to design a system that can run on all three.
I've also been thinking about a mathematical model to describe a wireless mesh. Think of a wired model. A picaxe with a pin that can be an input or output eg pin2 on an 08M. Ground that pin with 100k. Also, run that pin via a variable resistor 0-1M to a common point. Now build 10 of these and join them all up at that common point. Now inject white noise into that common point via a 10k resistor.
Set two of them with their resistors at 1k. These two nodes are 'near' each other in a wireless sense. When they are transmitting, they definitely move that common point high or low. They easily swamp the noise which is coming in via 10k.
Now let's have a node with 20k into the common point. This node is far away. It's signal is still audibile, but the noise is swamping it.
I think this illustrates two things. Firstly, the point is now how it works when signals are good - but rather how it fails when signals are bad. Signals might be white noise, but worse, they could be partial packets picked up from a node some distance away. Any mesh has to have some sort of filtering - either in the form of a picaxe or the Hope onboard micro. The second point this model illustrates is that only one node can be talking at once. Maybe some nodes won't interfere with others, but it is safest to assume they all interfere with each other. So you need some rules about how to talk. Eg a few bytes to say 'I want to talk'. Everyone else then listens. Then a few more bytes 'I want to talk to x'. All but x go to sleep for a bit, because there is no point being on and wasting power listening to a message that is not for you.
At a higher level, I am thinking about a system which can run various programs (as CP/M can). Eg there are nodes 1, 2 and 3. Node 1 wakes up node 2. Node 1 runs a 'bridge' program on node 2 that routes all messages to node 3. Node 1 talks to node 3. Then node 1 stops the bridge program.
Also you can automatically update software. I use a similar system in some practice management software that runs my surgery. Each program running on 8 computers has a version number. Every few minutes it checks with the server to see if the version number matches. So if you update just the server, it then automatically sends the updated version to all the other computers. Upgrades are thus easy and automatic.
You can do this with CP/M too. But you can't do it with picaxe, so picaxes will have to just do the low level stuff which is unlikely to change.
Another point is that I worry about being locked into proprietory systems. I think this should all be open source. Sure, people can use it in 'for profit' applications, but the system should still be open source.
In the last week, I've got all the jigsaw pieces working. CPM is working. Picaxe to CPM is working. Wireless is working. Picaxe to PC (and hence the internet) is working.
Now it is a matter of building the software with the appropriate network smarts. I don't know how it will look but I know it will evolve and I think it is possible to code it so it can evolve. Eg, at the simplest level, if you can copy a program to a remote node and run it, you can do anything. That program can copy to another remote node. It can copy files back. So the basic two things are just copy and run. And telling nodes to go to sleep.
Then one can write the code to, say, send a message to node 1,4,6,3 in that order, and for all other nodes to go to sleep. 1 wakes up 4. Sends message. 6 knows it is next so it only sleeps a short time. 3 only got garbled data so it will wake up in 2 secs time. Node 2 got the message and knows it is not part of the route so it goes to sleep a long time. Messages goes from 1 to 4. 1 now goes to sleep for a long time. 4 sends to 6. And so on.
I like the DTMF idea. In fact, with the 64k of program space of CPM, one can think of quite complex programs. Eg when a fax machine first turns on it tries increasing the baud rate till the data doesn't go through. It then backs off a bit so it finds the most efficient baud rate for the noise on that particular line. So one could try RS232. If that doesn't work, fall back to the dual frequency system described above. And if that doesn't work, fall back to DTMF. A lot of this could be software coded too, though I'm not so sure about a DTMF receiver in software. DTMF chips are still out there though - I got some quite recently (albeit in surface mount). But both picaxe and CPM can do serial, and tones and variable pulse widths etc. Maybe even some rudimentary DSP (I had a FFT running in compiled C on a CPM computer once).
Last edited:
