JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

METechs Drapery Control
Goto page Previous  1, 2, 3, 4, 5, 6, 7
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Protocol Decodes
View previous topic :: View next topic  
Author Message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21211
Location: Chicago, IL

                    
PostPosted: Mon Aug 22, 2011 1:49 pm    Post subject: Reply with quote

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.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!


Last edited by The Robman on Wed Aug 24, 2011 10:07 am; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website
kkl



Joined: 10 Aug 2011
Posts: 65

                    
PostPosted: Tue Aug 23, 2011 4:57 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
kkl



Joined: 10 Aug 2011
Posts: 65

                    
PostPosted: Tue Aug 23, 2011 5:04 pm    Post subject: Reply with quote

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:

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?
Back to top
View user's profile Send private message
kkl



Joined: 10 Aug 2011
Posts: 65

                    
PostPosted: Tue Aug 23, 2011 7:19 pm    Post subject: Reply with quote

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:
Quote:

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.
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21211
Location: Chicago, IL

                    
PostPosted: Tue Aug 23, 2011 8:45 pm    Post subject: Reply with quote

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
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21211
Location: Chicago, IL

                    
PostPosted: Tue Aug 23, 2011 8:49 pm    Post subject: Reply with quote

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".
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
cauer29



Joined: 03 Feb 2010
Posts: 236

                    
PostPosted: Tue Aug 23, 2011 9:47 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21211
Location: Chicago, IL

                    
PostPosted: Wed Aug 24, 2011 11:38 am    Post subject: Reply with quote

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.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
cauer29



Joined: 03 Feb 2010
Posts: 236

                    
PostPosted: Thu Aug 25, 2011 1:07 am    Post subject: Reply with quote

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:
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.
Back to top
View user's profile Send private message
kkl



Joined: 10 Aug 2011
Posts: 65

                    
PostPosted: Tue Sep 13, 2011 12:22 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - Protocol Decodes All times are GMT - 5 Hours
Goto page Previous  1, 2, 3, 4, 5, 6, 7
Page 7 of 7

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

Powered by phpBB © 2001, 2005 phpBB Group
Top 7 Advantages of Playing Online Slots The Evolution of Remote Control