Building an Open Source "Clicker"?

fieldtest asks: "Most Slashdot readers have read about "clickers", remote control style devices that students use to wirelessly answer a teacher's questions. Unfortunately, as a college student, I have had less than stellar experiences with these clickers. I hear complaints from my professors and fellow students often as well. So, I want to build an open source clicker system for all universities to use. I believe that this is a prime opportunity to show how powerful free software can be. So, what do the talented people of Slashdot recommend?" "The problem is this: a clicker system requires...clickers. What I need are remote controls that have a minimum of 6 buttons (for users to select options with). The sticking point comes when a button is pressed -- the remote must send the option choice, as well as a unique ID specific to the remote, so the clicker software can distinguish between different students.

I've experimented and Googled around. I've tried standard TV remote controls combined with an USB-UIRT receiver, but the range was too low. Googling shows some interesting programmable remotes, but they're far too expensive ($100+) to have each user purchase one.

How should I go about building the perfect clicker and receiver system? Any suggestion is welcome, from IR to radio, from Bluetooth to ZigBee based communications. Recommend a commercial product, or a do it yourself solution. Please also recommend a receiver device, and a way to connect it to a computer. Also, if you recommend that I just build a custom circuit board for the remote control, please give some references and examples of how it should be implemented."

Comments

Parent post has all the answers!

[fireboy1919]

Also, you might consider stopping all human maladies. Here's how you do it:
Do you know anything about psychology or physiology? If you're good at one, get somebody who's good with the other to help you out. And make sure you cure ALL people (Americans, Europeans, Asians, Africans, etc..).

What could be simpler?

Tackle the job in pieces

[planetmn]

I think you are getting a little ahead of yourself. If you haven't taken a product design class, now would be a good time.

You really need to spend some time figuring out what your requirements are (do you want a variable number of answers, or a set amount? Does there need to be any immediate feedback? Do you need a keyboard or will pushbutton input be acceptable?).

Define high-level requirements and then brainstorm for each one. Don't get caught up in wired or wireless, 802.11 or bluetooth, that's a medium and can be easily changed later.

Make sure for every requirement (and you should have a good number of requirements) that you have multiple ways of addressing that requirement. Write down every idea, don't judge them yet. Make sure you have some wacky ideas that just might work given some more time.

Get a focus group together of the "customer." This means students, teaching faculty, administrators, IT (they'll probably have to support).

Find out what their requirements and their desires are.

Get some people to help, multiple EEs/CSEs for the hardware side, some CompSci's to help with the software, even some psychology majors to help you with what works and doesn't for human factors.

Put together an initial prototype. It can be crude and rely on external addressing, wires, whatever, even if you plan to implement security and wireless later, you need a proof of concept.

Go step by step, so you have a rough interface done, work on the addressing scheme. Build another prototype (by the way, use an FPGA or something else that you can re-use without buying new, or at least put everything on protoboards).

Play around with different wired and wireless connections. Try getting an 802.11, bluetooth, wired, etc. connection working, and have users try them out.

Once you have an idea of what you want to build, do it. Design a PCB and have some made (some meaning enough to do a reasonable test, at least 25). Look for somebody to do injection molding for a plastic case, put everything together. This is your prototype.

Test, test, test.

Go back to the drawing board, what worked, what didn't. Redesign, get input from users, brainstorm again.

Build a second set of prototypes (maybe you can reuse some or all of the components if you are lucky).

Run more tests, this time on a larger scale. Ask a professor to use them in a class.

Take input from these tests and build yet a third prototype. By this time, get a MechE or materials person involved. These things will be in backpacks, under textbooks, sat on, dropped, will they withstand some abuse? Do some environmental testing (it doesn't have to be official, though, look at some of the things a place like Retlif laboratories (http://www.retlif.com/ can do, and at least mimic some of the tests.

You now have a Beta product. Have a few classes use it for a semester and get feedback. Repeat the necessary steps for the Alpha product. At this point, try to sell it as a system and get a wider group of users.

This process is not quick, not easy, not cheap. But if you want to create a serious product, it's the way to go.

As a design engineer, I know how big of a pain in the butt going through each step can be, but if you skip a step to save a week, it will cost you two weeks later on, when you don't have that time to spend.

-dave