Slashdot Mirror
Ask Slashdot: Wireless Proximity Detection?
New submitter Cinnamon Whirl writes "As a chemist, I work in a both lab and office enviroments, and need access to data in both, without causing undue clutter in either. My company has recently purchased two Win7 tablets for trial usage with electronic lab notebooks, propietry software, SAP, email etc. These are also useful for sharing in meetings, etc. As part of this project, I have been wondering whether we can use these tablets to detect other devices by proximity. Examples could include finding the nearest printer or monitor or, perhaps trickier, could two roaming devices find each other? Although lab technology is rarely cutting edge, I can see a day when all our sensors and probes will broadcast data (wireless thermocouples are already available), and positioning information will become much more important. What technologies exist to do this? How accurate can the detection be?"
Bluetooth is a good option, also look at RFID. There are RFID kits that are windows compatible. Check it out and hopefully this will help get you started as to some of the possibilities. http://www.trossenrobotics.com/p/RFID-experimenters-kit.aspx?feed=Froogle -cluge
"Science is about ego as much as it is about discovery and truth " - I said it, so sue me.
In what way is your tablet making wireless use of a monitor? Are you talking about a computer workstation, or just a standalone monitor?
I can't see ad-hoc networking being very useful for instrumentation. I would think you'd want sure fire, dedicated, reliable data capture and not random hodge-podge as far as that goes. For example, an instrument in the lab finds Tablet A and dumps its cached data to that tablet. The user of Tablet A promptly leaves the building and the data is now stuck on his device which is out of range. Worse, Tablet A is then dropped in a stream of molten lava in the field, and the data from that instrument is lost for good.
I think you need to better define exactly what you're even wanting proximity detection for in the first place - specifically, when two devices find one another, what is the point? Printers are one of the few things that makes some sense for proximity, but even in that case, how many printers are you talking about that it is too tedious to pick the desired printer from a list? What if you don't want to print to the closest printer, but the one nearest your office? Or the printer back at the office while you're out in the field? I would think printers in a lab would be part of the infrastructure, and not an ad-hoc wifi network. Further, you're usually better off with your tablet connecting to a WAP and accessing the LAN, instead of trying to wirelessly connect to individual devices like printers directly. In that case the whole concept of proximity is out the window unless your talking about PAN (bluetooth) type peripherals like keyboards and mice.
WAPs are usually strategically located for maximum wireless coverage, whereas things like printers and instruments are situated in entirely different locations where they are easy to reach (and thus suboptimal from a wireless perspective). Proximity could actually be a bad thing - it is really just a restriction. Wouldn't you want to be able to access a specific instrument whether or not you were in direct wireless range of that device?
Better known as 318230.
While seeing the closest is a tempting thought experiment, it may not be a practical solution for your actual workday (nearest printer may be low on toner, you may want these results in someone else's hands, etc). I'd still recommend what we do in our hospital by setting the shared device name with a zone number to indicate where it is. Your idea would be a great application for an RFID system with a map feature. Anyone have an idea with an existing app?
I used a similar Bluetooth setup in my old house with my phone system.
My VoIP setup had multiple outside lines (up to 12, fees were for usage), and numerous internal extensions.
I tossed some scripts together for my computers around the house to watch for the bluetooth signal from my cell phone, and routed the call depending on that data.
If my cell phone was in my kitchen, calls to my main # got redirected to the extension in the kitchen.
If my cell was in the bedroom, calls got routed to that extension instead.
If my cell was no where to be seen in the house, calls to my main # were forwarded to my cell phone number, under the assumption I was not in the house.
This saved me from using my cell phone battery while inside, but when I was out calls routed to me none the less with no configuration changes, or having to remember to flip some switch when leaving and returning.
It was pretty neat to have the phone in the family room ring once (as I was already walking upstairs) and have the ring "follow" me from there to the kitchen extension and finally to my bedroom before answering.
Behind the scenes it was a mess of asterisk configs/scripts, shell scripts, and some wrapped TCL executable for the windows machines.
But it was fairly straight forward work, not too difficult. This should be very doable as long as one has a little bit of programming (or really even just scripting) experience to glue all the bits and pieces together.