IR Detector - Sharp AC

[Tinaja]

I recently bought a Sharp CV-P10PC portable air conditioner, hoping to cool and dehumidify my basement. It does a good job of keeping a constant temperature but it doesn't do as well with humidity. After reading the IR detector tutorial I was hoping to use an SHT21 I have lying around and an arduino to control the AC functionality by learning the remote codes and then hanging an IR LED in front of the AC.

Oddly, with the tutorial code and just toggling between on and off on the remote I can't seem to get the same results twice. The pulse count varies between 45-100 depending on how close I hold the remote to the detector. Is it possible this detector is not at the right frequency? Before I dig out a dusty MSO-19, is there a way to find out what frequency Sharp normally uses for stuff like this?

Any other ideas on how to proceed?

[franklin97355]

Is it possible this detector is not at the right frequency

Which detector? Yes, it's possible.

[philba]

It could be a number of things. The carrier frequency of Sharp IR remotes for electronics is 38Khz. This means that any receiver in the range 36-40Khz will work. It's possible that the air conditioner group doesn't follow the rest of the company, though (but it seems unlikely).

If the remote repeats, the number of pulses you will receive is based on how long you hold the button down. Look for repetitions of a pattern. Also, look for long off periods which signify the end of a command. Note also that arduino timings won't be precise (because you only have 4 microsecond resolution). I'm surprised that the tutorial has such clean numbers - I've never seen that. Regardless, most remotes repeat the command 3 times. In many protocols, they use 400 uS and 800 uS pulses and anything within 10% is probably one of those. The accuracy of those remotes is pretty poor so there may be as much as 20% error in the timings. The protocols and receivers are designed to accept this slop.

[Tinaja]

Great. I'm using the one from the Adafruit sensor pack and I believe it runs at 38Khz.

You mentioned resolution - in the IR Detector code it says this:

Code: Select all

// what our timing resolution should be, larger is better
// as its more 'precise' - but too large and you wont get
// accurate timing
#define RESOLUTION 10

Should I be setting that to 4?

Thanks for the help.

[Tinaja]

The remote doesn't seem to be repeating. If I hold the button down I only get one burst of pulses and I have to release and press it again to generate another stream.

I rewrote the IRDetector sketch to output a pulse stream that I could just copy and paste into my code after capturing. The output in the serial monitor looks like what I've pasted below.

The power button is a toggle. The remote has an LCD screen so I can see what mode it's in. IOW, If the screen is off and I poke the button I'm sending ON. Toggling the button like this, slowly, generates the following results - this is typical:

ON - 46 pulses
OFF - 49 pulses
ON - 45 pulses
OFF - 46 pulses
ON -51 pulses
OFF - 50 pulses

and so on.... It seems to be random every time.

Code: Select all

...
delayMicroseconds(1370);     pulseIR(460);
delayMicroseconds(1360);     pulseIR(460);
delayMicroseconds(1380);     pulseIR(440);
51 pulses, total.



Received:

OFF    ON
pulseIR(3800);
delayMicroseconds(1820);     pulseIR(460);
delayMicroseconds(420);     pulseIR(480);
delayMicroseconds(1370);     pulseIR(460);
delayMicroseconds(420);     pulseIR(480);
delayMicroseconds(1350);     pulseIR(480);
delayMicroseconds(420);     pulseIR(480);
delayMicroseconds(1370);     pulseIR(450);
delayMicroseconds(430);     pulseIR(480);
delayMicroseconds(1360);     pulseIR(470);
delayMicroseconds(440);     pulseIR(460);
delayMicroseconds(1360);     pulseIR(470);
delayMicroseconds(440);     pulseIR(460);
delayMicroseconds(1370);     pulseIR(450);
delayMicroseconds(1370);     pulseIR(460);
delayMicroseconds(440);     pulseIR(460);
delayMicroseconds(1370);     pulseIR(460);
delayMicroseconds(440);     pulseIR(460);
delayMicroseconds(1360);     pulseIR(470);
delayMicroseconds(1360);     pulseIR(460);
delayMicroseconds(1370);     pulseIR(450);
delayMicroseconds(1370);     pulseIR(460);
delayMicroseconds(440);     pulseIR(460);
delayMicroseconds(450);     pulseIR(450);
delayMicroseconds(1370);     pulseIR(460);
delayMicroseconds(1360);     pulseIR(470);
delayMicroseconds(440);     pulseIR(460);
delayMicroseconds(440);     pulseIR(470);
delayMicroseconds(420);     pulseIR(480);
delayMicroseconds(430);     pulseIR(480);
delayMicroseconds(1360);     pulseIR(460);
delayMicroseconds(420);     pulseIR(480);
delayMicroseconds(430);     pulseIR(480);
delayMicroseconds(420);     pulseIR(490);
delayMicroseconds(1360);     pulseIR(460);
delayMicroseconds(440);     pulseIR(470);
delayMicroseconds(1360);     pulseIR(460);
delayMicroseconds(1370);     pulseIR(450);
delayMicroseconds(450);     pulseIR(460);
delayMicroseconds(450);     pulseIR(450);
delayMicroseconds(430);     pulseIR(480);
delayMicroseconds(420);     pulseIR(480);
delayMicroseconds(1370);     pulseIR(460);
delayMicroseconds(440);     pulseIR(470);
delayMicroseconds(420);     pulseIR(460);
delayMicroseconds(450);     pulseIR(460);
delayMicroseconds(440);     pulseIR(460);
delayMicroseconds(450);     pulseIR(450);
delayMicroseconds(1370);     pulseIR(460);
delayMicroseconds(1370);     pulseIR(460);
50 pulses, total.



[philba]

I took a look at the tutorial code. RESOLUTION is the resolution in microseconds that they are sampling. This yields results in multiples of RESOLUTION microseconds. Makes sense though you do lose accuracy. Not a killer because of the looseness of the specs. When you say 49 pulses, do you mean 490 microseconds?

At this point, I'd get your scope out. You might also want to use a phototransistor as a receiver for the scope or hook up directly to the IR emitter in the remote. I think the MSO-19 has a logic analyzer - that might be more useful. I've have good success with a USB LA to understand IR remotes.

[Tinaja]

If you look in the "code" example I attached you'll see a pulse count at the bottom of the streams. I just inserted a loop counter into the printpulse function. The only thing useful about it is to show that the stream looks different every time.

Code: Select all

void printpulses(void) {
  Serial.println("\n\r\n\rReceived: \n\rOFF \tON");
  for (uint8_t i = 0; i < currentpulse; i++) {
    if (i != 0){
    Serial.print("delayMicroseconds\(");
    Serial.print(pulses[i][0] * RESOLUTION, DEC);
    Serial.print(");  \t");
    }
    Serial.print("pulseIR\(");
    Serial.print(pulses[i][1] * RESOLUTION, DEC);
    Serial.println(");");
    lc++;  // Pulse counter
  }
  Serial.print(lc); Serial.println(" pulses, total.");
  lc = 0;
}


[philba]

Well, there is some randomness but that's not surprising. You will never see 100% exact results. At least I never have. Lots of variability. This is why I'm surprised at how clean the data in the tutorial is.

Instead of thinking delay and pulse. think space (0) and mark (1). Except for 2, all your spaces and marks fall into two lengths - about 1.37 mS (1.36 and 1.37) and about .46 mS (420 to 480 is close enough). (the two that don't appear to be a lead in sequence.) If you think of the output as a stream of encoded 1s and 0s sent at about 2200 bps, you will see that the 1.37 mS space is about 3X a .46 space and thus is probably a 0.

I would bet that the transmission of 11 would be .46 space, .46 mark, .46 space, .46 mark, .46 space and transmission of 10 would be .46 space, .46 mark, .46 space, .46 space, .46 space where the 3 spaces in a row would be a 1.32 space (so you would see .46 space, .46 mark, 1.32 space)

So, in the example you posted, I see the following: lead-in sequence (long mark (3.8 mS), long space (1.82 mS)), 110110110110101...

This doesn't necessarily solve the issue of varying lengths of encoded commands but I've seen that as well from various remotes. I would modify the program to boil the received data into an apparent command string and print it out (maybe in hex). (the ability to compactly visualize your data is critical here) Then run the program. press the same button 10-20 times and look for commonality in the print out. It should become clear at some point.

[Tinaja]

Thanks for all the help. There does appear to be some commonality about the results but I'm not sure what to do with it just yet. For the bulk of these the top section is identical, but the end of the stream is very random. These are all "Off" codes. http://screencast.com/t/eccG6I1Mv

[Tinaja]

Bah - the plot thickens...

http://screencast.com/t/bvakTD5cIaLb

[Tinaja]

I am not sure where to go next with this. In the previous spreadsheet each column represents a button press. If the delay was >800 us it's an "H" and if it's <800 us it's a "L". Both the OFF and ON codes look identical up to pulse 30 and they diverge after that. That would be OK if I got the same results out of every OFF press and every ON press, but, as you can see, it seems to be semi-random after pulse 30. The only thing that stands out is that the OFF pulses end with 2 H's and the ON pulses end with 4 H's.

[philba]

I'd try each of those sequences to see what it does.

[Tinaja]

I've tried all of them with no luck. The random element is really bugging me. Each column is basically identical up to pulse 30 then it just goes to banned. If the first 30 are basically identical then it would appear that the timing code is working properly. If it were completely random I would feel a lot better, frankly.

I'm not used to electronics working like this I should get the same pulse train every time I hit the same button repeatedly...

I found this: http://www.sbprojects.com/knowledge/ir/sharp.php but it doesn't explain the random elements.

[philba]

Very puzzling.

That link is somewhat useful but clearly the modulation scheme (1 is in a 2 mS window, 0 is in a 1mS window) isn't used by your remote. One thing that does seem interesting is the fact that they transmit the inverted signal after 40 mS. Are you seeing anything like that?

I would be tempted to hook directly to the emitter on the remote control to eliminate your receiver as a source of the variability. It will probably give you the same results but worth eliminating every possible source of error.

I wonder if there is some sort of rolling code or sequence that the remote goes through. I'd write some specialized code to look for the common lead-in sequence and then only spit out the variable part at the end as a hex or binary code. This would allow more efficient experimentation. If it's a rolling code thing, there will be a point where it repeat since there aren't that many bits. The last bit or bits of each sequence might be some sort of check digit (parity or whatever). Also, I'd see what happens if you let the remote sit unused for a while, do you get the same sequence?