Btw, just to be clear for folks, the 26ms that you divided by in your IRcarrier() function is THE PERIOD of the 38Khz. Freq = 1/Period, which means Period = 1/Freq = 1/38Khz = 0.0000263157 sec = 0.0263157msec = 26.3157usec, which is roughly 26usec. So, your code wanted 9000usec of 38Khz carrier freq means that "how many periods of 26usecs do I need to generate?", which means 9000usec/26usec = 346 periods, that is, 346 iterations of the loop in your IRcarrier() function. That's how the 38Khz carrier frequency is generated with an I/O pin.
great work Dave. i'm an electrical engineer who has been out of the technical loop for 25 years. your videos are perfect for bringing somebody like me up to date.
Dave R Good idea indeed but there's a limitation. The standard audio cards are made to sample from around 20Hz to 20000 Hz. That's not enough to see the actual carrier frequency, but its totally good enough to decode each button code. I just made this a couple of days ago, and I was able to decode every single button :D. Btw I used a free software that plots the mic input and lets you visualize interesting stuff like frequency gains.
I just did this, as my receivers did not make a proper capture of the signal. using a standard sound card was able to clearly see the codes with a simple ir receiver (2 pin on mic input). my air conditioner had a 36-bit code, so I made a few modifications to the code posted here, adjusted the initial timings (assumed a 38khz carrier) and bam! working fine! captured the output to match the original remote, and from there I refined the timings. (i did not have an oscilloscope). an arduino pro mini 3.3v did the job perfectly
What I enjoyed about this video is not the programming, although that is always instructive, but the reverse engineering of the raw pulses into a carrier freq., pulse codes, NEC standard... Big thumbs up video for newbie hackers and those who just want to understand how things work! Are there many major IR coding standards besides NEC?
Another very well known one is RC-5 (wikipedia.org/wiki/RC-5). It runs offically on a carrier of 36kHz, but a lot of manufacturers used 38 due to being misinformed or lazyness. It works anyhow. The bits are a fixed lenght where the direction (rising or falling) of the slope in the middle defines it's value. The toggle bit Dave talks about is used for ch+ and ch- for example. It prevents to skip 5 channels if you keep the button a bit to longue.
Thanks for this video Dave! Your code is much more elegant and easier to understand than any of the IR libraries online. I was able to modify it to duplicate a Sony AV remote and it worked!
By far one of the best explanations of IR signaling I've ever seen or read ... I definitely understand it 50% better than I did before watching the video ... but I am still uncertain how this knowledge can be applied to different protocols such as Sanyo, Sony etc. I'm going to power up the scope and see what I can figure out. Thank you for once again producing a quality electronic tutorial.
As I pointed out to countless people, yes the previous hack was much simpler and faster, that's why I did it originally. But this isn't too hard, even if you have to write your own IR library as I showed, but yes, you need at least some programming knowledge. You can just cut'n'paste code though of course.
Thanks Dave! i used your code to make a AC ON/OFF control for the Dometic HB2500 Airco. As far as i known no replacement remote controls are available for this Dometic HB2500 so i am making my own to help out a neighbour. He was told to buy a new Airco for his RV when his remote control broke down. Greetings from the low lands :-)
David - it’s an older video but I found it really useful! I’ve been recording a custom protocol used on original Macintosh keyboards (pre ADB) and plan to do an Arduino implementation. Your segment about using the Arduino and pitfalls to be mindful of confirmed the best practices I was anticipating - thank you!
An Arduino sketch IS in native C. It's just calling an abstracted routine to write to the IO pin. You can simply bypass that if you want and the sketch will give you the exact same speed as AVR studio.
I recently made a remote control and IR receiver for dimming six leds individually. Used a timer to create the carrier signal and used the UART with a baud rate of 2400 to send the information, worked liked a charm :D Each transfer consisted of four bytes, the first and last byte are address bytes, I hardly get any bit error :)
If you want to see some truly twisted IR encoding look at the MILES 2000 a.k.a. military laser tag. The older system used a relatively slow IR signal and when they decided to update things they still wanted to be able to use the old gear so they snuck in the new bits inside the existing bits. As I recall it was something like they split up the high time from one 'long' bit for the old system to many short bits for the new system. The old receivers would filter out the new fast bits and still work just fine and the new receivers would be able to 'see' the additional data. Since it did not add value to the project we were working on at the time to decode the actual MILES 2000 signals we skipped it (we were adding haptic feedback to the soldiers gear so they would feel where they were hit.)
Amen to that. This channel is really getting good with all the how-tos as opposed to teardowns, mailbags, and rants (not that those aren't appreciated).
A good little bit on reverse engineering. I like the fact that you pointed out something that not many newcomers (to programming) catch; the fact that subroutine calls do not take zero time to execute, especially when they have to change registers or interface to the real world... usually not a big deal, unless you are writing tight timing loops, and then it really matters. Good job.
IR LED's draw as much current as you give them, they don't "take" or "draw" current. You force the required current into them with a suitable dropper resistor.
This is exactly how a fundamentals video should be done. Well played Dave, a great combination of theory, practical and how to salvage stuff from everyday consumer junk. I dont have enough thumbs to put up.
That would be the more efficient approach, but I think that this video is more about how to use your gear to reverse-engineer or diagnose a serial protocol and how to implement it in A microcontroller. The IR protocol is just a special case and Dave did a good job by not introducing PWM here...
Dave thank you for this video, I just got my first oscilloscope and this made my day for another semi beginner! The protocol explanation was great it helps me put what I have learned about protocols into real world examples! Thanks again!
Great video. For solving the timing issues what about : 1) Generating the signal inside an ISR with proper timer setup. Signals might be a little bit too late (because of the delay between the ISR and the signal is finally outputted on the pin) but at least it wont drift over the time. 2) using UART
I ran into this style problem (the timing of a carrier frequency) when driving led strands over software spi; I learned a valuable lesson about digitalWrite that day. Very cool stuff. I would really like to have seen a quick note in the video reminding people that the more human friendly code is REALLY time-inefficient on these limited platforms. At least the reminder is in there about what caused the problem.
I know this is an old video, but for anyone watching that's having trouble getting the carrier frequency right, another approach would be to use a PWM channel and toggle it on and off rather than "bit banging" the carrier. The IR libraries Dave mentioned at the start likely do this. I'm sure Dave just chose this method because the code is easier to understand
Dave, there exists (or did) an IR receiver with a carrier frequency of 455kHz. I have succeeded in sending audio over this IR module (something like a TL9000--but I seriously doubt that's the exact part number since it's been so long). Most interesting of all is I managed to send DTMF codes over it (to a DTMF decoder) for remote control applications, and even multiplexed and patented it after I added a feature that allowed more than one DTMF encoder button to be pressed and held continuously with a receiver modification to match. Then this wonderful high frequency IR decoder was discontinued--go figure. I think I got all mine from Vishay...still got a few of them though.
I have been experimenting a LOT with this crap. It's a real pain in the butt to get enough documentation to know what the heck to do. I have spent a lot of time accumulating documentation. I'm doing it with a PIC chip. Specifically a PIC16F1503. I'm so close I can taste it. I have a handheld Qunda IR Remote Control Decoder. It sees and decodes my PIC's IR output but the TV is not. More tweaking needed. One thing I noticed is that you assume is that the 38Khz duty cycle is 100%. ie., 50% ON, 50% OFF. It's not. 33% on time is more like it. Keeps LED's from burning up. They are usually pulsed at some insanely high currents. I could write a book. Argh. Thanks for the video!
mike94560 I’m also working on a project that deals with a PIC16F883 and IR , how far did you get !? Can I see your results and how you got to where you wanted
That's a great job done. I had been trying to do this in software on an ESP8266. Thanks to your informative video, especially the debug part, I am able to send IR from the ESP8266 and ultimately anywhere in the world!
Thanks for the video, Dave. My cable TV provider is going all digital so I need to use an external digital decoder box to be able to pick up all the old channels. I've been wanting to make a device that can send the IR codes to the external box. This video has certainly helped me to work out how to decode the IR signals sent by the remote.
Excellent video Dave, also a representation why I use AVR Studio and native C to do my projects. When you do a simple loop, toggling an output on the uC, the Arduino sketch gives about ~200kHz square, compared to a C loop's ~3MHz! Much faster and not much more complicated. Cheers!
this is pretty cool, when I got my first car, I used my remote control watch to start my car and open the doors, I didnt know about NEC protocol so I was decoding hex code, it was working pretty well, but I wish I had new about this decoding technique
You could use one of the AVR timers to generate the carrier with an isr routine to blink the led, then just enable/disable the blinking in the isr for your bit times.
a) I would have used a PWM signal to generate at least the clock signal, so you don't have to tweak the timing. The 'professional way' would be to write the whole IR-signal generating code in the overflow interrupt of the PWM timer. But don't worry, for a demo your code is more than adequate. b) It could have used a little more cowbell.
Great video! I like the fact that you use the arduino platform, because it is easier to write code for than the usual development systems from AVR or Microchip.
So that people can just cut'n'paste setup routine into other code, it's more portable. setup is an Arduino specific thing. The while loop at the end stops it from running more than once. It's example code.
@bcsupport Dave programmed his Arduino with a 'sketch' written in the "processing" language (roughly speaking a subset of Java which is compiled to byte code and then interpreted on the device) - it's not ANSI C. It's possible to program the Arduino with pure C but mostly not necessary.
I guess the long burst up front is for the receiver to set its AGC. And the stop bit so every bit is followed by a leading edge, so you can just measure the time between leading edges. Its interesting to think about how the transmission is often designed for the receiver to receive it cheaply and reliably, rather than for the ease of the transmitter
Huge thumbs up. I actually wanted to do a very similar project just the other day, I needed to clone a flimsy remote control. Thanks for the info, now I think I can tackle the task.
Thanks so much for this. With this code and some remote control codes I found on the web I managed to regain remote control of my amplifier. It worked on the first try.
Thanks Dave! You managed to put so many different topics into a simple project like this and kept it easy enough for starters to follow. Great Video, I really enjoyed it :)
I've done this once. My solution for the carrier was to use the PWM module in the PIC I was using at the time to generate it. One side of the LED went to the PWM output pin, the other went to a pin with the data.
Really interesting and informative. I am sure that various experts can take pot-shot criticism at various details. However it takes real cojones to produce and share this. Thank you.
Hey Dave GREAT video! i just have three question about your code: Why did you make your own void IRsetup instead of using the normal void setup? you added your IRsetup to be called in your void loop and added commontary that you only need it to call setup once but what stops the loop from executing that setup over and over again? Also why do you prefer to use so many voids instead of putting all your code in the void loop? I'm not saying your code is wrong. I just wonder why you prefer this way
The other fix would be to replace Arduino's digitalWrite routine with one that optimizes down to the single machine instruction it should be. Considering the "digitalwritefast" implementation is entirely source compatible and has been around for years, I've no idea why the Arduino team hasn't already included it.
Thanks @Vorsteven for the clarification. Yes I was confused by reading that the IDE is based on the Processing IDE and that Wiring was influenced by the Processing language. My bad, sorry.
Excellent video. You even managed to review some code!! ;-) Great complete implementation of a smart solution to your specific need. But yeah I'm always a bit wondering as how fast these Arduino can actually deal with "real time" processing.
HIGH is just a macro that gets substituted by the preprocessor with "1" before comiling the code. So you will get exactly the same result, no matter if you use "digitalWrite(IRLED, HIGH)" or "difitalWrite(IRLED, 1)": avr/cores/arduino/Arduino.h:#define HIGH 0x1
Thanks a lot Dave! Awesome video :-). I was surprised that connecting the IR LED directly to the output pin actually works. My readings said that one has to use a transistor, because IR LEDs draw more current than normal LEDs. So I went directly for a transistor circuit, but never brought it to work. Does your LED light up as bright as the original remote-control, when filmed with a digicam? I thought the brightness was my problem, but now I think I should look for the problem in the IR-Code...
Where is the Double LIKE / Double Thumb UP button ? :) I need to discover the code for a function of the remote and had not a clue how to do it. You saved me hours of head scratching. An now i know to emulate the command. Thank you !
Well done Dave. This video is really useful. The setup and execution is a lot harder on your end I'm sure, but we get real meat - soup to nuts! Thank you for your efforts and please do many more like this. This is 100 times more valuable than a review video...
Excellent point! Would you mind making a video about this particular topic? I was wondering how exactly to "port" a Arduino IDE sketch into using base functions instead.
Though the length of '1' and '0' is not the same, the NEC protocol defines that you should send an inverted message as well, so the length of the whole transmission is constant., 67.5mS
I was just trying to capture the IR codes for some obscure DVD player (an ugly cyan/silver colored beast from RITECH). Just about no info online and you NEED the remote. I have the non-functional remote, but the stale-cheese looking resonator for the mystery COB's clock and IR carrier generation is dead. Did find it uses 36kHz carrier online... Maybe capture the data to the driving NPN's base (carrier freq is wrong, but should be able to scale it) then hand feed to LIRC for decoding. Hopefully!
Excellent video. Can you tell me does this relate in any way to the code number you have to enter in a universal remote to get it to work with your TV ?
I've been trying to control my AC for a week now, exhausted, and still can't figure it out. But I know I'm close! I will try your code now, but I'm not sure where you got your IRcode from. Did you convert Adress or Command to binary or what? Would appreciate your quick input mate, thanks alot.
Bit banging is sometimes cheap and effective. In non-critical applications like consumer remotes, I'd say slamming signals out of a GPIO is perfectly acceptable.
Dave you should have used DigitalWrite(IRLEDpin, 1) instead of using HIGH. It is considerably quicker than HIGH. That way you would not need to guesstimate the delay like you did. Give it a go and see if it helps... I suspect it would be much quicker.
Yes, but then the code wouldn't be as portable, or usable on chips without available PWM, or as understandable to beginners. Bit bang is always a nice way to explain it first IMO.
We are going to do it the old fashion way ... Let me grab my digital scope lol. Good fun tutorial I think I have a few remotes I can play around with here.
Aah I see! thx for your explenation and fast response! I learned a lot about the code and how to send it. I allready knew a bit of IR but not how to send the codes. I only used my arduino once to decode IR and turn a LED on and off via my logitech harmony wich i programmed for a old sony VCR wich are the easiest to decode. anyways thank you very much for the video and your quick respose really apreciate it : )
I guess we all code differently. Thanks for using a unsigned long to hold the binary message and not int bits[32] as appears elsewhere on the web. Is it necessary to repeatedly call IRsetup()? Could that be put in Setup()? The LED is OFF at the end of IRCarrier(). Thanks for the fulsome explanation, clear readable code (not C obscure) and your comments on available libraries, Murphy's law and sampled waveforms.
yup... awesome is the word... one thing Dave, It seems quite obvious, but just so as to clarify my understanding: the signal (waveform) at the IR receiver output is exactly inverse of the signal that is fed into IR transmitter. Is that right?
In binary 0x80000000 is one followed by 31 zeroes. When you do an and operation with that on a 32-bit number you end up with its most signifigant bit. Within the if statement in the code, if the MSB is one the the condition evaluates as true, if zero then false. After that there is code
Yeah. Learning how to use Git is quite difficult (even though Github helps a lot). Once you figured it out it's very useful for any kind of continued development (it works great with Eagle schematics for instance, or of course all kinds of source code).
The slow part of the loop is surely the divide by 26 in the conditional, which is executed every iteration of the loop. I'll bet the division is slower than the digitalWrite() call. The division should be pulled out of the loop.
Btw, just to be clear for folks, the 26ms that you divided by in your IRcarrier() function is THE PERIOD of the 38Khz. Freq = 1/Period, which means Period = 1/Freq = 1/38Khz = 0.0000263157 sec = 0.0263157msec = 26.3157usec, which is roughly 26usec.
So, your code wanted 9000usec of 38Khz carrier freq means that "how many periods of 26usecs do I need to generate?", which means 9000usec/26usec = 346 periods, that is, 346 iterations of the loop in your IRcarrier() function.
That's how the 38Khz carrier frequency is generated with an I/O pin.
Thanks a lot. That's the only part I didn't understood
great work Dave.
i'm an electrical engineer who has been out of the technical loop for 25 years.
your videos are perfect for bringing somebody like me up to date.
Haha
If you don't have a digital scope, just connect the output of a photo diode to your line input of your pc's audio card and record the data.
thats a great idea!!
Dave R Good idea indeed but there's a limitation. The standard audio cards are made to sample from around 20Hz to 20000 Hz. That's not enough to see the actual carrier frequency, but its totally good enough to decode each button code. I just made this a couple of days ago, and I was able to decode every single button :D. Btw I used a free software that plots the mic input and lets you visualize interesting stuff like frequency gains.
What was the name of that free software you used, please?
There are soundcards capable of 24 bit @ 192khz. That ought to be enough for things like this :)
I just did this, as my receivers did not make a proper capture of the signal. using a standard sound card was able to clearly see the codes with a simple ir receiver (2 pin on mic input). my air conditioner had a 36-bit code, so I made a few modifications to the code posted here, adjusted the initial timings (assumed a 38khz carrier) and bam! working fine! captured the output to match the original remote, and from there I refined the timings. (i did not have an oscilloscope). an arduino pro mini 3.3v did the job perfectly
"The old fashioned way" : A digital oscilloscope. :D
I understand your concern, his perception is relativistic
What I enjoyed about this video is not the programming, although that is always instructive, but the reverse engineering of the raw pulses into a carrier freq., pulse codes, NEC standard... Big thumbs up video for newbie hackers and those who just want to understand how things work! Are there many major IR coding standards besides NEC?
Another very well known one is RC-5 (wikipedia.org/wiki/RC-5). It runs offically on a carrier of 36kHz, but a lot of manufacturers used 38 due to being misinformed or lazyness. It works anyhow. The bits are a fixed lenght where the direction (rising or falling) of the slope in the middle defines it's value.
The toggle bit Dave talks about is used for ch+ and ch- for example. It prevents to skip 5 channels if you keep the button a bit to longue.
Thanks for this video Dave! Your code is much more elegant and easier to understand than any of the IR libraries online. I was able to modify it to duplicate a Sony AV remote and it worked!
By far one of the best explanations of IR signaling I've ever seen or read ... I definitely understand it 50% better than I did before watching the video ... but I am still uncertain how this knowledge can be applied to different protocols such as Sanyo, Sony etc. I'm going to power up the scope and see what I can figure out. Thank you for once again producing a quality electronic tutorial.
As I pointed out to countless people, yes the previous hack was much simpler and faster, that's why I did it originally. But this isn't too hard, even if you have to write your own IR library as I showed, but yes, you need at least some programming knowledge. You can just cut'n'paste code though of course.
Thanks Dave!
i used your code to make a AC ON/OFF control for the Dometic HB2500 Airco. As far as i known no replacement remote controls are available for this Dometic HB2500 so i am making my own to help out a neighbour. He was told to buy a new Airco for his RV when his remote control broke down.
Greetings from the low lands :-)
David - it’s an older video but I found it really useful! I’ve been recording a custom protocol used on original Macintosh keyboards (pre ADB) and plan to do an Arduino implementation. Your segment about using the Arduino and pitfalls to be mindful of confirmed the best practices I was anticipating - thank you!
An Arduino sketch IS in native C. It's just calling an abstracted routine to write to the IO pin. You can simply bypass that if you want and the sketch will give you the exact same speed as AVR studio.
I recently made a remote control and IR receiver for dimming six leds individually. Used a timer to create the carrier signal and used the UART with a baud rate of 2400 to send the information, worked liked a charm :D Each transfer consisted of four bytes, the first and last byte are address bytes, I hardly get any bit error :)
As you saw in the previous video, I am using the Arduino for the matrix display, it came with an Arduino driver and connection board.
Yeah, I deliberately wanted to do that, and was hoping the digitalWrite routine would be slow enough to show that. It didn't let me down!
Excellent explanation, thanks for showing how things actually work by theory using the oscilloscope.
Brilliant, explained so well and in just the right level of detail. Thanks Dave!
If you want to see some truly twisted IR encoding look at the MILES 2000 a.k.a. military laser tag. The older system used a relatively slow IR signal and when they decided to update things they still wanted to be able to use the old gear so they snuck in the new bits inside the existing bits. As I recall it was something like they split up the high time from one 'long' bit for the old system to many short bits for the new system. The old receivers would filter out the new fast bits and still work just fine and the new receivers would be able to 'see' the additional data.
Since it did not add value to the project we were working on at the time to decode the actual MILES 2000 signals we skipped it (we were adding haptic feedback to the soldiers gear so they would feel where they were hit.)
Amen to that. This channel is really getting good with all the how-tos as opposed to teardowns, mailbags, and rants (not that those aren't appreciated).
A good little bit on reverse engineering. I like the fact that you pointed out something that not many newcomers (to programming) catch; the fact that subroutine calls do not take zero time to execute, especially when they have to change registers or interface to the real world... usually not a big deal, unless you are writing tight timing loops, and then it really matters. Good job.
IR LED's draw as much current as you give them, they don't "take" or "draw" current. You force the required current into them with a suitable dropper resistor.
This is exactly how a fundamentals video should be done. Well played Dave, a great combination of theory, practical and how to salvage stuff from everyday consumer junk. I dont have enough thumbs to put up.
That would be the more efficient approach, but I think that this video is more about how to use your gear to reverse-engineer or diagnose a serial protocol and how to implement it in A microcontroller. The IR protocol is just a special case and Dave did a good job by not introducing PWM here...
Dave thank you for this video, I just got my first oscilloscope and this made my day for another semi beginner! The protocol explanation was great it helps me put what I have learned about protocols into real world examples! Thanks again!
Great video. For solving the timing issues what about :
1) Generating the signal inside an ISR with proper timer setup. Signals might be a little bit too late (because of the delay between the ISR and the signal is finally outputted on the pin) but at least it wont drift over the time.
2) using UART
It's easy to throw a video onto UA-cam. Not as much when you take the extra time to make the video concise yet meaty - like this video; well done.
I ran into this style problem (the timing of a carrier frequency) when driving led strands over software spi; I learned a valuable lesson about digitalWrite that day. Very cool stuff. I would really like to have seen a quick note in the video reminding people that the more human friendly code is REALLY time-inefficient on these limited platforms. At least the reminder is in there about what caused the problem.
I know this is an old video, but for anyone watching that's having trouble getting the carrier frequency right, another approach would be to use a PWM channel and toggle it on and off rather than "bit banging" the carrier. The IR libraries Dave mentioned at the start likely do this. I'm sure Dave just chose this method because the code is easier to understand
I couldn't get any IR libraries to work on the ESP8266
Dave, there exists (or did) an IR receiver with a carrier frequency of 455kHz. I have succeeded in sending audio over this IR module (something like a TL9000--but I seriously doubt that's the exact part number since it's been so long). Most interesting of all is I managed to send DTMF codes over it (to a DTMF decoder) for remote control applications, and even multiplexed and patented it after I added a feature that allowed more than one DTMF encoder button to be pressed and held continuously with a receiver modification to match. Then this wonderful high frequency IR decoder was discontinued--go figure. I think I got all mine from Vishay...still got a few of them though.
I have been experimenting a LOT with this crap. It's a real pain in the butt to get enough documentation to know what the heck to do. I have spent a lot of time accumulating documentation.
I'm doing it with a PIC chip. Specifically a PIC16F1503. I'm so close I can taste it. I have a handheld Qunda IR Remote Control Decoder. It sees and decodes my PIC's IR output but the TV is not. More tweaking needed.
One thing I noticed is that you assume is that the 38Khz duty cycle is 100%. ie., 50% ON, 50% OFF. It's not.
33% on time is more like it. Keeps LED's from burning up. They are usually pulsed at some insanely high currents.
I could write a book. Argh. Thanks for the video!
mike94560 I’m also working on a project that deals with a PIC16F883 and IR , how far did you get !? Can I see your results and how you got to where you wanted
That's a great job done. I had been trying to do this in software on an ESP8266. Thanks to your informative video, especially the debug part, I am able to send IR from the ESP8266 and ultimately anywhere in the world!
Again got help from here after so many years, thanks Dave , you are a legend.
Dear Dave Master,
Thank you for sharing your vast knowledge with us so enthusiastic and smart.
Thanks for the video, Dave. My cable TV provider is going all digital so I need to use an external digital decoder box to be able to pick up all the old channels. I've been wanting to make a device that can send the IR codes to the external box. This video has certainly helped me to work out how to decode the IR signals sent by the remote.
Excellent video Dave, also a representation why I use AVR Studio and native C to do my projects. When you do a simple loop, toggling an output on the uC, the Arduino sketch gives about ~200kHz square, compared to a C loop's ~3MHz! Much faster and not much more complicated. Cheers!
According to the C11 standard: "The result of E1
this is pretty cool, when I got my first car, I used my remote control watch to start my car and open the doors, I didnt know about NEC protocol so I was decoding hex code, it was working pretty well, but I wish I had new about this decoding technique
You could use one of the AVR timers to generate the carrier with an isr routine to blink the led, then just enable/disable the blinking in the isr for your bit times.
a) I would have used a PWM signal to generate at least the clock signal, so you don't have to tweak the timing. The 'professional way' would be to write the whole IR-signal generating code in the overflow interrupt of the PWM timer. But don't worry, for a demo your code is more than adequate.
b) It could have used a little more cowbell.
Great video! I like the fact that you use the arduino platform, because it is easier to write code for than the usual development systems from AVR or Microchip.
So that people can just cut'n'paste setup routine into other code, it's more portable. setup is an Arduino specific thing. The while loop at the end stops it from running more than once. It's example code.
@bcsupport Dave programmed his Arduino with a 'sketch' written in the "processing" language (roughly speaking a subset of Java which is compiled to byte code and then interpreted on the device) - it's not ANSI C. It's possible to program the Arduino with pure C but mostly not necessary.
This is a library, and I think it's simple enough beginners can use it.
I guess the long burst up front is for the receiver to set its AGC.
And the stop bit so every bit is followed by a leading edge, so you can just measure the time between leading edges.
Its interesting to think about how the transmission is often designed for the receiver to receive it cheaply and reliably, rather than for the ease of the transmitter
Really makes a nice change from teardowns. Nce job. Thanks Dave.
Well, when it takes 3.5us to write to an output pin using the recommended method, that could best be regarded as "dog slow"
Huge thumbs up. I actually wanted to do a very similar project just the other day, I needed to clone a flimsy remote control. Thanks for the info, now I think I can tackle the task.
Thanks so much for this. With this code and some remote control codes I found on the web I managed to regain remote control of my amplifier. It worked on the first try.
Well explained and from many ways of capturing!!!
Thanks Dave! You managed to put so many different topics into a simple project like this and kept it easy enough for starters to follow. Great Video, I really enjoyed it :)
If you want to run for 1000us, and each loop is 26 us, you need to divide 1000 by 26 to get the number of loops.
I've done this once. My solution for the carrier was to use the PWM module in the PIC I was using at the time to generate it. One side of the LED went to the PWM output pin, the other went to a pin with the data.
@Peter Mortensen The led was sourced from the data pin, and sinked into the pwm pin. Two pins, one driving the high side, the other driving the low.
Really interesting and informative. I am sure that various experts can take pot-shot criticism at various details. However it takes real cojones to produce and share this. Thank you.
Hey Dave GREAT video! i just have three question about your code: Why did you make your own void IRsetup instead of using the normal void setup? you added your IRsetup to be called in your void loop and added commontary that you only need it to call setup once but what stops the loop from executing that setup over and over again? Also why do you prefer to use so many voids instead of putting all your code in the void loop? I'm not saying your code is wrong. I just wonder why you prefer this way
The other fix would be to replace Arduino's digitalWrite routine with one that optimizes down to the single machine instruction it should be. Considering the "digitalwritefast" implementation is entirely source compatible and has been around for years, I've no idea why the Arduino team hasn't already included it.
Thanks @Vorsteven for the clarification. Yes I was confused by reading that the IDE is based on the Processing IDE and that Wiring was influenced by the Processing language. My bad, sorry.
It recommends that for 8 bit data, but if you need 16bit address or 16 bit data, then you don't need to send the inverse.
To be precise, two clock cycles on the Atmega328, if the register and bit to set are immediate/constant. SBI instructions are nice. =]
Excellent video. You even managed to review some code!! ;-) Great complete implementation of a smart solution to your specific need. But yeah I'm always a bit wondering as how fast these Arduino can actually deal with "real time" processing.
the BEST EVER tutorial about IR works. TOP! thanks!
HIGH is just a macro that gets substituted by the preprocessor with "1" before comiling the code. So you will get exactly the same result, no matter if you use "digitalWrite(IRLED, HIGH)" or "difitalWrite(IRLED, 1)":
avr/cores/arduino/Arduino.h:#define HIGH 0x1
Thanks a lot Dave! Awesome video :-). I was surprised that connecting the IR LED directly to the output pin actually works. My readings said that one has to use a transistor, because IR LEDs draw more current than normal LEDs. So I went directly for a transistor circuit, but never brought it to work. Does your LED light up as bright as the original remote-control, when filmed with a digicam? I thought the brightness was my problem, but now I think I should look for the problem in the IR-Code...
Where is the Double LIKE / Double Thumb UP button ? :) I need to discover the code for a function of the remote and had not a clue how to do it. You saved me hours of head scratching. An now i know to emulate the command. Thank you !
Hey dave, quick comment about your code there. The NEC protocol recommends a duty cycle of between 25 to 33% for the carrier, to conserve power.
You can also do it with an ISD1616BSY audio recorder at a high sampling rate. No programmer or programing required.
Andy Collinson in your blog have a nice ir project.
Well done Dave. This video is really useful. The setup and execution is a lot harder on your end I'm sure, but we get real meat - soup to nuts! Thank you for your efforts and please do many more like this. This is 100 times more valuable than a review video...
Excellent point! Would you mind making a video about this particular topic? I was wondering how exactly to "port" a Arduino IDE sketch into using base functions instead.
For starters Arduino is perfect and I think a big part of viewers are starters so yeah. Not everyone is an electronics expert like you.
Hello Dave,
a great video!!
For me it was always something mystical, when I read of decoded protocols. Thanks for your explanations.
This wold make a great new weekly segment! Great video :)
Though the length of '1' and '0' is not the same, the NEC protocol defines that you should send an inverted message as well, so the length of the whole transmission is constant., 67.5mS
Really impressive, informative with full clarity. Thank you.
I was just trying to capture the IR codes for some obscure DVD player (an ugly cyan/silver colored beast from RITECH). Just about no info online and you NEED the remote. I have the non-functional remote, but the stale-cheese looking resonator for the mystery COB's clock and IR carrier generation is dead. Did find it uses 36kHz carrier online... Maybe capture the data to the driving NPN's base (carrier freq is wrong, but should be able to scale it) then hand feed to LIRC for decoding. Hopefully!
Of course, yes, that's possible.
What a bloody great video Dave.
Great real world project, simple approach. Loved it. Brace yourself for 1000 alternate opinions on how everyone else wants you to skin that cat.
More logic analyser videos!!!
I'd love to see you decode some code on an older videogame console or an old PC.
Great video, just what I needed to understand how IR remote controls work :)
I tried to make it as complete yet short as possible.
Excellent video. Can you tell me does this relate in any way to the code number you have to enter in a universal remote to get it to work with your TV ?
Always great videos...ive watched you even before i started engineering and you're the real deal!
Great Master, thank you. I am still searching for GPX-Device signals.
I've been trying to control my AC for a week now, exhausted, and still can't figure it out. But I know I'm close! I will try your code now, but I'm not sure where you got your IRcode from. Did you convert Adress or Command to binary or what? Would appreciate your quick input mate, thanks alot.
Bit banging is sometimes cheap and effective. In non-critical applications like consumer remotes, I'd say slamming signals out of a GPIO is perfectly acceptable.
Dave you should have used DigitalWrite(IRLEDpin, 1) instead of using HIGH. It is considerably quicker than HIGH. That way you would not need to guesstimate the delay like you did. Give it a go and see if it helps... I suspect it would be much quicker.
How? Isn't HIGH just a constant used as a passed variable? If so it would make no difference at all to the digitalWrite function speed.
I miss this kinda thing, awesome vid
Thank you for this video, it was explained very easily and simply. 🤝
Yes, but then the code wouldn't be as portable, or usable on chips without available PWM, or as understandable to beginners. Bit bang is always a nice way to explain it first IMO.
We are going to do it the old fashion way ... Let me grab my digital scope lol. Good fun tutorial I think I have a few remotes I can play around with here.
Aah I see! thx for your explenation and fast response! I learned a lot about the code and how to send it. I allready knew a bit of IR but not how to send the codes. I only used my arduino once to decode IR and turn a LED on and off via my logitech harmony wich i programmed for a old sony VCR wich are the easiest to decode. anyways thank you very much for the video and your quick respose really apreciate it : )
I guess we all code differently. Thanks for using a unsigned long to hold the binary message and not int bits[32] as appears elsewhere on the web.
Is it necessary to repeatedly call IRsetup()? Could that be put in Setup()? The LED is OFF at the end of IRCarrier().
Thanks for the fulsome explanation, clear readable code (not C obscure) and your comments on available libraries, Murphy's law and sampled waveforms.
What's wrong with that? It means people know they can use it. What would you prefer?
The only pony trick left with this app is to use PWM to do it instead, or maybe using all 74xx logic? :->
Amazing video with some nice tips here and there. Great stuff.
yup... awesome is the word...
one thing Dave,
It seems quite obvious, but just so as to clarify my understanding: the signal (waveform) at the IR receiver output is exactly inverse of the signal that is fed into IR transmitter. Is that right?
In binary 0x80000000 is one followed by 31 zeroes. When you do an and operation with that on a 32-bit number you end up with its most signifigant bit. Within the if statement in the code, if the MSB is one the the condition evaluates as true, if zero then false. After that there is code
Thanks for this! I love tutorials like this.
Yeah. Learning how to use Git is quite difficult (even though Github helps a lot). Once you figured it out it's very useful for any kind of continued development (it works great with Eagle schematics for instance, or of course all kinds of source code).
The slow part of the loop is surely the divide by 26 in the conditional, which is executed every iteration of the loop. I'll bet the division is slower than the digitalWrite() call. The division should be pulled out of the loop.
the compiler optimizes that out already