What is the maximum number of transmitting beacons in the same room? Is it possible that there will be collision? How can be modified the ibeacon firmware to prevent wrong behaviour?
We build and test iBeacons at Radius Networks, so we often have many transmitting simultaneously. I have witnessed iOS and Android devices ranging several dozen at the same time.
There is no hard limit in the operating systems and detection libraries. You may begin to run into trouble when several hundred are visible simultaneously because your software might slow down when hundreds must be processed every second. (Better make sure your code is fast!) Also, radio interference will begin to become problematic with many hundred transmitting in the same place. See this discussion.
An iBeacon itself is a transmit-only device, so it doesn't really care how many other devices are around. No matter how noisy the room gets, it will just keep transmitting. There is therefore not anything you need to do to iBeacon firmware "to prevent wrong behaviour".
Sfavilla, I develop beacons at Gelo and can confirm David's answer. We've seen a few hundred in a single location work fine. We've also seen some older iPod Touches crash more often and intermittently miss beacons.
There will be a lot potential collisions where interference is caused an an advertisement from one beacon will be ignored. I've seen a lot sniffing the airwaves finding all of the advertisements that fail CRC checks. The more beacons you have the more errors that will exist.
Bluetooth Low Energy however is designed to be robust and work in these kinds of environments so all is not lost.
The biggest issue I've seen with processing advertisements is the fact that CoreBluetooth more likely crashes before your code becomes an issue. Apple I believe is working to fix that. CoreBluetooth also doesn't crash the same across iOS devices. I am guessing there are varying degrees of memory allocated to CoreBluetooth and its cache because iPhone 5s and above work way better than iPod 4s and older iPod Touches.
Related
(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'm sure we have all heard of apples iBeacon by now... We've been working on a few projects using the technology and have been wondering about one usage that I have seen others promoting.. that is using the LE Bluetooth radios to create a dwell time heat map in a space...
The concept sounds simple enough place a LE Beacon in an area and as people pass by it 'counts' that person which is then overlaid over a store map to create traffic patterns.. that's the claim. I'm trying to figure out how that can be possible?
The concept uses the mobile device on the passerby as the 'trigger' for the count. There is no way at all to achieve this with out the user having a certain app downloaded on their device correct? The only feasible way I can see it working is if the user has an app downloaded on their device and that app pings a web server every time it sees a beacon.. that is then mapped.. but that also will use data and battery resources on the mobile device which most likely will result in the user deleting the app before long...
This also leaves a large number of passers by who will not be accounted for... making the results very difficult to quantify.
Am I wrong in this assumption? Is there something that I'm missing?
Your analysis of the possibilities and challenges of the technology are largely correct. My company, Radius Networks, has done similar traffic visualizations for large events.
A few points:
Even if most users do not have an app on their phone, the data are still valuable if there are enough to provide a representative statistical sample.
When using iBeacons for this purpose, you must have quite coarse grained locations for two reasons:
The range of Bluetooth LE is about 50 meters.
Assuming the users will only be passively running the app in the background, beacon detection can take minutes on iOS.
Combining the two challenges above, you can really only use the technology to do this for very large venues.
The battery drain is not really a problem if the phone only wakes up every few minutes to report a beacon detection to a server.
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.
I have a thought, but am unsure how to execute it. I want to take a somewhat long usb cable and plug both ends into the same machine. Then I would like to send a signal from one end and time how long it would take to reach the other end. I think this should cause signal to arrive at different times and that would cause me to get random numbers.
Can someone suggest a language in which I could do this the quickest? I have zero experience in sending signals over usb and don't know where to start or how to start. Any help will be greatly appreciated.
I simply want to do this as a fun in home project, so I don't need anything official and just would like to see if this idea can work.
EDIT: What if I store the usb cable in liquid nitrogen or a substance just as cold in order to slow down the signal as much as possible (I have access to liquid nitrogen).
Sorry I can't comment (not enough rep), but the delay should always be the same through the wire. This might limit the true randomness of your numbers. Plus the acutal delay time in the wire might be shorter than even a CPU cycle.
If your operating system is Windows, you may run into this type of issue:
Why are .NET timers limited to 15 ms resolution?
Apparently the minimum time resolution on Windows is around 15ms.
EDIT: In response to your liquid nitrogen edit, according to these graphs, you may have more luck with heat! Interestingly enough...
Temperature vs Conductivity http://www.emeraldinsight.com/content_images/fig/1740240120008.png
I want to take a somewhat long usb cable and plug both ends into the same machine.
Won't work. A USB connection is always Host -> Device, a PC can only be Host. And the communication uses predictable 1 ms intervals - bad for randomness.
Some newer microcontrollers have both RNG and USB on chip, that way you can make a real USB RNG.
What if I store the usb cable in liquid nitrogen or a substance just as cold in order to slow down the signal
The signal would travel a tiny bit faster, as the resistance of the cable is lower.
I installed some APs at a facility. This facility is now complaining they are having issues with their 2.4 phone system.
The APs that I installed (different SSID) are running but no clients are associated or transmitting data.
Is it possible to cause co-channel interference without data being transmitted?
Thanks
Yes, 802.11 access points are chatty, users or no. You can expect every access point to transmit beacon frames on the order of 5-15 times per second.
These frames are transmitted very quickly and 2.4 GHz is generally very noisy, so I have difficulty believing that a 2.4 GHz phone system would fail in this scenario -- at least, assuming you didn't install an AP right on top of the phone system. Any device transmitting +20 dBm a few inches away from a device listening for -90 dBm signals could easily cause problems. Similarly, 2.4 GHz devices don't actually operate on 2.4 GHz the entire signal path; it's generally shifted down towards baseband at something like 100 MHz, and sometimes (particularly with high-power APs) this section is poorly shielded, and this leakage can cause issues even outside the target frequency band.
That said, none of that really matters for troubleshooting. The line of questions I would pursue is: does the problem go away if you shut off all your devices? If so, does it go away if you shut off one in particular? If so, what makes that one special?