Am working on a BLuetooth Low energy module embedded in a custom board . whenever i press an interrupt (push button) the ble module advertises some number once and goes to sleep ,again when interupt given it advertises the next number(incremented value) once and goes to sleep .These values are scanned in a custom android app running in nexus 5.Though the phone is scanning most of the packets ,sometimes it fails to capture some datapackets.the custom board advertises once and goes to sleep ,the phone must be able to capture this advertisement packets,but some times it miss the data packets. So my question is Is it normal that the BLE compatible phones cannot capture all datapackets from a pheriperal device i.e there may be loss of some data packets.Or is it the problem with smart phone nexus 5 ble hardware.
BLE is transmitting with low power on in a crowded spectrum. Some packet loss is to be expected (though I agree it is more than I'd like).
A higher level protocol will detect packet loss and request retransmission. In the case of BLE, instead of using advertisments for data you can actually connect to the device and then use notifications. These are far more reliable and shouldn't be dropped. The downside is most devices only support connecting to a handful of peripherals, usually 7. Listening for advertisments doesn't require connection and therefore there's no fixed limit to the number of advertisers you can listen to.
The packet loss also depends on what is listening. A nRF51822 trasmitting to my Nexus 4 with Android 5.0 at zero range gets >50% PLOS. When transmitting to another nRF51822 it gets around 20% PLOS. I guess the Nexus 4 tries to save power so maybe it doesn't listen continously.
I had a similar problem, that only some data packets were arriving. It seems that enabling the SCAN_MODE_LOW_LATENCY mode with ble scanner helps - your device will keep listening continously, so no data will be missed (unless there is clutter, bad range etc. like Timmmm suggested).
https://developer.android.com/reference/android/bluetooth/le/ScanSettings
hope this helps
Related
My app is sending some data via bluetooth socket using Serial Port Profile, and the other device is Microchip's BM78 module.
Everything is working fine except one very particular case when testing with Huawei NEM-L21 phone. The data delivered correctly right after connection is made, or if data frames are sent frequently. But if there's a pause of 5-10 seconds between transfers, then the next transfer will get the beginning of the data blob altered. The first two blocks of approximately 650 bytes each is swapped, like if it was buffered before sending, and the second buffer gets transferred before the first one. The rest of the blob is ok.
I have no explanation for that. I've excluded BM78 issues, it's working totally ok with windows (virtual com port for bluetooth), and with a bunch of other android devices. It's only this particular phone that shows this issue.
So, is that just a bug in the phone's firmware, or there's something about bluetooth that's missed my attention? Like maybe power management options I can tweak in the phone? Anything related to Bluetooth in general?
I have been doing a ton of research on this project I want to do, probably read every SO post (bluejacking, RFCOMM, beacons, etc...) and my head is spinning.
I want to create a system at home, using Arduino (with bluetooth le) that will scan bluetooth and detect when my phone or any of my family members phones are in proximity. Whether this is a MAC scanner or simply getting the friendly name. I would also like to get the RSSI. I dont need to do accurate distance measurement but I would like to know approximately how close they are. Does anybody have any suggestions for this approach? I know I can create an app on the phone and have it become a beacon and this may be an option but I am concerned with Android, it would have to be Marshmallow 5.0 at a minimum. I would like support to be a little lower than that, like JB or KK. So, it seems like there should be a simple scan, just looking for the MAC or name. That is all I really need.
That said, the main question I have is, can you scan for and see bluetooth devices in range if they are already paired to something? Like a Bluetooth headset? I understand bluetooth is point to point but does it allow multiple connections or at least broadcast the mac or name when paired?
This question, along with any general suggestions will help me out tremendously!
Thanks!
Bluetooth Discovery from the Listener involves Listening for Bluetooth Inquiry packets(RX) and inquiry response (TX).if done continuously this will deplete the battery. Hence most devices (including Mobile Phones and Headsets) has a policy of when to be discover-able and connectable. Headsets in particular are discoverable only when they are instructed and connectable until one device is connected to it ( There are probably exceptions where the headset has the capability to be connected to multiple phones at the same time). Most Mobile Phones are discoverable only when they are in settings screen ( Android,IOS and Windows Phones), but unlike the headset case they are connectable.
so one option with the MobilePhone is to see if it is possible to connect to them after pairing once ( for example by trying a service search on the remote device and see if it returns the service attributes, this internally makes a connection and indirectly ensures the presence of the device).
if you are specific about a mobile phone which is already paired then you might need to establish a higherlayer connection ( such as SPP) with Authentication and encryption. This would force a two way check between devices to see whether they are already paired. other less secure option is to rely on the Phone (Android and IOS phones doesn't generally Allow a higher layer connection without encryption/pairing) and try to establish an SPP connection to the phone.
Another option is to use Bluetooth-LowEnergy. But Note that security in BT was superior to BLE till BTv4.1 and same on BTv4.2.
I'm developing a Bluetooth low energy application to connect with a device which will be sending 20 byte long transmissions in notification mode in intervals of 6 milliseconds or more.
So far the application is working fine. It can scan, discover and then subscribe to the characteristic to receive data notifications. The issue is that for the first 2-4 seconds the data will be read nicely in a sequential order but after that the notification data starts to appear in bursts or as in chunks of data but not in consistent intervals between each transmission.
This doesn't happen when i check the data transmission with the Texas Instruments BLE evaluation kit, there my reader shows a perfect transfer with not bursts appearing. Only on android it's become visible.
Could this be an issue that can be configured to fix in android side?
Could this be a problem with the high transmission rate (~milliseconds intervals)?
Thank you..
So it sums up to that optimal throughput can be achieved with the proper configuration of connection parameters for the BLE connection. It is usually done at the peripherals end and may have to differ for the platform connecting to (i.e. IOS , Android may have different connection requirements..)
P.S. : Since i was looking at android found this method documented here https://developer.android.com/reference/android/bluetooth/BluetoothGatt.html#requestConnectionPriority(int) which is calling for a connection priority( CONNECTION_PRIORITY_BALANCED, CONNECTION_PRIORITY_HIGH or CONNECTION_PRIORITY_LOW_POWER) But I didn't test it.
You could try to enable Bluetooth HCI Snoop Log in Developer Options and then view the log file in WireShark. Look for connection update commands, these can be issued by either side of communication. This command change the transmission settings and slow down the transfer. Also look for GAPROLE_PARAM_UPDATE_ENABLE in your TI BLE app.
Yes Michael we use CC2650 and for our requirement BLE is sufficient bur I'm not sure if it really supports bluetooth classic (http://www.ti.com/product/CC2650/description) .
You can try playing around the BLE connection parameters to get the setup tuned, that's what we did other than trying to build the app giving priority to BLE operations.Take a look at this for more information on connection parameters.
https://devzone.nordicsemi.com/question/60/what-is-connection-parameters/
You can't configure the connection parameters on the phone but the peripheral(i.e. SensorTag) even so there's not guarantee that the given parameters will actually be accepted by the central device in case will settle with a set of parameters accepted by the central device. (Android and IOS have different policies in terms of these..)
In our case we are transmitting in intervals of 15ms and seems quite stable. But all these high frequent transfers at the cost of the low power consumption capabilities of BLE which is really what it is intended for. We could go even below that close to 7.5ms which is the minimum connection interval supported by Android. Our initial tests were stable but reliability of such a low latency is questionable.
How can a device identify the other devices to whom we need to send data and transfer the data to other device.
If the device1 send the data to device2, will other device say device3 near to them will receive same data?
Please read up on the whole Bluetooth story. You seem to have problems with basic concepts. Also, it would probably help to be a bit more specific in your questions for example specifying which BT version are you referring to.
For identifying the devices, each of them has a separate address. They even have human readable names. (Look at the Wiki page linked above Connection and communication) Also, during the pairing process, you should have to get to know and explicitly allow the devices which you really want to communicate with, the goal of the process is exactly to make sure to have an explicit authorization between the devices for communication.
Yes, device3 will receive the radio signals, but if not authorized, it won't be able to tell what is going on - unless it is a misbehaving device cracking the encryption... (Given the communication is actually encrypted, that is.) Reading the Security Concerns part is also useful.
Bluetooth can connect up to eight devices simultaneously. With all of those devices in the same 10-meter (32-foot) radius, you might think they'd interfere with one another, but it's unlikely. Bluetooth uses a technique called spread-spectrum frequency hopping that makes it rare for more than one device to be transmitting on the same frequency at the same time. In this technique, a device will use 79 individual, randomly chosen frequencies within a designated range, changing from one to another on a regular basis. In the case of Bluetooth, the transmitters change frequencies 1,600 times every second, meaning that more devices can make full use of a limited slice of the radio spectrum. Since every Bluetooth transmitter uses spread-spectrum transmitting automatically, it’s unlikely that two transmitters will be on the same frequency at the same time. This same technique minimizes the risk that portable phones or baby monitors will disrupt Bluetooth devices, since any interference on a particular frequency will last only a tiny fraction of a second.
So what if they interfere and there is a erroneous data, the receiving system simply discards it based on correcting bits of the packets transffered.
Bluetooth devices have a parameter or option called visibility. When you enable visibility, then the bluetooth device starts
publishing its presence within the bluetooth frequency range. This presence can then be detected by any other bluetooth device which can connect to this device when
it scans the above bluetooth frequency range.
As they use spread-spectrum frequency hopping described above they
publish data to all receivers but only the intended receiver with whom
the sender is connected will have the key to unlock the data.
i have been reading about proximity security devices through bluetooth, but i am wondering how it works in reality. As far as i have been reading, there are two techniques:
constant scanning from a master. The central device scans the target device every x minutes. When the target is into range, it gives back MAC bluetooth address and RSSI. The negative side is that being constantly into discoverable mode drains the battery, so does the master device that has to be constantly scanning for devices.
Paired and connected. As some product details: "Your laptop locks itself down when you step a certain distance away, and opens again once you're in range". It means that after paring and connected processes, the master can have information when the slave device is out of range, or get inside range again. In bluetooth 4, is going to be even as a profile.
Regarding to the second option, which feature is this? how it works? i mean, maybe you can code a sequence number counter that counts everytime the slave sends a packet through RFCOMM every x milisecs (android or ios), but what i dont understand is how a slave can connect to master again in a transparent way, when normally two bluetooth devices disconnect when they are out of range each other (so you cant send information again from the same bluetooth socket RFCOMM connection).
How proximity devices works in reality? how can you code it?
Bluetooth 4.0 (BT Low Energy) is a whole other animal than traditional Bluetooth. It is designed from the ground up to be good at things like the Proximity profile you describe. Basically a computer and a fob create a connection to periodically communicate at a slow interval, say once every 5 seconds. When you go out of range the connection drops due to a timeout and the PC knows the fob is gone. The PC side isn't power constrained, so it can constantly or periodically scan for the fob when connections are dropped. The fob can advertise its presence using infrequent advertisement packets, which costs only a small amount of power.
Note that there is no RFCOMM in BT LE. Android and other BT stacks currently lack BT LE support because it is too new. Only a few devices exist which actually use BT LE, so getting much real info is hard right now. In a few years this will be much bigger. The new iPhone 4S and new macbooks have the 4.0 BT chips, so you can expect more usage soon.