For one of our projects i'm looking for a way to only let centrals (native iOS or Android app) connect with the perhiperal when they are inside a defined connection range (distance around the perhiperal).
I know that BLE is not designed for distance measuring but i hoped there is a reliable way to make a difference between centrals in a range <2m from the perhiperal and centrals >3,5 meter from the perhiperal.This means i do not need to measure the exact distance.
An important thing to mentoin is that our perhiperal can be located in an "open field" situation but also in situations where it is surounded with walls or concrete for example in a entry floor of a building or a carpark.
Another possible issue is that the central can be inside a car but if this is the case, all centrals for the concerning perhiperal are inside a car. Ofcourse it can be different cars.
Note that there is max 1 perhiperal at the time inside the connection range.
In our current version we developed an formulla what uses the received RSSI strength to estimate the distance. Unfortunately we cannot get this working reliable enough. Maybe we need to use another formulla or calibration method or whatever, we really tried many things during the last 6 months.
The concrete question is:
Is it technically possible to achieve the target as described above and when yes, what is the way to achieve the target above? We are open for specific BLE antenna's or specific designed casings for the BLE antenna or whatever is needed. It is also okay when we need to build an calibration application or specific hardware to calibrate our perhiperals, for each perhiperal, so we are realy open minded for any solution as long as it works reliable!
When more info is required to give an answere, please let me know what is missing and i will complete the info.
Unfortunately, it is like you said, you cannot use Bluetooth or Bluetooth Low Energy for short distance/range measurements. Bluetooth was just not designed that way. You want to get accurate reliable measurement for something between 2-3.5, this is way too small for BLE to be capable of that. I know that this is not what you want to hear, but I have already tried this and wasted many months on this before.
The only thing I can recommend if you really really need to continue down this path is that in order to get a more reliable outcome, you will need many many devices that are measuring the RSSI simultaneously, and then those devices need to be talking to each other to get an average RSSI measurement. You may also want to look at configuring the Tx power based on the average readings that you get, i.e. the closer the device gets, you lower the Tx power of both the scanning and advertising devices. Finally, directional antennas can be used if you are planning to use non-Android non-iOS devices for scanning, but this will be tricky if the only antenna you can change is that of the peripheral.
Related
My application is EXTREMELY dependent on user location, so much so that accuracy is very crucial to the use of the app. Speaking with my team we have realized the scenario that if a user is in close proximity to another geofence that we have created, CoreLocation may not recognize the difference. Are there currently any frameworks that work better for CL or LocationManager in iOS. I check the Cocoapods library but they all seem pretty close to one another in functionality.
You cannot overcome the physical and technological limitations of the GPS system. If you call CLLocationManager's requestLocation when the location manager is configured with the highest desired degree of desiredAccuracy (namely kCLLocationAccuracyBestForNavigation), the response in locationManager(_:didUpdateLocations:) is as accurate is you are going to get. Using a "library" is not going to change that.
You can set the accuracy to kCLLocationAccuracyBestForNavigation and then you will get the best data available. If you are not happy with iOS handling of geofences you could try to implement the geofence thing yourself by just subscribing to the delegate methods.
That way you can also filter CLLocations with a low accuracy and ignore them for example.
As others have said, there no magic bullet to give you accuracy better than what the GPS is able to provide.
What you can do is
Set the desiredAccuracy to the max
Check the accuracy value you get back from location updates, and reject readings with a horizontal "accuracy" value that is too large (since the "accuracy" reading is actually a "circle of confusion" or radius in meters where the phone may actually be located.
Note that step 2 may cause it to take a LONG time to get an acceptable location fix, or you may not be able to get an acceptable reading at all. Based on the testing I did several years ago, requiring a horizontal accuracy reading of 16 meters was the best I was able to achieve, and I could only get that signal quality in an open area free of buildings and without a lot of tree cover. (I haven't tried it in an open prairie, however.)
I want to define an area with a certain number of beacons. Theoretically it should be possible, Is it possible practically? Because the distance value that i get fluctuates erratically.
Do you mean that you'd want to figure out an exact position of a person based on trilateration from multiple beacons in the area? Like you said, it is quite hard with the sporadic signal transmission. There's some SDKs that exist for this, such as the Proximi.io free SDK and platform (http://proximi.io)
I would like to develop a mobile app for iPhones, that calculates time needed to reach a given velocity. For example: I'm in my car, open the app, choose 100km/h and when I accelerate the app should start to count time and it stops counting just in the moment when I reach 100km/h. It should be very accurate.
I heard about two solutions. First is to use the accelerometer/gyroscope, but some people told me it's bad idea, because I won't be able to calculate time on longer distances. The second option is to use GPS, but on the other hand it can be not as accurate as I want it to be.
So I need suggestions, which option is better and why.
My targets are iPhones 4s and newer.
If you want to be more precise than the GPS you will need to have some sort of sensor. Most similar apps and concepts will create a receiver that plugs into the car that the iPhone can connect to. This has the benefit of making all of the sensors in the car available to you. This is an example: https://www.automatic.com/how-automatic-works/
I'm working on a project which needs the iPhone to detect a small set of voltage data (two different values of voltage representing 0 and 1 respectively). My initial thought is to detect it through microphone, but I'm not sure if iPhone would be able to detect these signals since it contains no info of frequency. I searched in iOS Developer resources and on google, but nothing clear about this problem. Can anyone help me with this question? Thanks a lot!
as per our discussion, it seems you want to send a digital signal to the iphone. Now there are two main ways to do this.
Either sign up to Apples MFi hardware licensing program which allows you to create hardware for the iPhone. MFi program. Or,
There is an easy way to do this but it would require the use of the headphone jack. For demonstration and testing purposes you can use the headphone jack and if its a simple on and off signal then you can get good results with the headphone jack overall and might not require to create yourself a piece of hardware. Here's a link to that Grab sensor data and send it through the iPhone headphone jack
In fact, using the headphone approach is not as bad as it may sound, you can receive a nice signal if needed. Anyway, it will suffice for your purposes. Have a look what this guy is doing. I suggest you start with the video demonstration to get an overall idea of this approach.
UPDATE 1
Have a look at this link. People are using the headphone port to detect voltage. The reason this works is because the iPhone jack is a combination earpiece (output only) and microphone (input only) connector. The microphone input is a single wire, with common ground to the earpieces.
The usual problem when trying to use an audio signal as digital signal input is that it is high-pass-filtered to avoid offsets (long term pressure changes which could destroy the dynamic range of the soundcards Analog-to-Digital converters). This means you will get only the changes of the digital signal (like "clicks"). Actually you will be better of the higher frequency your signal has, but it will be non-trivial to process it well then (this was what ordinary modems did very well).
If you can control the digital signals sent as sound (or to the microphone jack), make sure they are modulated the signal with one or more tones, like a morse transmitter or modem. Essentially you want to use your iPhone as an Aucoustic Coupler. This is possible, but of course a bit computationally expensive considering the quite low bandwidth.
Start by using some dirt simple modulation, like 1200-1800 Hz and make an FFT of it. There's probably some reference implementation for any sound card out there to get started with.
There have been some cool viruses recently that was said to be able to jump air-gaps, they used similar techniques as this one.
If you still really want a DC (or slowly changing digital signal), check out a solution using a separate oscillator that is amplitude-modulated by the incoming signal
I'd like to have an iPhone and an Arduino-based device talk to each other. Here are the requirements:
I want to fully rely on iPhone's built-in components without any peripherals (for example, HiJack).
The less configuration before the two can communicate, the better. This means a WiFi-based is not desirable, because we'll need to set up Wi-Fi credentials for the Arduino beforehand.
Bitrate is not important. Only a few bytes are exchanged.
As cheap as possible.
I see that Bluetooth 4.0 LE (for example, Stack Overflow question iPhone - Any examples of communicating with an Arduino board using Bluetooth?) meets my requirements, but are there any cheaper solutions?
One thing that came into my mind is sound - the way Chirp used to share data between two iOS devices, but I don't know if is feasible on Arduino and, if it is, how much it would be. Any other solutions?
I can think of a few options:
Bluetooth, you can get a cheap one from eBay for about $10
Wi-Fi using Electric Imp (cost around $30), which is very easy to setup using the brilliant BlinkUp technique. See the project ElectricImp, control central heating via iPhone for an example.
Chirp is a brilliant idea as well. From a hardware prospective I see it is feasible to do in Arduino; you just need a MIC circuit ($8) and speaker.
However, the real challenge is the software side, i.e., the algorithm that you will use to encode data as sound and vice versa. If such algorithm requires intensive calculation, you might not be able to do it in Arduino, and you can consider using an ARM-based microcontroller.