[Rack] how to open noisebridge door from computers
embeddedlinuxguy at gmail.com
Tue Feb 21 00:36:06 PST 2012
For some reason the keypad daemon fails to open the serial port after
a while and has to be restarted. I just pushed a change to restart
after a serial open failure. The current architecture closes and
re-opens the serial port after 10 seconds of idle time; this seems
unnecessary, so I will change it to hold the serial port open and see
if that problem goes away.
On Tue, Feb 21, 2012 at 2:06 AM, Jonathan Lassoff <jof at thejof.com> wrote:
> On Mon, Feb 20, 2012 at 10:51 PM, Jake <jake at spaz.org> wrote:
>> so the thing wasn't working when i came in tonight - it was plugged into one
>> of the grey serial ports on a ribbon cable and i don't know if that's right.
>> i also don't know if the program is running on the other end, but when i
>> pressed keys on the keypad, there was no response (no Wrong buzzer or
>> anything else)
>> Did someone change serial ports? Is the program running?
> So, some things to know:
> - The gray ribbon cables with DE9 hoods on the end are proper serial
> ports. The UART on the mainboard just didn't have connectors.
> -- They should also mostly all be labeled. If not, let's fix that.
> - There is a conserver instance running on minotaur that will make it
> awfully difficult to communicate with any ports it thinks it's
> Currently, it's got:
> switch2.noise on /dev/ttyS0
> bikeshed.noise on /dev/ttyS1
> There's also an apcupsd running on /dev/ttyS2.
> If it's still not clear which port it is, see if you see the mainboard
> model number and where it's physically cabled. We could probably get a
> good idea from the manual.
> Is it possible to interrogate or interact with your remote AVR? That,
> or a protocol definition would be useful to debug or test the cable
> run. I suspect we're really stressing the limits of what the MAX232
> can drive, and some sort of test of bit error rates would be darn
> useful in proving the system to be robust.
More information about the Rack