The SERIN2 timeout function doesn't seem to work. I connected it to a RF receiver and it never seems to jump out of the timeout. Anyone knows what the problem is?
Printable View
The SERIN2 timeout function doesn't seem to work. I connected it to a RF receiver and it never seems to jump out of the timeout. Anyone knows what the problem is?
As long as the input pin is toggling (even just with noise), the timeout will keep being reset. Also, I cannot recall which (but you can easily test this), but if the input is in the wrong state when at idle, it won't time out either.
Is there anyway to overcome this?
First identify - is your problem noise or inversion (ie by inversion I mean is the idle in the wrong state for timeout to happen)?
It is noise. No problems when I connected it to GND.
Then you have a problem.
If you have a Carrier-Detect signal from your RF module, you can AND that with the input going to the SERIN pin like a pseudo 'Squelch' control. This will solve some of the problem BUT it will be at a cost of Range and introduce a few other problems which for brevity I'll skip at this time. It is not a full proper solution but it's easy for those that don't know better.
Everyone feeds the output of the RF module straight into a PIC and expects results. This is not the professional way to go. SERIN does a lot for those that can't do it for themselves, but there are limitations - and you've just come across one of them.
With Radio, a single noise spike in the wrong place can easily destroy a complete data packet (or prevent a timeout) and it is therefore unwise to try to use SERIN (or for that matter the Hardware UART) directly. Just because everyone uses this method, or details it in their applications books, does not mean it is the correct way to go. It is NOT. It is very very amateurish and no true professional would subscribe to this method of use.
The best method is to take multiple samples of each bit period and reconstruct the data by majority decision. This will handle noise spikes and also the 'jitter' that you get as receivers are operated at the extremes of range. Using this method you get reliability under adverse noise conditions, an extended range far beyond what is achieved using other methods and a controlled timeout. So basically, don't use SERIN, HSERIN, DEBUGIN or whatever, and write your own routine to do what I've just described above.
Melanie