MLGenericSerial plugin v2.0

[alexzogh]

Just a quick update.

In reading the PDF file again, I decided to try something in "send" line to test - I added a #13 at the end of my command, and it worked!

The catch is adding a #13 to the end of each mapped command doesn't. It also doesn't seem to work every time.

At this point, since the piece of equipment provides no feedback (Stewart ultimate 4 way masking screen), I will revert to the MLRS232Send plugin which works until this gets sorted out.

[K-Wood]

Here's what I understand so far:

The Power on command, in hex, is 83 45 01. To calculate the checksum, you convert each value to its decimal equivalent and add them up, and then express the sum in hex.

This gives you 131+69+1 = 201. 201 in hex is C9.

So the command is written 834501C9.

For standby, it would 83 45 02 with a checksum of CA (202 in hex).

For "Tuner" input select, it would 83 45 03 CB.

In your final example 83 45 FF, the checksum would be 1C7, which is 455 in hex.

I don't really understand how the hex to decimal conversion is done, or how the least significant byte is dropped, but with the help of an online hex to decimal converter, I was able to calculate the checksums.

Have it done it correctly?

Thanks,
Ken

[jpimentel]

Bascially the hard way. You have to convert the acsii symbols to hex and put them in a string. An ascii conversion chart comes in handy for this task. See http://www.lookuptables.com/

For example, if you want to send "PowerOn + CR" to a device in hex you would send the following:

506F7765724F6E0D

Where...

Uppercase P = 50
Lowercase o = 6F
lowercase w = 77
lowercase e = 65
lowercase r = 72
Uppercase O = 4F
lowercase n = 6E
Carriage Return = 0D

Note that values less than 0x10 should be prefixed with a 0 (zero) since all ascii characters are represented in 1 byte (aka 8 bits or 2 hex digits). This would only be special characters since the first normal printable character is the space character which is hex 20.

Not very intuitive but you can actually memorize the table after using it for a while.

Have Fun...

[K-Wood]

I've just finished writing all of the commands in hex and trying them out, and low and behold, they all work. I found this helpful website for the hex to decimal conversion:

http://www.ronshardwebapps.com/Numbers.asp#marker

Using it, I was able to calculate the checksums for each of my hex strings.

For those interested, I've attached my Outlaw 990 file from the plugin.

The next step is to figure out how to parse the incoming data and set variables in MLServer based on it. No small task!

Any thoughts on how to do that based upon the Outlaw documentation?

Thanks again for the help, John.

- Ken

P.S. -- The thought of memorizing the hex table is really quite scary!

[jpimentel]

The status protocol of the 990 seems a bit dauting to me and almost seems out of reach with the current generic serial plugin. It appears after looking through the docs that you would need to do a binary compare since the has bit wise values for status words. The current wild card mechanism does not handle this very well (at least I can't figure out how to make it work).

What makes this protocol challenging is the fact that the data and status bits themselves are variable in length and can only be determined as the data comes in. You would have to go through several levels of filtering to sort things out. Perhaps you could dump the whole status word to a variable and use MLMath to parse it. I think there are now binary operators in that plugin???

I think the plugin author might have to pipe in here. I am a bit over my head on this one.

Sorry I couldn't be more help.

[K-Wood]

Regarding the incoming data, would it be possible to use the COUNT field to determine how many TEXT and STATUS fields there are?

Assuming that the data is coming back in hex, the first two hex values will always be the system ID (83 45). The next hex value is the Count, which, when translated into ascii, should give the number of bytes in the DATA field. I assume the number would be no more than 22 (13 TEXT fields and 9 STATUS fields).

The DATA field consists of two parts, TEXT values and STATUS values. The TEXT values correspond to what is being displayed on the unit's LCD screen. I suspect, but am not sure, that we could simply translate the hex values into ascii and it would give us the letters appearing on the LCD screen.

As for the DATA fields, I suspect the hex values for each STATUS field would correspond to the hex values for each command, but I'm not sure. For example, if mute is on, then STATUS3, Bit 7 would have a hex value of 11.

One difficulty we'll face is matching up the hex values to the appropriate TEXT and STATUS fields. In other words, how do we tell whether a given hex value is part of STATUS1 or STATUS4? I suspect the answer will lie in the COUNT, but we'll need some sort of way to apply programming logic to the incoming data.

Another thing that would be helpful would be a programming tool to convert hex to ascii on the fly. Perhaps MLMath will do this? Or can the GenericSerial plugin handle it?

Last though -- could the forthcoming DBDatabase plugin -- which uses SQL tools -- somehow be used to parse the incoming data?

This make any sense?

Thanks,
Ken

[alexzogh]

John,

Thanks for the reply.

Converting all of my ascii commands to hex just to add a CR is just too painfu for me to contemplate.

Funny how the old one way plugin allows you to add a CR without a LF as a standard parameter.


These plugin's are getting more and more powerful. I just wish there was a bit more standardization on functionality and how parameters were used.

For example: this plugin has command followed by device to receive command, while the GC100 has device followed by command - both can send and receive serial commands which can really add complexity.

Some use Boolean logic, some use RPN, it's fun for someone like me that's a computer historian (I can tell you what computer behaves most like a particular plugin), but will ensure that mainlobby as a product will never really break into the professional market.


May be time for Cinemar to lay down the law for a more standard plugin command line and logic plugins.


Meanwhile, I'm still hoping for an updated genericserial plugin that doesn't have the directories of the xml files hard coded.......

[K-Wood]

I agree with Alex about plugin standardization. For example, it would be nice to have a standard method of writing command maps that applied across all plugins. For example, AFAIK, command maps written in the GenericSerial plugin can only be called by MLServer with the MLServeCmd.MLGenericSerial|SendMap command, as opposed to just directly calling the mapped command. (If I'm wrong about that, let me know!)

Standardizing logic would be great as well. I'm not a programmer, so I don't have an opinion on the best logic to apply, but perhaps SQL is a viable choice?

- Ken

[K-Wood]

On the other topic of how to interpret the data being returned by the Outlaw 990 processer, I've made some progress in understanding what is coming back. But I'm at a lost as to how to get the plugin to work with it.

Here's what I know about the return data.

I've attached a screen captures from the GenericSerial plugin. All of the data is in hex.

In screen capture, the source selected in Aux, the input is analog stereo, and (I think) the surround mode is Upsample. Sending a command seems to produce two response strings. They appear in reverse order in the screen capture. For example, in the volume down example, the first response string has Last Char = 65 and the second string has Last Char = 54.

Each response string has 5 parts:
1. System ID
2. Data count
3. Text fields (13)
4. Status fields (up to 11)
5. Checksum

Just looking at one of the strings, it appears that converting each hex value to ascii gives you the TEXT portion of the feedback and is equivalent to what is shown on the unit's LCD display. In the string that ends with Last Char = 54, the translation is:

83 = System ID
45 = System ID
18 = No translation; decimal value of 24 (perhaps means 24 bytes in data field? Makes sense - 13 text values and 11 status values)

20 = space These next 13 values are the TEXT field.
20 = space
41 = A
55 = U
58 = X
20 = space
20 = space
20 = space
20 = space
20 = space
20 = space
20 = space
20 = space

81 = no translation Here is where I get lost!
85 = ...
70 = p
2A = *
32 = 2
3D = equal sign
00
00
18 = no translation
29 = )
38 = 8

B6 = paragraph symbol; also 182 in decimal. (This must be the checksum).

My main difficulty is in translating the status fields. In particular, the volume would be nice to have! Current main volume is set forth in the STATUS4 field. Assuming that the fourth hex value is the STATUS4 field, then the hex value is 2A, which is 42 in decimal. The protocol document says that 0 = -76dB, and 1 = -75dB, so I guess that 42 = -34dB. Unfortunately, I can't check that here at work. But it seems logical.

Another puzzling thing is why does it send two (or more, sometimes) feedback strings?

I suspect that if we could parse out the TEXT field, and write it to a variable in ascii, we could get MainLobby to display exactly what is being displayed on the Outlaw's LCD screen.

But it would be even better to actually poll the device for status and volume levels. Perhaps, if the volume information is always in the same place in the string, could we use a variable character to parse out the STATUS4 field? How would that be done?

Any thoughts?

Thanks,

- Ken

[Granville]

Last Char = 54, the translation is:

83 = System ID
45 = System ID
18 = No translation; decimal value of 24 (perhaps means 24 bytes in data field? Makes sense - 13 text values and 11 status values)

Right!

20 = space These next 13 values are the TEXT field.
20 = space
41 = A
55 = U
58 = X
20 = space
20 = space
20 = space
20 = space
20 = space
20 = space
20 = space
20 = space

81 = no translation Here is where I get lost!

8 1 hex =
1000 0001 Binary

Since this is status 1, looking at your protocol doc, it means tone defeat and power are on.



85 = ...

Since this is status 2, it means Main video input is Video2, and audio is Aux.

70 = p

zone2 is set to video1/FM

2A = *

volume as you figured 2A = 42 - 76 = ...


32 = 50 decimal -76 = volume level

zone 2 voume, but not = 2, you have to calculate as you did for volume.

3D = equal sign

hmm, this one is suppose to be digital input, but it shouldn't be 3d, d isn't an option. 3 = Optical 1, but d doesn't compute!
00
Status 7 - DH 0ff

00
Status 8 - Stero(DownMix)

18 = no translation
Status 9
No Back Ch Surrount speakers
Yes to subwoofer
Small Front Center Left speakers

29 = )
Status 10 -
2 9 hex
001 0 1 001 binary

80hz Front crossover
reserved
Wide DVS mode
80Hz Center Crossover

38 = 8
Status 11
3 8 hex =
001 1 1 000 binary =

001 = 1 = 80 hz Surr Crossover
11 = 3 = 5 speaker
000 = 0 = 100 hz surr back crossover freq


B6 = paragraph symbol; also 182 in decimal. (This must be the checksum).

Right


My main difficulty is in translating the status fields. In particular, the volume would be nice to have! Current main volume is set forth in the STATUS4 field. Assuming that the fourth hex value is the STATUS4 field, then the hex value is 2A, which is 42 in decimal. The protocol document says that 0 = -76dB, and 1 = -75dB, so I guess that 42 = -34dB. Unfortunately, I can't check that here at work. But it seems logical.

I doubt your going to parse out the volume without writing a plugin for this device specificly. I've only been using genericserial for 2 days, but I haven't seen anything on how to extract something from an offset, which is what you need. You need to look at a specific byte.


Another puzzling thing is why does it send two (or more, sometimes) feedback strings?

Since the text is different for the 2 messages, I assume it's mirroring what's displayed on the unit:

AUX
VOLUME -34dB


Maybe you should set your trigger on VOLUME -*
And your terminator to 64, the d then you would
end up with 34 to set your variable with. ( that's 2 spaces between VOLUME and the -*.

Good Luck!


I just started yesterday, and I've been able to use GenericSerial to get all the info I've wanted from my denon receiver and I've got all the 2-way stuff working great. ( this is cool stuff! )

--
Granville Barker

[K-Wood]

Granville:

That is immensely helpful. I hadn't thought to translate the STATUS fields into binary -- but that makes sense now.

I like the idea of setting up a wildcard to return the volume data. But why do you suggest using 64 as a terminating character? Does that mean that it looks for data only up until the 64th bit?

You have to take baby steps with me . . .

Thanks,
Ken

[Granville]

I like the idea of setting up a wildcard to return the volume data. But why do you suggest using 64 as a terminating character? Does that mean that it looks for data only up until the 64th bit?

Not from my understanding, this would tell it to Look for the data after "Volume -" and grab data until it gets to a character 0x64 "d" from the "dB" in the text field after the volume value. Put a command in like:

MLServeCmd.SetVariable|outlawvolume~<<*1>>

specify the terminator, and might work!

[K-Wood]

Excellent -- I'll give it a try tonight. If it works, then I can use the same concept to define a variable that gives me the hex values for each of the TEXT fields (which provide the info that shows up on the unit's LCD display). But, assuming that it correctly populates the variable with the data, how do I translate the hex values into ascii? Is there a MLMath function that can do it? Or other MLServer plugin function?
Thanks,
Ken

[bhiga]

The latest version of MLMath has Hex conversion functions.

[geislerk]

Alex,

I got my VSX-52TX working by converting the commands to HEX, and adding a CR (0D) to the end of each command.

Actullay, by entering the commands in ASCII, then going back and checking Device Communicates in HEX, the program converted all of my ASCII commands in to hex and I just have to add the CR.

Attached is my export for the VSX-52TX.