METechs Drapery Control

Post by **The Robman** » Mon Aug 22, 2011 12:49 pm

kkl wrote:"The data that you see is an internal encoded, it is not directly related to the serial protocol.

Where you see the alternating 01 and 00, that is the actual IR code.
Each byte has two fields. upper 4 bits represent the burst, lower -
space. So in the byte 01 "zero" is burst, and "1" is the space. The
duration of those is taken from an array. The first entry of which is
00 00 00 35, 4 bytes per entry. To get the time in uS you need to
multiply that value by 8.

Here's a break down of the code you originally posted for OPEN, using the info from above:

00 00 00 00 08 00 00 00 = unknown

35 00 00 00 = time 0
9D 00 00 00 = time 1
ED 10 00 00 = time 2
08 2B 00 00 = time 3

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 34 88 27 05 00 00 00 00 00 00 00 00 02 00 00 00 0C 00 00 00 84 67 00 00 00 00 00 00 5F 00 00 00 FF FF FF FF = unknown

00 01,00 01,00 01,01 00,00 01,00 01,00 01,01 00,00 01,00 01,00 01,00 02 = signal 1 = 000100010000
00 01,00 01,00 01,01 00,00 01,00 01,00 01,01 00,00 01,00 01,00 01,00 03 = signal 2 = 000100010000
00 01,00 01,00 01,01 00,00 01,00 01,00 01,01 00,00 01,00 01,00 01,00 02 = signal 3 = 000100010000
00 01,00 01,00 01,00 01,00 01,00 01,00 01,00 01,00 01,00 01,00 01,00 __ = signal 4 = 000000000000

00 01 = time 0 (on), time 1 (off) = logical 0
01 00 = time 1 (on), time 0 (off) = logical 1
00 02 = time 0 (on), time 2 (off) = logical 0 followed by short leadout
00 03 = time 0 (on), time 2 (off) = logical 0 followed by long leadout

By all means, please show my decode to the developer and see if he agrees with it, and maybe ask him if he can provide some meaning for the rest of the data.

The interesting thing here is that the only difference between the code that worked and the code that didn't was one of the leadout times.

kkl · Post by **kkl** » Tue Aug 23, 2011 3:57 pm

The Robman wrote: please show my decode to the developer and see if he agrees with it

I'll see if I can get a response.

kkl · Post by **kkl** » Tue Aug 23, 2011 4:04 pm

The Robman wrote:So it was just the burst times after all. Well, we got there in the end.

Uh oh...

I've been doing a lot of testing with the IR blaster and finding it very inconsistent, mostly not working. I think it might be the 8 key, which we spent very little time on. The way this controller works is, if it receives a number other than 8, it will stop responding until/unless it receives an 8. I have tried relearning the 8 key and am getting a slightly different response almost every time. Here are the learns:

Code: Select all

8
0000 0072 0000 0018 0010 002D 0010 002C 0010 002D 0010 002D 000F 002D 002F 000F 0010 002C 002F 000F 0010 002D 0010 002C 0010 002D 0010 04F3 0010 002D 0010 002D 0010 002C 0010 002D 0010 002D 002D 000F 0010 002D 002D 000F 0010 002D 0010 002D 0010 002C 0010 0E34

8b
0000 0072 0000 0018 0010 002D 0010 002C 0010 002D 0010 002D 0010 002C 002F 000F 0010 002D 002D 000F 0010 002D 0010 002D 000F 002D 0010 04F5 000F 002D 0010 002D 0010 002C 0010 002D 0010 002D 002D 000F 0010 002D 002F 000F 000F 002D 0010 002D 0010 002D 000F 0E34

8c
0000 0071 0000 0018 000F 002E 0011 002E 0011 002E 000F 002E 0011 002E 002E 000F 0011 002E 0030 000F 0011 002C 0011 002E 0011 002E 000F 0500 0011 002E 000F 002E 0011 002E 0011 002C 0011 002E 0030 000F 0011 002C 0030 000F 0011 002E 000F 002E 0011 002E 0011 0E54

8d
0000 0071 0000 0018 0011 002E 0011 002E 000F 002E 0011 002E 0011 002C 0030 000F 0011 002E 002E 000F 0011 002E 0011 002E 000F 002E 0011 0500 000F 002E 0011 002E 0011 002C 0011 002E 0011 002E 002E 000F 0011 002E 0030 000F 000F 002E 0011 002E 0011 002E 000F 0E54

Sat8 (JP1)
0000 0072 0000 0018 0010 002C 0010 002D 0010 002D 0010 002C 0010 002D 002F 000F 000F 002D 002F 000F 0010 002D 000F 002D 0010 002D 0010 04F3 0010 002D 0010 002D 0010 002C 0010 002D 0010 002D 002D 000F 0010 002D 002F 000F 000F 002D 0010 002D 0010 002D 000F 0E34

Cbl8 (JP1)
0000 0071 0000 0018 0011 002E 000F 002E 0011 002E 0011 002C 0011 002E 0030 000F 0011 002C 0030 000F 0011 002E 000F 002E 0011 002E 0011 04FE 0011 002E 0011 002E 0011 002C 0011 002E 0011 002E 002E 000F 0011 002E 002E 0011 000F 002E 0011 002E 0011 002E 000F 0E54

Could there be something like a toggle-bit going on here? The number keys were the only ones that were decoded as sub-device 0. The transport keys were sub-device 1. Could that be making the difference? I don't know which code is right now and cannot get a consistent response from the device. Any help?

kkl · Post by **kkl** » Tue Aug 23, 2011 6:19 pm

kkl wrote:
The Robman wrote: please show my decode to the developer and see if he agrees with it
I'll see if I can get a response.

Reply:

I made a small error in my previous email. The array of entries starts
at byte 8, not 5, so the time0, time1 etc are as following:

35 00 00 00 (0x35)
9D 00 00 00 (0x9D)
ED 10 00 00 (0x10ED)
08 2B 00 00 (0x2B08)

Otherwise his decoding is correct.

Post by **The Robman** » Tue Aug 23, 2011 7:45 pm

Was he willing to say what the rest of the data means? If we know how to read this data, we might be able to create a tool that reads it and links up with DecodeIR.dll to give JP1 style decodes.

Post by **The Robman** » Tue Aug 23, 2011 7:49 pm

kkl wrote:I've been doing a lot of testing with the IR blaster and finding it very inconsistent, mostly not working. I think it might be the 8 key, which we spent very little time on. The way this controller works is, if it receives a number other than 8, it will stop responding until/unless it receives an 8. I have tried relearning the 8 key and am getting a slightly different response almost every time.

Could there be something like a toggle-bit going on here? The number keys were the only ones that were decoded as sub-device 0. The transport keys were sub-device 1. Could that be making the difference? I don't know which code is right now and cannot get a consistent response from the device. Any help?

The "unit code" is really just a flag that states whether the signal repeats or not. The "8" button should not repeat, so the unit code should be 0. The transport keys do repeat, so the unit code should be 1.

All of the "8" learns that you just posted are stored as repeating keys, which is wrong. To edit the pronto hex so that they don't repeat, change the 3rd and 4th bytes from this "0000 0018" to this "0018 0000".

cauer29 · Post by **cauer29** » Tue Aug 23, 2011 8:47 pm

The Robman wrote:Was he willing to say what the rest of the data means? If we know how to read this data, we might be able to create a tool that reads it and links up with DecodeIR.dll to give JP1 style decodes.

Rob,

If you follow the link provided previously, you'll see the format for the Tira documented. I looked at it some days ago and it looks remarkably like the JP1 learned format. I think the first few bytes are different though. IIRC instead of frequency, it spec'd the period or some such, but the burst pairs and the nibble index to the burst pairs were identical to the JP1 learned format. It's either a big coincidence or the author is familiar with JP1 learned format.

Here's the link to the Tira2 protocol spec:

http://www.home-electro.com/download/Protocol2.pdf

or is it:

http://www.home-electro.com/download/Protocol1.pdf

A.A.

Post by **The Robman** » Wed Aug 24, 2011 10:38 am

Are you able to follow those PDFs sufficiently enough that you can decode the rest of the data that kkl posted? I tried but the data doesn't appear to match the info in the PDFs.

cauer29 · Post by **cauer29** » Thu Aug 25, 2011 12:07 am

The Robman wrote:Are you able to follow those PDFs sufficiently enough that you can decode the rest of the data that kkl posted? I tried but the data doesn't appear to match the info in the PDFs.

I went back and studied what had been posted so far and the docs. About the only thing I figured out that you hadn't already, is that the 5F in the sequence below is the count of on/off pairs in this signal, following the 4 FFs.

Code: Select all

00 00 00 00 08 00 00 00 35 00 00 00 9D 00 00 00 ED 10 00 00 08 2B 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 34 88 27 05 00 00 00 00 00 00 00 00 02 00 00 00 0C 00 00 00 84 67 00 00 00 00 00 00 5F 00 00 00 FF FF FF FF 00 01 00 01 00 01 01 00 00 01 00 01 00 01 01 00 00 01 00 01 00 01 00 02 00 01 00 01 00 01 01 00 00 01 00 01 00 01 01 00 00 01 00 01 00 01 00 03 00 01 00 01 00 01 01 00 00 01 00 01 00 01 01 00 00 01 00 01 00 01 00 02 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00

The 6784 converted to decimal is 26500 which isn't particularly interesting. The 0C and the 02 before that don't mean anything that I could figure out. There is something about the 08 near the beginning. I would think that it is the count of 32 bit time values that follow, since there is mention of a limitation of 8 unique values somewhere in the docs. Still, there is a lot more data after the 8 32 bit time values before we get to the FFs which are clearly a marker for the end of the block.

On second thought, the 0x05278834 is 86476852 and if we assume that is in units of nanoseconds, it is suspiciously like the leadout time. That seems like more coincidence than anything else as I don't see how anything as wimpy as this Tira is spitting out stuff in ns.

Sorry, that's all I got. If I had more examples or maybe some time to research it from the Event Ghost side, maybe I could figure out more.

A.A.

kkl · Post by **kkl** » Tue Sep 13, 2011 11:22 am

The Robman wrote:Was he willing to say what the rest of the data means? If we know how to read this data, we might be able to create a tool that reads it and links up with DecodeIR.dll to give JP1 style decodes.

Following up on this, I never did receive a reply. However, I did test multiple remotes and the "header" data never changes. Every single button learned starts like this: 00 00 00 00 08 00 00 00