I have a question regarding the bluetooth LE protocol.
I have an Android Device and a peripheral device.
Looking at the transmission with a sniffer and wireshark there is +/- every 40ms an empty PDU message. As I understood the protocol this means the connection interval those device chose is 40ms.
For testing I am using a simple "UART" application where the android device enables the notification on an antribute of the peripheral device and gets notified whenever the attribute changes.
Now, if I "send" multiple 20 byte packets through this setup, wireshark shows me, that those value notifications are just about 7-10 ms apart. Each Notification contains 20 Bytes
Does that mean, that the connection interval does not apply for notifications and that each notification can hold max. 20 Bytes?
Thanks & Greetings!
There is one connection event per connection interval. In each connection event multiple packets can be sent directly after each other. When no side has anything left to send, the connection event is closed and next exchange will occur at the next connection interval point. So yes, many notifications can be sent in one connection interval.
Related
👋
I'm researching for a PoC that users would have a mobile app (Android and iOS) connected to a Bluetooth device. Users would lock their cellphone, put them away (close enough for keeping the Bluetooth connection) then the mobile app would stream (broadcast the Bluetooth packets) to an HTTP endpoint.
The mobile app would behave like a hub broadcasting Bluetooth packets.
The stream should last for about 1 - 2 hours.
Would that work or Android and iOS eventually terminate the app?
On iOS, it seems like if you enable Bluetooth-LE related background modes [1], you should be able to "handle important central role events, such as when a connection is established or torn down, when a peripheral sends updated characteristic values, and when a central manager’s state changes.". The caveat to this is that once woken up, you only have a short amount of time (approximately 10 seconds) to perform some processing like sending an HTTP request.
[1] https://developer.apple.com/library/archive/documentation/NetworkingInternetWeb/Conceptual/CoreBluetooth_concepts/CoreBluetoothBackgroundProcessingForIOSApps/PerformingTasksWhileYourAppIsInTheBackground.html
My android device is connected to a BLE dongle. The BLE Dongle is sending me messages for example A at 20 to 40 milliseconds of interval. I am getting messages in onCharacterticChange method. I am modifying the messages to for eg. to B. I am calling Bluetoothgatt.writeCharacterstic(characterstic) method at 20 to 40 millisecond interval to send messages B back to BLE dongle. I am sending near about 10,000 messages to BLE Dongle. Some times instead of B ,the dongle is getting message A. That is very strange i don't know what is happening in the background?? How to prevent that. I hope anyone have answer to that.
I am new to the BLE development. I want to send some large amount of data over a BLE connection with maximum throughput.
I have a GATT server, which is running on Linux, and a client which is running as an app on Android. I have created a custom characteristic with the maximum allowed size(512 bytes). I am requesting it from the app with a read operation. Every time I receive a call for reading on the server side I change it's value until I am finished with all the data(I know this isn't the best way but that's not the problem for now).
As for the connection parameters using android's requestConnectionPriority(CONNECTION_PRIORITY_HIGH) i can see that they are trying to negotiate a connection interval of 7.5ms but for some reason, it changes to 15ms and it remains there. Maybe my phone doesn't support it but I don't think so.
The next thing and the main problem is the MTU. Using hcidump, I can see that they are starting to negotiate the MTU as I can see an MTU Request from the client with a value of 517(by default) and a server Response with the same value. But when I trigger the data exchange I can see(using Wireshark) that the packets are containing only 32 bytes of payload. I don't know if it's a restriction with my Bluetooth adapter.
An MTU packet can consist of many radio packets and the 32byte radio packet payload is probably a restriction in your bluetooth adapter. No phone supports 7.5ms connection intervals at this point in time. You should also enable Data Length Extention if your phone and device supports it. This will allow you to transmit multiple MTUs throughout the connection event.
My client is building an application using a Bluetooth Low Energy dongle. This unit takes continuous measurements. They originally went with the BLE for energy purposes and power saving. Since this unit will run for about 8 hours at a time while recording data, they will need it to operate the full 8 hours.
They want me to setup their android app to Poll the device on 4 different channels at a frequency of up to 250/sec. To me that defeats the Low Energy aspect. I am pretty sure that BLE was designed with notifications in mind which should send data to an app onChange instead of the app asking the device for data at a given frequency.
At the moment I have the App setup with device notifications. That means that the GattServer is sending data and then the app is only receiving notifications of data change. The problem with that is that there are 2 channels for a sensor which require an amount of data at a rate of 250/sec. Even if there is no change.
The server may or may not send at that rate. For one channel I get about 25 reads er sec and for the other channel I get maybe 4 reads per second. Since this is all setup with Notifications which only notify onChange I suspect that the app is doing exactly what it is designed to do. So since there are not enough data points, we are thinking of switching those two channels to polling instead.
Does this make sense to you and doesn't this defeat the Low Energy or even the entire design of a Low Energy chip design?
250/sec = 1 packet per 4ms.
BLE's smallest connection interval is 7.5ms. All data exchanged between master and slave must be done within a connection interval. Even though multiple packets can be sent back and forth within a single connection interval, I don't know how you are going to make Android squeeze multiple messages into one connection interval. In that way, you cannot make sure the 250 polls are equally spaced in time.
I think Android simply wouldn't let you send messages at that frequency. Send networking packets is usually a blocking operation. So your app will be blocked by the operating system when tx is busy. In the end, what you might get is simply tens of messages per second.
I want an Android service, which is listening for data (I have tried TCP and UDP) to wake up the service/phone when data arrives.
Currently the phone stays asleep when IP data arrives and that data is lost. Is this normal for Android? I see sleeps of 2+ hours several times a day, and 7+ hour sleeps when I am asleep.
Does GCM provided a solution which wakes up a service/phone when a message arrives.
I need messages to be displayed within a few seconds of them being sent from the server.
Can this only be achieved by keeping the CPU running all day long? Is there no interrupt from the GSM modem on the arrival of data?
As I understand it, if you have an outstanding socket connection over mobile data to a server, that socket connection is maintained while in sleep mode, and incoming packets will wake up the phone out of sleep mode (briefly) to deliver the data.
The same is not true of WiFi (and presumably not for hardwired Ethernet, either). You would need to hold a WakeLock and a WifiLock.
Does GCM provided a solution which wakes up a service/phone when a message arrives.
Yes, but...
I need messages to be displayed within a few seconds of them being sent from the server.
First, GCM has no service-level guarantee. I am not aware of any solution that does, including anything that you might roll yourself (e.g., MQTT).
Second, you have no idea if the device is capable of receiving any such messages (GCM or otherwise), as the device may be turned off, in airplane mode, etc.