am needing the rs232 codes to work with msc-400 for mitsu ws-65613. can anyone help...

ps..not on mitsu's website.

I posted it over at IP a few weeks ago... if you don't have access over there,

send a request to this guy, he's the one that gave it to me.

[email protected]

Here You Go. This is what we use for one-way serial:

Power On\xDF\x80p\xF8\x02\x00\x006

Power Off\xDF\x80p\xF8\x02\x00\x015

Input 1\xDF\x80p\xF8\x03\x01\x00\x013

Input 2\xDF\x80p\xF8\x03\x01\x00\x022

Input 3\xDF\x80p\xF8\x03\x01\x00\x031

Input 4\xDF\x80p\xF8\x03\x01\x00\x040

Input 5\xDF\x80p\xF8\x03\x01\x00\x05/

Comp 1\xDF\x80p\xF8\x03\x01\x00\x09+

Comp 2\xDF\x80p\xF8\x03\x01\x00\x0A*

Comp 3\xDF\x80p\xF8\x03\x01\x00\x0B)

Comp 4\xDF\x80p\xF8\x03\x01\x00\x0C(

Comp 5\xDF\x80p\xF8\x03\x01\x00\x0D'

DVI \xDF\x80p\xF8\x03\x01\x00#\x11

Input VGA 1\xDF\x80p\xF8\x03\x01\x00 \x14

Input VGA 2\xDF\x80p\xF8\x03\x01\x00!\x13

Input VGA 3\xDF\x80p\xF8\x03\x01\x00"\x12

Input Ant A\xDF\x80p\xF8\x03\x01\x00\x06.

Input Ant B\xDF\x80p\xF8\x03\x01\x00\x07-

Input Ant DTV\xDF\x80p\xF8\x03\x01\x00\x08,

Input Up\xDF\x80p\xF8\x02\x01\x014

Input Down\xDF\x80p\xF8\x02\x01\x023

Input DTV\xDF\x80p\xF8\x02\x01\x023

George P.

george, did you just cut and paste from your msc-400 file?

or do you have this info from something else.

I've been disecting (trying at least) the document that I got from mitsubishi, and it has a few more octets in each line, I'm curious, you have these confirmed??

for example I got:
Power On: DFH80H70HF8H02H00H00H36H

you had: Power On\xDF\x80p\xF8\x02\x00\x006

mostly the same, I'd like to understand the difference... (Alan care to join in)

Brent,

These codes were used on two Crestron jobs we completed this month. The clients already had the Mits TV's so we needed to get them working. We used these codes in Crestron's SystemBuilder and worked great on a 4 year old CRT RPTV and also a more recent DLP RPTV.

I too have that confusing Mitsubishi RS-232 document. There are "check digit" calculations that guys like Alan thrive on that I decided not to spend time on.

The codes I posted were derived buy using a module I downloaded from the Crestron Yahoo group. This module is a traditional SIMPL Windows module. It would take some work to make it SystemBuilder compatible. So instead, we loaded that module on a Pro2 processor and monitored the serial string outputs for the commands in Test manager. Then I took those commands and created a new 1-way SystemBuilder RS-232 module for our projects. Worked like a champ.

We don't do URC but, we also do RTI and I'm sure they will work equally well there. So I think you should have success using anything that can send those strings.

BTW, when I pasted the commands in the forum here, the spaces between the command name and the first hex symbol were deleted. The actual command string starts after the command name. So you should NOT send the words Power On with the string. (you probably know that but I thought I should mention it)

The Mits protocol uses ODD parity. Don't forget to set that up properly.

Good Luck,

George P.

You will have to forgive me. I have a programming schedule that is just rediculous and I'm dealing with a less than impressive crew of sales pukes who believe I ought to walk in a fix everything, including their tech's wiring errors and cold solder joints.

I would need to see the protocol. I cannot tell what this " check digit " is but I assume it's an optional check sum, which in my book is never an option. you add up the values of all of the bytes in the string and this is the check sum.

The first question that comes to mind is why are you sending a value greater than 1 byte in the string (\x006) when this is clearly a low byte value protocol ( this is a 8 bit protocol and clearly the second value or low byte is what is necessary; \x0006 is the correct value but \06 is the only relavant value. )

\x is a short cut that some compilers support that signals to the compiler to take the next to values as 1 byte. It would seem to be that the exrtra value might screw that up, if the compiler saw \x006 as 00 and not 06.

I'd need the protocol to answer this more and you'd have to get it quickly. I am working a rediculous amount of hours and i will not have much time this week for play--isn't this what these chat rooms are?

Alan

Alan,

As part of my quest to become better at what I do, (and more valuable as an employee) I'm trying to learn how this whole serial thing works, and would like to learn how to use the seemingly incomprehensible documentation provided by some manufactures. So I'd like your help pulling apart the methodology.

I posted the full protocol sheet at IP a few weeks ago. I've been trying to disect the checksum thing...it's not just add them up, it's add them up and then take the "1's compliment" which I gather is the FF, minus the sum. What I haven't been able to find is a program that can easily make all the conversions for me. I have an excel sheet, that I can paste the string, then convert to decimal, run the sum, subtract 255, then reconvert to hex...

Am I even close? Is there an easier way?

anyway thanks for the help.

Thanks Brent, for the tip. Didn't mean to start a vigorous discussion but it looks like I did.

I emailed your contact and got the Mitsu' publications for BOTH RS232 and Discrete IR functions. Too bad Mitsu's service can't do the same.

At least this promises to be an educational "vigorous discussion" I'm hoping to learn something.

Not like pissing into the wind in the global warming thread.

I'm on 1 hour's sleep and it's only 11:05 and I've been at it for over 17 hours. If i'm less than clear forgive me.

The check sum is the sum of all bytes in the string. The ones complement would be that value ( low byte ) converted to binary, inverted and then converted back to hex.

Since I do not know your IP hearder I could not tell which of the two Mitsu protocols was posted by you. Here is an example for power on quickly done.

This was posted by ice pick and it is a typical Japanese hex protocol. Notice that for all the nonsense most values are fixed. Thus you have a 8 byte data length composed of
header, unit ID1, Unit ID2, Header 2, Command length and command1 and command 2
DF 80 70 F8 02 00 00

Check sum is the sum of the above or 2C9. Since the protocol tells you to take the low byte we discard the 2 and use C9. Convert C9 into binary or

1100 1001
0011 0110 is the one's compliment or 36h

Alan

and the h at the end of the 36, is just their way of indicating that it's a hex value?? right??

btw hope you get some sleep.

The "h" at the end of "36" is to tell the programmer that "36" is to be expressed in hex.

Also, the \x before a value tells the MSC400 that the value that follows is to be expressed in hex. You use this only if the commands are set in ascii and you need to express some part in hex - if the whole thing is in hex you don't need the "\x" modifier. You do need to check the "hex" box in the software, and our software also requires you to seperate the hex values with a comma - just leaving a blank space won't cut it in the MSC400.

Hope that helps,

Jeff

thanks jeff,

I haven't finished disecting the protocol yet so I haven't started putting the info into the MSC editor yet

that last little bit is going to save me hours.

I have the PDF from Mitsu, but I still can't seem to get it to work with my WS55813.

I am using a straight through RS-232 cable and have tested it with a multi-meter by checking for continuity between pin 2, 3 and 5. For testing sake I am using hyperterminal and I don't see any response from the ws55813 I am trying to control. My RS-232 settings are, 9600,8,odd,1, no flow control.

On my Sharp TV if I test with hyperterminal and just hit enter (or any incorrect input) I get an ERR in response. The Mitsu doesn't respond at all, which makes me think my cabling or port settings are incorrect.

Any idea what I am doing wrong?
Thanks

did you try a cross over cable?