On 4 Sep 2002 at 9:11, James Hillman wrote:

> >Tried a 22k + 10nF RC filter (plus two CMOS schmitt trigger inverters
> >as buffers) between the output of the receiver module and the input
> >of the micro. Time constant is 220us.
>
> >Makes a huge difference! Hard to quantify but I think it at least
> >doubles the working distance. Was having trouble at 5-10m, now better
> >even at 20m+ (BTW, m is for meters, not miles;-)). Thanks Richard.
>
> >That proves, to me anyway, a software filter will help things very
> >much. In the back of my mind though is the thought...shouldn't the
> >data splicer in the receiver module be doing it's job better?
>
> >I'll keep working on it...
>
> Have you considered the approach of sampling the input at a fixed rate
> and then looking for patterns in the data
>
> > The data is sent as a combination of short and long pulses. I
> > receive the pulses OK, and have developed some code that
> > discriminates between short and long pulses, (approx 500us &
> > 1500us), and succesfully recognises each button press. It works
> > well, but not well enough. There is zero tolerance for pulses that
> > are "broken up" during less than perfect reception. This results in
> > a relatively poor range of operation. My assumption is that there is
> > still enough of the pulse getting through that it should still be
> > possible to identify short and long data pulses.
>
> Lets say you sample every 50us and bit shift the result into a rolling
> bit buffer of say 10 bytes (80 bits).
>
> For a strong signal you would see either 10 '1' s in a row or 30 '1's
> in a row for your 500 and 1500 us pulses respectively, with series of
> '0' s in between:
>
> 0000000000111111111100000000000000111111111111111111111111111100000000
> 0
>
> When the signal starts to break up you are more likely to see a few
> '0's where you would expect '1's and maybe a few '1's among the '0's,
> possibly like this
>
> 0010000000111011101101010001001000111110011101110101111001111100000000
> 0
>
> You can filter out these glitches with some form of averaging, for
> example average the last 5 bits on a majority basis so 00011 = 0
> ,11010 = 1 etc ....
>
> 0010000000111011101101010001001000111110011101110101111001111100000000
> 0 would go to this
> XX00000000111111111111000000000000111111111111111111111111111100000000
> 0
>
> this effectively does what the RC filter did, allowing you to look at
> the filtered data and spot sequences of 10+/-2 or 30+/-2 pulses or
> something
>
> I've never tried this on the pic, and coding it could be a bit of a
> headache, but this sort of approach works for cleaning up noisy bitmap
> images etc.

Thanks James,

Yes exactly the right idea. I'm not sure if it's going to be feasible
to do regular sampling at that kind of rate in my application though.
Rolling 80 bits around every 50us might be hard to do.

I may be able to combine this idea with a rising edge interrupt.

I am filing ideas at the moment (and working on other peoples jobs
that seem less urgent to me, but not to them!) I intend to post the
solution when it's done. Thanks again.
--
Brent Brown, Electronic Design Solutions
16 English Street, Hamilton, New Zealand
Ph/fax: +64 7 849 0069
Mobile/txt: 025 334 069
eMail:  brent.brown@clear.net.nz

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads