Increasing speed on an OTA transaction
@ryanbis Ok, that's nice of android to post back on different threads Good thing you are making is consistent at least.
I mean't that I am using the device read/write listener to listen for when an OTA characteristic has been written without response, then I keep writing data to the characteristic(not waiting for the callback) until it returns false, in which case I can't keep buffering the data due to the buffer being full, so I wait for the next callback/readwrite event to do it again.
You can see from this wireshark screenshot using this method is much better now, I'm getting packets sent in bulk way more regularly. I managed to get the transfer down to 5 minutes for roughly 180k.
benp last edited by benp
@ryanbis Do you think you could give me access to a onCharacteristicWritten callback(without any thread switching) for the device? This way I'd be able to have the writeCharacteristic/onCharacteristicWritten on a tight loop for OTA. Perhaps you could have a BluetoothGattCallback proxy object which is setable on the device for people which would like to use the native stack callbacks for certain things?
On another note, do you increase the priority of the thread/looper which the OtaTransaction runs on?
ryanbis last edited by
If you set BleManagerConfig.postCallbacksToMainThread to false, it will just post the callback on whatever thread it came in on from the android system.
There is no mechanism to increase thread priority. Usually this just ends up causing problems, and doesn't really give much performance improvement. All update calls are run from the SweetBlue thread. If you want to decrease the tick time between update calls, you can set BleManagerConfig.autoUpdateRate.
@ryanbis Oh ok, good to know there is no thread switching when it's set to false. I did end up leaving it set to false, and it did seem to run faster. I agree about the thread priority, it didn't seem to help me in the end, I think at the least i'd have to increase the priority of the bluetooth service as well which seems impossible other than from a process level when the device is rooted.
So I guess the update calls are any calls going out which the autoupdaterate regulates/and is ran on the sweetblue thread, where as any callbacks are not put onto this thread and are just logged and pushed through to callbacks in use?
Things are running pretty good now that I'm writing directly to the characteristic, I also disabled the logging temporarily during the transfer to squeeze more performance.
Very interesting findings. @benp, do you think you could make an example Nordic DFU Android project for the community to reference to?
@alejandrohcruz I used macros from within the rfConnect app to test the upgrade speed, I didn't actually write any code. I'm probably going to post up the java code I wrote to work with sweetblue once I'm done ironing out any remaining issues, we are currently using xamarin for our app but I had to do the ota code in java to improve the speed.
Interesting, thanks for the info. Good luck and looking forward to that Java code. I will try to do the test myself on code and see what I get. By the way, did you try to do a test with the SweetBlue Toolbox app? I guess it should be possible to perform an OTA transaction with it.
@alejandrohcruz I didn't see a way to use macros with the toolbox app so didn't end up using it.
I've attached a zip of the java files I used for doing the OTA transaction.
@ryanbis It also includes the wrappers I needed for callbacks to work in xamarin(it doesn't support callbacks which make use of java generics).
@benp thanks a lot, will check it out!