Here's the deal...

Going to have 6 H20/HR20s connected to MSC-400, controlled via RS232. In my testing of a H20 via laptop using a hex terminal program, I see that the following Open User Channel commands work to change to channel 282:

FA,A6,01,1A,FF,FF OR $FA$A6$01$1A$FF$FF OR \xFA\xA6\x01\x1A\xFF\xFF

All is fine and good right....and for ease of typing all of it in, I wanted to go with the hex format inputting of "FA,A6,01,1A,FF,FF" on the msc-400 editor. However.....

In the msc-400 rs232 area, when I type in the function data "FA,A6,01,1A,FF,FF", it translates that to "FA,A6,1,1A,FF,FF" (removing the leading zero of the "01") when I click SAVE. The problem is that when I test that string (FA,A6,1,1A,FF,FF) using my hex terminal program, the H20 doesn't like not having that leading zero.

Another issue.....EPSN HD (channel 73) (FA,A6,00,49,FF,FF). Again the MSC400 would translate that to FA,A6,0,49,FF,FF and again the H20 doesn't like that string without the leading zero. So...I thought, ok, PITA but I'll convert it all to ascii. Convert that to ascii and it's "\xFA\xA6\x00I\xFF\xFF". Problem is that the H20 doesn't like the "\x00I".

What am I doing wrong or is this a limitation?

I would appreciate any and all input on this as I am stumped.

Thanks, Roger

Hi Roger I just sent you an email

cheers

Hey Pete, got it and thnx. I appreciate your help. Here's the deal though....your file looks just like mine. My concern or question is this.....

FA, A5, 0, 1, B2 for Play in the msc-400 editor for example. That's how mine looks as well. Here's my concern....when I take the same data "FA, A5, 0, 1, B2" and issue that against the HR20 via a laptop running a hex terminal program for testing, it doesn't like the command. But when I modify the string and put the zeros back in (FA, A5, 00, 01, B2) it likes it and works just fine. So I guess my question may be this......is this just how the msc-400 editor is presenting it to us in the editor, but when it actually transmits to the device it is including the leading zeros?

Make sense?

Sorry I can't help you Roger - I'm not very knowledgeable on RS232.

Peter

That's ok, I appreciate it. I may be making this out to be more than it is....

Thanks again....

Sincerely, Roger

Well, you are probably going to have issues with this. To control the HR20 properly you really need something that is not just one way. Actually, you need to be able to program a protocol to make it work properly. I'll try to explain.

The hex codes are each one byte (one command, or 8 bits sent across the serial bus to the HR20). Thus to send "Play" you need to send 0xFA (first byte), then 0xA5 (second byte), then 0x00 (third byte), then 0x01 (fourth byte) and finally 0xB2 (fifth and last byte).

The problem is between the second and third byte. You are supposed to wait for the HR20 to respond with a 0xF0 before you continue. The time it takes to respond is not the same every time (it depends on what else it is doing at the time). I tried sending that command to my HR20 and it ignored it (since I did not wait between the second and third byte). It did however respond fine to single commands (like standby). This is why it is better to send complete commands rather than button presses to DirecTV boxes (fewer chances for it to be busy). You might be able to get around it by inserting a delay where the HR20 is supposed to respond. However, since the delay can not be predicted, you will sometimes find the commands do not work (the delay can not be too short, or too long).

I wish with all my heart that URC would update the MSC-400 to allow for at least some simple scripted responses since this would eliminate this problem (something as simple as a "wait up to xx milliseconds for a 0x??" would sort of work). Unfortunatly for now you will have to try and kludge something together.

This is only a guess from me as I have not ordered my serial cables for my MSC-400 yet, and thus it will be a while before I can really test out my thoery. However, since it accepted commands from my PC fine (I have a hex terminal program) except for the ones requiring delays, I think this is the problem. The reason adding another 0 probably helps is it gives the HR20 time to respond before the "real" 0 is sent (it probably ignores the extra "0").

Just my opinion...

Thnx for the input Joe. I understand what you are saying and I see the various responses from the receiver when testing via a laptop and hex comm program. So far in my testing, all commands work without waiting for the receivers responses.....as long as that leading zero is in there. I'm going to do some testing with the actual msc400 today and I'll let you know what I find.

Good luck, and let us know what you find out...

Joe et all,

Ok here's the deal.....and others probably already know this, but I'll share for the masses.

Say you enter "FA, A6, 01, 0D, FF, FF" into the format data window for "open user channel 269" for The History Channel. When you save it, the msc-400 editor translates that to "FA, A6, 1, D, FF, FF" automatically. Which will not work if you actually transmit that to the H20/HR20 (I tested this via a laptop and a hex terminal program). However, it seems as though the msc-400 editor is only doing that for presentation purposes because it does work. So in reality it must be transmitting "FA, A6, 01, 0D, FF, FF" while presenting "FA, A6, 1, D, FF, FF" to the programmer. So all of that worrying for nothing....but at least I didn't have to redo all of the keys and then remap all of the macros.

Another thing I tested was breaking out the "FA, A6" Open User Channel command separately from the major and minor numbers. As opposed to having the entire string all together in one macro step. For example:

Broken Out:

Open User Chnl Macro (#1) - FA,A6
History Chnl Macro (#2) - 01,0D,FF,FF (269 major chnl, no minor chnl)

You would then assign macro #1 to button X, then macro #2 as step 2 to same button.

All together:

Combined Macro - FA,A6,01,0D,FF,FF (open user chnl, 269 major, no minor)

Assign macro to button X.

Both worked fine, no problems. Luckily the combined string is not overwhelming the H20/HR20 by not waiting for the F0 Command Ack response from the STB. From a programming perspective, you might as well combine the two and save some steps when mapping buttons because you still have to create a func and then a macro for each chnl you want to access via the open user channel command.

Hope this is helpful to others....

And thanks again to those who helped...

Sincerely, Roger