I've done it, very crudely, for a small kit robot called Cybot, details are at . Really you should use a more reliable system, Manchester coding is often used, I just used inverted RS232 - it worked fine for my application, but reception errors weren't a problem.
I was interested in the experiments in transmitting RS232 in your link, Nigel. A few years ago I had the job of sending 18xbyte data streams at 1200baud via a radio link. This was really at a lower speed than the data slicer in the receiver was designed to work at (min 4800baud).
I added start and stop bits to make 10bit words and then sent each byte normally, followed by the same byte inverted. There were as many '0's as '1's in the total transmission, so the mean level of the data did not change and the data slicer coped OK.
A further advantage was that sending each byte twice gave near-perfect error checking.
They have simple ASK (or OOK) low range Tx, Rx modules for really cheap. However, as in "cheap" modules like that, they do not have RSSI squelch, and doing direct RF modulation is not truly recommended. You can try Manchester encoding (nice side benefit of embedded clock), or bit padding to improve DC balance. You can also try sending each byte three times (with the middle one inverted). That also improves DC balance.
A good suggestion is using audio range FSK. Use one of the timers in your microcontorller with a suitable pair of divisor to get two fairly close frequencies within the audio range. In the Rx, use a PLL with center frequency midway between the two mark/space frequencies. The NJM2211 (Digikey) is ideal for this. It even cuts off if it does not detect any valid data.