Help for serial comm novice

[Ricks]

As a true novice to serial communications I would sincerely appreciate any help.

I am trying to communicate with a piece of Xantech audio gear which communicates via ascii as follows:

Command for Volume increment is !2VI+ where all commands begin with ! and end with +. The number 2 is the zone and VI represents Volume Increment. Pretty easy!

The only way I get it to work is to convert it to hex as
hs.Send To Comport(4), chr(&H21) & chr(&H32) & chr(&H56) & chr(&H49) & chr(&H2B)

Is there a way to send it as "!2VI+"?

If not, how would I send a value higher than 9 in the example where I want to set volume to a specific value such as the command to set volume to 14: in ascii its "!2VO14+" Since it won't take an additional chr(&Hxx), how would I write 14 in one character: chr(&H??)?

Thanks in advance for anyone with the patience to help a true neophyte.

Rick

[Michael McSharry]

I suspect that the "VI" in !2VI+ is a single character that represents a binary level. If you wanted to set zone 2 to increase volume by 5 increments then you would use

"!2" & chr(5) & "+"

It could also be where the increment allowed was only between 1 and 9 per command and the VI is an ascii rather than binary value. In that case it would be

"!25+"

There should be no difference between chr(&H21) or "!" in your send string. They resolve to the same thing.

[GregKing]

You seem to be saying two things differently in your post.

On the one hand, you say the command is supposed to be: "!2VI+", but you don't say that it is to include an increment level. More importantly, if it is to be there, then does the protocol spec say it is to be an ASCII string representing the amount, or a BINARY value?

In your example, I don't see you sending the "9" value, so I'm not sure how you think this is being sent. Therefore, I don't see how to send "14" either. This sounds like the increment command is just a SINGLE increment that must be repeated.

As you say, if ASCII, then either the increment amount can't be more than 9 or it must take 2 characters. You say you can't fit "14" into one position. This is correct if you are to send it the ASCII value as you do in your first example.

So...either your interpretation of the protocol is incorrect or it needs the two characters as you say. You noted that it won't "take" the additional character. Did it not work correctly? Did it reject it?

I suspect you should either send it a BINARY value for the VI, i.e. chr(&H1) through chr(&H99), assuming there are up to 99 levels of volume increment or it should allow for the two ASCII chars.

Also, you don't say what the chr(4) is for. If this is really the VI command, then I suspect the "VI" is the single byte for the volume.

gk

[jay]

Ricks - which Xantech gear is it?

[Ricks]

Hi guys,

Thanks for the help.

According to the document there are two ways to adjust volume: by increments of 1 or by setting the volume level (0-38).

The document says that !2VI+ will increment the volume of zone 2 by 1 unit. It doesn't give other incremental value options so the string !2VI+ increments by 1, ie. VI means increment by 1. In the same manner !2VD+ decrements by 1.

The document also says that !2VO14+ will "set" the volume level of zone 2 to 14.

If I could send the command as:

hs.SendToComPort 4, !2VO14+ then I would be all set.

Could it be a simple matter of my syntax being wrong?

Like I mentioned, if I send it in the format of chr(&Hxx) it will work for !2VI+ but not for !2VO14+ due to that extra character.

This is a Xantech MRAudio8X8 which is the same as the MRC88.

Thanks,

[Ricks]

Thanks everyone. From the clues above I was able to identify my mistakes.

Thanks!

[karls]

Thanks everyone. From the clues above I was able to identify my mistakes.

Thanks!

Ricks,

Could you please elaborate on how you fixed it. The reason I ask is two fold.
a) it may help someone else out later down the road.
b) it may help you out as it is documented somewhere other than that piece of paper that is always in a safe place......darn....so safe I forgot where I put it safe.

and of course I am interested to know as well.

Regards,

Steven

[Ricks]

Hi Steven,

It was simply a case of syntax. Sending the inquiry to the Xantech as ?2VO+ just needed quotes "?2VO+" to make it work. Stupid user error! Since my only previous experience was scripting a Russound ST2 which uses hex, I defaulted to sending hex to see if the Xantech would work. A little knowledge is a dangerous thing. Hex worked fine except when I came across the additonal character for values greater than a single digit.

Had I had a little more experience I would have recognized the error immediately. Now to convert these scripts to plugins!!!! Ya, right. Sure wish there was a tutorial for that.

Rick

[kevind]

Rick

This is great! There are a few of us waiting on an MRC88 plugin. Basshook is writing a script for HS V2.x+ but gather this could be a while, I'm starting to experiment controlling via PERL to be used with HS ver 1.7x and in theory 2.x (as long as comports protocols have not changed) .

Which HS version are you using? Plugin?....fantastic. Will you consider sharing when finished?

[Ricks]

Hi Kevin,

As a novice I am in no position to do anything other than running the Xantech via scripts.

What I may do is get it operational via scripting and then farm it out to someone to build an appropriate plugin for it. Certainly not the "HA'ers" way of doing things but I just don't have the skills to make a solid plugin and there seems to be so few Xantech MRCxxx users that its unlikely anyone will in the near future. I like the MRC that much that it would be worth it for me.

If/when I get there I will gladly make it available to anyone.

Rick

[kevind]

I'm quite versed in PERL so am progressing but am perplexed by something.

HS opens the com port on startup...no problem

 sub Power($data){
 ($data)=@_;
 
 	$hs->SendToComPort ($ComPort,"$data"); 
 	$hs->waitsecs("1");
 	$hs->SendToComPort ($ComPort,"?1PR+");  
    }

This works as subroutine called from a script and then the main "callback" script (assigned on OpenComPort) sub-routine is executed...I am assuming this at this point.


Notice the hs.waitsec command between the to calls. If hs.waitsecs(1) then both serial commands are sent and status returned correctly.

If I take out the "hs.waitsecs" the script fails. The latter I don't understand other than the MRC88 has to wait 1 second between each serial command received or something. Weird

The first call is to send a command and the second call is to send a command for the status of the amp to get a true "status" to apply to a virtual device. IE First send On/Off Second get status of Amp On/Off.

I am wondering if there is a way to send both commands at once...one after another without having to use hs.waitsecs