Anyone written an RS-232 driver for the Pioneer Elite PRO-150FD? I wrote one for CQC and the TV has an annoying habit of displaying the OSD everytime a RS-232 status query is sent. I could understand perhaps on changing something (like volume or input) but when I query the set to get current status (due to IR remote change, want to keep it synched), it displays the OSD. The protocol says this is not supposed to happen (In typical Japanenglish - 1. The GUI is not displayed about the operation when using RS232C.) The user I wrote the driver for has so far had no luck with Pioneer tech support. There is an OSD turn off command in the protocol that I suppose I could use before every query, but that's three commands instead of one each time I get status of the set (which I do every few seconds, round robin). If I permanently turned it off, then I think it disappears even for remote useage.

Any experience?

What command are you using to query the set?

I've never seen anything in print that would suggest that you can poll a consumer grade Pioneer for status.

Each of the commands that change an Input, Volume, Mute, etc. are also queriable by leaving off the action. So, for example, the command to change volume:

**VOL050 replies with VOL050, but the command
**VOL also replies with VOL050 to give you the current setting. I'm using the following commands:

VOL // query the volume
INP // query the input
AVS // query the picture mode
SZM // query the Aspect
AMT // query the Mute

Oddly enough, the protocol doesn't include a Power status, but it is easily maneuvered around because if you issue a VOL query, the set responds with VOLXXX when the set is turned off. A psuedo power query, so to speak.

Here's the protocol: [Link: pioneerelectronics.com]

As an update, the user was able to contact someone in Pioneer Long Beach who replicated the issue in their lab. We'll see if there is any resolution.

LOL...I'm not quite sure how I've managed to misread those protocol docs for so long? Guess I'm too used to the commercial sets that detail the query commands/responses separately? Regardless, that's one demerit for me...many thanks for the heads up!

I do know that the command \x02**QPW\x03 will give you some info about the state of the set without pulling up the OSD. I'm not sure if this works on all models? The return data *seems* to give you power status and whether or not the current input has signal [if it's on]. Some return data examples from a PRO950HD...

Power is Off:

\x02QPW****T**********************07070712*1***01\x03

Power is On, and selected input has signal:

\x02QPW60VST111223825622551251251207070712*10**32\x03

Power is on, and selected input has no signal:

\x02QPW60VST111223825622551251251203030312*10**26\x03

Note...you'll have to excuse a bit of Crestron-speak in my strings...anytime you see "\x", that means that the following two characters make up one [non-printable] hex byte. Example "\x02" equals hex 02.

I'm not sure how consistent and/or usable this is?

As a workaround for your issue, perhaps you could write a macro that would first turn off the OSD, count thru the desired series of status commands, sending one, wait for a response, send the next, etc... until the count is complete, then turn the OSD back on. This way you'd only add a total of two commands to the entire polling sequence, as opposed to two commands per status command.

Oh...forgot one thing.

If the QPW command looks familiar, it's because it's Panasonic's power status command. I've tried other Panny status commands [QMI, QAS, etc...] with no luck.

It may have been something added in this year's line. There's another user that has a two year old model and it doesn't support the query.


That's a possibility and may be the ultimate work around. Maybe Pioneer will come through but not holding my breath. Thanks for the idea!

On a related note, I am trying to control the PRO-150FD from an RTI RP6 system using RS232. So this means I have only 1 way communication (cannot check status). I am a bit troubled by the fact that when the system is off, and I send a power on command, that any subsequent commands seem to be ignored for a period of about 3.5 seconds. Has anyone else seen this? I would think that since the RS232 can be used to turn on the set, that the RS232 chip would continue to receive the commands (like change the input etc) at least put them in a FIFO.

My problem is that since I cannot query the system to see if it is on, when I want to switch from "Watch TV" to "XBOX" that I have to have it wait for 3.5 seconds in my macro. When the system is already powered this is quite annoying. I could get a current or voltage sense circuit, but I was looking for alternatives. I have tried sending out all the commands twice, once before the power on and the delay, and once after...but you end up with extra OSDs and the system cannot responds to any other remote commands while it's processing that wait command anyway.

Very typical of digital displays. You need to write logic, even kludge logic ( not based upon feedback ) that waits X seconds after initial turn on before sending additional commands but that once the unit is on, commands are immediately sent.

You could try using bouleans for this, assuming RTI permits this. When system is first turned on the flag is set high so the logic then knows to send the command immediately from that point on. Upon an off signal the flag is sent low and this low signal is how you know to wait the X seconds before sending your additonal commands

If you wish you can think as a simple if / else statement

If
Flag=0
{
(then [execute code);
}
else if flag=1
{
( execute other code);
}

Alan

One bit of correction. "\x" is neither particular to Crestron nor does it indicate that an unprintable ASCII character follows. It tells the compiler to take the following 2 values as a single byte rather than as individual bit values. \x30 tells the compiler to see 30 as a single 1 byte value rather than as "03" and "00" and as you know 03h and 00h is very different value from 30h The compiler also could care less if the value is in base 10, base8 or base16. \x will tell the compiler to see the following 2 values as a single byte and that's all. Yes, you could very well write the turn on command as \x02\x2E\x2E\x50\x4F\x4E\x03 The fact that 02h and 03h are unprintable ASCII characters is beside the point. Different compilers may or may not accept the "\x" syntax but the fact that Crestron's compiler does and that it's typically used for base16 values is pure coincidence.

By the way, a very lucid explanation of the device's feedback.

Alan

Actually, without the "\x" prefix, the Crestron compiler would take the following two characters as two individual bytes, not individual bits. The rest of your post indicates as much, so I'll assume that the bit reference was a typo [and I'm overly anal].


In general you are correct that in Crestron land "\x" does not necessarily mean the following hexadecimal byte represented isn't printable as ASCII. However, within the context of my original post, my statement[s] are accurate...each instance of "\x" is in reference to an ASCII control character [as opposed to a printing character]. My intent was not to get into a protracted discussion of Crestron serial string formatting, but rather to explain the syntax of the example strings with as much brevity as practical.


Thanks, I found it quite interesting that a Pioneer set would respond respond to a Panasonic power query [pure coincidence, but still worth documenting].

This might seem nitpicky--or my Pioneer 5020FD might differ in this regard to the Elites--but when powered off my TV responds to the "**VOL" command with just "XXX", not "VOLXXX". When powered on, its response is the full "VOL###", where ### is the volume level.

Ohno

He's been on pins and needles waiting 9 YEARS for this.

Just my way of saying "thanks!" even if you've all moved on to OLED by now. :-)

The same "XXX" response is received from the "INP" command, as well, when power is off.

(The material is relevant to my 7-year-old Pioneer, which is still running strong, and intended to help a major HA SW developer.)