Alright, this may sound completely insane, I am not an electronics guy, just asking.
As far as I'm concerned, there are two most popular technologies for close-range communication: RFID and NFC. These technologies are just emerging in the mobile phones, as you don't see a lot of devices supporting them. Is it possible to build a GSM based sensor for the purposes of detecting who's sitting at the desk?
Let me describe the context. I'm working with a mobile phone operator to build a shop as part of my studies. They are able to install any GSM transceiver anywhere, and use it legitimately.
As NFC is not quite there yet, one of my proposals to them is to let people use their phones instead of (or as they would use) any RFID card, like Oyster in London, in order to make payments, quickly change tariffs, top-up, etc. I imagine that this may be possible by making a low-power GSM base station combined with a proximity sensor.
If so, then we can get a phone user with the strongest signal, get the information from the proximity sensor to define if there is a phone in front of the sensor and thus detect who is the user. What do you think? Is it something possible?
You can definitely have low powered base stations but they would generally be for a small area in a big venue/city or for a house or room.
Any phone in the coverage area from that operator would connect to that cell if it had the best signal, so you would find it very difficult to distinguish between two users who are a couple of feet apart. I'm guessing this would not be good enough for your use case.
Related
Just watched the last Google Dev video on Eddystone & Beacons (https://www.youtube.com/watch?v=s-4J7cijPAo).
I don't understand the need for physical beacons when a database linking latlong & a specific data can do exactly the same (except for indoor use-cases).
Is GPS not precise enough to make sure the user interacts with the right object?
GPS is generally accurate up until 30 meters (being lax here). iBeacons are here to bridge the gap between geolocation and micro location. So GPS would be good to tell when you arrive at someone's house. However, if you wanted to know when they arrived a certain room at said house, you would use an iBeacon.
So to answer your question, no GPS is not precise enough to make sure the user interacts with the right object.
Example:
We demo'd an app at Comic Con that would award users badges and points by visiting booths. We placed iBeacons in each booth to tell when a users had entered/exited a booth. GPS would not have been precise enough to tell this, also there were signal issues inside the venue that also hindered GPS usage. Also, if someone changed booth locations, all they had to do was move the iBeacon rather than try to change the lat/long of the booth.
i need to measure the time between 2 points. I can not use a simple watch because i have no free hands for this. (mountainbike - downhill)
My first idea was to set two GPS points and measure the the time between those points, but I think it will be to inaccurate.
my second idea was to set one bluetooth device to each Point and just measure the distance from me to the bluetooth device , check the shortest distance and save the time.
But than I realized that I would need 3 bluetooth devices to make a distance calculation, which is kinda annoying.
Any idea how i can measure the time between two points with an accuarcy <1sec ?
I want to control this via smartphone.
edit:
Okay i have another idea. Maybe i could set one bluetooth device to each point. I set the signal strenth to <=1m. Than i could easily start and stop the time until i receive the bluetooth signal on my android.
Do you think this would be the best approach ?
It seems you're trying to take total and split times for a course. Definitively, forget of using bluetooth for other things that are not constant transmissions, with slow connection time... (I speak from experience). Of course you want to do it in the cheap, because there already professional solutions for that (e.g.).
From my point of view, if you want something accurate and been able to integrate it with you phone, you'll need the following:
DIY photocell sensors. Maybe involving simple chip (e.g. msp430), phototransistor-diode pair, cheap 433mhz transmitter and batteries.
DIY 433mhz receiver for your phone. There already many boards that supports android open accessory library, (e.g. 49$ from sparkfun), so you only have to connect it to a 433mhz receiver and to your phone.
Custom code programming in your android phone. To be able to receive the signals from the split signal senders and keep track of all times.
It seems to be a pretty decent project for under $250-200(if you self made it :P).
One possible solution that does not require any special hardware would be to use a smartphone at the finish line. You would only need an extra smartphone (SP) with net connection, and some software.
SP sends the start signal to your phone. You start when you hear the signal.
SP uses its camera to detect when you reach the finish line.
SP calculates the time between start and stop and displays it, and possibly sends the info to your phone, too.
Maybe you could even record a video with time stamps.
(Of course, the low cost solution would be to let one of the guys to use a stopwatch at the finish line.)
Good evening all.
I'm just trying to collate some ideas really and was wondering if I could pick some brains.
I'd like to develop an app that relies upon measuring distance reasonably accurately. So for example, I have a central point, I want to be able to detect whether the phone is within a radius of a meter.
How could I achieve this?
The points would be static but I don't think GPS would be accurate enough to rely on this solely.
I'm definitely not a hardware chap but is there a way of combining GPS and some other sort of transmitter to ensure accuracy?
Any help or suggests greatly appreciated.
One meter accuracy? It's probably not going to happen with any phone hardware out there - definitely not with any Windows Phone. GPS isn't accurace enough without a differential beacon, and phones don't have the hardware to receive that (and I doubt you have a differential transmitter either).
The location service on the phone (assuming high accuracy is selected) combines data from GPS, cell towers and WiFi hot spots to provide a location.
There is no way to include the use of other sensors to improve this data.
You also won't be able to get the level of accuracy you're after from the phone. It's just not designed for the purpose you describe.
hey guys,
i'm working on a concept for university. i wonder what's the easiest and best way to measure certain vibration in a room. imagine a room full o people dancing. is there any affordable device i can put on the floor that sends data to my computer so i can read out vibration values or use vibration as data?
thank you for your help
I would guess that a microphone, as Pointy suggested, would work, but if you're on a near-zero budget, find an old speaker and bolt it face-down to the floor. Connect the wires to a 1/8" phono plug and plug it into the microphone-in jack on your sound card. Record the vibration data using Audacity. The floor's vibration will flex the speaker cone and generate small amounts of electricity, which the sound card input will see. If you put a foam-lined box over the top (actually back) of the speaker you'll minimize the effect of sound waves from the air on the speaker cone.
There is specific noise monitoring equipment which could serve that purpose, depending on how accurate the information you are monitoring needs to be.
I used to operate sound monitoring equipment as part of a rotating equipment inspection program when I was in the Navy. Basically it was a set of transducers you mounted to the equipment you wanted to monitor, and a proprietary box for recording and analyzing the results. I'm sure you could easily replicate that functionality with a PC.
Do a search for "Vibration Monitoring Equipment" or "Condition Monitoring" and see what turns up. If you are at a University with an engineering department I would imagine the ME's would have something like what you're looking for.
Greetings!
The idea is simple. Let's say that I have a service wherein people can walk up to a kiosk and "pair their phone" with a bluetooth device on that kiosk. We'll ignore why people would do this, but let's say that they have an incentive to do so.
Let's say that I have convinced thousands (if not millions) of people to do this thing... and they're walking around with their cellphones with bluetooth ON. (Not discoverable.) How do I solve the problem of scanning for "known devices" if there is a possible pool of millions of known devices?
Again, I don't want to connect with them once I've actually done the initial pairing. I simply want to know they are proximate.
Thoughts?
Well, the first thing is that even if your kiosk has a Class 1 Bluetooth radio in it, which can actually go farther than the advertised 100 meters, it's still extremely unlikely that there will be millions of Bluetooth cell phones who have previously paired with your kiosk within the range of your kiosk's radio. So that narrows down the potential number of Bluetooth devices you're dealing with.
Second, if a device is not discoverable, then it doesn't matter if you've paired with it before or not. You will not find it using a general "Hello, is anybody out there?" inquiry scan. If you've paired with a device, you will know its Bluetooth Device Address and can therefore ping it explicitly and get an answer. This doesn't seem like a reasonable thing to do if you're thinking you might have millions of cell phones paired with your kiosk. (Have you thought about the fact that if you have multiple kiosks your users would have to pair with each kiosk separately? Do you really need to pair with the cell phones to do what you need to do?)
Having said all that, a general inquiry scan will produce a list of discoverable Bluetooth devices in the vicinity of your kiosk's radio. You could use that list to search your own list of devices paired with the kiosk. I can't remember if you get back just the friendly name in the first response or if you get a BD_ADDR as well. If you just get the friendly name, there could be multiple devices with the same friendly name, as I doubt many users change their phones' friendly names.
It's been a while since I really delved into the Bluetooth spec so things may have changed.
Pairing may be overkill: that's about establishing secure communications. Worse, ISTR some phone UIs don't separate pairing (having a secure channel) and trust (allowing the remove device to do stuff without asking the user whether it should), although I hope modern phones get this right.
If you just want the other device's Bluetooth address, you could get people to send the kiosk a business card or something. Or tell them to become discoverable and have your kiosk initially find them. Or they could pair, but as Kirsten says, they'd be paired with a single kiosk: you may not care if all you want is their address, though, rather than the secure channel.
Now you've got a list of Bluetooth addresses. You can share these addresses between multiple kiosks if you've got some sort network between them. In an ideal world, detecting proximity would then be a matter of performing BT inquiry (you don't even need full device discovery here, just knowing what addresses are out there is enough) and matching the addresses you get from that against your list. But that only works when remote devices are discoverable (which means they're listening for inquiry packets, doing what the spec calls inquiry scanning). If they aren't, you'd have to try to connect to each one in turn (you can drop the connection once you know the other guy is there). You could parallelise this with multiple BT radios, but you're looking at a few seconds per address per radio. You're doing the old "Redfang" brute-forcing that people got excited about a few years ago, but it's going to be slow: http://www.newswireless.net/index.cfm/article/924
Of course, if people aren't leaving their devices discoverable, the implication is they don't want to be found, so it's not surprising that this doesn't work.