How to send information via Bluetooth LE 4.0 using CLBeacon UUID, major and minor identifiers?
According to CoreBluetooth documentation the maximal distance is 15 m, but as for iBeacons technology it's ranged up to several tens of meters.
You cannot transfer any data in an iBeacon transmission other than UUID major and minor. No other fields can be sent and received by apps in iOS.
The range of iBeacon transmissions are basically the same as regular Bluetooth LE transmissions because iBeacon transmissions ARE Bluetooth LE transmissions.
Because iBeacons are one way transmissions they may be more workable at the very end of the range of BLE, because they can still work if 80 percent of packets are lost.
While you could design your own one way BLE transmission using advertisements, an iOS app would not be able to read the encoded fields because iOS disallows access to the raw advertisement data.
Related
I would like to create the indoor positioning system. I hope the system can collect all beacon signal and create map automatically. However, I know that far away beacon maybe cannot detect. Therefore, is that possible to discovery far away beacon based on other beacon? That is, beacon can transfer their signal based on other beacon?
Sorry, but no, it is not possible to use a beacon to relay signals of more distant beacons. Bluetooth beacons are extremely simple devices that just transmit a unique identifier. They are transmit only, and therefore completely unaware of other beacons around them.
My beacon tags are broadcasting ibeacon,TLM,URL and UID at a time with different different frequency.
I am not clear about these slots.
I am using beacons for tracking purpose only so don't need to consume all slots data.
What is the simplest way to configure beacon only for detection of his presence only.
Just use either the UID slot or the iBeacon slot for this purpose and turn off the other slots.
Use iBeacon if building an app for iOS and you need fast detection in the background. (iOS is optimized for iBeacon in this mode.)
Eddystone-URL is useful to transmit a website URL on the beacon itself so it can be displayed in nearby Google Chrome browsers configured to detect these beacons.
Eddystone-TLM is useful for knowing the battery level of your beacon (if battery powered) as well as its temperature if that is useful to you.
I am using Estimote beacons to determine if something moved. This is done by monitoring which beacons are in range (MonitoringListener) and which beacons have moved (TelemetryListener).
The problem is EstimoteTelemetry has a field UniqueId but Beacon uses UUID, Major and Minor to determine the unique beacon. EstimoteTelemetry does not broadcasat UUID, Major and Minor..
I need to know which beacon is broadcasting the telemetry packets. I can't see any fields that are the same in both. Anyone know how to do this on Android or iOS?
As you mentioned there are no data fields in the BT packets that are shared among iBeacon and Telemetry packets. These are completely independent packets and contain different set of information. It is not possible to use iBeacon identification in telemetry packet - it takes too much space so telemetry data would be extremely limited.
If you need to collect both packets and keep them together look-up table in your app/server is the only solution. Estimote does not provide this kind of functionality.
Each Estimote beacon has single non-changing identifier (16 bytes) assigned during production. Telemetry packet contains first half of it (8 bytes). You need to create table where this 8 bytes are related to exact iBeacon identification you use.
(how) Is it possible to have the Eddysone-URL provide functionality, similar to NFC, that would have the user only within a close proximity be able to get the URL?
I've been testing using the eddystone-beacon library on the Intel Bluetooth 4 enabled Wifi card to send the signal successfully. But I find that I can receive the signal from far (20+m) away, when I'd like to limit it to within one meter.
The library has options to attenuate the power txPowerLevel: -22, // override TX Power Level, but I find that changing this only messes with the distance calculation, and not the ability to receive the signal.
Is this perhaps an issue with the hardware (maybe a dedicated USB would allow control?)
Eddystone-URL is not designed to work this way using Google's standard services. However, it is possible to do what you want if you have a dedicated app on the mobile device that detects the beacon.
If this is an option for you, then you won't want to reduce the transmitter power on your hardware device. Even if you get hardware that allows this, sending a very weak signal will lead to unpredictable minimum detection ranges of 3 feet or more on devices with strong receivers, and not detections at all (even if touching the beacon) on devices with weak receivers.
Instead, leave it at the maximum transmission power and then filter for a strong RSSI on the receiving device, showing the detection only when the RSSI meets a threshold. You'll still have trouble with varying strengths of receivers, but it is much more predictable. I have used this technique combined with a device database that tracks the strongest signal level seen for a device model, so I know what RSSI a specific device model will detect when it is right next to the beacon.
If you are game for this approach, you can use the Android Beacon Library to detect Eddytstone-URL for your app on Android devices and the iOS Beacon tools on iOS devices.
I'd like to modify the SensorTag Software from TI for the CC2650STK kit, so that it speeds up the reading and also the transmission of the sensor values.
Do I need to modify only the Sensor Software (CCS BLE Sensor stack from TI) or also the android app?
I'd principally need only one temperature, so other sub-question is: how can the other sensors be deactivated if not needed or if they conflict with the higher speed of the temperature sensor?
What do you mean by "speeding up"?
There are a number of different things you might mean.
Reduce the latency between opening the mobile app and displaying a
reading.
Refactor the mobile app to make it simpler to get new
readings.
Increase the frequency with which notifications are sent
by the device, if you use it in that way.
Change the firmware interaction with the sensors to obtain a reading.
Each of these meanings entails a different approach.
The period for each sensor is described in the User Guide that you reference and is typically between hundreds of milliseconds and one or two seconds. Do you really need readings more frequently than that? Typically each sensor will need an amount of time in order to obtain a reliable reading. This would be described in the sensor data sheet, along with options for working with the sensor.
More generally 'speed' will be a function of the bluetooth handshake, the throughput available over the physical radio link, the processing within the sensor tag and the processing within the sensors. I would expect the most variable part of this would be the physical link.
It is up to the mobile app to decide which sensors services it wishes to use.
Have you studied the Software Developer's Guide, available at the same page as the BLE Stack?