Samsung Air Conditioner

[Mark Pierson]

I suspect delimeters(such as <<. >>, |, etc.) are causing the problem. Since Korean Characters are based on 2 byte character codes, when it is mixed with a certain ASCII byte and/or non-printing characters we see unwanted weird results.

The easiest solution would be to disable the embedded notes in KM/RM before copying over to IR. If you want notes, you'll have to enter them manually in IR.

I'm not sure how to deal with the language issue since this is the first occasion I've heard of this happening. Are you using KM or RM for the upgrades?

[johnsfine]

Rob, I haven't been following this thread.

I took a quick look at the txt file generated by CaptureIr that yesok just posted.

This is a 56 bit signal. I assume you had already figured that out. DecodeIR didn't recognise the protocol, but gave generic decodes that I think are correct. The generic decode is the seven bytes of data (each byte done LSB first) output in hex. For example the 1 key was decoded as:

1.D2.FE.21.83.1B.C4

I assume all that is consistent with what you already figured out.

[johnsfine]

I have uploaded CaptureIR captured signals for Power Off/On( see http://www.hifi-remote.com/forums/dload ... le_id=4421).

Having skimmed through this thread, I guess I don't understand what that captureIr output represents. Maybe I need to fix captureIr to save some extra context or timing info.

It looks like a capture of ten seperate key presses, each with a slightly different signal. Is that correct? (Was it ten seperate presses?)

You said it was Power Off/On. Are they all Power Off/On?

Code: Select all

1.D2.FE.21.83.1B.C4
1.B2.FE.21.83.1B.F4
1.D2.FE.21.83.1B.C4
1.A2.FE.B1.82.1B.F4
1.C2.FE.B1.82.1B.C4
1.A2.FE.B1.82.1B.F4
1.C2.FE.B1.82.1B.C4
1.A2.FE.B1.82.1B.F4
1.D2.FE.21.83.1B.C4
1.B2.FE.21.83.1B.F4

The last byte toggles, which I guess could be the On/Off aspect of the On/Off button (or maybe just an every button toggle of this protocol). But I don't make sense of what the second and fourth bytes are doing.

If this were less than ten presses, so the signals is very long containing BIG pauses, then the second and fourth bytes would make more sense. But then captureIR might be missing something during the decode intervals.

If you think that is the case, you can slow CaptureIr down. Under File/Preferences/Timing put an even bigger number in Max Gap time (though if I'm reading your output right, you already set that way higher than default).

[The Robman]

This is indeed a very long signal and subsequent presses of the same button do sometimes generate different signals. The POWER-OFF button has more than one data stream and the stream is too long for a regular learning remote to capture as it only gets about 1/2 of the 2nd stream.

The executor that I created for this (which works) uses 1 fixed byte of data and 6 variable bytes of data. I would hope at some point to be able to reduce the # of variable bytes, but I haven't spotted a pattern yet.

[johnsfine]

I see now that I was misreading the saved data (I've previously only looked at CaptureIr output on screen as generated, not as saved).

There is more than one decode per capture (more than one 56 bit signal sent per press). I think that would have been more visible on screen when CaptureIr was run, but it is very unclear from the saved text.

You almost need to ignore the saved decodes and redecode by hand from the saved timing info, which I don't have time to do today. Maybe Rob already has a clearer idea of what is going on.

Rob, do I understand correctly: Power Off sends two 56 bit frames (with different contents) divided by just a 1.8 ms gap? Power On sends just one 56 bit frame?

Each of Power On and Off changes what it sends from one press to the next?

[The Robman]

I've just got done decoding the CaptureIR text (there's no rounding option here, so it takes a LONG time).

Here's the decodes...

POWER OFF
80 41 F0 00 01 05 C0
80 4B 7F 84 C1 D8 23

80 41 F0 00 01 05 C0
80 4B 7F 84 C1 D8 23

80 41 F0 00 01 05 C0
80 43 7F 8D 41 D8 23

80 41 F0 00 01 05 C0
80 43 7F 8D 41 D8 23

80 4E F0 00 01 0D C0
80 4B 7F 84 C1 D8 23

POWER ON
80 4D 7F 84 C1 D8 2F
80 45 7F 8D 41 D8 2F
80 45 7F 8D 41 D8 2F
80 45 7F 8D 41 D8 2F
80 4D 7F 84 C1 D8 2F

The executor that I wrote will need to be modified in order to send two frames for the POWER-OFF button. I'll try to do it soon.

Let me know what results you get testing the various TEMP buttons.

[yesok]

The easiest solution would be to disable the embedded notes in KM/RM before copying over to IR. If you want notes, you'll have to enter them manually in IR.

How to do that in KM? I know how to do that in RM.

I'm not sure how to deal with the language issue since this is the first occasion I've heard of this happening.

How about relying on Unicode?

Are you using KM or RM for the upgrades?

I am using RM most of the time.


Yesok

[yesok]

Having skimmed through this thread, I guess I don't understand what that captureIr output represents. Maybe I need to fix captureIr to save some extra context or timing info.

Real good news. Thanks in advance.

It looks like a capture of ten seperate key presses, each with a slightly different signal. Is that correct? (Was it ten seperate presses?)

It is a capture of a same key(toggling between power off/on), pressed sequentially 10 times.

You said it was Power Off/On. Are they all Power Off/On?

Yes.

Code: Select all

1.D2.FE.21.83.1B.C4
1.B2.FE.21.83.1B.F4
1.D2.FE.21.83.1B.C4
1.A2.FE.B1.82.1B.F4
1.C2.FE.B1.82.1B.C4
1.A2.FE.B1.82.1B.F4
1.C2.FE.B1.82.1B.C4
1.A2.FE.B1.82.1B.F4
1.D2.FE.21.83.1B.C4
1.B2.FE.21.83.1B.F4

The last byte toggles, which I guess could be the On/Off aspect of the On/Off button (or maybe just an every button toggle of this protocol).

I think so.

But I don't make sense of what the second and fourth bytes are doing.

If this were less than ten presses, so the signals is very long containing BIG pauses, then the second and fourth bytes would make more sense. But then captureIR might be missing something during the decode intervals.

If you think that is the case, you can slow CaptureIr down. Under File/Preferences/Timing put an even bigger number in Max Gap time (though if I'm reading your output right, you already set that way higher than default).

Robman may have some idea.


Yesok

[Mark Pierson]

The easiest solution would be to disable the embedded notes in KM/RM before copying over to IR. If you want notes, you'll have to enter them manually in IR.

How to do that in KM? I know how to do that in RM.

On the Setup sheet under the Device Upgrade Code is a checkbox labeled DISABLE Embedded Notes.

I'm not sure how to deal with the language issue since this is the first occasion I've heard of this happening.

How about relying on Unicode?[/quote]KM, RM, and IR are all using the same special characters to parse the embedded notes. My guess is that the language support at the Windows level is what's causing these problems. I honestly don't know if Unicode is the answer.

[yesok]

Hello,

On the Setup sheet under the Device Upgrade Code is a checkbox labeled DISABLE Embedded Notes.

I found it. Thanks.

KM, RM, and IR are all using the same special characters to parse the embedded notes. My guess is that the language support at the Windows level is what's causing these problems. I honestly don't know if Unicode is the answer.

Yes, Microsoft Korea is no exception in poor customer support, as in other countries.

Yesok

[yesok]

Hello Robman,

Let me know what results you get testing the various TEMP buttons.

All Temp up/down signals do not work.
I have uploaded CaptureIR captured signals for those buttons(see http://www.hifi-remote.com/forums/dload ... le_id=4423).

Maybe they are like Power Off Button?

Yesok

[The Robman]

By the way, if you want to try something while you're waiting for a new executor, you could try this...

1) create two new entries in the functions sheet that use the following hex codes...

1st button: 41 F0 00 01 05 C0
2nd button: 4B 7F 84 C1 D8 23

Then assign then to buttons on your remote, then press then in sequence to power your unit off. If it works, you could try programming a macro to do it. If that works, maybe you won't need a new executor.

Heck, you could try each button by itself to see if it does anything.

[yesok]

Hello Robman,

1) create two new entries in the functions sheet that use the following hex codes...

1st button: 41 F0 00 01 05 C0
2nd button: 4B 7F 84 C1 D8 23

Heck, you could try each button by itself to see if it does anything.

The 2nd button alone works as Power Off!

Could you tell me how it works?

Many thanks for your wonderful work!

Yesok

[johnsfine]

The 2nd button alone works as Power Off!

The power off button on your original remote sends two commands. The second command turns it off. If I understand correctly, you don't know what (if anything) the first command does.

I hope it is safe to use just the second. Maybe the first does some sort of prepare_to_turn_off function that avoids stopping it in a bad state and/or turning off two many parts at once (causing a power surge).

[The Robman]

Try these hex codes for the 2 temp buttons...

temp up
45 7F 8D 49 D8 0F

temp down
4D 7F 8D 41 D8 0F