What is the best Infrared modulation frequency for avoiding interference?
JohnR2010
Posts: 431
in Propeller 1
My current project uses a battery powered propeller with an infrared receiver (I have been using the VISHAY TSOP38238 for testing). The propeller sends a step sequence to a motor driver that is connected to a small dashboard sized stepper. The stepper has a needle attached that sits in front of a custom gauge (clock face). It is basically a custom gauge that hangs on a wall that can display data you send it. I send the stepper value with an infrared LED connected to a Raspberry Pi ZeroW.
I’m using a Raspberry Pi Zero W to grab data and send it to the propeller by modulating a 940nM infrared LED at 38kHz. At this point I have everything working and it’s time to pick a modulating frequency and receiver that won’t compete with tv remote controls. VISHAY makes TSOP382xx receivers for 30kHz, 33kHz, 36kHz, 38kHz, 40kHz, and 56kHz. I have ordered receivers for the 33kHz and 56kHz to test with (should be here end of the week).
Does anyone have advice on a good (not used much in the home) modulation frequency I should use?
Is there a governing agency that regulates infrared modulation frequency and protocols?
Thanks, all advice is welcome.
For your enjoyment here is a quick video of the project as it sits on the bench.
You will see the first prototype on the breadboard with an unpopulated PCB next to it. It is all through hole as I plan on making this a do it yourself kit for one of my articles. Next, I show a populated PCB with the battery pack soldered to the back connected to a clock face. I then pan to the Raspberry Pi Zero connected to a bread board driving an infrared LED. Finally, you see my DMM showing the Propeller’s current pulling ~11uA. I have been logging current over the weekend and waiting for the run to complete so I didn’t want to disturb anything and move the needle for you. But you get the idea!
PS: I have been able to do everything on the propeller at 20kHz with just the internal clock. Very rewarding project to this point!!
I’m using a Raspberry Pi Zero W to grab data and send it to the propeller by modulating a 940nM infrared LED at 38kHz. At this point I have everything working and it’s time to pick a modulating frequency and receiver that won’t compete with tv remote controls. VISHAY makes TSOP382xx receivers for 30kHz, 33kHz, 36kHz, 38kHz, 40kHz, and 56kHz. I have ordered receivers for the 33kHz and 56kHz to test with (should be here end of the week).
Does anyone have advice on a good (not used much in the home) modulation frequency I should use?
Is there a governing agency that regulates infrared modulation frequency and protocols?
Thanks, all advice is welcome.
For your enjoyment here is a quick video of the project as it sits on the bench.
You will see the first prototype on the breadboard with an unpopulated PCB next to it. It is all through hole as I plan on making this a do it yourself kit for one of my articles. Next, I show a populated PCB with the battery pack soldered to the back connected to a clock face. I then pan to the Raspberry Pi Zero connected to a bread board driving an infrared LED. Finally, you see my DMM showing the Propeller’s current pulling ~11uA. I have been logging current over the weekend and waiting for the run to complete so I didn’t want to disturb anything and move the needle for you. But you get the idea!
PS: I have been able to do everything on the propeller at 20kHz with just the internal clock. Very rewarding project to this point!!
Comments
Table of protocols and carrier frequencies from page 5 of Vishay Document 80071:
about multipath distortion at these very low frequencies (compared to typical RF frequencies).
If you have compact fluorescent lighting you want to avoid the frequencies used by those lamps,
which can be in the same range as IR systems alas, 10 to 40kHz, apparently.
You want to avoid mains harmonics from other mains lighting too, so its probably best to be above 5kHz,
but frankly anywhere from 5kHz to 500kHz could be made to work (higher frequencies requiring care
in choosing components).
If you have a spectrum analyzer and a high speed photodiode you can probably test the available
spectrum quite scientifically - but that's not practical for most...
Thanks!
So I don't think you can guarantee no conflicts.
That said, TV remotes tend to be quite directional, and the TV sensor faces square into a room, and they are very intermittent use.
38KHz is the number I am most used to hearing.
How likely is your unit, to be in close proximity to the TV signal pathway (Chairs to TV) ? What % use time does it have ?
What happens if someone sends a TV signal into your unit ?
What range do you need ?
There are 2 families of IR receiver, those with modulated carrier have ranges like 25~45m, but there is another class for Learning remotes, and they have less filtering and wider bandwidths (and also less range, eg TSMP77000 specs 5m range)
Choosing one of the learning ones, and going for a gap, as well as unique modulation, would be another way to reduce crosstalk, but simple swamping could still be an issue.
The wall hanging unit (receiver) sleeps for 15 minutes and wakes up for two minutes to listen for IR data. The Raspberry Pi (IR transmitter) sends out the value to display every 60 seconds in a very short two packet burst. I want to flood the room with the IR packet so I'm driving my LED at 100mA and would like to have a 30' range or so. I would expect all devices in the room will see the IR traffic. If the wall unit is awake and listening for data and a TV remote is pushed it will just ignore the data.
I find IR bounces well off white ceilings for good coverage but you might get better results if you repeat your transmissions a few times since this is what IR remotes do to ensure that the receiver gets a valid code despite interference and receiver stabilization.
-Phil
Thanks Phil. I just read through your post on Walsh-modulated IREDs posted by Mark_T above. Very impressive!! I'm tucking it away for a future project.
Using an IR Receiver that demodulates the signal is a good fit for this project. Since I don’t have to demodulate the signal I can decode the data with one COG running my PASM app all at RCSLOW (20kHz). When the stepper moves it requires 40mA and takes about ¾ of a second to make a typical change. To get a year plus run time out of 4 AA batteries I must make up for it between moves and limit the updates the stepper makes to 5 an hour. So, we’re not talking about transferring a lot of data here. Basically, one long every 5 minutes or so. Another thing to keep in mind is I’m driving the transmitter LED with a Raspberry Pi. I want to keep that side simple as well. Just a transistor and maybe a couple IR Diodes. I haven’t had much luck getting the Pi to control a pin with sub millisecond accuracy. To this point my C app that modulates the Pi’s hardware PWM pin works pretty good. But it acts like I’m pushing it to the max as the timing is little off depending on the Pi’s load. So far, the PSAM app on the receiving side is able to ignore the small timing changes from the Pi.
If you want 'flood' type operation, and not 'point at' that would exclude the Learning types, as they have less range.
As well as the all-in-one encapsulated modules, I see Vishay also have the diode-less silicon http://www.vishay.com/docs/82748/vsop383.pdf
For that, you add your own photodiode, which could result in a more sensitive unit ?
How much jitter do you see ?
What is the Pi PWM formula ?
I like the idea of supplying your own photo diode. I’m going to store that away as a possible next step if I run into too much interference. I think what I may do is have two photo detectors on the PCB that are selectable with a jumper. This way if a user sees interference at one modulation frequency they can just pick a second. From the Pi side it is easy I just change the PWM frequency.
On the Pi side here is the method I use to send a bit. It is based on the PIGPIO.H library. I use one of the Pi’s hardware PWM pins. I setup a pulse at the desired carrier frequency with a 50% duty cycle. I then modulate the carrier frequency by changing the PWM value to 0 and back to 50%.
Here is a snapshot of the signal generated by calling the above method to send bits. The top trace is the output pin of the detector (pin connected to Propeller) and the bottom trace is the irLED (driven by Raspberry Pi Zero W).
Here is the same pulse zoomed in with the A1 and A2 time markers showing a 565uSecond pulse (this pulse is close to 560uS goal).
Here is another data packet zoomed in with the A1 and A2 time markers showing a 539 uSecond pulse
We are talking about a 26uS difference between those two pulses. That is not bad for the Pi Zero! There are times I notice a larger delta but still close enough for the Propeller to tell the difference between a one and a zero.
If you use 50% PWM, an alternative approach could be to use the UART, and set a 76kHz baud equiv ( 76011 Baud?) to get 5 cycles per 0x55 serial char.
Instead of needing the Pi to keep up with 38KHz, this would have 7.6kHz + FIFOs to smooth things more...