Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem in IRLib_P01_NEC.h not setting the modulation frequency correctly #57

Open
hiduino opened this issue Aug 5, 2018 · 1 comment · May be fixed by #90
Open

Problem in IRLib_P01_NEC.h not setting the modulation frequency correctly #57

hiduino opened this issue Aug 5, 2018 · 1 comment · May be fixed by #90

Comments

@hiduino
Copy link

hiduino commented Aug 5, 2018

The definition to pass the frequency from IRLibCombo.h send case statement is using 'khz' parameter.
public:
void send(uint8_t protocolNum, uint32_t data, uint16_t data2=0, uint8_t khz=38) {
if(khz==0)khz=38;
switch(protocolNum) {
IR_SEND_PROTOCOL_01

However, the IRLib_P01_NEC.h is using 'data2' which is passing the wrong parameter for frequency.
#define IR_SEND_PROTOCOL_01 case 1: if(data2==0)data2=38;IRsendNEC::send(data,data2); break;

This should be changed to:
#define IR_SEND_PROTOCOL_01 case 1: if(khz==0)khz=38;IRsendNEC::send(data,khz); break;

@hiduino hiduino changed the title Bug in IRLib_P01_NEC.h not setting the modulation frequency correctly Problem in IRLib_P01_NEC.h not setting the modulation frequency correctly Aug 24, 2018
@FidgetyRat
Copy link

I concur with @hiduino. Until I found this post, I spent two days fighting what I thought was a hardware issue as my television was intermittently receiving codes I sent. My code is using the IRLibCombo send method with 3 paramters, the protocol, code, and number of bits as my device handles multiple protocols at the same time.

With the above bug, when the # of bits is supplied for an NEC code (32) it overrides the frequency to 32 khz instead of 38 khz. The result was that my television had a weak response to codes which sometimes were skipped altogether.

With the corrections above, my device now has complete reliability in transmitting codes.

@andrea689 andrea689 linked a pull request Dec 5, 2019 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants