Russell,

Correct.  Some batches in the future may be much worse than the sample set I 
get/test.  

The IR receiver module takes care of a lot of the little details (noise 
filtering, etc) in a really small package.  Any discrete solution will 
probably take a lot more space.  And space is tight, since I'm modifying an 
existing application to do this.

Syncing will probably be a problem, since the transmitter puts out 2 
different-length pulses, and is a very simple scheme.  If the PIC starts 
picking up pulses at the wrong time, it will interpret the wrong signal.  
Same reason why I wanted to figure out the startup-time for the IR module.

Now, I haven't seen any IR module with a standby input yet, but I just found a 
much lower power unit on Digikey's website -- Sharp GP1UD26XK, at 200uA max.  
Since I know the start-up/wake-up time for a PIC, I can reverse the 
master-slave relationship between the PIC and IR module -- ie: have this 
module wake up the PIC from sleep (no occasional wake-up to poll for IR 
signals).  Total current draw then (IR + PIC + regulator quiescient) should 
be under 300uA, which I can live with.  I'll have to go thru the datasheet to 
ensure that it's timing constraints are fine for my app.

Cheers,
-Neil.


On Monday 02 May 2005 02:59 pm, Russell McMahon scribbled:
> It's going to be extremely product dependent and quite likely not in
> most data sheets. Some testing yourself is liable to be required as
> its not usually something the makers characterise. It's easy enough to
> do it yourself. Power on the RX and send data a variable period
> thereafter and monitor the output. Biggest trap is liable to be to get
> a result which is truly representative of worst case results, which is
> what you want.
>
> You may be better off finding a module that has a low power standby
> mode and an enable input to reduce latency (but I don't know if these
> exist) .
>
> This may be an occasion when rolling your own makes sense. It seldom
> does otherwise.
> The TSSOP4838 draws around 1 mA. I'd have thought a careful discrete
> design could easily enough reduce that by an order of magnitude when
> running.
>
> You could consider synchronising transmitter and receiver to eg 1
> second boundaries so the PIC wakes up at potential transmission time.
> You could arrange so transmission always occurs after N cycles to
> allow occasional clock resyncing.
>
>
>
>
>         RM


-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist