The timing is not important - the story was told in Parliament as part of his farewell speech.
Kim Beazley, former opposition leader (crude US translation - Minority Leader combined with non-incumbent party presidential candidate) is retiring from politics, and with an election due soon, today was the last day parliament would be sitting before the election. This made today the last time he'll set foot in the parliament as a member of the House of Reps (hence farewell speeches containing a lot of retrospectives). During his time, he was Defense Minister when Labor was last in power (the party / coalition with the most seats in the House of Reps).
I remember seeing on TV in Australia about 10 years ago something that might be useful.
Some background - my mother used to work in a hospital with a brain injured patient who could still understand complex dialog, but was inable to speak and had limited mobility. Originally they would slowly repeat the alphabet letter by letter until he nodded ("A-B-C" *nod* "OK C... A-B-C..."), and eventually string together with pencil and paper what he was trying to say.
Eventually, they changed to a system with a series of largish lights - one labelled for each letter of the alphabet (maybe sort them so that Y and N appear at the "top" of the list). Each light would turn on for a period (adjusted so that it's suitable for the patients reaction time). To select a letter they would simply press a switch with the limited mobility they had in their hand. This was connected to an LCD that slowly spelt out the message.
I'm thinking it's not too difficult to learn to use, and requires very little mobility to operate.
Given the situation you've described, and the situations where we've seen them deployed, I'd say these would be ideal. I suspect IP cameras may not be practical, due to the need to refit the existing setup (going from video cable everywhere to ethernet everywhere); to say nothing of bandwidth requirements.
An alternative would be to write to whoever was the lowest ranking Senator on the Liberal Party NSW Senate ticket - that is, the Liberal senator who only just managed to scrape in 2 elections ago (who will be up for reelection this election - only half the senate is up for grabs each election, assuming no double dissolution stuff happening).
S/he would be very sensitive to a couple of thousand people in NSW adjusting their Senate preferences even a little bit. Perhaps indicate (if you are otherwise a coalition supporter) that you will preference them ahead of their opposition, but still move them further down your preference list - this way they can't simply disengage from dialog with you on the basis that "they wouldn't vote for the coalition anyway, so why bother?".
If you're planning to run it as a daemon (with the implication that you're running it as root), then my code suggestion will work just fine.
ioperm(0x378, 1,1); outb(byte, 0x378);
Substitute 0x378 with the address that your printer port resides at, the variable byte is used to refer to the output you intend to send to the printer port.
The design that we are advocating would work just fine. The 8 data bits from the printer port goes into the latch, whose latching action (the output of the latch stays the same irrespective of the input) controlled by the STROBE pin of the printer port. The latch's output in turn controls the ULN-driver chip, whose output lines are connected directly to your LEDS. If you need to control a multicolour led (I'm assuming these work by having a common ground terminal and multiple input pins) then you can just wire another bit to the same LED (but different colour). This would allow you to control a total of 8 single colour LEDS. For example, sending 128 down the line would light up the last LED, 64 the second last etc.
My side comment was to use 3 of the 8 data pins to control a chip that accepts a 3-bit binary number, and uses them to make ONE OF EIGHT output pins change state. These could be used in turn to control 8 latches, which are connected to the remaining 5 data lines, yielding up to 40 single LEDS.
I would probably use a variant of the code that I use at the moment, which is something along the lines of:
ioperm(0x378, 1,1); outb(byte, 0x378);
The problem with treating it as a line printer is all the extraneous characters that might be generated, such as "\n" or "\r" s. Although I'm sure there is a way around that problem (I just don't have any experience in printcappy things).
I've used something like this as well, except to drive relays that drive reset buttons on a series of machines at uni.
I agree with hotair's use of the ULN2803 chip; however, I think you need a 74HC373 octal latch. Basically when you send a byte to the printer, you need the latch to "catch" the byte and hold it after the signal goes away. The latch is controlled by 1 of the printer control lines that goes low when the data on the bus is valid (I think it is the STROBE pin).
If you want more than 8 leds, you could probably use a 74hc138 (3 to 8 demultiplexer) to control a bank of latches, but that would require alot more thinking on my part, so I'm leaving it with you.
A fair point - we still have Windows-based units here. In Chris' Operating Systems unit (here at the University of Western Australia), the differences between Unix and Windows-based (i.e. NT / Win2K etc) are explored, and the unit project involves writing a piece of software that interacts with the operating system (as opposed to the user-level libraries) for both Windows and Linux.
Which variant of UNIX are you referring to? Being a postgrad at this School, we've been dual boot Linux / (NT/2K) since PCs replaced our old X-terms (circa 1995 or so); indeed almost all of our infrastructure is Linux based.
Perhaps reading the entire article is called for; clearly the implication from your comment was that we are a non-Unix shop, where I think most people would say that running Linux certainly entitles us to say that we are.
Slashdot Mirror
The timing is not important - the story was told in Parliament as part of his farewell speech.
Kim Beazley, former opposition leader (crude US translation - Minority Leader combined with non-incumbent party presidential candidate) is retiring from politics, and with an election due soon, today was the last day parliament would be sitting before the election. This made today the last time he'll set foot in the parliament as a member of the House of Reps (hence farewell speeches containing a lot of retrospectives). During his time, he was Defense Minister when Labor was last in power (the party / coalition with the most seats in the House of Reps).
I remember seeing on TV in Australia about 10 years ago something that might be useful.
Some background - my mother used to work in a hospital with a brain injured patient who could still understand complex dialog, but was inable to speak and had limited mobility. Originally they would slowly repeat the alphabet letter by letter until he nodded ("A-B-C" *nod* "OK C... A-B-C..."), and eventually string together with pencil and paper what he was trying to say.
Eventually, they changed to a system with a series of largish lights - one labelled for each letter of the alphabet (maybe sort them so that Y and N appear at the "top" of the list). Each light would turn on for a period (adjusted so that it's suitable for the patients reaction time). To select a letter they would simply press a switch with the limited mobility they had in their hand. This was connected to an LCD that slowly spelt out the message.
I'm thinking it's not too difficult to learn to use, and requires very little mobility to operate.
Hi,
My IT Consultancy (picoSpace PTY LTD) has some involvement in the video surveillance industry in Australia, and nearly all the DVRs we encounter are Linux-based DVRs manufactured by Dallmeier. Have a look here for an overview of their specifications on one page or straight from the manufacturer.
Given the situation you've described, and the situations where we've seen them deployed, I'd say these would be ideal. I suspect IP cameras may not be practical, due to the need to refit the existing setup (going from video cable everywhere to ethernet everywhere); to say nothing of bandwidth requirements.
An alternative would be to write to whoever was the lowest ranking Senator on the Liberal Party NSW Senate ticket - that is, the Liberal senator who only just managed to scrape in 2 elections ago (who will be up for reelection this election - only half the senate is up for grabs each election, assuming no double dissolution stuff happening).
S/he would be very sensitive to a couple of thousand people in NSW adjusting their Senate preferences even a little bit. Perhaps indicate (if you are otherwise a coalition supporter) that you will preference them ahead of their opposition, but still move them further down your preference list - this way they can't simply disengage from dialog with you on the basis that "they wouldn't vote for the coalition anyway, so why bother?".
If you're planning to run it as a daemon (with the implication that you're running it as root), then my code suggestion will work just fine.
ioperm(0x378, 1,1);
outb(byte, 0x378);
Substitute 0x378 with the address that your printer port resides at, the variable byte is used to refer to the output you intend to send to the printer port.
The design that we are advocating would work just fine. The 8 data bits from the printer port goes into the latch, whose latching action (the output of the latch stays the same irrespective of the input) controlled by the STROBE pin of the printer port. The latch's output in turn controls the ULN-driver chip, whose output lines are connected directly to your LEDS. If you need to control a multicolour led (I'm assuming these work by having a common ground terminal and multiple input pins) then you can just wire another bit to the same LED (but different colour). This would allow you to control a total of 8 single colour LEDS. For example, sending 128 down the line would light up the last LED, 64 the second last etc.
My side comment was to use 3 of the 8 data pins to control a chip that accepts a 3-bit binary number, and uses them to make ONE OF EIGHT output pins change state. These could be used in turn to control 8 latches, which are connected to the remaining 5 data lines, yielding up to 40 single LEDS.
I would probably use a variant of the code that I use at the moment, which is something along the lines of:
ioperm(0x378, 1,1);
outb(byte, 0x378);
The problem with treating it as a line printer is all the extraneous characters that might be generated, such as "\n" or "\r" s. Although I'm sure there is a way around that problem (I just don't have any experience in printcappy things).
I've used something like this as well, except to drive relays that drive reset buttons on a series of machines at uni.
I agree with hotair's use of the ULN2803 chip; however, I think you need a 74HC373 octal latch. Basically when you send a byte to the printer, you need the latch to "catch" the byte and hold it after the signal goes away. The latch is controlled by 1 of the printer control lines that goes low when the data on the bus is valid (I think it is the STROBE pin).
If you want more than 8 leds, you could probably use a 74hc138 (3 to 8 demultiplexer) to control a bank of latches, but that would require alot more thinking on my part, so I'm leaving it with you.
A fair point - we still have Windows-based units here. In Chris' Operating Systems unit (here at the University of Western Australia), the differences between Unix and Windows-based (i.e. NT / Win2K etc) are explored, and the unit project involves writing a piece of software that interacts with the operating system (as opposed to the user-level libraries) for both Windows and Linux.
Which variant of UNIX are you referring to? Being a postgrad at this School, we've been dual boot Linux / (NT/2K) since PCs replaced our old X-terms (circa 1995 or so); indeed almost all of our infrastructure is Linux based.
Perhaps reading the entire article is called for; clearly the implication from your comment was that we are a non-Unix shop, where I think most people would say that running Linux certainly entitles us to say that we are.