A picaxe wireless transceiver


New Member
RF transceiver modules are great, but I've been wondering if one could be built using a picaxe and raw RF modules. Attached is a preliminary schematic.

The module has RS232 D9 male or female plugs (install either) and a max232. Or you could leave those components out for TTL. Transmission goes straight to the module via an inverter. Transmit also turns off the receiver for a short time so the receiver doesn't hear its own signal.

Raw RF modules can be as low as $2 for a Tx and $2 for a Rx, though this design has slightly more expensive ones (higher power Tx and more sensitive Rx). But you could use any sort of raw RF module.

The picaxe acts as a RF 'filter', in that it won't respond unless it gets UUUUU wakeup plus a valid header (eg ABC). A packet can be up to 14 bytes.

The RC time constant is affected by the baud rate. Eg at 1200 baud and 10ms you will need to wait at least 12-15ms after a transmission for a reply to come through. However, at the other end, it will have received 20 or so bytes and then has to process them and then send out 14 bytes (and then whatever is at the other end has to process them) and this will take at least 15ms anyway. At 4800 baud the RC time constant would by 1/4.

Serin hang is always an issue, and if one didn't want whatever chip was connected to this module (ie another picaxe) to be stuck in serin hang, one could always implement RTS and CTS via spare pins on the 08M - eg raise a line to say some data has arrived, then wait for the other micro to acknowledge it before sending on.

Can this be simplified further? Thoughts etc would be most appreciated.



Technical Support
Staff member
I think it depends on what you are attempting to do and how this transceiver fits in with the scheme of things. If it were to provide a transceiver for a PC it might be easier to build it with very simple hardware, move control into the PC; it controls power to the transmitter via the RTS line, waits a while then sends the data and can simply ignore whatever comes back in from the receiver without even turning it off. Not a PICAXE in sight, probably just 74xx inverters.


Yes, I think let the PC take the strain too.

What prevents sod's-Law spurious noise causing a false PICAXE serial read?
If that happens then a genuine packet might not get read completely.

I would spend an extra couple of pennies and start of with RF modules which have RSSI. Makes things much for flexible.

Anyway, I'm sure you'll get it sorted drac.


Senior Member
Of course, using a PC has the advantage of having 'infinite' processing power (compared to PICAXE based systems).
BUT (and you knew that there would be one!:D) for wireless remote stations, the DC power constraints would be exhausted rather quickly using a PC. Using a PICAXE as a base (or almost any other uC), power requirements of the processor comes down to mA, if not uA, using various sleep modes.


Senior Member
Dr_A: Even given our mutual 433 MHz interest I'm not sure just what you've got in mind here. At first glance I'd thought you were looking at the old CMOS logic chip oscillator trick. A variation on this uses a 1 MHz crystal oscillator module =>http://sci-toys.com/scitoys/scitoys/radio/am_transmitter.html Maybe you are, even thought ranges are only a few metres? A breadboarded NPN 88-108 MHz FM tone version may have some mileage?

2nd opinion - perhaps you're considering a dula module 433 MHz PICAXE transciever in the style of the data repeater => http://www.picaxe.orconhosting.net.nz/all3.jpg ?

Last edited:


New Member
Good points. I've modified the circuit, see attached.

Some background - we now have a wireless mesh with 5 boards all talking to each other using Yishi modules. They are able to exchange files (usually 2k to 50k), automatically update software and build up databases of nearby nodes and exchange those databases with each other.

Further, we also have managed a link between two boards from Canada to Australia using a serial tunnel through the internet. This was done using software on a PC to translate telnet to serial and hence get a BBS type of link working. However, a better low power solution is to use dedicated ethernet to serial devices, each with their own IP address. These have got a lot cheaper recently, and there are even boxes with 8 or 16 outputs that look like router boxes with cat5 sockets, except the cat5 sockets are actually serial sockets.

Next job is to bring it together with internet links and wireless links. And to get the cost down. Just in the last few days for instance, the guys over at the propeller forum have managed to put a CP/M computer into an $8 40 pin chip. 2 pins for a keyboard, some pins for a vga and some to a max232 for serial. Plus a 2G microSD for storage. This little circuit here is another way of getting the costs down for the short haul RF links.

Yishi will do the medium range RF, Stocky's radio data modems can do the long haul, and the Lantronix modules will interface it all to the internet.

Some simple sensor nodes don't need a complicated CP/M computer - they might just be sensing one thing or turning one relay on and so are perfect for the smaller picaxes. But there is the problem of serin hang.

I guess working with all these parts, you kind of need a standard way of connecting things and I've gone for RS232. It means there are lots of redundant max232s, but the advantage is you can't zap things by connecting powered boards to unpowered boards, or by plugging things in the wrong way.

On the circuit below, you can install the max232 and the inverter chip, or talk to it using TTL logic eg from another picaxe chip. The module is meant to be a standard sort of module, like the Yishi ones, where you can plug it into another picaxe (with max232), or into a CP/M board, or into a Lantronix device, or into a PC.

The protocol on this version is a bit simpler. Transmission just goes straight out. But when a device is transmitting, it also raises CTS from -9 to +9V. (TTL 0V to 5V after the inverter) The picaxe is listening all the time, and if it hears a packet and CTS is -9V then it sends the packet through. But if it hears its own packet coming back, ie CTS is high, it does not send it through. Further, the picaxe buffers a packet till the controlling device is ready, ie it gets a packet, then raises RTS high (-9 to +9V on the RS232), and when the controlling device is ready it puts CTS high, and the packet is sent through.

There is nothing really new or unique about this, especially with the concept of using extra lines as flags to get around the serin hang problem. I suppose the main thing here is to formalise what those flag lines are and to describe them in terms of RS232 lines. It is easy for instance to write vb.net code to use RTS and CTS, as it is also easy to use a picaxe with flags. Though it does use 4 lines instead of two.

Re spurious reads, it would use what we already know works, ie UUUUUUABC and then 14 data bytes. The picaxe on this module would just pass them through and do no error checking. It would be up to the controlling device to do the error checking, as some of those 14 bytes might be a checksum. Or perhaps I might write a version of xmodem that sends data in 14 byte packets rather than 128 bytes? And xmodem includes error checking as part of the protocol, and asks for up to 10 resends if a packet is corrupted.

This also might be easier to use in some situations than transceiver modules, because these modules don't implement handshaking, so you are either stuck with a picaxe in serin hang, or have to use one of the more expensive picaxes.


Last edited: