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.
Related
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.
(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 noticed that a beacon didn't detect it's own transmission. Did that mean that the beacon alternate between the transmission and the scan, and turn off the transmission when it scan? If yes, did that affect the transmission rate, even a little bit, if I am using a transmission rate of 10Hz ?
No, transmission does not affect scanning. Bluetooth radios are designed to both scan on multiple channels (slightly different frequencies) and transmit on those same channels. There is a channel hopping mechanism that governs this.
Devices by design are not supposed to pick up their own advertisements in scans. This is a separate issue than described above.
How can I receive a time signal with an unmodified RTL-SDR USB TV Dongle here in Europe?
RTL-SDR Dongles are able to receive the frequency range 52-2200MHz.
Here in Europe, radio-controlled clocks receive DCF-77, a time signal broadcast on 77KHz, but as 77KHz is a bit lower than 52MHz, that's out.
The GPS L2 signal is at 1575.42 MHz, so that's within the dongle's range, but the signal is way too weak to be received with the TV antenna. An active GPS antenna is needed, and for providing the antenna with the power, I'd need to make some modifications to the electronics which I don't really want to do.
In the old age of analog TV broadcasting, we had Teletext / Videotext here in Germany, which contained a time signal, but these times are long gone.
ADS-B reception with a dongle works like a charm, but unfortunately they did not put in time or date bits into the data packets.
So: Does anybody have any idea where in the spectrum that can be received by an unmodified RTL-SDR dongle there is a time signal that could be easily decoded?
I'm well aware that getting time over the network via NTP, or via a GPS modem via NMEA 0183 would be way easier, but I'm curious and just want to play around with that dongle a bit. Precision is not important. +/- 2 seconds is fine. And I'd like to do it the SDR-way, so using the dongle in the originally intended way (as a DVB-T receiver using the original software) defeats the purpose (i.e. learning and DIY)
The GPS L2 signal is at 1575.42 MHz, so that's within the dongle's range, but the signal is way too weak to be received with the TV antenna. An active GPS antenna is needed, and for providing the antenna with the power, I'd need to make some modifications to the electronics which I don't really want to do.
Well, first of all, GPS is really weak, but it still works under the noise floor; that's something important to realize – I've seen it more than one time that people are worried because they can't see GPS on a PSD display. You won't; you'll need signal processing to recover it from all the noise.
The modifications aren't all that complicated; basically, you need a capacitor to let through the AC component to the RTL dongle, and a voltage source to feed the active antenna; the required component is usually called a bias-T.
Nevertheless, an active antenna will be necessary – your RTL dongle probably won't have a Noise Figure low enough to receive GPS signals on its own.
In the old age of analog TV broadcasting, we had Teletext / Videotext here in Germany, which contained a time signal, but these times are long gone.
True; haven't looked at local FM stations, but RDS might be the way to go – it can contain a clock/time signal; the German Wikipedia claims that mainly publicly owned stations transmit that information field.
Have a look at gr-rds; it's a GNU Radio implementation of the Radio Data System. If you don't have a working GNU Radio installation (yet), you might try out the GNU Radio LiveSDR Image, which contains a ready-to-use gr-rds.
We are discussing a large scale deployment scenario with iBeaons in several locations cross-country. The question was raised as to whether the IDs with which iBeacons advertise their presence is unique? Because our client wants to be really sure that the app only responds to a specific iBeacons and not to something else that's impersonating with the same ID (even if inadvertently).
If not unique, does the protocol allow iBecaons to advertise any additional authentication information?
It is absolutely possible to impersonate another iBeacon. I went to the Apple Store in Washington DC with a copy of the Android iBeacon Locate app, and used it to scan the identifiers of the iBeacons in Apple's store. I then went back to my office and configured my own iBeacon to transmit this same three-part identifier, and was able to make my iPhone get the same in store messaging from Apple. You cannot stop other people from doing this if they really want to. But the good news is that for most use cases, there isn't a real motivation for other people to do this.
That said, an inadvertent overlap of iBeacon identifiers is extremely unlikely. If you generate your own ProximityUUID using a standard UUID generator, the odds of another generated ProximityUUID being accidentally the same are infinitesimally small -- less than the odds of being hit by a meteorite.
Standard iBeacons do not have any other authentication mechanism. They are connectionless, transmit-only devices that only send out a three-part identifier (Proximity UUID, Major, Minor) and a transmitter power calibration value.
I work on the beacons at Gelo ( http://www.getgelo.com ). Payload confidentiality and anti-spoofing are very large concerns with a few of our customers.
UUIDs themselves are not guaranteed to be unique. It is entirely possible to spoof an UUID and all of their advertisement data (including major/minor). This presents a number of security risks.
There are rotational UUID schemes that some beacon manufacturers employ in whice every X minutes, seconds, or hours the UUID itself is changed. This would mean that someone wanting to intercept and/or spoof the beacon would need require either being in the same location as the original device and constantly matching the new values or figuring out the rotational scheme or algorithm.
The problem with rotational UUID approach is that it doesn't protect the payload (the advertising message or the scan response) so an attacker could mimic another beacon and change the value(s) being sent. Based on what the beacon communicates and how it's used by any listening devices (observers, centrals in BLE terms) or consuming applications this could not be a problem or it could be a very large problem.
We've spent time researching how-to mitigate the risk at all levels while taking into account power consumption. This is because most BLE beacons run on batteries and you want to extend the battery life as much as possible. We've come up with an approach that successfully mitigates the risk for an international organization with nearly 100k locations.
Solving this problem is possible and it's something that we've been working on. If this is what you're looking for give Gelo a call or email. We may be able to help you.
There is definitely no "UUID anti-spoofing" in place in iBeacon technology. In fact, many developers make the situation even worse and just use the default UUID provided by the iBeacon vendor. As a result, whenever you go - lets say - around an Estimote iBeacon, you see an app that is not valid in the current context, therefore just adding to users' confusion.
You can help preventing this issue and keep the environment cleaner by using globally unique proximity UUID generator and catalogue for your deployment.
See our OpenUUID service, that aims to do exactly that...
iBeacon ids are 20bytes (16 byte UUID, plus a 2-byte "Major" number and a 2-byte "Minor" number). The odds that someone will guess or accidentally choose all 20 bytes exactly the same AND be in range of the same beacon at the same time are extremely small. The combination of the near-unique number and relative short range of the BLE signal make an accidental collision pretty unlikely.
In addition to sensing the above mentioned parameters you can usually get info about the beacon mac address. If it´s based on any of the more common circuits such as the TI CC240x chips the MAC address is hardcoded unique to every chip. So that one is less easy to spoof.
One typical idea if you are both beacon deployer and app provider is to program some custom service/characteristic into the beacon as well so that your app can connect to it and verify it´s a known beacon. BUT if you at all allow someone to connect it means the beacon is extremely sensitive to a Denial of Service attack. Most beacons are single tasking and cannot radiate and id and handle a connection attempt at the same time. So some dark force could install "beacon timewaster modules" in the vicinity that keeping your beacons busy talking to a waster rather than providing the id radiation you want them to. Those rotating UUID schemes may be good enough in a hostile environment. For the most part I would say the beacons are likely to work pretty much undisturbed. It is very easy to develop a beacon quality monitoring app or custom BLE device that will keep listening for deployed beacons and report on the uptime. That way a deployer of a deployed farm of beacons will be alerted if a node goes out of service.