>Cris Wilson wrote:
>
>>At 11:00 PM 3/31/2005 -0600, you wrote:
>>
>>>I'm trying to build a little network of microcontrollers that can report
>>>their status to a central server, in a forest. We want to make the
>>>various flag/objective stations when we play paintball automatized, and
>>>I'm looking for some ideas/recommendations. The uC need to report
>>>something simple (eg, which sides owns that station), and maybe a timer.
>>>However, it would be great to further expand it to use rfid/bluetooth
>>>technology to record when a player is actually 'holding' the station. It
>>>would transmit this data to a central server that would display the
>>>whole results.
>>>
>>>Any ideas for bluetooth/rfid/'presence' signalling?
>>>
>>>Even more importantly, should I try to use little rf transmitters, and
>>>do it myself, or woiuld it be better to use 802.11 wireless types? The
>>>picotux (recently posted,
>>>
http://www.linuxdevices.com/news/NS8386088053.html) looks great: I could
>>>just use tcp/ip for reports and command line scripts, since they run
>>>linux. But they are 100 euros a pop. I'm also concerned about how much
>>>power consumption I should expect from these things, as well as what
>>>range would I get in forests?
>>
>>
>>I faced a similar problem like this last year with some PIR monitors in a
>>forest.
>>
>>We first tried using 802.11 and found that if we had a clear line of
>>sight between the sender and receiver
>>that it worked fine out to about 200 yards. Of course, we could only get
>>a clear line of sight with 2 of the
>>senders. Without a clear line of sight, we could only get about 100 feet
>>of reception amongst softwood
>>pines trees, and around 50 feet of reception amongst hardwood hickory trees.
>>
>>The solution we used was to buy a bunch of the 2-mile range hand held
>>radios and hack them apart.
>>We set them all to the same frequency, replaced the send button with a
>>transistor to act as a switch,
>>and replaced the microphone with a simple beeping circuit run from a pic.
>>Once the PIR was activated,
>>the PIC would broadcast its beeps 5 times. (The beeps just identified
>>which monitor it was - 9 beeps
>>for monitor #9). On the receiver end, we had another hacked hand held
>>radio with a PIC that would
>>count the number of beeps (voltage pulses) that came in and dump it into
>>a computer serial port. A simple
>>basic program on the computer then logged the time and receiver number.
>>
>>I think we pretty much got all of the basic circuits from a model rocket
>>telemetry web page.
>>
>>There is one problem with the system though. If two of the monitors
>>activated at the same time then we
>>would get the wrong the sensor logged. (If sensor 1 and sensor 2
>>activated at the same time, then we
>>would get 3 beeps and the computer would log sensor 3). Luckily that only
>>happened a couple of times
>>and when we looked at the data it was obvious that something had messed up.
>There are two ways of doing this, the RIGHT way and an acceptable way.
>
>The RIGHT way needs the ability to listen for a synchronizing time pulse
>to reset the timeclock inside each unit.
>Each unit would be assigned a timeslot beforehand, and would only send
>during that time period, even if that
>delayed the PIR indication for a few seconds. The synch pulse would only
>need to be sent once every 6 hrs or
>so, and when it occurred also indicated that the sequence is then reset
>(the first interval means address 1).
>Since you now have given a unit a time slot, ANY pulse during that time
>slot will come from that unit. So two
>can't send at the same time. To save the battery, I'd turn the RCVR off
>except about 5% before its expected
>time of occurrence. This is the way the military does security perimeter
>sensors.
>
>An ACCEPTABLE way is to make use of the fact that the PIR sensors don't go
>off that often. When a signal is
>needing to be sent, the unit listens carefully to see if another is
>sending. If so, it waits until it is finished PLUS a
>random interval , then check again, before sending its own pulse train.
>The randomness is needed because if
>the interval is fixed, two units listening for an earlier unit to quit are
>CERTAIN to write over each other. It might
>be best if the "randomness" is fixed ahead of time.
>
>- - - - -
>
>BTW, Are you aware that an animal can be detected by blocking PIR from the
>big bang, rather than straight
>IR sensing? Its very good for sensing humans, who can bundle up in coats
>so that no PIR gets out, but it
>blocks the big-bang energy well.
engineer.cotse.net .
