Hitachi projector status parsing
gregr
Junior Member
I don't use a lot of Hitachi's, but was enticed because of the built-in TCP/IP ports.
But the protocol seems like a holdover from the 60's. The commands are verbose (13 bytes to do anything including on/off).
I can deal with that, but my difficulty is how do you parse the responses, which don't seem have any exclusivity. For example, the response for power on is "01 00". The response for cover error is "01 00".
Am I missing something? The Sanyo's that we normally use have responses which in addition to being human readable ASCII, are for the most part exclusive-very easy to parse.
I have set flags before on the Hitachi when requesting status, but this seems to be a kludgy way to do things.
Is there a better way to parse responses from the Hitachi's, or similar devices whose feedback is so generic?
Thanks much.
But the protocol seems like a holdover from the 60's. The commands are verbose (13 bytes to do anything including on/off).
I can deal with that, but my difficulty is how do you parse the responses, which don't seem have any exclusivity. For example, the response for power on is "01 00". The response for cover error is "01 00".
Am I missing something? The Sanyo's that we normally use have responses which in addition to being human readable ASCII, are for the most part exclusive-very easy to parse.
I have set flags before on the Hitachi when requesting status, but this seems to be a kludgy way to do things.
Is there a better way to parse responses from the Hitachi's, or similar devices whose feedback is so generic?
Thanks much.
Comments
-
For protocols like the Hitachi, I usually set an internal flag noting what kind of request I've sent. (GetPower, GetInput, GetLampLife, etc) When/if a reply comes back, I do a switch/case on the flag so I know how to treat the response. Once the response is dealt with, I clear the flag.
I also queue all my strings to the projector. When I'm expecting a reply, I ensure that I do not send more strings until the first reply has been dealt with, or a reasonable timeout has occurred.
Roger McLean
Swinburne University -
Thanks much, Roger. Pretty much what I am already doing.
Categories
- All Categories
- 2.5K AMX General Discussion
- 922 AMX Technical Discussion
- 514 AMX Hardware
- 502 AMX Control Products
- 3 AMX Video Distribution Products
- 9 AMX Networked AV (SVSI) Products
- AMX Workspace & Collaboration Products
- 3.4K AMX Software
- 151 AMX Resource Management Suite Software
- 386 AMX Design Tools
- 2.4K NetLinx Studio
- 135 Duet/Cafe Duet
- 248 NetLinx Modules & Duet Modules
- 57 AMX RPM Forum
- 228 MODPEDIA - The Public Repository of Modules for Everyone
- 943 AMX Specialty Forums
- 2.6K AMXForums Archive
- 2.6K AMXForums Archive Threads
- 1.5K AMX Hardware
- 432 AMX Applications and Solutions
- 249 Residential Forum
- 182 Tips and Tricks
- 146 AMX Website/Forums