IR Library in 2.07

[schmidmi]

At first thanks to all guys for implementing the nice IR - features in 2.0.7!
In the most cases it seems to work fine.
But I've found a problem working with an remote for a Mitsubishi Heat Pump.
I can read the IR-code with the IR-scanner, but it seems to be only a part of the bit stream being sended by the remote. I suppose the remote is sending a stream of about 144 bits which are processed by the IR-scanner to a raw data array of 80 words (see attachment)

Sending these raw data shows exactly the code, which was captured by the IR-scanner.
Unfortunately I have no oscilloscope for further investigations.

I believe that there is a limit inside the ZUNO for the length of the bit stream which is to be decoded.

My question is:
Is there any solution which make it possible to scan such 'long' IR codes?

[PoltoS]

Hello! Indeed, we currently have a limit of the IR command. We plan to rise this limit in 2.0.8 because few customers reported that their remotes are sending longer commands than we read.

You can use Arduino to read the full command, so we know how much the limit should be rised.

[schmidmi]

Hello!
Thanks for the quick reply.
As mentioned in my 1st post, I need to store an IR code of 144 bits (18 Bytes).
Looking to the internet pages of https://www.analysir.com/blog/ I've got the feeling, that 160 Bits should be suitable for most cases.

[schmidmi]

Hello!

I found some additional information about IR codes for air conditioners:

Air conditioners typically send the full configuration every time a key on the remote is pressed. This results in much longer signals compared to TVs.
AC signals can be as long as 128+ bits vs 32 for typical TVs. (or 256 vs 64 pulses)

[PoltoS]

Please try it with 2.0.8 - we have rised the limit.

viewtopic.php?f=3427&t=24573

[schmidmi]

A little bit frustrating
The new versions 2.0.8 now handles 9 bytes of IR code, but Mitsubishi A/C equipment needs 18 bytes.
Will there be any chance, to get these huge codes being handled by the IR scanner in Z-UNO?

[PoltoS]

18 bytes? Really? This is too big. We need to waste 300 bytes more in our RAM to handle it. Not sure we can do so - RAM is not elastic

Anyone else who need more than 9 bytes?

[p0lyg0n1]

The hardware limit is 15 bytes in the case we get the maximum amount (511) of raw bytes to IR controller. I Don't think that you really need 18 bytes. Can you sniff sequence with logic analyzer?

[schmidmi]

Indeed Mitsubishi uses 18 bytes. The reason is, that they transmit all settings in each telegram. And there are a lot of settings

There are some guys who made a reverse engineering for a type of A/C controller, but mine seems to be different.

See here:
https://www.analysir.com/blog/2015/01/0 ... -protocol/

But I understand the problem with the ram.

So I will have to analyse the protocol of my transmitter with a different hardware and than write a code in Z-Uno to send it to my A/C system.

[schmidmi]

Thanks to all the programmers of the Z-UNO firmware!

Using the new Features of GPT and external interrupts I was able to analyse the protocol of my Mitsubishi A/C.
I connected the IR - receiver to the ZEROX (Pin 3).
With the GPT I measured the length of the pulses coming from the IR transmitter.
Now I can prove, that Mitsubishi is using a code length of 18 Bytes!

These 18 bytes are transmitted twice with a special Repeat Mark between.
The only thing I have to do now, is to write a small C# program, which converts my measured values into raw data for sending them with Z_UNO.

Thanks a lot again!