Your Universal Remote Control Center
RemoteCentral.com
Custom Installers' Lounge Forum - View Post
Previous section Next section Previous page Next page Up level
Up level
The following page was printed from RemoteCentral.com:

Login:
Pass:
 
 

Page 2 of 2
Topic:
Pro.Relay.4 and URC MX880
This thread has 23 replies. Displaying posts 16 through 24.
Post 16 made on Monday May 12, 2014 at 12:34
Ernie Gilman
Yes, That Ernie!
Joined:
Posts:
December 2001
30,104
FWIW, Justin at ProControl just created a .cml file for the Pro.Relay.4. Can that be imported into the MX-880?

If you want it, PM your email address to me. I'm sending it later today to Daniel for publishing here. And of course, since I was able to nudge Justin into doing that, are there any other ProControl products for which an RTI file would be helpful? I'd appreciate you writing down any reasons you have for further convincing a manufacturer that an ASCII file is not enough!

I took on making a ccf when I thought there were a dozen commands. Once I saw there were almost a hundred, I tried to see if the manufacturer might do something to help, and they did.

What slowed me more than anything else was the senseless order of the file, where since the time periods are not actually in order of time, but in that pseudo-order you get when you sort things in an ASCII file (that is, you get 100 msec followed by 1 sec instead of followed by 250 msec; etc). If I was going to make a file to be helpful, it would not retain that logic mistake, so it was going to take a lot more time to create the file.

I hope the RTI file will be helpful.
A good answer is easier with a clear question giving the make and model of everything.
"The biggest problem in communication is the illusion that it has taken place." -- G. “Bernie” Shaw
OP | Post 17 made on Monday May 12, 2014 at 13:03
avintegrator
Long Time Member
Joined:
Posts:
March 2003
348
Sorry, I hadn't seen this since the second post. I was going to post the file once I got it to work but spent an hour copying, pasting and and testing and couldn't get the Relay 4 that I had to do anything. Justin @ Pro Control was at a loss as well. Showed it was receiving an IR signal but none of the commands did anything. I tried the output of an MRF350 as well as a table top IR through a connecting block.

Ernie, I still have all the "stuff" on the bench so I could test that file tomorrow maybe.
Post 18 made on Monday May 12, 2014 at 14:54
Ernie Gilman
Yes, That Ernie!
Joined:
Posts:
December 2001
30,104
Aha. After I chided their customer service for not creating a .cml for a product that they would sell more of if they would only support it to work with products made by their sister company, bla bla bla, Justin replied "sorry, we only send out the hex commands." Maybe your phone call to him changed this to "Well… It looks like I had enough time to create one [a .cml file]. So here you go. J"

I just emailed it to you.

I see in the process here that I changed my plan to create a ccf to a request for them to create a .cml. I hope that does it for you!

Ernie
A good answer is easier with a clear question giving the make and model of everything.
"The biggest problem in communication is the illusion that it has taken place." -- G. “Bernie” Shaw
Post 19 made on Tuesday May 13, 2014 at 11:51
Ernie Gilman
Yes, That Ernie!
Joined:
Posts:
December 2001
30,104
I'm working on a ccf now, about 60% done. I'll let you know. I doubt there will be much demand, but at least all the commands will be available to everyone without having to use dealer-only software.
A good answer is easier with a clear question giving the make and model of everything.
"The biggest problem in communication is the illusion that it has taken place." -- G. “Bernie” Shaw
Post 20 made on Tuesday May 13, 2014 at 19:05
Ernie Gilman
Yes, That Ernie!
Joined:
Posts:
December 2001
30,104
Still messing with these commands, I changed them from a .txt to a .doc and in doing so noticed that they are not all the same length.

Wouldn't a perfect set of IR codes for one device all be of the same number of hex words?
A good answer is easier with a clear question giving the make and model of everything.
"The biggest problem in communication is the illusion that it has taken place." -- G. “Bernie” Shaw
Post 21 made on Sunday May 25, 2014 at 23:17
3FG
Select Member
Joined:
Posts:
August 2009
1,861
These IR signals are bi-phase encoded, and all of them parse without error.  Bi-phase encoding, also called Manchester encoding, is used in RC5 and RC6 and other IR protocols found in IP/cable/satellite boxes.

Here's a typical signal expressed as 75 bits:
R1 MOM. CLOSE 10S
111111111100000100000001000001111000011110000000001000000011000000010000000
The engineering concepts behind the signals can be seen if each byte (starting from the rightmost bit) is reversed in bit order.  This sort of reversal is common in IR protocols, e.g.  NEC, Pioneer, Sony, etc.  Showing the above signal with bit reversed values in hexadecimal notation gives:
3FF 1010 3C3C 8080 0101

If we ignore the 3FF, the remaining 4 words have repeated bytes, so we can remove the redundant information:
10 3C 80 01

We don't know the meaning of the initial 10, but perhaps it is a unit number.
Action: 0=Open, 1 = Close, 2 = Toggle, 3 = Mom.  Close, 4 =  Mom. Open, 5 = Mom. Toggle
Duration of momentary action in units of 3.125 mSec.
Relay:  01 = Relay 1, 02 = Relay2, 04 = Relay3, 08 = Relay 4, FF = All Relays

Other durations can presumably be programmed by adding the following to IrpProtocols.ini in IrScrutinizer:


[protocol]
name=Pro-Relay4
irp={40.2k,398}<1,-1|-1,1>(1,1023:11,2056:16,F:4:8,S:4,F:4:8,S:4,F:8,F:8,R:8,R:8,-19.5m)\
{R=2**D} [D:1..8,S:0..15,F:0..4095]
[documentation]
Put Relay number (1-4) in D, Action (0-5) in S, Duration in units of 3.125mSec in F
Actions: 0=Open, 1 = Close, 2 = Toggle, 3 = Mom.  Close, 4 =  Mom. Open, 5 = Mom. Toggle
Post 22 made on Tuesday May 27, 2014 at 01:40
Ernie Gilman
Yes, That Ernie!
Joined:
Posts:
December 2001
30,104
I'd love to understand this stuff.

On May 25, 2014 at 23:17, 3FG said...
These IR signals are bi-phase encoded, and all of them parse without error.  Bi-phase encoding, also called Manchester encoding, is used in RC5 and RC6 and other IR protocols found in IP/cable/satellite boxes.

Here's a typical signal expressed as 75 bits:

Why as 75 bits? Are you saying that the command is a 75 bit digital word?
R1 MOM. CLOSE 10S
111111111100000100000001000001111000011110000000001000000011000000010000000
The engineering concepts behind the signals can be seen if each byte (starting from the rightmost bit) is reversed in bit order.  

Why would one think to do that? Are you saying that if the last eight digits were abcdefgh, that the reversed version would start with hgfedcba? Or that the last bits would remain as the last bits, but be dcbahgfe?

This sort of reversal is common in IR protocols, e.g.  NEC, Pioneer, Sony, etc.

Common doesn't mean always. How does one know when this happens, to know when to look at reversing things?

Showing the above signal with bit reversed values in hexadecimal notation gives:
3FF 1010 3C3C 8080 0101

What are you trying to do in your post when you write span style equals quote fontdashsize etc., which does not show up in the post?

If we ignore the 3FF,

Why do we ignore the 3FF? How do we know we can do that? Doesn't it mean anything? If so, why is it there?

the remaining 4 words have repeated bytes, so

Wait a minute. "so" means that you have come to a conclusion. Does one just ignore repeated bytes? Under what condition?

we can remove the redundant information:
10 3C 80 01

At least I followed that part.

We don't know the meaning of the initial 10, but perhaps it is a unit number.

From what I know, then, that's descriptive but not part of the action. Is that right?

Action: 0=Open, 1 = Close, 2 = Toggle, 3 = Mom.  Close, 4 =  Mom. Open, 5 = Mom. Toggle
Duration of momentary action in units of 3.125 mSec.

I take it the duration is, in hex, 0380 times 3.125 msec. Right?

Relay:  01 = Relay 1, 02 = Relay2, 04 = Relay3, 08 = Relay 4, FF = All Relays

Other durations can presumably be programmed by adding the following to IrpProtocols.ini in IrScrutinizer:

[protocol]
name=Pro-Relay4
irp={40.2k,398}<1,-1|-1,1>(1,1023:11,2056:16,F:4:8,S:4,F:4:8,S:4,F:8,F:8,R:8,R:8,-19.5m)\
{R=2**D} [D:1..8,S:0..15,F:0..4095]
[documentation]
Put Relay number (1-4) in D, Action (0-5) in S, Duration in units of 3.125mSec in F
Actions: 0=Open, 1 = Close, 2 = Toggle, 3 = Mom.  Close, 4 =  Mom. Open, 5 = Mom. Toggle
A good answer is easier with a clear question giving the make and model of everything.
"The biggest problem in communication is the illusion that it has taken place." -- G. “Bernie” Shaw
Post 23 made on Wednesday May 28, 2014 at 01:09
3FG
Select Member
Joined:
Posts:
August 2009
1,861
Yes the signal has 75 bits.  It can also be described as 76 bits, in which the first bit is required to be zero, but I prefer to think of the first on pulse as being a start pulse which provides the timing reference for the subsequent edges.  I've chosen a convention that a negative going edge denotes a zero and a positive going edge denotes a one.

More than half of all IR protocols transmit bits with the least significant bit of the data sent first.  Typically the reversal is done on byte boundaries. RS-232 has worked the same way for the last half century, and it makes reading the data on an oscilloscope difficult.   IR protocols designed in the last several years tend to be msb-- they send the most significant bit first.

All of the signals posted in this thread start 0x3FF1010.  Since they all do this, we can't know anything about their purpose, but I choose to think that the 3FF is a constant behavior of all Pro.Relay signals, but the 1010 carries data.  I infer that because it is 2 bytes with a repeated value, and the other 3 words with repeated bytes clearly contain data which varies with the commanded functions.

So why do I believe that the negative edge is a zero, and that the bits are sent in lsb format?  Partly because it provides simple correlation to relay number and actions, but mostly because it gives a very reasonable interpretation of the duration-- an exact match.  0xC80  (not 0x380; I don't know where you got that) is 3200 decimal and 3.125 mSec times 3200 is  10.000 seconds.  All the other durations derived from the IR signals follow this rule.

Many IR protocols try to check for transmission errors.  NEC, for example, originally sent the complement of the 1st and 3rd bytes in the 2nd and 4th bytes.  Most modern signals use a check sum or XOR computation to detect errors.  Lutron uses an elaborate scheme of parity bits and Gray encoding, which allows them to detect and correct a single bit transmission error.  Here I suppose that ProControl has made an attempt to detect errors by sending the same byte twice.  That's not very efficient, and it won't detect some types of systematic errors, but it still is quite a bit better than nothing.  With the posted Pronto Hex, there is no possibility of a transmission error (a typo is still possible), so I consider the repeated bytes to be redundant information.
 
Post 24 made on Wednesday May 28, 2014 at 02:33
Ernie Gilman
Yes, That Ernie!
Joined:
Posts:
December 2001
30,104
Thanks for the response!

...and after all this, the Original Poster and ProControl can't tell us if all the commands work.

On May 28, 2014 at 01:09, 3FG said...
Yes the signal has 75 bits.  It can also be described as 76 bits, in which the first bit is required to be zero, but I prefer to think of the first on pulse as being a start pulse which provides the timing reference for the subsequent edges.

Okay, I see the number part of this, maybe. I'd go for the consistency of discussing bytes, so 01 and 76 digits. I mean, in the binary world, 01 and 1 ARE the same, so you've got your starting pulse and its width. Hey, what's the state of the signal before that first 0 you're not showing? Is it 1? Is it 0? Is it indeterminate?

I've chosen a convention that a negative going edge denotes a zero and a positive going edge denotes a one.

Perfect and comprehensible.

More than half of all IR protocols transmit bits with the least significant bit of the data sent first.  Typically the reversal is done on byte boundaries. RS-232 has worked the same way for the last half century, and it makes reading the data on an oscilloscope difficult.   IR protocols designed in the last several years tend to be msb-- they send the most significant bit first.

Sigh. This is a new product. Is this a new protocol? When one sees a string of data like this, or a hex string (is this a hex string that's somehow only got 1s and 0s?), how does one know whether it's MSB or LSB first?

All of the signals posted in this thread start 0x3FF1010.  Since they all do this, we can't know anything about their purpose, but I choose to think that the 3FF is a constant behavior of all Pro.Relay signals, but the 1010 carries data.  I infer that because it is 2 bytes with a repeated value, and the other 3 words with repeated bytes clearly contain data which varies with the commanded functions.

Yeah, okay, your experience probably tells you that's reasonable.

So why do I believe that the negative edge is a zero, and that the bits are sent in lsb format?  Partly because it provides simple correlation to relay number and actions, but mostly because it gives a very reasonable interpretation of the duration-- an exact match.  0xC80  (not 0x380; I don't know where you got that)

Typo.

is 3200 decimal and 3.125 mSec times 3200 is  10.000 seconds.  All the other durations derived from the IR signals follow this rule.

Many IR protocols try to check for transmission errors.  NEC, for example, originally sent the complement of the 1st and 3rd bytes in the 2nd and 4th bytes.  Most modern signals use a check sum or XOR computation to detect errors.  Lutron uses an elaborate scheme of parity bits and Gray encoding, which allows them to detect and correct a single bit transmission error.  Here I suppose that ProControl has made an attempt to detect errors by sending the same byte twice.  That's not very efficient, and it won't detect some types of systematic errors, but it still is quite a bit better than nothing.  With the posted Pronto Hex, there is no possibility of a transmission error (a typo is still possible),

tell me about it

so I consider the repeated bytes to be redundant information.
A good answer is easier with a clear question giving the make and model of everything.
"The biggest problem in communication is the illusion that it has taken place." -- G. “Bernie” Shaw
Page 2 of 2


Jump to


Protected Feature Before you can reply to a message...
You must first register for a Remote Central user account - it's fast and free! Or, if you already have an account, please login now.

Please read the following: Unsolicited commercial advertisements are absolutely not permitted on this forum. Other private buy & sell messages should be posted to our Marketplace. For information on how to advertise your service or product click here. Remote Central reserves the right to remove or modify any post that is deemed inappropriate.

Hosting Services by ipHouse