Searching \ for '[EE]: IR remote control...' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/io/irs.htm?key=ir
Search entire site for: 'IR remote control...'.

Exact match. Not showing close matches.
PICList Thread
'[EE]: IR remote control...'
2002\10\14@031645 by William Chops Westfield

face picon face
I'm thinking about IR remote control for models, where I want several models
to be controllable simultaneously (meaning, I think, several different
carrier frequencies.)  Now it seems to me that with the off-the-shelf IR
receivers, the supported frequencies are pretty close together and that the
frequency selectivity isn't all that tight (ie 3dB per F/10 for Vishay, so a
40kHz receiver still has a fair amount of sensitivity to 38kHz or even
36kHz.)  You could get three simultaneously usable transmitter/receivers
with 30kHz, 40kHz, and 56kHz, I guess, but I'm rather worried about the
low-volume availability of non-standard frequencies as well.

So.  I'm thinking about doing my own IR receiver.  Icky.  How much of this
could be done in DSP-like software on something like your average PIC?  I
think I only want about 40bits/s of data throughput, so perhaps the carrier
frequency could be cut down pretty far, perhaps getting down into the range
where something like Scott's DTMF algorithms might come into play, but
there's the added complications of rejecting all that noise that will be
present in an optical environment.  (Carrier might be continuous.  Does that
help?)  Any thoughts on the matter?  The ideal HARDWARE is a phototransistor
connected directly to an A2D input pin.  Or less. :-)

Thanks
Bill W

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


2002\10\14@035555 by Wouter van Ooijen

face picon face
> but I'm rather worried about the
> low-volume availability of non-standard frequencies as well.

http://www.conrad.nl or http://www.condrad.de or http://www.reichelt.de or
http://www.voti.nl/shop/products_1.html#IR-TSOP-30

> I'm thinking about doing my own IR receiver.

Don't. This is almost all analog work, not digital. And these receivers
are so damn cheap, you wont even come within 10 * their price, and I
seriously doubt you will match the performance.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

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


2002\10\14@040010 by Russell McMahon

face
flavicon
face
> I'm thinking about IR remote control for models, where I want several
models
> to be controllable simultaneously (meaning, I think, several different
> carrier frequencies.)  Now it seems to me that with the off-the-shelf IR

More details may help.
IF you are  sending from physically isolated TXs then what you propose may
be necessary. If you have a central to TX to multiple RXs then it would be
MUCH easier to have all receive the same signal and differentiate in any of
the normal manners.
The commercial RX modules are liable to be cheap compared to the cost of any
model you are liable to control; and the inbuilt filtering, amplification
and data slicing/demodulation is probably worth the cost. At any range you
are liable to need at least some gain if you want to feed an A/D pin
directly. Possible but, unless this is for a large volume product, unlikely
to be repay your effort.

Even with multiple TXs, unless your bandwidth is full controlling one model,
it would be easier to use a single frequency and time share the ether. You
could either do this with multiple transmissions of the one command or have
a received on each TX and perform some sort of co-operative channel sharing.
Shouldn't be very hard at all (ha!) unless bandwidth is tight.



       RM

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


2002\10\14@042744 by William Chops Westfield

face picon face
   More details may help.  IF you are sending from physically isolated
   TXs then what you propose may be necessary. If you have a central to
   TX to multiple RXs then it would be MUCH easier to have all receive
   the same signal and differentiate in any of the normal manners.

Think toy micro-robots not dissimilar from the miniature RC cars that
are currently being sold (http://www.zipzaps.com)...  nano-battlebots,
or somesuch.

BillW

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


2002\10\14@072406 by Russell McMahon

face
flavicon
face
> Think toy micro-robots not dissimilar from the miniature RC cars that
> are currently being sold (http://www.zipzaps.com)...  nano-battlebots,
> or somesuch.

OK - if you don't mind the participants being hard wired to their
environment you could use a single transmitter as I suggested. If necessary
you could use a number of LEDs at different locations but all driven
together to get coverage in "dark corners" but my experience of IR control
is that it bounces around nicely.

The integrated 3 pin receivers (complete with IR filter) cost a bit over
$US2.retail one off here at hobbyist stores so I imagine in any quantity
they would be substantially less. Very very hard to better that. Performance
(sensitivity anyway) varies quite signifcantly between brands I'm told. I
have tried two different models and both were similar.



           RM

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


2002\10\14@074448 by Olin Lathrop

face picon face
> I'm thinking about IR remote control for models, where I want several
models
> to be controllable simultaneously (meaning, I think, several different
> carrier frequencies.)  Now it seems to me that with the off-the-shelf IR
> receivers, the supported frequencies are pretty close together and that
the
> frequency selectivity isn't all that tight (ie 3dB per F/10 for Vishay, so
a
> 40kHz receiver still has a fair amount of sensitivity to 38kHz or even
> 36kHz.)  You could get three simultaneously usable transmitter/receivers
> with 30kHz, 40kHz, and 56kHz, I guess, but I'm rather worried about the
> low-volume availability of non-standard frequencies as well.

Can the transmitters be connected?  If so, you could use one master
transmitter and therefore one carrier frequency.  All receivers would see
the data stream, and the protocol would indicate which information is for
which receiver.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

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


2002\10\14@074455 by Jinx

face picon face
>3-pin receivers......... Very very hard to better that. Performance
> (sensitivity anyway) varies quite signifcantly between brands I'm
> told. I have tried two different models and both were similar.

Even better are the canned IR receivers in domestic appliances, eg
VCRs and TVs. They use around the same V and I of the 3-pin type
like 1SU60 but are far more sensitive to coded IR. There are plenty
of scrapped VCRs/TVs around and I don't think you'd have much
trouble finding all you need. Most of the ones I've got are made by
Sharp, who also make the 1SU60, but AFAIK the cans are not for
sale

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


2002\10\14@080151 by Wouter van Ooijen

face picon face
> Even better are the canned IR receivers in domestic appliances, eg
> VCRs and TVs. They use around the same V and I of the 3-pin type
> like 1SU60 but are far more sensitive to coded IR.

Do you have datasheets to back that up? BTW here in the Netherlands all
TVs and VCRs that I dissected recently used one of the Vishay/Telefunken
TSOP or SFH 3-pin receivers.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

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


2002\10\14@083106 by Jinx

face picon face
> Do you have datasheets to back that up?

No. I've looked for it but as they don't seem to be available for
general sale probably the data isn't out there either. I tested
several types of IR receiver using a VCR remote and found that
the canned type have a much wider reception angle and will pick
up relections that retail 3-pin or home-made ones won't

> BTW here in the Netherlands all TVs and VCRs that I dissected
> recently used one of the Vishay/Telefunken TSOP or SFH 3-pin
> receivers

Maybe it's an Asian  / Pacific thing. If you open up a can there's
usually an SMT chip or hybrid inside, more than would fit in a 1SU60

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


2002\10\14@084058 by Wagner Lipnharski

flavicon
face
Olin Lathrop wrote:
> Can the transmitters be connected?  If so, you could use one master
> transmitter and therefore one carrier frequency.  All receivers would
> see the data stream, and the protocol would indicate which
> information is for which receiver.


Yes, IR splash is very messy for the receivers.  The actual receivers are
very poor when compared to RF filters.  They can not differentiate between
50 and 55% of IR energy, as to discriminate one of two IR splash at the
same time in the same room, as RF receivers do.

If xmiters should be isolated, then IR is not the best choice.  They are as
dumb as if you try to differentiate a 74HC00 from a 74HC02 in the dark.

VV46NER

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


2002\10\14@084306 by Alan B. Pearce

face picon face
>If necessary you could use a number of LEDs at different
>locations but all driven together to get coverage in
>"dark corners" but my experience of IR control is that
>it bounces around nicely.

I would look into having one transmitter on the ceiling, and require each
bot to have the sensor looking straight up. May save directional problems
with the bots.

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


2002\10\14@084521 by Wagner Lipnharski

flavicon
face
Jinx wrote:
>> Do you have datasheets to back that up?
>
> No. I've looked for it but as they don't seem to be available for
> general sale probably the data isn't out there either. I tested
> several types of IR receiver using a VCR remote and found that
> the canned type have a much wider reception angle and will pick
> up relections that retail 3-pin or home-made ones won't
>
>> BTW here in the Netherlands all TVs and VCRs that I dissected
>> recently used one of the Vishay/Telefunken TSOP or SFH 3-pin
>> receivers
>
> Maybe it's an Asian  / Pacific thing. If you open up a can there's
> usually an SMT chip or hybrid inside, more than would fit in a 1SU60
>

AFAIK, the molded ones I also tested in the past, use digital filtering,
while the canned use some analog what makes them more sensible.  The canned
ones also detect more trash.  Try a cigarrete lighter sparks close to a
canned and scope its digital output.  Even a fluorescent light 60Hz
blinking affect very much the canned output.

Wagner Lipnharski - email:  spam_OUTwagnerTakeThisOuTspamustr.net
UST Research Inc. - Development Director
http://www.ustr.net - Orlando Florida 32837
Licensed Consultant Atmel AVR _/_/_/_/_/_/

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


2002\10\14@113831 by Mark Brown

flavicon
face
I work for a company that develops bespoke hardware solutions and while I
have only recently started using PIC Microcontrollers, I have successfully
used the Sharp IR modules in other applications.  They are the same modules
which are often used in consumer electronic devices (particularly VCRs, CD
players etc) and are pin compatible with the GP1U52X devices popularly
specified in IR remote control projects.  I have datasheets for the devices
we use and I've posted them at
http://www.applestorm.com/datasheets/sharpirmodules.htm.  The devices we use
(and can supply if required) are GP1U271R (horizontally mounted leaded
package), GP1U281Q (vertically mounted leaded package) and GP1U101X (SMT
package).  All have a center demodulator frequency of 38kHz and vary in
price from about USD 2.60 to USD 5.30 depending on package type and
quantities required.

Any requests for products should be sent to me directly at .....markKILLspamspam@spam@mbcc.co.uk

Regards,
Mark Brown

{Original Message removed}

2002\10\14@115601 by Robert E. Griffith

flavicon
face
This was alluded to by others, but to put it in simple terms... If you are
not constantly sending IR data to the models, (bandwidth is not tight), but
rather are sending short commands every once in a while (like turn, stop,
go, etc...), then you can just include a device address with each IR
command.  All receivers listen to every command, but respond only to the
ones with the address set to their own address.  If two transmitters
transmit a command at the same time, they will interfere with each other and
neither will be received.  The operator would just resend the command.

Most consumer IR protocols dedicate some bits to identify the device so
that, for example, your DVD remote does not control your VCR.

--BobG



{Original Message removed}

2002\10\14@130306 by Wagner Lipnharski

flavicon
face
Robert E. Griffith wrote:
> This was alluded to by others, but to put it in simple terms... If
> you are not constantly sending IR data to the models, (bandwidth is
> not tight), but rather are sending short commands every once in a
> while (like turn, stop, go, etc...), then you can just include a
> device address with each IR command.  All receivers listen to every
> command, but respond only to the ones with the address set to their
> own address.  If two transmitters transmit a command at the same
> time, they will interfere with each other and neither will be
> received.  The operator would just resend the command.
>
> Most consumer IR protocols dedicate some bits to identify the device
> so that, for example, your DVD remote does not control your VCR.
>
> --BobG

... except if transmitter A starts to send the packet, receiver A decodes
its own address and starts to receive. In middle of the A data frame,
transmitter B starts to transmit and garble all A reception...

TXA AAAAAAAAAAAAA------
TXB ------BBBBBBBBBBBBB

RXA AAAAAAXXXXXXXXXXXXX
RXB -------------------

There is a simple (?) way, collision detection, a transmitter can only
start to send IR if there is no IR being transmitted.  Even so, there is a
chance of collision, it is not that difficult two operators press the key
within milliseconds.

VV46NER

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


2002\10\14@133831 by Olin Lathrop

face picon face
> ... except if transmitter A starts to send the packet, receiver A decodes
> its own address and starts to receive. In middle of the A data frame,
> transmitter B starts to transmit and garble all A reception...

Of course the packets would contain a checksum.  In this case the packet
would be detected as corrupted and ignored.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

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


2002\10\14@152649 by Robert Rolf

picon face
Or you could do what Sony does, repeat the command packet 3 times.
If a button is held down, you get bursts of 3 frames.
If all 3 packets are the same, there was no collision.

Think Ethernet without the carrier sensing. Keep you command bytes
short with long intercommand intervals (ICI). If every remote uses a
different ICI your probability of repeated collisions becomes quite low.

Olin Lathrop wrote:
>
> > ... except if transmitter A starts to send the packet, receiver A decodes
> > its own address and starts to receive. In middle of the A data frame,
> > transmitter B starts to transmit and garble all A reception...
>
> Of course the packets would contain a checksum.  In this case the packet
> would be detected as corrupted and ignored.

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


2002\10\14@155730 by Wagner Lipnharski

flavicon
face
Olin Lathrop wrote:
>> ... except if transmitter A starts to send the packet, receiver A
>> decodes its own address and starts to receive. In middle of the A
>> data frame, transmitter B starts to transmit and garble all A
>> reception...
>
> Of course the packets would contain a checksum.  In this case the
> packet would be detected as corrupted and ignored.
>


There is a double problem.

1) This kind of broadcast system, where the sender never receives
confirmation from the destination.  A system like this requires certain
insurance that the destination WILL receive the packet correctly.

2) Different from a real broadcast system, where the sender keeps sending
the same transmission over and over, this unidirectional communication
system probably will really need a collision avoidance by monitoring the IR
environment before transmit.

Of course, for better safety any kind of checksum is required.

Also, a bi-directional system can be implemented, with confirmation, "ack",
"nack", etc.  It will make the collision avoidance easier to implement.

VV46NER.

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


2002\10\14@161644 by Robert E. Griffith

flavicon
face
>> 1) This kind of broadcast system, where the sender never receives
>> confirmation from the destination...

Some inexpensive model vehicle systems use optics as the return path for the
packet ack.  An elaborate, but very common biological optical sensor is used
to detect the path of the vehicle to ack the receipt of the command.

Such systems suffer from a common failure mode whereby the optical sensor
ages poorly and after about 40 years, the focal range decreases resulting in
numerous collisions of the vehicle with room partitions.  For optimum
operation of the model, a control unit with sensors aged from 8-28 years is
recommended.

:-)

--BobG

{Original Message removed}

2002\10\14@161652 by Francisco Ares

flavicon
face
I have used one ove those 3-pin Sharp / Vishay / whatever IR decoder and
they look great.

Did you think on sending an address byte? Each of your models could have
a DIP switch to check for a match at the beginning of the transmition,
ignoring the rest on no match.

I have done this with an EEPROM storing a default address at the target
system and a special code sent by the IR remote to switch this address
at the target to the one that is being "broadcasted" by the remote
control. This instruction would mean "update your address to this one".
Note that all targets in range would obey to this command, so this is a
task to be done one by one.

I am using:
- a 16C511 on the remote control unit, serializing an address byte and a
two-byte key code, sending each bit in a pulse train to a transistor
driving two IR LED; the carier frequency of this pulse train is a
characteristic of the receiver, but the amount of pulses is determined
by if the bit is a "1" or a "0", separated by a fixed amount of time
with no pulses;
- and a 17C756a on the target system, using one of its timers in a clock
count mode and one of its CAPTURE interrupt chanels to build a stopwatch
for the pulse widths of the IR detected signal, that eliminates the
carier frequency, leaving pulses as large as the time elapsed by each
pulse train on the transmitter; the ISR "de-serializes" the bits to a
one-byte address and a two-byte funcion code that will be decoded if the
address bytes match.

Hope this helps
Francisco


William Chops Westfield wrote:

>I'm thinking about IR remote control for models, where I want several models
>to be controllable simultaneously ...
>
>

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


2002\10\14@162517 by Wagner Lipnharski

flavicon
face
Robert Rolf wrote:
> Or you could do what Sony does, repeat the command packet 3 times.
> If a button is held down, you get bursts of 3 frames.
> If all 3 packets are the same, there was no collision.
>
> Think Ethernet without the carrier sensing. Keep you command bytes
> short with long intercommand intervals (ICI). If every remote uses a
> different ICI your probability of repeated collisions becomes quite
> low.


You mean this?

XMITA  AAAAAAA   AAAAAAA   AAAAAAA
XMITB   BBBBBBB     BBBBBBB     BBBBBBB

RXA   AAXXXXXXXXAAAAXXXXXXXAAAAAXXXXXXX
RXB   --------------------------------

VV46NER

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


2002\10\14@164423 by Russell McMahon

face
flavicon
face
> If xmiters should be isolated, then IR is not the best choice.  They are
as
> dumb as if you try to differentiate a 74HC00 from a 74HC02 in the dark.

Still OK IF each transmitter carries a receiver as well and you carry out
some form of media sharing algorithm (CSMA or whatever). Even possibly dumb
time sharing transmissions if transmitter clock stability is good enough.

What is the required data rate? I would imagine at least 10 updates per
second to get crisp enough controls and at least 1 byte per command.
Possibly several if you want motor speeds and directional controls. Say 10
per second x 4 bytes/bot x 10 bots x 10 bits/data_byte  = 4,000 bps. May be
pushing 38 kHz common devices if you need much higher rates than this with
independent TXs. A shared TX would only need this rate and should be OK.

Anyone know how fast can you reliably demodulate asynchronous data using
typical 3 lead type IR receivers?
Any issues with response time from receipt of carrier? (as would be required
when multiple TXs were time sharing the ether).


       Russell McMahon




       Russell McMahon

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


2002\10\14@164426 by Matt Heck

flavicon
face
Hey Bill,

Why not just do this digitally, assign a serial number to each target
receiver, and preface the command packet you send with the intended
target?  The receiver can ignore any packets not intended for it.  Of
course, if there are multiple transmitters, there might be the issue
of packet collisions-- ethernet solves this by a wait-random-and-then-
retransmit algorithm, but it sounds like your system is half-duplex.
If it is, you could sync the transmitters to a common clock such that
they will each wait for their assigned timeslice to transmit.

Protocols to look at include serial multidrop (RS...233?) and Ethernet.

Going to have a group of folks racing RC cars, or something like that?

Good luck,
  Matt

> {Original Message removed}

2002\10\14@172432 by Wagner Lipnharski

flavicon
face
Russell McMahon wrote:
{Quote hidden}

That's another problem.  The receiver module REQUIRES some 38kHz pulses to
recognize the frequency.
It all will depend on the distance and IR power. As much closer to the
receiver (tests over the bench) can lead you to transmit as fast as
4800bps, but at home family room environment (12 to 15ft away) can't ensure
you not even 2400bps.  The real problem starts if the environment uses
fluorescent lamps... and worse, if they use electronic reactors.

The RX time delay is based on the above statements. As more pulses the
module takes to identify 38kHz IR radiation, as delayed will be the RX bit
received.

By other side, collision is easy to minimize, you just need to implement a
receiver module into the transmitter.  For every bit transmitted the
processor should check the echoed IR, if mismatch happens it means somebody
else is transmitting, so the transmitter should shut up for a while and try
again.

VV46NER

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


2002\10\14@173729 by Peter L. Peres
picon face
On Mon, 14 Oct 2002, Robert E. Griffith wrote:

*>This was alluded to by others, but to put it in simple terms... If you are
*>not constantly sending IR data to the models, (bandwidth is not tight), but
*>rather are sending short commands every once in a while (like turn, stop,
*>go, etc...), then you can just include a device address with each IR
*>command.  All receivers listen to every command, but respond only to the
*>ones with the address set to their own address.  If two transmitters

Or, more practically, send all the time but use Aloha or some similar
probabilistic time distribution scheme in the transmitters to ensure
receivers see valid packets often enough.

Peter

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


2002\10\15@004849 by Peter Crowcroft

flavicon
face
>Date: Tue, 15 Oct 2002 00:44:43 +1300
>From: Jinx <joecolquittspamKILLspamCLEAR.NET.NZ>
>Even better are the canned IR receivers in domestic appliances, eg
>VCRs and TVs. They use around the same V and I of the 3-pin type
>like 1SU60 but are far more sensitive to coded IR. There are plenty
>of scrapped VCRs/TVs around and I don't think you'd have much
>trouble finding all you need. Most of the ones I've got are made by
>Sharp, who also make the 1SU60, but AFAIK the cans are not for
>sale

there are plenty of Chinese ones. I use two of them in my kits.

http://www.kitsrus.com/pdf/pic1018scl.pdf


Waitrony IR Receiver Module PIC1018SCL is the main one,  and a similar one
by Kodenshi which is more expensive because  it holds its output (used in
my interrupted light beam kit, Kit 130) rather than giving a pulse output.
I can sell these individually. In fact I am starting to put together a
Components page. See the start of it at

http://www.kitsrus.com/bits.html


I will be in the UK for the next week. I will add more items when I return.

I can sell the Waitrony module for $US1.00 each plus p&p. It is ideal for
receiving remote control signals.




regards,

Peter Crowcroft
            DIY Electronics (HK) Ltd
      PO Box 88458, Sham Shui Po, Hong Kong
Factory: voice 852-2304 2250    Fax: 852-2729 1400
         M/F, 97 Fuk Wa Street, Sham Shui Po
Home: voice 852-2720 0255          Mobile: 6273 2049
Web:  http://www.kitsrus.com        Email: .....peterKILLspamspam.....kitsrus.com
      Yahoo Messenger  'peter5999'  with webcam
-------------------------------------------------------------

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\10\15@143543 by Peter L. Peres

picon face
On Tue, 15 Oct 2002, Russell McMahon wrote:

*>Anyone know how fast can you reliably demodulate asynchronous data using
*>typical 3 lead type IR receivers?
*>Any issues with response time from receipt of carrier? (as would be required
*>when multiple TXs were time sharing the ether).

Pulses under 300usec are hard to discriminate and the module will change
the mark/space ratio.

Peter

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\10\15@150457 by Wouter van Ooijen

face picon face
> *>Anyone know how fast can you reliably demodulate
> asynchronous data using
> *>typical 3 lead type IR receivers?
> *>Any issues with response time from receipt of carrier? (as
> would be required
> *>when multiple TXs were time sharing the ether).
>
> Pulses under 300usec are hard to discriminate and the module
> will change
> the mark/space ratio.

And (at lower baudrates) a continuous 'on' pulse will raise the
threshold, so it will tend to 'off' after a while. These receivers need
frequent off periods, consult the datasheets.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


More... (looser matching)
- Last day of these posts
- In 2002 , 2003 only
- Today
- New search...