Agreed. If we can get an open discussion going with Shane or Mike, then I'll detail some of the "odditites" I've run into with the rs232 protocol. I'm just glad theres another Bryston'er tryingn to use it!
I've been planning my design-from-scratch Music Room automation for about 6 months. It integrates lighting, control of the SP1.7 and 2 Bryston amps, with touch sensors, motion sensors, and inputs like doorbell and phone ring, to create (what I hope will be) a room that more or less manages itself. Hit the THX button on the Bry remote, and the system will figure out that it's movie time, and it will select the DVD, dim the lights, set the phone to flash-but-not-beep, fire up the amps, etc.
Everything is working in prototype, but I've had to hack the code to use timeouts, as you mentioned earlier. This is the only kludge in the entire design.
What I've got is -
1. Wait for the first > to show up after power up. That declares the preamp "ready for command"
2. On sending a command, declare the preamp unready.
3. On seeing >, declare it ready (and kill the timer in the next step)
4. On seeing Return, set a countdown timer
5. If timer goes off, declare preamp ready for commands.
Now I reaslize that Bryston probably can't change their protocol, as people who have coded to it would have Bryson's intestines on a stick. But here are some talking points:
- On the RS232, set up CTS, or RI, or *some* pin, to indicate when you're ready to accept a command. Polling the input stream for ready markers isn't ideal. I don't think we want full flow control, but this would have been easy and cost about one transistor. (This would have the useful side effect of giving a controller some positive knowledge of whether the SP1.7 was alive, without hacks like peeking at Rx.)
- send > after every state change. Some button presses send back more than one line, and some events, like the volume control, will send back lines of text at any time, so my "line-end-and-timer" hack, above, isn't always likely to work.
- Make AFY the default. There's no reason not to. Unless you're afraid that serial responses are injecting noise into the audio side....
- PU, when the unit is on, shouldn't return error (!). It has the useful side effect of lighting up the display, and sometimes controllers won't be sure if the SP1.7 is on (and will want to make sure.)
- MY SP1.7 powers up by sending B<ret>SP1.7 OS v44D1<ret>. Is the B for Bryston?
-It would be great if serial commands could affect the 12v control relay. Also if they could turn the display on and off.
-It would be great of unrecognised remote codes would be echoed down the serial line (eg., "UC94"), as this allows the Bryston remote to become an input to an automation controller.
-It would be useful if there was a command that was guaranteed forever to return Error. One way to see if the SP1.7 is awake without changing the state is to send AA<Ret>, and get back the !. I'd hate for this to someday do something unintended.
-Is it my imagination, or is there something weird about sending lower case x's as a command? I mean, if it's an Easter egg, a response like "Avoid brand X; Bryston rocks" would have been funnier.
Thanks!
