Bruce,

Thanks, I've not yet tried out the code but it is exactly what I wanted. I note that you work at Renton - that's the place I get my LINX radio modules from - I am using the 433 MHz Long Range type - easy to use and reliable. Thanks

Melanie & Others

I am obviously not getting my point over. It would be a foolish person who claims an expertise in radio communications but I'm far from a beginner (but I am a relative beginner at PBP and Assembler stuff). I do understand data encoding, modulation, statistical nature of noise, error detection, error correction, CRC, Manchester encoding and lots of other aspects of telecommunication - it has been the area I've worked in for many years.

However, this does not make me right and you wrong but please, if you are interested, have a careful read of the following:

1. When in range my radio link works perfectly.

2. The code is SERIN2 RXPin, 200, Lost_Signal, [Wait(!), My_Data]

3. Now lets assume that the robot goes out of range.

4. The Rx module receives noise that causes the RxPin to leave the idle state.

5. The software now sits there and waits for a '!' and it will only arrive due to the random nature of noise (a very large number of monkeys typing away at random will, after a significant delay, accidentally type a '!'). The software grabs the gibberish that follows and some software can now deduce that it is gibberish and take appropriate action. For example using a Cyclic Redundency Check, look for some transmitted patern '101010' and so on.

6. But what I was looking for is a means of taking action BEFORE the noise makes a '!'

The cause of this difficulty is using the WAIT("!") approach and combinig it with the 200, Lost_Signal.

Lost_Signal is useful when there is a squeltch type noise suppression or the signal is way stronger than the noise and false triggers are not likely to occur.

WAIT("!") is useful to synchronise the Tx with the Rx.

I guess one just has to abandon the business of using WAIT("!") and instead grab everything the receiver gets and use error detection/correction to deal with the noise. Or use the stop-watch approach?

I was looking for anyone with experience in this area.

Regards Bill legge