Your Universal Remote Control Center
RemoteCentral.com
URC's Consumer Remotes Forum - View Post
Previous section Next section Up level
Up level
The following page was printed from RemoteCentral.com:

Login:
Pass:
 
 

Topic:
MX700: Long commands (or bursts in macros)?
This thread has 6 replies. Displaying all posts.
Post 1 made on June 10, 2003 at 13:49
T
Tige
Lurking Member
Joined:
Posts:
June 2003
5
Hi everyone,

It seems that I have sort of a problem with my newly bought MX-700. I have an amplifier made by Philips in my system. So far, I have not found codes for turning the amplifier on or off. (Finding such codes would be the easiest way to solve my problem.)

Turning the amplifier power on is not actually a big problem, because I can command for example the tuner of mine (made by Philips, too) that is connected to the amplifier by a separate command cable and as a side-effect the amplifier is turned on as well.

However, if thinking about the original Philips remote, it seems that for turning the amplifier power off I should press for example the tuner-off button for one second or so (pressing it once will turn off the tuner but not the amplifier). Now, if I would like to emulate the original remote I could indeed create
a similar button to be pressed for one second, but the problem is that I want to have a macro that will turn off the power of all my devives at once.

Making a macro with multiple tuner-off-commands does not work, because apparently the macro execution fires the commands too slowly and the amplifier does not see a burst of commands, so it does not turn itself off.

So, apparently I would need a possibility to
- shorten the time between the commands in macros, or
- somehow edit the MX700 data files so that there
would be one single command that outputs an IR
pattern that actually consists of several
tuner-off IR patterns, or
- find a discrete code that immediately turns off the
amplifier

Any help?


This message was edited by Tige on 06/14/03 21:23.
OP | Post 2 made on June 14, 2003 at 20:04
T
Tige
Lurking Member
Joined:
Posts:
June 2003
5
Problem solved!

Fortunately MX-700 has reserved quite a lot of memory for each learned command, so with the help of hex editor, I was able to define my own "burst commands". (I simply copied the learned IR-sequence about 8 times one after another, and the resulting burst now lasts about one second and that helps me out from this problem.)

Actually, I also noticed an interesting issue. If the command now takes about 1 second when pressing its button directly, the command takes almost 4 seconds when executed from a macro. It seems that MX-700 will rapidly fire the macro commands several times to be sure that none of the steps of the macro are missed. I have seen some people complaining here why the macro execution takes so long time. Perhaps here is one reason for that.

This message was edited by Tige on 06/14/03 21:10.
OP | Post 3 made on June 14, 2003 at 20:19
T
Tige
Lurking Member
Joined:
Posts:
June 2003
5
(Seems that I'm making a message thread of my own :-)

If you ever have wondered why MX-700 will send some learned commands repeatedly when their button is pressed whereas some commands are sent only once, here is something to be looked at. In MXD file, the learned commands appear like this:

00000000000014007000040000006A00
0000000000000300A60CE10041002100
59332223333223323323313322233332
23323323313322233332233233233133
22233332233233233133222333322332
33233133222333322332332331332223
33322332332331332223333223323323
3133222333322332332331FFFFFFFFFF

The command above is a normal repetitive command. However, if the number below the "1" of the top line would be "4", we would have a single-shot command. In such a case, the MX-700 does not allow the command to repeat itself. Like this:

00000000000014007000040000006A00
0000000000004300A60CE10041002100
59332223333223323323313322233332
23323323313322233332233233233133
22233332233233233133222333322332
33233133222333322332332331332223
33322332332331332223333223323323
3133222333322332332331FFFFFFFFFF

Post 4 made on June 15, 2003 at 06:46
D
Don Black
Lurking Member
Joined:
Posts:
April 2003
7
Tige: It's very cool that you found a solution to this common problem but I still can't see how you made it work. I tried opening up the MXD files in a hex editor but I couldn't for the life of me distinguish what went where. Any chance I could e-mail you my file and have you copy and paste an IR command over and over again so I can finally turn off my TV? =) Thanks!
OP | Post 5 made on June 15, 2003 at 14:57
T
Tige
Lurking Member
Joined:
Posts:
June 2003
5
Have you already seen this message about editing MXD files:

[Link: avsforum.com]

When I started looking at MXD files more closely, I also found out it very difficult at first. So I saved my MXF system under a different name and removed all but couple of learnt commands from the device I was going to edit with a hex editor. Now, when saving the device file after this, learning some other command on top of already-learnt code and saving another device file of the same device for comparison made it a lot easier to spot the place to be edited.

All the learnt codes are in one section of the device file. Database codes are stored differently, so they can probably be ignored now. The order of learnt commands is something that probably does not come into one's mind at first, so that is why it helps to remove the other, currently uninteresting, learnt commands first. (There are no "empty" learnt commands in the MXD file, so the place where your command-to-be-changed lies depends on the amount of other commands you have taught to the remote.) When you know what kind of code you are going to change, then you can revert back to your original device setup and do the change.

See my example above about the learnt command. The IR sequence begins on the 3rd line. The first byte is the amount of actual IR command bytes to follow MINUS 1. Unused bytes are FF's. There are zeros in MXD file after FF's, so if you cannot fit your repeated code into the place of FF's, this does not help (after all, there are some limits what MX-700 can memorise and what not).

However, remember, that if long enough command does not fit there, use a macro to fire off the command. At least if your command is repetitive (see my note about this in previous messages), the command is being sent more times in macros as in normal press.

As you can see, in my example the code "33222333322332332331" is repeated 8 times. I haven't figured out the precise rules how these 3's and 2's and 1's should be understood, as some codes of the same original remote (that I used in learning) seem to be based on 1's and 2's only in which cases the numbers above the IR sequence (on second row) are somewhat different. So in your case the IR sequence looks probably different as well, but the principle should be the same.

And oh, on the first line of my example the lonely "4" is the ordinal number of the learnt command. The previous learnt command has ordinal number "3" and the next one has "5". However, when new commands are learnt or old ones removed, these numbers can change because the commands are sorted so that for example a command (if exists) for top-right LCD key always comes before a command of down-right or top-left LCD key (if that key has a learnt command).


This message was edited by Tige on 06/16/03 01:54.
Post 6 made on August 13, 2003 at 22:58
A
Adolfo Velasco
Lurking Member
Joined:
Posts:
August 2003
3
Using the IR discussion found in www.irclone.com for the MX500, I think I found out how the MX700/800 stores the learned data in the MXF file. Using the previous message as an example.
"6A" looks like the amount of memory allocated. 6A=106 in decimal and if you start at "03" until the last "FF" I believe thats 106 bytes.


Post 7 made on August 13, 2003 at 23:22
A
Adolfo Velasco
Lurking Member
Joined:
Posts:
August 2003
3
Using the IR discussion found in www.irclone.com for the MX500 as reference, I think I found out how the MX700/800 stores the learned data in the MXF file. Using the previous message as an example.
<6A>=number bytes allocated=106 bytes. Counting from byte1 to last FF=106 I think.
<00,00,00,00,00,00,00>=empty space?
<03>=byte1. First nibble can either be 0 or 4.0 for repeat when button held down or 4 for single burst. The 2nd nibble defines # of timing words explained later.
<00A6>=carrier period. There's a formula for this in the IR discussion file on www.irclone.com
<0CE1>=timing word 1. This multiplied by the carrier period gives the timing period 1. Everytime you see a "1" in the IR sequence it uses this period for high/low.
<0041>=timing word 2. Everytime you see a "2" in the IR sequence it uses this period for high/low.
<0021>=timing word 3. Same as above.
<00>=Decimal value+1=start of repeated bytes. In this case <00> means sequence from 1st byte to last byte in the IR sequence is repeated.
<59>=# of bytes in IR sequence.
<33222...>=Actual IR sequence w/each digit refering to corresponding timing word.
I'm paraphrasing some of this from the IR discussion file and I added some of my own teminology and notes. Has anyone figured out how the buttons are assigned the learned data and where they are labeled? I'm hoping to discover the entire mxf file structure to do some more editting. I'm assuming its similar to the MX500. Thanks and I hope this helps.

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.