Long ramble - then I'll try to answer this!
Yes, I think a number of us might have a "wish list" for timeout. I've been working on a board for the last 6 months and the latest incarnation is that this is one problem that might have to be done with a Z80 in machine code rather than with picaxe. But the problem is a bit complex so that is nothing against picaxe!
For radio - using a dedicated 08 is a good solution. This then can pass the data along to the main picaxe. But this handshaking cannot use Serout/Serin otherwise the hang problem is still there. So you have to hand code your own protocol using high/low commands (I've replicated the RS232 protocol but at 1 baud). Or clock in the signal using a clock line. Any protocol really, as long as it uses instructions that do not time out in any way.
Or, the main picaxe can be one of the newer picaxes that has a timeout.
The problem I'm up against is how to build a system that listens to 5 different lines at the same time - 4 RS232 lines and a radio link. You can have 5 08s all acting as filters and buffers and talk to the main picaxe with slow serial as above. You could make the main picaxe an X2 and poll the lines - but this might risk missing a packet. Or you can go to a machine code solution and poll all the lines so quickly that nothing is missed, and read in all the lines in parallel. Machine code is at least 1000x faster than picaxe code.
I'm still pondering the merits of all the above solutions. And then I have another design parameter - down the track it would be great to send large amounts of data - eg pictures, and most picaxes can only handle 14 bytes in one packet.
Using seperate 08s is a bit of a pain as there are now 6 picaxes on the board, but it does have the advantage of allowing asynchronous comms - data can be arriving all at the same time and it can be buffered until the main picaxe is ready for it.
But there are also advantages in machine code, and it may help solve the problem of dropped packets. Even with lots of header "U"s, some packets don't go through. I think this may be to do with framing errors. A radio Rx is receiving random noise before the signal starts, and the serin will be sitting in an endless loop waiting for a low to high transition. If it picks one up, it reads in a byte, and checks for a low stop bit at the end. If that isn't there, it assumes that byte was not valid and tries to read the next byte. I'm not exactly sure how that happens, but I think the probability of framing errors is halved with each "U" that goes through, so after there are 4 "U"s, the probability of a framing error is 1/2^4 = 1/16. The mathematical problem is how the system moves towards a correct beginning of a byte if it happens to start in the middle of a byte. One would need to see the source code for Serin to answer this properly. Suffice to say that 8 "U"s and "ABC" makes for a very reliable header, but you still need a checksum word, and now all these extra bytes are more than the number of data packet bytes.
With machine code, one can read in the actual waveform with many captured bytes into an array, and then compare this with an array containing, say, "UUUUABC", and check for the % match or even a fancy check with a corellation coefficient.
Or there are other algorithms - eg a wakeup can be a series of 255/0/255/0s. In that sequence there will be long periods of high or low, so these can be used to check for a signal vs noise. Then once a signal is flagged as present, send a series of 0s. In that sequence, the only high transition will be 1 bit wide and will be the start bit. So this can be used to synchronise the signal and avoid framing errors. It could also even be used to determine the baud rate automatically as that bit will be of a known width.
With radio, the aim is to minimise the chatter and to keep the packets short. This conserves power, keeps the neighbours happy, and enables lots of picaxes to talk on the same frequency with a low chance of collisions.
Keeping the packets short means even the wakeup bytes and the qualifier bytes should be kept to a minimum.
Going back to the question in post #10, I'm sure RevEd will think about it and may put it in their next revision. But as you can see from the above, serin coding is not simple so they may look at it and decide it is too hard. So if you want something working and working soon, I think the 2 picaxe solution would be the most practical.
I have the "2 picaxe" solution working with radio repeaters and it does work well. The "main" picaxe often isn't working all that hard and some of the repeaters are simply 2 08s.
Addit: To Marky26 - one quick test to check reliability of radio modules is to setup a picaxe producing a 1khz square wave, put that on a protoboard with a tx module, set up a Rx module to a scope, and then go and put your Tx out in the garden. Go back to the scope and see what the waveform does. It is quite informative to see how the waveform distorts depending on distance to the ground, trees, sheds etc. If you are lucky you may be able to persuade a 'significant other' to walk round with the Tx module. My experience is that the distance the manufacturers claim is usually a little optimistic. 50 metre units go 10 metres. 4000m units go 500 metres. I think the figures they quote are the furthest distance one can hear a signal on a scanner using the marvelous noise reducing properties of the human ear, not the furthest distance one can send data.
