IR Codes

[Turgut Guneysu]

Hi John,

I was testing the IR library between microBlocks and MakeCode.

I noticed that the same remote controller and IR sensor combo, connected to the same port produces different key codes between the two IDE’s.

              MAKECODE:          microBlocks: 
UP Arrow         170                 98    
DOWN Arrow       121                168
LEFT Arrow       168                 34
RIGHT Arrow      167                194

etc.

Also, in MAKECODE the emitted key codes are three digits, but only the last two are used in comparisons.

In microBlocks, the emitted codes vary betwen 2 & 3 digits, and all digits have to be used in comparisons.

It’s not a problem per se, but it creates confusion when porting code.

And why would they be different?

TG

[John Maloney]

I agree, it’s surprising that you’re seeing different codes in the two systems with the same remote. There could be a bug in the MicroBlocks decoder, although the most likely bug would be inverting the sense of the 1 and 0 pulses and the codes are note binary inverses of each other.

But it’s even stranger that only the last two digits are used by MakeCode comparisons. Do they offer any explanation for that?

[Turgut Guneysu]

There is no explanation.

I need to take a break from all the hex trouble shooting I've been doing. Tried to follow the code for the mb IR library without much success.

NEC protocol transmits 4 bytes and 3rd is the normal code whereas 4th is the inverted code.

Could you tell me if mb uses the 3rd or the 4th byte for IR Code?Then I'll chase the makecode as well as Arduino codes trying to figure it out.

Thx.

[Turgut Guneysu]

I did some more checking and discovered that the DFROBOT KIT I have been using (MAQUEEN - https://wiki.dfrobot.com/micro:Maqueen_for_micro:bit_SKU:ROB0148-E(ROB0148)#target_8 ), when used with DFROBOT’s own IDE for programming (MIND+ v1.56) also produces even different codes than the ones in MakeCode. This is totally strange, because the library is written by DFROBOT and the same code is used in MakeCode and MIND+ (At least so it seems, since they come from the same gitHub.

Anyway, now there are tickets opened in both environments. Let’s see what responses they will provide, and if it will help clarify the microBlocks issue.

Just as documentation, I have included the 0-9 numbers values in a comparison table below:

NEC CODES             MQ-IR CODES     MQ-IR CODES     MQ-IR CODES   
Key Encoded Value     in MIND+        in MAKECODE     in microBlocks
        hex    dec    hex  dec           dec            dec

0   0xFF6897 - 151    B5 - 181           182             74
1   0xFF30CF - 206    97 - 151           122            104   
2   0xFF18E7 - 231    67 - 103           125            152
3   0xFF7A85 - 133    4F -  79           113            176
4   0xFF10EF - 239    CF - 207           112             48
5   0xFF38C7 - 199    E7 - 231           124             24
6   0xFF5AA5 - 165    85 - 133           194            122
7   0xFF42BD - 189    EF - 239            18             16
8   0xFF4AB5 - 181    C7 - 199           128             56
9   0xFF52AD - 173    A5 - 165           190             90

[Turgut Guneysu]

A bit of progress regarding the codes:

The REMOTE I have been using is an Arduino Remote. A picture is included:

‌

I made a mistake of assuming all NEC protocol remotes produced the same codes for a given button press. Based on that assumption, I have been comparing codes I saw in a NEC code table in an article, which I have used in my previous message.

It turns out that the particular remote I have does NOT produce the same codes listed in the previous message.

Here is a corrected CODE table of my model:

NEC CODES             MQ-IR CODES     MQ-IR CODES     MQ-IR CODES   
Key Encoded Value     in MIND+        in MAKECODE     in microBlocks
        hex    dec    hex  dec           dec            dec

0   0xFF4AB5 - 181    B5 - 181           182             74
1   0xFF6897 - 151    97 - 151           122            104   
2   0xFF9867 - 103    67 - 103           125            152
3   0xFFB04F -  79    4F -  79           113            176
4   0xFF30CF - 207    CF - 207           112             48
5   0xFF18E7 - 231    E7 - 231           124             24
6   0xFF7A85 - 133    85 - 133           194            122
7   0xFF10EF - 239    EF - 239            18             16
8   0xFF38C7 - 199    C7 - 199           128             56
9   0xFF5AA5 - 165    A5 - 165           190             90

‌

After I figured this out, I verified the microBlocks codes again and noticed that indeed they are inverse of the original codes, eg.:
0 is hex B5 and has a decimal IR code of 181.
microBlocks produces 74 which is the code for 4A, the inverse of B5.

As such, I can confirm your original suggestion that MB has an inversion problem with the codes.

I will leave it up to you to decide if this is a bug, or code is referring to the wrong column in the NEC protocol data per the chart below:

‌

If the column 4 data is used, it would be the inverse of the command.

There is still the issue of why MakeCode IR codes are different for the same code base in DFROBOT library. But that has nothing to do with MB.

Sorry I took so much space describing this problem, but I hope it will be helpful to someone in the future.

[John Maloney]

Great detective work! This is indeed helpful!

Looking at the code for the MicroBlocks IR library, it appears that it is using the third byte as the command, which matches the spec, but the complemented version of the address – or “device ID” – (which doesn’t). Also, it isn’t checking that the the 2nd and 4th bytes are complements of the 1st and 3rd bytes, which maybe it it should.

[John Maloney]

I did a big more poking to see if I could figure out what MakeCode is doing wrong.

Here are the IR codes from your corrected table represented in binary from Mind+ (and the article you cited) and MakeCode:

Mind+    MakeCode 
10110101 10110110 
10010111 01111010 
01100111 01111101 
01001111 01110001 
11001111 01110000 
11100111 01111100 
10000101 11000010 
11101111 00010010 
11000111 10000000 
10100101 10111110 

I don’t see any obvious bit-level relationship between the two columns. For example, one value is not the inverse or the bit-reversed version of the other. So, while it appears that MakeCode has some sort of bug in decoding the incoming IR signal, it’s not as simple as inverting the bits or reading them in reverse order.

I’d need check the IR signal against the NEC spec to be sure, but it’s possible that both your article and the DFROBOT library have the bits inverted relative to the NEC spec and MicroBlocks actually matches the spec. That could have happened if, for example, the article misinterpreted the spec and DFROBOT used the article as their reference.

However, from the practical standpoint, which one is “correct” doesn’t matter much – either way, every key on a given remote will generate a unique and repeatable code. And since key codes are not standard across different remotes, programs written with one remote will often need to be modified with a different remote in any case.

That said, I agree that it would be nice if MicroBlocks and MakeCode reported the same codes for a given IR remote. But the codes you’re getting from MakeCode don’t seem to make sense at all. So I’ll wait and see what codes MakeCode reports after they fix their bug. It sounds like you reported the bug to the MakeCode team. Let me know if you get a response from them.

[Turgut Guneysu]

Yes I reported it. And their reply was that DFROBOT extensions are not approved by MakeCode and that I should take it up with DFR. Well, I also reported to them but no answer yet. Anyway, I'm getting tired of working with MC. They seem to have a different way of looking at things. I don't know if it is so because of Microsoft or just the particular project. From now on I'll be focusing on Microblocks, Snap, S4A, and Arduino.

Get Outlook for Androidhttps://aka.ms/ghei36