I’m working with some interesting design criteria:
1) picaxe to picaxe communication with no serin hang (multiple inputs to one chip)
2) comms between picaxe and other micros which have no uart – eg tolerant of timing errors
3) wireless comms where the average DC value must be zero
4) Low power wireless modules using microamps that can wake up a picaxe using simple circuitry.
5) Ability to handle more than 14 bytes in one packet
6) A comms system that uses the same protocol for wires and for RF.
The problems are:
1) Serin hangs the picaxe. It is hard to see how a picaxe can read multiple serial inputs at the same time. You can have handshake lines but that takes another line and with radio, another line = another frequency. You can send back an acknowledge but then the sending picaxe might go into a hang. And even if this is solvable, it is hard to poll multiple lines.
2) Picaxes still need to talk to other picaxes! Think of a robot with a brain and multiple limbs, each limb having its own local controller. The brain can send out data to all the limbs. But all the limbs can’t send data back at the same time very easily with serin/serout.
3) A single wire-or bus works and I’ve used those, but there are problems. As a minimum, a dedicated picaxe is needed to send out dummy packets to the bus to kick any other picaxes out of a serin hang if they are stuck. And there is a maximum number where data clashes start occurring. If you then design a send/acknowledge system, a) you need the bigger code space of an 18X or better, and b), the acknowledge packets crowd the bus even further and soon it grinds to a halt.
4) Wireless comms go further if the DC average of the signal is zero. For example, sending a long series of binary %00000000 will upset the DC average – ditto long series of %11111111.
5) It would be very useful to have a comms protocol that worked reasonably fast and worked on wires and wireless. Then protocol translation would not be needed.
6) A picaxe uses about 3mA, but there are wireless RF modules that work down in the microamps. If you buy one with an onboard micro, they tend to be more complicated and more expensive. Surely it is possible to “roll your own”? The default ‘no signal’ state using a wired system is a zero (or a 1). But the default ‘no signal’ state with RF is random white noise. Any comms system should be able to cope with either state. If a node/board can monitor the status of a single comms wire, or a RF receiver, the total resting current can be very low. Nap/Sleep may miss short packets.
7) The packet size with serin is limited to the 14 bytes b0-b13. Add in a checksum and you have even less. Sometimes a long data stream may be needed – and this data stream could be produced by a picaxe that is sensing rapidly changing inputs and sending out the data on the fly.
Manchester coding has some very useful properties. http://en.wikipedia.org/wiki/Manchester_coding
But as pointed out in the article, if you get out of sync by one pulse width, you can read out invalid data. You can correct for that with checksums but then the packet would need to be resent. You could send some synchronisation pulses at the beginning with a series of “0”s which is a tone, then a single “1” to synch.
Manchester coding resynchronises on each bit. This compares with RS232 comms that synchronise at the beginning of a byte, but then the next 8+2 bits need to stay synchronised. My experiments conclude this needs xtal accuracy.
However, Manchester coding doesn’t quite suit picaxes. If you detect a change in the line – positive or negative edge, you then need to start a clock for 1 and a half times the pulse width. This implies a delay counter and to get the resolution you might need a delay of at least 10, and that limits the baud rate to 100 or so. I think it can be done faster.
The next interesting coding system is http://en.wikipedia.org/wiki/Biphase_mark_code
This does have the nice property that it does not care about polarity. But it still has the baud rate problem.
The problem with both of the above is you can’t use pulsin because the phase keeps changing. If you read in a positive pulse, you then want to read in the width of the following negative pulse, but the transition has already happened when the positive pulse ended.
The thing with manchester type coding systems is they all assume that the width of a data period must be the same for a 0 and a 1. But that does not necessarily need to be so. A 1 can take longer to send than a zero, and indeed, this may suit picaxe better.
This leads to a proposal for a new data comms system.
A zero is a short positive pulse followed by a negative period of the same duration as the positive pulse.
A 1 is a longer pulse followed by a longer duration negative period.
Pulsout is a bit tricky. It can generate the positive pulse, but the negative pulse would not work straight after. But it does not really matter, one could do a pulsout then a pause for 1ms.
A 0 would be a pulsout of 1ms and a 1 would be 2ms.
The pulses are read using pulsin. If they are short, it is a 0. If long, it is a 1.
The receive code thus ends up quite simple – use a pulsin, if > a certain value this is a “1”. Start with b0=0 and b1=1. If the bit was a 1, add b1 to b0. Then multiply b1 by 2, and repeat 8 times.
This system has another interesting property – it can pause for a little while between bits and bytes, (as long as the pause is less than the pulsin timeout of 0.655 secs). So a picaxe could read an adc, send a byte, read an adc, send a byte, and thus create a data stream of hundreds of bytes – far more than using serin/serout. A receiving picaxe might take these bytes and reconstruct the original voltage using pwmout – so you could send an AC waveform.
But one of the most interesting features of this comms system is the ability to wake a sleeping circuit. Certainly, a wired comms system can use Sleep and Nap and the picaxe can wake up, test the status of a line and go to sleep if it is low. But this doesn’t work for radio. As soon as it wakes up, it will read in some white noise, which is essentially random low to high to low transitions, will trigger a pulsin, this will timeout with some random value, then the picaxe will go to sleep but it could be awake half the time reading rubbish data.
But 74HC chips use only 80uA and 74HCT chips only use 2uA. So a wakeup circuit should be possible using a few discreet chips.
Consider a wakup signal which is a series of 0’s. This is essentially a tone, of maybe 500Hz. If this goes into a non retriggerable monostable, and the period of the monostable is 1ms, then the output of the signal and the output of the monostable will be high at the same time. Eg 74HCT221. If these go into an XOR gate, and the output of that goes into an RC network and then into another gate, when the signals mostly match then output will go high and that can wake up the picaxe. This uses two chips. There are lots of other tone detector chips – but the key parameter here is microamp current consumption.
I think this could combine a number of useful things. Reasonably fast comms. Relatively simple code. Multiple inputs to one chip. Works with RF and with wires. And a low power wakeup system.
Thoughts and suggestions would be very much appreciated.
1) picaxe to picaxe communication with no serin hang (multiple inputs to one chip)
2) comms between picaxe and other micros which have no uart – eg tolerant of timing errors
3) wireless comms where the average DC value must be zero
4) Low power wireless modules using microamps that can wake up a picaxe using simple circuitry.
5) Ability to handle more than 14 bytes in one packet
6) A comms system that uses the same protocol for wires and for RF.
The problems are:
1) Serin hangs the picaxe. It is hard to see how a picaxe can read multiple serial inputs at the same time. You can have handshake lines but that takes another line and with radio, another line = another frequency. You can send back an acknowledge but then the sending picaxe might go into a hang. And even if this is solvable, it is hard to poll multiple lines.
2) Picaxes still need to talk to other picaxes! Think of a robot with a brain and multiple limbs, each limb having its own local controller. The brain can send out data to all the limbs. But all the limbs can’t send data back at the same time very easily with serin/serout.
3) A single wire-or bus works and I’ve used those, but there are problems. As a minimum, a dedicated picaxe is needed to send out dummy packets to the bus to kick any other picaxes out of a serin hang if they are stuck. And there is a maximum number where data clashes start occurring. If you then design a send/acknowledge system, a) you need the bigger code space of an 18X or better, and b), the acknowledge packets crowd the bus even further and soon it grinds to a halt.
4) Wireless comms go further if the DC average of the signal is zero. For example, sending a long series of binary %00000000 will upset the DC average – ditto long series of %11111111.
5) It would be very useful to have a comms protocol that worked reasonably fast and worked on wires and wireless. Then protocol translation would not be needed.
6) A picaxe uses about 3mA, but there are wireless RF modules that work down in the microamps. If you buy one with an onboard micro, they tend to be more complicated and more expensive. Surely it is possible to “roll your own”? The default ‘no signal’ state using a wired system is a zero (or a 1). But the default ‘no signal’ state with RF is random white noise. Any comms system should be able to cope with either state. If a node/board can monitor the status of a single comms wire, or a RF receiver, the total resting current can be very low. Nap/Sleep may miss short packets.
7) The packet size with serin is limited to the 14 bytes b0-b13. Add in a checksum and you have even less. Sometimes a long data stream may be needed – and this data stream could be produced by a picaxe that is sensing rapidly changing inputs and sending out the data on the fly.
Manchester coding has some very useful properties. http://en.wikipedia.org/wiki/Manchester_coding
But as pointed out in the article, if you get out of sync by one pulse width, you can read out invalid data. You can correct for that with checksums but then the packet would need to be resent. You could send some synchronisation pulses at the beginning with a series of “0”s which is a tone, then a single “1” to synch.
Manchester coding resynchronises on each bit. This compares with RS232 comms that synchronise at the beginning of a byte, but then the next 8+2 bits need to stay synchronised. My experiments conclude this needs xtal accuracy.
However, Manchester coding doesn’t quite suit picaxes. If you detect a change in the line – positive or negative edge, you then need to start a clock for 1 and a half times the pulse width. This implies a delay counter and to get the resolution you might need a delay of at least 10, and that limits the baud rate to 100 or so. I think it can be done faster.
The next interesting coding system is http://en.wikipedia.org/wiki/Biphase_mark_code
This does have the nice property that it does not care about polarity. But it still has the baud rate problem.
The problem with both of the above is you can’t use pulsin because the phase keeps changing. If you read in a positive pulse, you then want to read in the width of the following negative pulse, but the transition has already happened when the positive pulse ended.
The thing with manchester type coding systems is they all assume that the width of a data period must be the same for a 0 and a 1. But that does not necessarily need to be so. A 1 can take longer to send than a zero, and indeed, this may suit picaxe better.
This leads to a proposal for a new data comms system.
A zero is a short positive pulse followed by a negative period of the same duration as the positive pulse.
A 1 is a longer pulse followed by a longer duration negative period.
Pulsout is a bit tricky. It can generate the positive pulse, but the negative pulse would not work straight after. But it does not really matter, one could do a pulsout then a pause for 1ms.
A 0 would be a pulsout of 1ms and a 1 would be 2ms.
The pulses are read using pulsin. If they are short, it is a 0. If long, it is a 1.
The receive code thus ends up quite simple – use a pulsin, if > a certain value this is a “1”. Start with b0=0 and b1=1. If the bit was a 1, add b1 to b0. Then multiply b1 by 2, and repeat 8 times.
This system has another interesting property – it can pause for a little while between bits and bytes, (as long as the pause is less than the pulsin timeout of 0.655 secs). So a picaxe could read an adc, send a byte, read an adc, send a byte, and thus create a data stream of hundreds of bytes – far more than using serin/serout. A receiving picaxe might take these bytes and reconstruct the original voltage using pwmout – so you could send an AC waveform.
But one of the most interesting features of this comms system is the ability to wake a sleeping circuit. Certainly, a wired comms system can use Sleep and Nap and the picaxe can wake up, test the status of a line and go to sleep if it is low. But this doesn’t work for radio. As soon as it wakes up, it will read in some white noise, which is essentially random low to high to low transitions, will trigger a pulsin, this will timeout with some random value, then the picaxe will go to sleep but it could be awake half the time reading rubbish data.
But 74HC chips use only 80uA and 74HCT chips only use 2uA. So a wakeup circuit should be possible using a few discreet chips.
Consider a wakup signal which is a series of 0’s. This is essentially a tone, of maybe 500Hz. If this goes into a non retriggerable monostable, and the period of the monostable is 1ms, then the output of the signal and the output of the monostable will be high at the same time. Eg 74HCT221. If these go into an XOR gate, and the output of that goes into an RC network and then into another gate, when the signals mostly match then output will go high and that can wake up the picaxe. This uses two chips. There are lots of other tone detector chips – but the key parameter here is microamp current consumption.
I think this could combine a number of useful things. Reasonably fast comms. Relatively simple code. Multiple inputs to one chip. Works with RF and with wires. And a low power wakeup system.
Thoughts and suggestions would be very much appreciated.
Last edited: