IR Remotes & Microcontrollers - Arduino & ESP32

Hello Guys:

regarding the issue of the output not turning off I was having , using the ir-remote-receive.ino sketch with my esp32, the fix was very easy. Only had to change line 110.

For reference , 

The link to the article is    https://dronebotworkshop.com/ir-remotes/

Scroll down the article to Resources and download the zip file from Code Samples

the link to the file is ( and sorry for the amazones )

https://s3.amazonaws.com/download.dronebotworkshop.com/IR-Remote-DroneBot-Workshop.zip

Change line 110 from:

110 digitalWrite(LED_PIN, LOW);

to :

110 analogWrite(LED_PIN,0);

I am not sure as why this is not an issue in Bill's video but for my esp32 it was.

digitalWrite and analogWrite on the same output was not working for me.

Hope this can help someone else.

PS : was able to fix an other issue where the remote seems to work intermittently.

If you watch the video in the article at time 52:17 , 52:23 , toggling the led on/off

appear to be challenging. Not sure if i'll extend this post of just start a new one.

I'll be back

enjoy the sun if you can

Hello Shunt,

I've had reasonable results with this project so far today and I wonder whether the issue of intermittent remote operation is actually the same problem I am experiencing.

i.e. the sent code is repeated rapidly by the sender unit and if my finger is not quick enough there may be two or more repeats of the code sent.

therefore the led may end up being not what is desired.

I will start a new post with this issue.

Posted by: @davee

↑

Hi @davee @shunt

   I have not looked at this project/video, and have not tried it, but I had a quick 'eyeball' at the code. I am not sure if I am missing the point (which is always easy at a quick glance), or there is a mistake.

    // Set LED Power and Level
    if (lampPower) {
      // Lamp is powered, set level
      analogWrite(LED_PIN, lampLevel);
    } else {
      // Lamp is off
      digitalWrite(LED_PIN, LOW);
    }

I was surprised to see an analogWrite ... shouldn't both writes be digitalWrite?

And although it may work, why is lampLevel used in one case, and the 'specific' LOW in the other.

Apologies if I have missed the point.

Best wishes, Dave

 

analogWrite is used to set the level of brightness, whereas the digitalWrite(LED_PIN, LOW) is how the pin is turned OFF. 

I will attempt to create this hardware hookup (not sure if I have an IR remote that will work yet) and feed back my test results.

@shunt Where is the following in Bills code?

remote buttons 1-2-3 for 0x10-0x11-0x12

push the button 1 once, serial monitor shows lampPower=1 , gpio 4 is high, led is ON

push the button 1 again, serial monitor shows lampPower=0 , gpio 4 is high, led is ON

@shunt If what you said below is correct, I hope you have reported to Bill (@dronebot-workshop) that his code has a bug. I doubt it, and will attempt to test today.

 @davee @will , as you pointed out , and thank you for this, mixing Digital and Analog Write is the issue.

@shunt 

regarding the issue of the output not turning off I was having , using the ir-remote-receive.ino sketch with my esp32, the fix was very easy. Only had to change line 110.

What about line 86???

digitalWrite(LED_PIN, LOW);

See attached pic for context

@zander hello Ron, as mentioned before , the digital write vs analog write was an issue for Esp32.

@shunt I know what you said. Why was it NOT an issue for Bill? Also, why did you only change one of the two uses of it in the sketch, 86 and 110?

Posted by: @zander

↑

@shunt I know what you said. Why was it NOT an issue for Bill? Also, why did you only change one of the two uses of it in the sketch, 86 and 110?

hi Ron , to answer your question, made no difference if line 86 was there or not on my esp32.

I was able to get the output Off only by changing line 110.

tks

Posted by: @old-plumber

↑

Hello Shunt,

I've had reasonable results with this project so far today and I wonder whether the issue of intermittent remote operation is actually the same problem I am experiencing.

i.e. the sent code is repeated rapidly by the sender unit and if my finger is not quick enough there may be two or more repeats of the code sent.

therefore the led may end up being not what is desired.

I will start a new post with this issue.

Good day to you Old Plumber

I dont have enough posts to write to you ( or any one else )  directly so I will add some notes here . Feel free to add them in your new post if they were usefull to you.

The sent repeats can be an issue if your using the same button to 'toggle' your output. You have to be finger fast to avoid the issue. I have prove this by using a different button to turn Off and the code work very well.

If you want to keep the toggle approach ( which I preferred ) , I had better luck decoding the Raw Data instead of the commands when I use my NEC remote and here is why :

By serial printing the raw data and commands once decoded, you can see that the raw data does not get repeated, and again, this is using my NEC remote ( might be different on others ).

@shunt @davee @will @old-plumber To whom it may concern. I have a bad habit of READING Bill's articles, I usually only watch the videos once if at all. It seems there are more than a few posts that complain about mixing digital and analogue write. What nobody apparently noticed is when Bill said

Also note that if you turn the LED off, it retains its brightness level.

That sentence is immediately after the picture that is after the verbal explanation that is after the sketch you all have been fussing with.

I am always VERY suspicious when someone claims to have found a bug in Bill's code. I am not remotely arrogant enough to assume that if a sketch does not work then it must be Bill's fault. The only time I am aware of is when a library had an issue AFTER Bill published resulting in breaking Bill's code. 

Hello Ron,

for your info, the analogWrite (x, 0 ) is turning off the led .

the brightness is mémorised in level variable

@shunt Sorry, you are reading Bills example incorrectly but if you are happy that is cool, I just wanted to make sure anyone reading this understood that Bills example is correct as documented.

Hi Ron @zander,

   I only made a suggestion to the effect that, if the code was proving troublesome, that is where I would try looking.

I, in no way, intended any accusation about Bill (@dronebot-workshop), or his code, and I apologise if anything I posted implied that was the case. I have great respect for the effort Bill makes in producing high quality material.

It seems from the following discussion, that my suggestion had some merit, in that it was reported to fix, or at least ameliorate, the problem, but I make no claims as to its accuracy or efficacy. It was just a suggestion to investigate.

-----------

Many times in the past, when looking for solution to a problem, I have done an experimental change, which was not a fix for the problem in itself, but the effect the change caused, provided a valuable clue as to the true mechanism of the problem.

-----------

I have just had a look for the phrase "Also note that if you turn the LED off, it retains its brightness level.", and see it is in a section where the microcontroller is an Arduino Uno.

@shunt says in the opening question "For reference, I am using an esp32 and a Panasonic Remote."

Do we know, for certain, that a Uno and an ESP32 will behave in the same way? I am Not saying they will behave differently, but I would certainly include it as something to check out, before jumping to conclusions.

-----

To do a full analysis of the 'problem', I would need to look at all the top level program, the library code (at assembler level), combined with the hardware implementation within the microcontroller(s). If I was the responsible person behind a safety critical product, I think that would be justified, but as someone who is just trying to help someone solve their particular issue, I do not feel it is justified, before making a speculative suggestion

-------

As I pointed out in my original post, "I have not looked at this project/video, and have not tried it, but I had a quick 'eyeball' at the code. I am not sure if I am missing the point (which is always easy at a quick glance), or there is a mistake.", so it was obvious I would not have seen the comment, "Also note that if you turn the LED off, it retains its brightness level."

I also apologised and explained it was only a suggestion, I think it is unfair to suggest I in any way implied Bill's code was flawed.

So my apologies to anyone I have inadvertently offended or harmed, particularly our generous host Bill (@dronebot-workshop). I was only trying to be helpful.

Ron, you may have a valid point in suggesting that there is a contradiction in the available evidence, but sorry, I do not have the inclination to investigate it further, as for me at least, the consequences do not seem to justify it.

Take care and best wishes to all, Dave 

@davee I do intend to run a test with both an UNO and an esp32 but I would make a substantial wager it will work the same way for each since it is a standard.

I think too many folks perhaps myself included do too much speculation and not enough actual testing. You and I know each other well enough to know we like to debate and tease out minutia but to a noob that is likely confusing. I think all your posts start and end with a paragraph of 'cover your *ss statements' whereas I am a little more risk-taking and leave out the obvious caveats most of the time.

I think this Topic is a good example. Here is the ORIGINAL problem statement

My led will turn ON when lampPower goes HIGH but stays ON when lampPower is LOW.

Was wondering if others have experienced the same issue.

As I pointed out a post or so back, Bill says that is what happens. All of us 'helpers' missed that until I stumbled upon it an hour or so ago.

All of us 'helpers' have been less than helpful, and that includes me. Had I seen the statement above at the beginning, the entire discussion would have gone a different way and a more educational way.

I think all of us can benefit from reading ALL the background material before sending someone on a wild goose chase and that includes me.

I have some personal issues tying me up for the next few hours, but if someone else can fire up Bill's setup and then switch it for an ESP32 to see if it works the same way then that would be great. If not then I will as soon as I can.