What is the best Infrared modulation frequency for avoiding interference?

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!!

Comments

  • 12 Comments sorted by Date Added Votes
  • Here is a little more information in a white paper from Vishay that helped me get my head around the infrared communication protocols in use today.

    Table of protocols and carrier frequencies from page 5 of Vishay Document 80071:
    Capture.PNG
    840 x 620 - 78K
  • The higher the frequency the better the receiving diode has to be, and you don't really have to worry
    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 Mark that is good input. I'm limited by the detector's predetermined modulation frequencies and they range from 30kHz, 33kHz, 36kHz, 38kHz, 40kHz, up to 56kHz. It looks like the frequency of these detectors fall within your guidelines. I'm more worried about interfering with an existing TV or some other infrared controlled device.

    Thanks!
  • JohnR2010 wrote: »
    Thanks Mark that is good input. I'm limited by the detector's predetermined modulation frequencies and they range from 30kHz, 33kHz, 36kHz, 38kHz, 40kHz, up to 56kHz. It looks like the frequency of these detectors fall within your guidelines. I'm more worried about interfering with an existing TV or some other infrared controlled device.
    All of the commercial frequencies ones exist because somewhere, someone is likely using them as TV remotes in volumes...
    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.

  • jmg wrote: »
    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 ?

    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.
  • Why stop at only one IR LED? Anyway you can drive them at much higher currents since the duty cycle is actually quite low taking into account that even a continuous carrier is already only 50%.

    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.



    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    Tachyon Forth News Blog
    TACHYON DEMONSTRATOR
    Brisbane, Australia
  • If you use an amplified photodiode instead of a prebuilt receiver, you will have a lot more options for filtering out interference. Of course, you'll have to deal with an analog input and do the signal processing in code. But that's something the Propeller is good at.

    -Phil
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • JohnR2010JohnR2010 Posts: 400
    edited October 10 Vote Up0Vote Down
    Why stop at only one IR LED? Anyway you can drive them at much higher currents since the duty cycle is actually quite low taking into account that even a continuous carrier is already only 50%.
    I think multiple LEDs are in the cards! I haven't got to the point of testing range. Right now, I'm driving one IR LED at 80mA and plan on adjusting my circuit to get it up to 100mA. But first I want to get the communications between the Propeller and the Pi all buttoned up. So, the transmitter and receiver are sitting on the same bench.


    If you use an amplified photodiode instead of a prebuilt receiver, you will have a lot more options for filtering out interference. Of course, you'll have to deal with an analog input and do the signal processing in code. But that's something the Propeller is good at.
    -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.


  • JohnR2010 wrote: »
    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.

    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 ?
    JohnR2010 wrote: »
    .. 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.

    How much jitter do you see ?
    What is the Pi PWM formula ?



  • JohnR2010JohnR2010 Posts: 400
    edited October 11 Vote Up0Vote Down
    jmg wrote: »
    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%.

    Capture.PNG

    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).

    Capture.PNG

    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).

    Capture.PNG


    Here is another data packet zoomed in with the A1 and A2 time markers showing a 539 uSecond pulse

    Capture.PNG

    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.

    497 x 381 - 32K
    756 x 98 - 32K
    699 x 179 - 71K
    671 x 160 - 65K
  • JohnR2010 wrote: »
    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.
    That's quite good, looks like it adds one extra carrier cycle. I can see that is tolerated fine.

    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...


Sign In or Register to comment.