Do all Cars that support Bluetooth also automiatically support iBeacon without any additional work?
I want to test if the user is currently I his/her car. According to this question, this is generally not possible but iBeacon may be a solution. Thus, my question is if iBeacon is always supported by a Car if it has Bluetooth or if special hardware is required.
No, not all Bluetooth enabled cars emit iBeacon transmissions. I can say this with certainty as my 2017 Mini Cooper pairs over Bluetooth yet does not emit an iBeacon transmission.
I also rent late model cars relatively frequently and am the developer of a number of beacon detector apps. While I have not explicitly tested all vehicles I have rented, I have never once noticed one triggering a detector app. My conclusion is that few if any vehicles emit iBeacon transmissions in general use.
I have worked with an insurance provider that provides beacons to be installed in customer cars (typically plugged in to a USB adapter) allowing vehicle usage tracking with the company app in exchange for a discount. An extra hardware solution like this would be required to accomplish your goal with iBeacon.
Not sure this is an alternative for you, but you could place a beacon in the car and have an app on your phone detect it and perform an action on that fact. Of course the app then would have to run also when the phone and the app are not actively used.
NFC could also be used this way, provided the phone is always placed in a holder.
Related
I've been researching a possible iOS-based app, developed in Unity, that would require a high-degree of positional accuracy (centimeters).
I expect I would need to connect, from the app, to an external GPS device using Bluetooth (or similar) and obtain NMEA sentences (or similar) containing location data.
My research has brought me to RTK, which is extremely accurate. From what I've seen already, it seems that normally GPS receivers which offer this operate themselves at normal GPS precision (2-2.5m). The correction to a high-accuracy location happens in software on a connected computer or tablet with a connection to an NTRIP server.
Assuming what I've said is correct, does anyone know of a GPS device that performs this RTK correction on the GPS device itself? Ideally I could just connect with Bluetooth or similar and get NMEA (or equivalent) data with high-accuracy location.
It may also be that I'm thinking about this incorrectly. On iOS, assuming there is an 3rd party app performing the RTK calculations, is there a standard way to obtain that high-accuracy location? Alternatively, are there GPS vendors that supply SDKs that would allow me to get to where I need to go?
Thanks very much,
Kieran
There is a recent module from U-Blox named ZED-F9P which has internal processing and is faster then RTKLib. Check this blog for performance
You can buy a board like ArduSimple's simpleRTK2B with an XBee module for WiFi/Blutooth or something similar from Sparkfun. You could also wait for the development board from U-Blox which is not yet available.
I am trying to wrap my head around the possibilities of the HM-10 but am very new to a lot of how it works. I am only familiar with higher level things.
I originally thought I was going to use the hm-10 as an iBeacon but quickly found out it's limitations. Here was the original plan prior:
iBeacon(HM-10) broadcast in a particular room, when I walk in with my iPhone, it detects my iPhone and then does something, i.e Sets one of its Pins to High.
But based on my research now, this is not possible with iBeacon? I need to use iBeacon broadcasting in hand with regular bluetooth?
As in, upon my App/Phone detecting the iBeacon it then pairs with the HM-10 and sends an AT- command to set one of the pins HIGH.
Does all of this make sense? Could anyone provide some more input?
I am in the process of putting together an iPhone App but just wanted to know if I am on the right track.
Since the HM-10 is based on the CC2540, it should be possible to turn it into a Bluetooth LE beacon, including one that supports an iBeacon format.
A few thoughts to help your understanding:
Standard Bluetooth LE beacons (AltBeacon, iBeacon, URL beacon) are transmit only devices that don't detect phones -- phones detect them using a custom app. So when you say "it detects my iPhone and then does something" this is diverging from a standard Bluetooth LE beacon.
The concept of "pairing" with a Bluetooth device is typically related to Bluetooth classic (e.g. pre-4.0) technology. Bluetooth LE devices like the beacons mentioned above have the concept of connecting to read and write GATT characteristics.
If you do build a custom BLE device that out of a HM-10/CC2540, it would be possible to make it "detect" mobile phones, perhaps by advertising a GATT service, and then doing something upon connecting and/or writing to a characteristic. Since the CC2540 contains GPIO pins, it would be possible to make it "do something" by making a pin go high.
There are two big chunks of work to doing what you describe: (1) writing custom firmware for the CC2540 and (2) writing an iPhone app using CoreBluetooth and/or CoreLocation iBeacon APIs. Before starting on the iOS side, you need to figure out how the Bluetooth device is going to work.
I am trying to develop one app with using a lot of beacons like say in any muti floor shopping mall. In this situation how can I control these
Suppose someone clones a beacon and starts advertsing the signal with same UUID, major, and minor, how to prevent that and what are the other security measures that can be taken?
How to avoid mutiple notifications, suppose somewhere conflicted by two beacons any area is common to more than one beacons, how to control that in app?
The iBeacon standard does not provide any built-in ways to prevent cloning. Apple restricts iOS devices from seeing iBeacons except for ones where the ProximityUUID is known, suggesting this may have been a rudimentary security attempt. But since other operating systems (Android, OSX Mavericks, Linux) allow reading identifiers of all iBeacons, this restriction seems rather silly. It is possible to read identifiers using a tool like Android iBeacon Locate and deploy your own iBeacon with the same identifiers.
Four common approaches to address this:
Do nothing. This is appropriate for most use cases where cloned beacons will cause minor consequences or for low profile deployments where the risk of someone doing this is minimal.
Rotate the iBeacon identifiers. You can do this manually by replacing beacons or manually changing their identifiers periodically. This does not eliminate the problem, but it limits the risk and impact on time.
Use an automated rotating identifier combined with an automated system for validating/converting it to a trusted identifier.
Abandon the iBeacon standard and use a proprietary beacon technology using encryption. This should be considered a last resort, because this choice makes it impossible to use widely available open source and commercial tools for working with iBeacons, and locks you into a single vendor.
Before you choose any option other than the first, be sure you carefully evaluate the risk and consequences of cloning, and be sure any countermeasure you take is really worth the downsides.
The multiple notification problem described in the question is generally not an issue in the absence of intentional cloning. Simply design the ProximityUUID/major/minor numbers of your beacons to be unique for each event you wish to give to users and make your app respond appropriately.
For beacon clone:
customize your beacon firmware and encrypt major/minor with a random key. If beacon and app both can access to cloud, maybe exchange random key via cloud to encrypt/decrypt the major/minor id. If no cloud is involved, beacon and app need to deal with a random key generating algorithm, ex use time as a seed.
(Encrypt with a forever fixed key is useless because clone or replay beacon advertising data still can cheat app)
Rotate UUID with a predefined table-based list. This just reduces the risk with a periodically changing UUID but not really fix the security issue. And the UUID list has a limited size because all UUIDs in list may need to pre-register in App, ex iOS, to let iOS take it as a recognized region and then pass data to your App.
For Multi-notification:
Usually, this should be handled by App.
When enter a region or beacon trigger callback, app should check if it is a duplicated region by uuid-major-minor info. App should also check if it is related notification/info has been sent to user or not to avoid user be bothered by duplicated notification.
I recently purchased a Bluetooth 4.0 LE micro controller known as the Bluno. It's an Arduino compatible micro controller that has BT4.0LE built-in with no need for additional hardware. Anyways, I can program the micro controller to act as a central or a peripheral and same goes for the iPod Touch 5G that I plan on using to communicate with the device.
I initially thought that I should make the Bluno act the central and have the iPod Touch act the peripheral because the app I have written in Obj-c sends messages to a micro controller, and previously the micro controller we exhibit a behavior based on the message it would receive.
However when I look at the sample app written by the people who sell the Bluno they have the iDevice configured as the central, which makes me wonder because their app has the micro controller responding to what the user inputs into the app and then have the micro controller perform an action.
Needless to say I'm a little confused, any constructive thoughts would be appreciated.
The roles of the phone and the microcontroller really depend on what you're creating.
In the majority of cases though, the microcontroller has some sensors attached to it and that data is made available over bluetooth, and that is your "peripheral". Your phone app in the "central" role will read that data and likely have some user interaction based on that data.
This Apple doc explains it well: https://developer.apple.com/library/ios/documentation/NetworkingInternetWeb/Conceptual/CoreBluetooth_concepts/AboutCoreBluetooth/Introduction.html
In Bluetooth low energy communication, there are two key players: the
central and the peripheral. Each player has a different role to play
in Bluetooth low energy communication. A peripheral typically has data
that is needed by other devices. A central typically uses the
information served up by a peripheral to accomplish some task. For
example, a digital thermostat equipped with Bluetooth low energy
technology might provide the temperature of a room to an iOS app that
then displays the temperature in a user-friendly way.
I am currently developing an iOS app for a BLE device which will implement the Proximity Profile (which I currently don't have access to yet), but I am at a loss as to what that actually means.
I have read the pdf document from bluetooth, and know that the BLE device would be the proximity reporter and the application the proximity monitor, but what does that mean in terms of the CoreBluetooth framework?
After connecting to a BLE device, the method I am currently using to measure proximity is through calls to readRSSI on the peripheral device. Does a device which implements the proximity profile behave differently so that I don't need to make that call? There isn't much documentation around to give a better idea.
Here is a description of the GATT services related to the proximity profile: http://developer.bluetooth.org/gatt/profiles/Pages/ProfileViewer.aspx?u=org.bluetooth.profile.proximity.xml
It looks like it allows for an attribute to read the RSSI from (I think normally you can read that value from a lower level method directly from the transmitter/receiver). So you should be able to read the RSSI value on both ends of the connection.
The profile also allows for alerts to happen on both ends and you can control what level of alert occurs.
I think essentially, a "profile" is just a collection of attributes in GATT. If you have the required attributes you can state that you support that particular profile.
Here's a PDF with the little details if you want: https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=239392