Musings re picaxe comms

moxhamj

New Member
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.
 
Last edited:

ciseco

Senior Member
Hi,

The way we background receive is to use X parts and hsersetup mode 0

Then periodically check HSerInFlag think you can also set an interrupt for it.

I've long since given up with the lower end models as they don't have this feature and I can't get more than one or two functions into the available code space, saving the sensor settings in eeprom reduces this still further, is a shame but unless I get into assembler I can't get a square peg into a round hole.

One of the experienced guys might be able to implement the more difficult bits into a PIC design as a Drac protocol buffer before the picaxe. A blank F886 (28x1) is less than the cost of a 08M.

That's all I can suggest, sorry I can't be of much more use :(

Miles
________
juggalos
 
Last edited:

hippy

Technical Support
Staff member
Once you reach a critical mass of requirements which are hard to implement on a PICAXE I'd suggest it is time to look elsewhere, keep the PICAXE's for what they can do.

If you need a number of serial inputs, all asynchronous, none blocking there are three options - a micro with a set of external UART's, or better a micro with a lot of on-chip UART's, ideally IMO, a micro with multiple CPU's each controlling one ( or more ) on-chip UART.

For multiple comms inputs my choice would have to be a Propeller Chip. That can handle up to 8 RX/TX software UART's each running at 115200 baud upwards with 4KB buffering on each with flow control. If you don't need such high-spec even more UART's could be controlled. Best advantage is it's a single chip ( DIP available ) package ( plus Eeprom ) so smaller footprint and probably just as cheap as using external UART's, certainly a lot easier.
 

boriz

Senior Member
Thought:

Data is encoded into base 16 (Hex). TX sends PWMOUT signals at 16 discrete frequencies, each corresponding to a Hex digit (Hit?). RX uses COUNT command to distinguish between digits and re-codes the number back into binary or whatever. This means data can travel as nibbles. I figure maybe 100 Baud-ish?. And it ticks all the good Doc’s boxes. It should have pretty good noise resistance too. But would it work?

COUNT command: “At 4MHz the input pin is checked every 20us, so the highest frequency of pulses that can be counted is 25kHz, presuming a 50% duty cycle (ie equal on-off time).”

If base 16 is too ambitious, what about base 8?
 

moxhamj

New Member
Yes, certainly pushing picaxe to its limits here. Raw pic has advantages and I've been playing with some code and a raw pic programmer. It isn't as easy as picaxe though. For a start my programmer wouldn't program - till I did a trace on the PCB and worked out the chip goes in upside down! Good old picaxe by comparison "just works".

Count sounds interesting. Counting individual bits isn't the most effiecient, but intuitively neither is counting 0-255 and sending whole bytes. A nibble probably is the most efficient. I might see how that looks in code.

The other problem I guess is the project that just keeps evolving. It would be a real pain to upgrade 20 units out in the field. Hmm - moving towards upgradeable firmware via wireless. Possibly a Z80 with picaxe support.
 

manuka

Senior Member
Boriz- I'd pondered "IR over RF" when the 08M arrived, but initial trials were not helpful. As 08M's have inbuilt RX/TX IR features it is tempting however. Maybe time for another look see?

DTMF- legendary robustness of course, but (given the chip sets needed) no real RX power saving. The latter has high priority with Dr_A. Mmm- Dr_µA ?

I've had a fair exposure to assorted soundcard based digital modes now much favoured by radio hams, & suggest considering the features of these-perhaps starting with DomoinoEX as covered by Murray Greenman ZL1BPU => http://www.qsl.net/zl1bpu/. Alert- Murray is strongly ham radio focused, & is really sensitive to copyright issues if his ideas are used for "commercial" purposes. I once innocently used a Googled WW2 1940s era Hellscreiber picture that he subsequently claimed ownership of, & had to print a SiChip apology!
 
Last edited:

ciseco

Senior Member
"My experiments conclude this needs xtal accuracy"

Haven't tried this yet, but did cross my mind when I was having to tweak the frequency of the internal resonator to get 9600 comms to perform properly.

What I thought was you could have a bit of code that receives a predefined string and loops round tweaking it's self until the message matches byte for byte what you have sent.

When I was testing, if you recieved for example 8 bytes, it usually got 8 bytes but the characters were somewhat out. The idea was to loop up and down calibfreq till it matched what I had sent.

If it's wildly out this might not work however as you might not even get all the 8 bytes received.

Just a thought

Miles
________
Jeep Cherokee (SJ) specifications
 
Last edited:
Top