Cheap wireless (RF) receiver/transmitter solution?

[Rich Grise]

On Sat, 18 Dec 2004 16:32:19 +0000, d.wills wrote:

Since you didn't indicate that this was based on some "game" "quick
response" type situation, I would go the route of IR. A simple handheld
device for each student, with the output configured to send a serial #
(uniquely assigned to each student) and then the response (A, B, C ... etc.)
You could easily place a couple of receivers around the room and have them
all tied into one PC. A simple display board that gives feedback to the
students that their response was received would allow them to know whether
or not their answer has been registered (I am thinking a grid of lights, one
per student that gets reset with every question, assuming that all students
are answering every question.) The PC could give immediate feedback to the
teacher to indicate whether they understood the material, or, if this is a
true testing situation, would give immediate scores. You would also know
each student has answered before moving on to the next question.

I see it as a bunch of IR remotes transmitting to 4 or 5 carefully placed
receivers, attached to a pc running a fairly simple VB program to tally the
results.

Now if you are thinking a gaming system of some sort, most of this doesn't
work (ir is too prone to interference), but since you didn't indicate that,
I think this will work. The great thing about this layout is you can always
add remotes and basically have an unlimited supply of unique serial numbers
or number of answers (10 to 16 with most standard keypads), and can cover a
larger area by simply adding ir receivers. Each student can keep their own,
and you can probably build (buy?) them for $3 to $6 each (small board, PIC,
ir led, crystal, a few discreet components) and write the software in a day
(or have someone do it for you.)

Just an opinion

And who writes the software that parses all these IDs coming in to your IR
receiver simultaneously, i.e., all on top of each other?

Thanks,
Rich

 

[d.wills]

And who writes the software that parses all these IDs coming in to your IR
receiver simultaneously, i.e., all on top of each other?

Thanks,
Rich

Well, if I were doing the project, then I would. Or maybe the same
undergrads that you would use for your bushbutton idea. The reason I thought
that some type of visual feedback was necessary for the students was that
if some responses clobbered each other, the student would see that his/her
response wasn't accepted and would simply push the button again. A Microchip
PIC 16F877 attached to almost any IR detector and a few other components,
programmed using the free JAL language could store dozens of respones and
could send them to the PC when polled (or the PIC could initiate the
transfer when the PC is ready.)

Note that the op's only requirements were: "only
requirements are that the devices have some sort of unique signature to map
to a particular student (though simple attacks to this like giving their
device to another student are not an issue atm), as well as that the device
allow the student to choose one of four options, and work at an acceptable
range (say, 20-25 meters). I would like to translate the results real time
to some comodity pc hardware."

As far as I know from this, only one student is answering each question. If
all (up to 100) need to answer at once, just increase the number of
receivers. If they all receive send a serial stream to the pc, and the
students are likely to respond at different speeds, then the likelyhood of
frequent problems is small, but some students will have problems almost
every time. Any normal PC should be able to handle the serial stream easy
enough and if all id's come in as something like FF12345678A where 12345678
is the serial number and A is the answer with a header of FF to signal valid
data, then it would probably be close enough to s finished product that some
tweaking would be all that is necessary to complete it. OK, you're right, a
checksum of some sort is in order to validate the incoming data stream, but
I don't think that would be too hard.

Note that I never said this was the best way to solve his problem, just
another way. Since people were sending out ideas and the OP hadn't
necessarily spelled out all of his requirements, I was just bouncing around
an idea.

-Doug

 

[Rich Grise]

On Wed, 22 Dec 2004 22:33:52 +0000, d.wills wrote:

And who writes the software that parses all these IDs coming in to your IR
receiver simultaneously, i.e., all on top of each other?

Thanks,
Rich

Well, if I were doing the project, then I would. Or maybe the same
undergrads that you would use for your bushbutton idea. The reason I thought
that some type of visual feedback was necessary for the students was that
if some responses clobbered each other, the student would see that his/her
response wasn't accepted and would simply push the button again. A Microchip
PIC 16F877 attached to almost any IR detector and a few other components,
programmed using the free JAL language could store dozens of respones and
could send them to the PC when polled (or the PIC could initiate the
transfer when the PC is ready.)

Note that the op's only requirements were: "only
requirements are that the devices have some sort of unique signature to map
to a particular student (though simple attacks to this like giving their
device to another student are not an issue atm), as well as that the device
allow the student to choose one of four options, and work at an acceptable
range (say, 20-25 meters). I would like to translate the results real time
to some comodity pc hardware."

As far as I know from this, only one student is answering each question. If
all (up to 100) need to answer at once, just increase the number of
receivers. If they all receive send a serial stream to the pc, and the
students are likely to respond at different speeds, then the likelyhood of
frequent problems is small, but some students will have problems almost
every time. Any normal PC should be able to handle the serial stream easy
enough and if all id's come in as something like FF12345678A where 12345678
is the serial number and A is the answer with a header of FF to signal valid
data, then it would probably be close enough to s finished product that some
tweaking would be all that is necessary to complete it. OK, you're right, a
checksum of some sort is in order to validate the incoming data stream, but
I don't think that would be too hard.

The problem is, they'll be coming in like this:

000000000000111111110000000000000111111110000000000011111100000000001111
000000001111100000000111110000000000011111000000111111000000000001111100
111110000000000011111110000000000000011111111110000000000000000001111111
000000000000111111111111111000000000000000000011111110000000000000000111
000000111111111111000000000000000000011111111111110000000000000000001111

S:111110111111111111111111111000000111111111111111111111111100000001111111

Where the '1's are IR remotes with the LED "on", and the '0's are the
IR remotes while the LED is off.

How does your sensor distinguish which photons are coming from which
channel during the times that _any_ transmitter is transmitting an IR
pulse?

Thanks,
Rich

 

[d.wills]

The problem is, they'll be coming in like this:

000000000000111111110000000000000111111110000000000011111100000000001111
000000001111100000000111110000000000011111000000111111000000000001111100
111110000000000011111110000000000000011111111110000000000000000001111111
000000000000111111111111111000000000000000000011111110000000000000000111
000000111111111111000000000000000000011111111111110000000000000000001111

S:111110111111111111111111111000000111111111111111111111111100000001111111

Where the '1's are IR remotes with the LED "on", and the '0's are the
IR remotes while the LED is off.

How does your sensor distinguish which photons are coming from which
channel during the times that _any_ transmitter is transmitting an IR
pulse?

Thanks,
Rich

Your point is well taken, but the sensor doesn't need to distinguish between
photons from different ir remotes, it just needs to determine whether or not
it has a valid response from any remote. I would place the ir sensors on the
front wall with baffles in place to block all (most) signals but those
coming from the appropriate row. This isn't too hard to do. Now the sensor
will receive an incoming signal(s). If the sensor reads a proper header (
example - "1111000010100101"), then count the next several bytes. Receive
the serial number, answer and check sum, and then check the input. If the
signal gets clobbered by another remote, the checksum bombs and the receiver
rejects that particular input(s). This is why the visual feedback is
necessary (think bingo type board with one light per student, reset each
question). A student will push their button, see that their answer wasn't
accepted, and push again.

If we limit the number of remotes per sensor (my guess is anything less then
10 would be ok), and questions are displayed to the crowd or read to the
crowd, and there are 2 to 4 possible responses, I've got to believe that the
responses will come in over a 10 to 20 second time period per question,
making the likelihood of competing entries even smaller. A quick check on
standard baud rates for ir communication via remotes seems to be in the
100-2000 bps range. Although not particularly fast, it should be fast
enough. Yes, I know I am assuming a lot here, but I am envisioning a normal
classroom setting with some students getting the answer much more quickly
then others. With these assumptions, most student responses would be
received the first time, with a few here and there that would have to
re-enter their answer per question

Again, not a perfect solution for all situations. I.E.: if only one student
is to answer at a time, perfect and cheap. If all students are taking a
test, but the answers are not based on the quickness of a response, it will
work well for most students for most answers with cost and expandability
still being protected. If this is a Jeopardy type game speed is of the
essence, then it doesn't work at all.

- Doug

 

[Eric R Snow]

On Thu, 23 Dec 2004 06:31:34 GMT, Rich Grise <rich@example.net> wrote:

On Wed, 22 Dec 2004 22:33:52 +0000, d.wills wrote:



And who writes the software that parses all these IDs coming in to your IR
receiver simultaneously, i.e., all on top of each other?

Thanks,
Rich

Well, if I were doing the project, then I would. Or maybe the same
undergrads that you would use for your bushbutton idea. The reason I thought
that some type of visual feedback was necessary for the students was that
if some responses clobbered each other, the student would see that his/her
response wasn't accepted and would simply push the button again. A Microchip
PIC 16F877 attached to almost any IR detector and a few other components,
programmed using the free JAL language could store dozens of respones and
could send them to the PC when polled (or the PIC could initiate the
transfer when the PC is ready.)

Note that the op's only requirements were: "only
requirements are that the devices have some sort of unique signature to map
to a particular student (though simple attacks to this like giving their
device to another student are not an issue atm), as well as that the device
allow the student to choose one of four options, and work at an acceptable
range (say, 20-25 meters). I would like to translate the results real time
to some comodity pc hardware."

As far as I know from this, only one student is answering each question. If
all (up to 100) need to answer at once, just increase the number of
receivers. If they all receive send a serial stream to the pc, and the
students are likely to respond at different speeds, then the likelyhood of
frequent problems is small, but some students will have problems almost
every time. Any normal PC should be able to handle the serial stream easy
enough and if all id's come in as something like FF12345678A where 12345678
is the serial number and A is the answer with a header of FF to signal valid
data, then it would probably be close enough to s finished product that some
tweaking would be all that is necessary to complete it. OK, you're right, a
checksum of some sort is in order to validate the incoming data stream, but
I don't think that would be too hard.

The problem is, they'll be coming in like this:

000000000000111111110000000000000111111110000000000011111100000000001111
000000001111100000000111110000000000011111000000111111000000000001111100
111110000000000011111110000000000000011111111110000000000000000001111111
000000000000111111111111111000000000000000000011111110000000000000000111
000000111111111111000000000000000000011111111111110000000000000000001111

S:111110111111111111111111111000000111111111111111111111111100000001111111

Where the '1's are IR remotes with the LED "on", and the '0's are the
IR remotes while the LED is off.

How does your sensor distinguish which photons are coming from which
channel during the times that _any_ transmitter is transmitting an IR
pulse?

Thanks,
Rich
I see advertised in Nuts and Volts small transmitters and recievers.

And small transcievers. It seems to me that each device could be
polled by a computer and when all devices have answered the computer
tells the teacher. I know there are wifi setups that let many people
connect at the same time. I believe these all ask for data from
specific devices that it recognizes to avoid interference. Sorta like
the way cell phones work.
ers