I want to broadcast several BTLE beacons, preferably from a single bluetooth LE radio dongle.
Instead of buying multiple dongles, would it be possible to "pulse" say 5 UUID, major and minor broadcasts very quickly - every second or even half second on loop so that it would appear there were 5 beacons to a device?
I imagine it would depend on the scanning rate of the handset and other factors... but could it theoretically work?
Yes, you can do this. On iOS devices, I have only been able to switch identifiers once per second, making it only practical to simulate transmitting two iBeacons simultaneously without getting CoreLocation exitedRegion callbacks.
See: Can I broadcast multiple ibeacon signals from only one bluetooth? and how
Other BLE capable devices may allow faster switching.
Related
I'm dealing with the following challenge. In my system, there are two devices. Tags and anchors. Tags have BLE module with the transmit power 0dBm and not Long Range feature (BLE 4.0). Anchors have BLE module with transmit power over 8dBm and Long range feature (BLE 5.0).
I want tags to only receive some commands. Bi-directional communication is not necessary. This way, I can utilize the transmit power of anchor (8dBm) and thus quite bigger range, if tag with 0dBm is only receiving.
I read something about Observer/Broadcaster principle, where connecting is not necessary. But somehow devices have to agree on what frequencies should they hop on, the step and so on.
I'm asking, is it possible for device to only receive commands without previous negotiation with the sender?
Thank you very much for help. I'm beginning with BLE standard and there is a lot to learn.
Yes, it is possible to send data via adverts/scanning only. This way, there's no connection that needs to be established, and therefore no connection parameter negotiation takes place. As for the frequency hopping agreement - this happens via the baseband (in other words you will not deal with this in the software yourself) and is generally not applicable for advertising/scanning (these happen on 3 frequency channels only and therefore it is likely that the observer will catch what the broadcaster is broadcasting).
However, keep in mind that because you are broadcasting/advertising the data as opposed to directly sending it, that data can be received by any observing/scanning BLE devices which is not desired for safety/security/privacy purposes.
For more information on BLE communication, I recommend the links below:-
Getting Started with Bluetooth Low Energy
Is it Possible to Send Data with BLE Broadcast Mode
I am working with HM10 BLE chip with Arduino. I am able to establish serial communication between the two. In the manufacturer manual from jnhuamao.cn, it says that for AT+DISC? , "...Before V535 max results is 6, Since V535 not limit"
AT+DISC? is the AT command for scanning nearby BLE devices. The firmware for my chips are V539 and V540.
However, I am only able only received maximum 6 devices as scan result in the serial monitor. And they are different everytime. (I have 8 chips powered up nearby). Has anyone ran into the same problem? What could be the problem? What might be the solutions?
THANKS A LOT
the number of discoverable devices for hm-10 is 6 devices in one go.
its in their datasheet.
Even im facing a similar issue.
Im looking for something that will give me upto 20 devices in the scann results.
I would like to track a large number of beacons (~500) at once within a 50-100 m radius via an app on an iPhone (5s). I've had a look at the spec and online and I can't see if there is any limit on the number of beacons you can track at once using BLE. Does anyone know if there is limitation on the number of beacons you can track exists or if an iPhone 5s would be up to the task of tracking that many beacons?
You used the word track, but iOS has two different methods: monitoring and ranging.
You can set a maximum of 20 regions to monitor. (Found in documentation for the startMonitoringForRegion: method.) Region limits mostly come into play if your app is in the background. The OS will alert your app when you enter or leave a region that you're monitoring (give or take a few minutes). The OS will even launch your app just to let it know what happened (although only for a short time).
The other method is ranging, which is to find all the beacons within the Bluetooth range of the device (typically around 100 feet give or take). If your beacons are spread out over 100 miles, then you probably won't run into any practical limit here. I have not found any documentation for this, and I have only four beacons that I'm testing with, and four at a time works.
Here's one way to handle your situation. Make all your 500 beacons use the same UUID, and make a beacon region using initWithProximityUUID:identifier: method. (Identifier is just for you -- it doesn't affect anything). Starting monitoring for that beacon region. That way, your app will be notified whenever one of your 500 beacons are found (give or take a few minutes). Once notified, you can use startRangingBeaconsInRegion: to find all the beacons around that area, then use the major and minor values to figure out which beacons the user is near.
I'll add to Tim Tisdall's answer, which sets out the right framework. I can't speak to the specific capabilities of the iPhone 5s, or iOS in general, but I don't see any reason why it wouldn't return every ADV_IND packet (i.e. beacon transmission) that it receives.
The question is, will the 500 beacons be able to transmit their ADV_IND packets without collisions?
It takes about 0.128ms to transmit an ADV_IND packet. The time between advertising transmissions is configurable between 20ms and 10240ms (at intervals of 0.625ms), so the probability of collisions depends on the configuration of the beacons.
Based on the Poisson distribution, the probability of a collision for any given ADV_IND packet is 1-exp(-2*N*(0.128/AI)), where N is the number of beacons within range, AI is the time in milliseconds of the advertising interval (assuming all the beacons are configured the same), and the 0.128 is the time in milliseconds it takes to send the ADV_IND packet. (See http://www3.cs.stonybrook.edu/~jgao/CSE590-fall09/aloha-analysis.pdf if you want an explanation.)
For 500 beacons with the maximum advertising interval of about 10 seconds, there will be a collision about once every 81 packets (or about 6 out of 500). If you're willing to wait for a couple intervals (i.e. 30 seconds), there's a good chance you'll be able to receive all 500 ADV_IND packets.
On the other hand, if the advertising interval is smaller, say 500ms, you'll have a collision about 23% of the time (or 113 out of 500). You'd have to wait for several more intervals to improve the probability that you'd see the broadcasts from all the beacons.
The other way to look at it is that the more beacons you have, the longer you have to wait to make sure you receive all their packets. (The math to calculate the delay to receive the packets with a certain probability from the number of beacons and the advertising interval is too much for me today.)
One caveat: if you want to connect to these beacons, as opposed to just receiving the ADV_IND packet, that requires an exchange of two more packets on the advertising channels, and the probability of a collision in the advertising channels goes up a bit.
If I am reading your question right, you want to put all 500 iBeacons within 100 meters of each other, meaning their transmissions will overlap. You will probably run into radio congestion problems long before you run into any limitations of iOS7 or your phone.
I have successfully tested 20 iBeacons in close proximity without problems, but 500 iBeacons is an extreme density. this discussion on the hardware issue suggests you may run into trouble.
At a minimum, the collisions of the transmissions of 500 iBEacons will make it take longer for your iOS device to see each iBeacon. Normally, iOS7 provides a ranging update once per second for each iOS device, but you may find that you get updates much less often. It all depends on your application whether or not less frequent updates are acceptable.
Even if delays are acceptable, I would absolutely test this before counting on it working at all. Unfortunately, that means getting your hands on lots of iBeacons.
I don't agree. It is true that ble beacons only transmit advertising data, but the transmission of such data last about 3ms (considering three advertising channels).
Having 500 beacons, WITHOUT considering any collision, the scanner will takes 1.5s to see them all.
But, if all beacons are configured in same way (same advertising interval) it is inevitable to have collisions which lead to have undiscovered beacons. Even if the advertising interval is different between beacons collisions occur. To avoid collision probability one should use longer advertising interval, but this lead to longer discovery latency.
This reasoning is very raw, it doesn't take care of many effects, but is just an order of magnitude calculation.
By the way, the question is not easy, there are many parameters which play role, some are known some are unknown. But I'm working with ble since one year about and, to me, 500 is a huge number and there is the possibility that you don't see the majority of nodes because of collisions.
I was doing some research into iBeacon's because of this question (I had no idea what it was about).
It seems that on the "beacon" side of things all that happens is general advertising packets are sent out. It's similar to how a device advertises that you can connect to it. However, you don't actually connect to iBeacon's, it just reads those advertising packets. There's no built-in limitation on how many advertising packets a device can receive.
So, it wouldn't surprise me if 500 iBeacon's would run with no issues. The advertising packets are small and are spaced out (time wise, they are repeated every X ms). There's no communication going from the phone to the iBeacon, the phone is simply receiving the packets it hears. If there's interference on one packet it'll likely manage to get the next one.
I built a robot from a thin client pc (can run Windows CE or Linux) and two servo motors. I put USB ends on the servo motors, so when they are plugged in to the thin client they continuously run. In Linux, how could I set the amount of current or voltage going from the USB ports to the servo motors? Would I be able to run a shell script to set the power of a certain USB port to slow down a motor or stop one? If this cannot be done through software, what is the easiest way to do this through hardware without having to buy too much?
The USB voltage is fixed at a nominal 5 volts and cannot be controlled.
The behavior of USB devices regarding their current draw is well defined in the USB specifications. USB devices are supposed to draw up to 1 unit load (100mA) unless they have negotiated a higher load from the USB host. It's quite likely that the servo motors that you have are going to need to draw higher currents than that, and wouldn't be able to request it without being a USB device and negotiating with the host.
It's also likely, depending on the servo motor that you are trying to control, that you'll need to either provide a PWM signal or an analogue voltage to control motor position. USB hosts are not intended to provide either of these.
Your best options to drive your motor from your PC are:
Get a dedicated USB controller for your servo motor (if one exists)
Make your own, based on a small microprocessor (eg. using an arduino)
Choose a different port on the PC. If available, PC parallel ports can be controlled to provide control for motor drivers.
The answers here seem to say it is a hardware issue, but I think this is a software issue. ASUS has Ai Charge which more then doubles the volts to charging Apple products from a standard 2.0 usb port.
USB 1.0, 2.0 and 3.0 Specs (All at 5 volts) 4 Wires (2 Data and 2
dedicated power)
Voltage Breakdown: USB 1.0 and USB 2.0 = 0.5A or 500 mA = 2.5 watt
USB 3.0 = 0.9A or 900mA = 4.5 watt Wall wart = 1.5A or 1500 mA = 7.5
watt Ai Charge = 1.2A or 1200mA = 6 watt
Ai Charge works on ASUS and non-ASUS motherboards and is a program you can install in Windows.
Personally I HATE Apple so I want to figure out a way to do this 1.2A usb 2.0 output trick for my netbook while running Linux.
I don't believe it is possible to directly manipulate the USB voltages. They are designed to provide a +5V output at all times unless power is diminised with other hubs.
You might be better served posting this question on http://electronics.stackexchange.com
you need to use PWM to control motors speed, to do that you need a micro controller, PIC18F series supports USB communication, there are plenty of code samples available internet how to use USB in PIC18F series, also you need a transistor array or H-Bridge to control mortors from PIC.
The simplest way to communicate is, program a USB serial in PIC18F micro controller, and when you plug that 18F to your computer, it will detect USB serial port, so you can send the commands to serial port to control speeds.
I dont think its possible, and even if it was, consider this: The USB port is not suposed to power motors because you can burn the USB port. USB is limited to 500mA (or there abouts) and any power device like a motor can potentially require more than that.
Another thing is that servos should be driven with constant voltage, and the speed is controlled by timing impulses on the control wire.
http://en.wikipedia.org/wiki/Pulse-width_modulation
You should use a driver (hardware) to power the motor with an external power source.
This is transistor's purpose, or try with a potentiometer
I am designing an information kiosk and need a BT application which can automatically push a file to the nearest BT enabled device assuming that this would be the phone of the person currently standing in front of the kiosk.
Is there any other ways of doing this except by checking the RSSI (Received Singal Strength Indicator)?
Do all Bluetooth stacks support accessing this property?
How accurate is RSSI as the basis for the decision to which device to push to? Can it be that other phones which are further away from the kiosk can emit a stronger signal than the signal coming from the phone of the guy standing right in front of the kiosk?
Not all stacks support RSSI.
There's an alternate way: the device who first answers to Inquiries should have a stronger signal.
Your guess is true, it only depends on signal strength, not distance.
Also, the device with the stronger signal is not necessarily the one which answers first, since implementations of the protocol are different among devices. Thus you would have to test all target devices separately.