Search the Community

Hi, for one of my Bluetooth BLE projects, the MTU has to be adjusted in the Bluetooth communication. There is a "requestMTU" function in the Bluetooth framework for this, but how can I find out to which MTU the devices have agreed on? When I call requestMTU(200) and look into the logcat profiler I see the following messages there: BluetoothGatt: configureMTU() - device: <DEVICE> mtu: 200 BluetoothGatt: onConnectionUpdated() - Device=<DEVICE> interval=6 latency=0 timeout=500 status=0 BluetoothGatt: onConfigureMTU() - Device=<DEVICE> mtu=200 status=0 There is an "onMtuChanged" handler in "Android.JNI.Bluetooth.pas", but I don't know how to implement this or where. I really just need a tip on how to include this event in a Bluetooth class from "System.Android.Bluetooth.pas". I'm sure I'll be able to grind through the event myself through the remaining levels. Does anyone have a hint or maybe an example code for me?

Hi there, I see some strange behaviour here when using Bluetooth with Android in the background. I'm using the permissions BLUETOOTH , BLUETOOTH_ADMIN, ACCESS_COARSE_LOCATION , ACCESS_FINE_LOCATION and there is the new permission ACCESS_BACKGROUND_LOCATION Currently I do not really use lcation at all, only in combination with Bluetooth LE, which requires that. Since I want to use Bluetooth in the background, it seems that I have to set the ACCESS_BACKGROUND_LOCATIONas well. Usually all works well, but I can see a strange effect after first install: Only when the app is first time installled, - I see the first permission alert popping up, and - usually I set location permission to ALWAYS - If I check the system permission dialog, I can see that location ALWAYS is perfectly set in the Android system - ! But Bluetooth LE its NOT working. Only after that I do, - close the app (closing not really needed, also good enough to change the system permission dialog to "WHEN IN USE") - change the location permission to "WHEN IN USE" - open or start the app again - ! opening, after changing the permission, will re-start the app, which is same as close/open So that really close/open is not needed, the system permission change causes the same effect. ! Changing from "WHEN IN USE" to "ALWAYS" doesn't re-start the app. - the app is asking again for location "ALWAYS", as it should - when I set "ALWAYS" (the second time), only then Bluetooth LE is working Conclusions: - So seems to work only from the 2nd time setting "ALWAYS", permission needs to be switched to "WHEN IN USE" once before. - I can also install the app, set permission alert to "WHEN IN USE", and then in system dialog change from "WHEN IN USE" to always, the app doesn't re-start, but seems to work with Bluetooth now. - It needs a sequence with "WHEN IN USE" firstly be required, before switching to "ALWAYS", is that the case ? Any clues what the real reason for this odd behaviour might be ?

Hi there, I have a very nasty problem again with BLE background mode. Since I have the feeling that I have read all available articles and references about this topic worldwide, I still got no clue howto get this working. All is working as expected under forground mode. I hope that I can find some help or new ideas from here, because my head is going to be empty right now. My setup is: Rx10.3.3, XCode 11.4.1, iOS13.4.1, modern iPhone/iPad devices, all running fine with debug and release My task: I need to connect external Bluetooth LE peripherials, which works well in foreground. They send data string (20 bytes) via unspecific custom characteristics, and I receive a HEX string, all that is fine. With integrated logging functions in the app, I can monitor all behaviour in fore- and background. Also debugging in fore- and background is no problem. The devices send new datastring every < 2 sec., and the other every < 12 sec., anyway, both get killed after a while. Maybe there are some restrictions in the datarate, I have read somewhere that peripherals > 2 sec. might considered to be killed (?), but I cannot find anything about that in the official docs (also not much in the forums, seems only one case). The connected devices stay connected, I cannot see any unusual behaviour, moreover I test with three different hardware types, all behave same. So the issue seems not to be caused by the peripheral hardware. I use the following settings: Background modes: audio, bluetooth-central (audio is used for Tts text-to-speech also in background, but its not used currently when receiving the data sting). Info PList NSBluetoothPeripheralUsageDescription (deprecated, but shouldn't it be there for older devices ?) I didn't see any hint that this might be harmful. NSBluetoothAlwaysUsageDescription (defining both should be any problem, right ?) Permissions FMLocalNotificationPermission = true; Location: I do not use that, since Apple rejected this once, for adding an "unused background operation". Some time before I added this background location as workaround to keep background mode permanently running. I've made also some experiments before to add bluetooth-peripheral mode, as workaround to keep background mode permanently running. Both workarounds should be not necessary, but I was searching for a stable way to keep background active. I touch the location in foreground, so that the Location permission alert appears to the user,, since I think that location might be relevant for Bluetooth as well, same as is under Android. But I don't use Location in foreground, but in the past it seems that location permission alert seemed to help keeping background active.. When I take the location out completely, then also the Bluetooth LE permission alert seems not to appear every time, so sometimes BLE stays unavailable, and I need re-install to fix that problem. Thats why I touch the location in foreground, to enable location, and then I don't use the location any more, but BLE works with that approach in foreground. Device capabilities: I don't set specific BluetoothLE capabilities (UIRequiredDeviceCapabilities - bluetooth-le), as I never had to, and it works in foreground. Application events, I handle all of them, and especially at WillEnterBackground I stop some unneeded timers and delay the Threaded ringbuffer for receiving and processing the data, by TThread.Sleep(500);. (I used this sleep method before, and it seem to work well under older iOS, but I never checked that too deeply). on BecameActive I restart the timer and threads With TThread.Sleep(500); I throttle the thread which processes the incoming data (there is no data overflow, datarate is too small). I can see the processed incoming data, also in background, the ReadCharacteristic appends the data to the ring buffer, and then every 500ms the thread still seems to run and process this. In background I stop running timer, and I can see data from the periperal coming in. So far, so good, but longer operation (> 1min, > 10min) might kill the app in background. With kill I mean, its not only in background stopped, but the app is killed and restarts fresh. There is no other resource shortage, enough memory, etc., no need to be killed IMHO. I don't see any place where my app could get stucked, so that Apple might push me out of business, I tried to implement all measures to keep everything lightweight, asynchronously, only the threaded ringuffer sleeps for 500ms every cycle. I can see the data package running through the process handler, even debugging in background is possible. Please let me know if you have some helpful hints here, because I got stucked a while now by this issue, I'm at my wits end right now.