Serial IO patch flow control

ahoeben's picture

Thanks for the Serial IO patch. I am trying to use it to control (turn on/off) a projector. The protocol for the projector is pretty straightforward, but I am running into an issue.

I am using a Prolific PL2303-based USB-to-RS232 bridge. Most - if not all - USB-to-DB9 RS232 converters seem to be based on that chipset. Prolific has OS X drivers, but they seem to be unstable; they work fine using 'screen >/dev/tty.usbserial', but they lock up when piping output from the terminal to the port more than once, and when using them with the Serial IO patch.

I have found an open sourced alternative for the drivers that works lots better:

However I am still having a somewhat strange issue. If I use a terminal app ('screen', like above), I can control the projector just fine. When I use Quartz Composer and connect the serial port to another serial port using a null-modem cable, I can see that Quartz Composer outputs the correct characters over the serial port. But when I connect the serial cable to the projector, I can't get it to work; commands don't seem to get through. When I connect the serial port back to the null-modemed connection to the other computer, the serial connection is no longer working, even using screen instead of QC.

So somehow, even though QC is outputting the correct characters, and uses the correct timing, etc, it seems to lock up the serial port once connected to the projector. As a last straw, I am thinking that my 'screen-over-null-modem' has support for RTS/CTS hardware handshaking, whereas the projector does not implement flow control (I am not sure about that; grasping straws...). Could that be an issue? Is the Serial IO patch enforcing strict handshaking? Can I somehow configure the port not to use handshaking?