>I'm really going to upset folks here...
<b> We might surprise you </b>

>No professional would consider the use of SERIN or SERIN2 etc.

It is designed to give you a very simple and easy way of accessing what is quite a complex activity. Because it is so easy to use, everyone uses it.

<b> Exactly</b>

>There is a heap of down-side to all this ease of use... if you have crappy comms for example, it can't handle it. If the input toggles (for whatever reason eg noise), again it can't handle it.

<b>Agree !</b>

>The proper way is to ditch all PBP's serial commands (including HSERIN), and access the PICs UART directly - BYTE AT A TIME and save it in a buffer. You then make a decision YOURSELF, parsing the buffer, whether the bytes that have just arrived are valid or just junk. You're not stuck in a routine WAITing for qualifiers that never come, or hanging about due to noise toggling your pin.

<b>Are you feeling charitable? That's light years ahead of the average poster here. Teach me to fish, I'm all outta beer . . . </b>

>Let me also remind you all, that there is a BIG difference between something like a Remote Control application, where pushing a button repeats the same byte(s) over and over again for as long as the button is depressed on the Transmitter (giving the receiver the chance to catch the transmitted packet multiple times, validate what is being sent and act on it), and a Data Communications Application where differing non-repeating data of variable length and complexity could be sent. In this instance, you must include some kind of error correction in your transmission protocol, because you WILL receive bad data and will need to know how to deal with it at the extreme range of your link.

<b> Argument well founded in fact !</b>

>There is NO simple, painless way of approaching this with SERIN, HSERIN etc. There is a lot of functionality in those commands, but they limit you to using a 100% reliable link. You replace that 100% reliable wired connection with something that is WIRELESS (be it RF, or IR or whatever), then you introduce a whole heap of parameters (noise, signal degredation, signal loss etc) which those PBP commands were never designed to handle.

You are already starting to discover this for yourself... if you eliminate the noise by turning up the squelch to increase reliability, then it is done at expense of range.

You now have to turn to other techniques... if you insist on using those PBP commands, then you must improve the reliability in your hardware (increase power-output at the transmitter, use different modulation techniques, hardware manchester or similar encoding etc, and likewise at the receiving end have a receiver with better signal/noise characteristics, hardware manchester decoding etc).

<b> Thank You Melanie !