bluetooth LE receive bandwidth

[efiLabs]

i have upgraded my hardware from a china ble module to a dedicated northern semiconductor arm cortex-m4f mcu which also holds now all of the firmware together with the nordic serial data protocol (20 bytes max / gatt pkg)

this hw sends out binary data pkgs, either to an android app running on a nexus-7 2013 or a ubuntu 16.04 or 18.04 desktop computer

data rcve rate is about 30 bytes every 50 ms, so roughly 600 bytes / sec (6 k baud)

for comparison, the android app consists of the same c++ bin pkg decode code in the JNI portion of the app and java is getting the decoded data, stuffs it into it's data array and displays it on the tablet

the QT app uses the exact same c++ bin pkg decode code and puts the data into the data structs ... a timer updates this data on the appropriate dialog window

the android app with a humble quad core arm cpu can keep up with a pkg rate of 20 ms / 30 byte pkgs, which was a big improvement when i switched the china ble modules against the nordic mcus

the QT desktop apps dies slowly even with the 50 ms data pkg rate ... what i mean by it is observing the system monitor cpu load and having some dbg info (single char print) for each pkg reception as well as a 1000 rcv char cnt timestamp

it all starts out working fine for a few secs and then the cpu load on the 8 cores (evenly spread out, one at a time) goes up and goes down again the next time it goes up higher and after 30 plus secs this game happened about 10 plus times and then one cpu reaches 100 % of it's slice for too long and the whole thing hangs ... also QT debug mode with breakpoints doesn't seem to like ble based apps since it never connects

i don't know how else to describe it

on another test app i only count 1000 rcv bytes and print a timestamp and nothing else and i can reach a 30 ms pkg rate ... if i want to display the data in 2 byte hex format in a text edit it dies the same way

is this all i can expect from an amd 8 core or and intel i7 8 core cpu on a QT desktop computer running the above mentioned ubuntu versions ???

at this point i wouldn't even know how to spit the whole app up into threads or similar to even the load

for the simple bandwidth test app i see no reason what part to put on a separate thread

for the data processing app i have 2 solutions, one being single threaded and the other one as follows

the code for "characteristicChanged" slot sticks the data into a very simple queue and a 2nd thread checks to see if there is something in this que and takes it out and does the pkg decode and sticks it into the data struct
the main app updates the gui based upon a timer from this data struct
note, it's interesting that the que never gets full, overflow ... how comes that the ble rcve from the qt library doesn't run independent in it's own thread (environment) and produces the rcv data regardless of the main app ... this data has to come from a system driver ???

can this QT ble data rcv library be run in it's own thread ... right now i wouldn't know how

there seemed no performance difference for both app versions (single vs double threaded)

sorry for the lengthy description

i feel that others might run eventually into similar issues and face the same ble bandwidth dilemma.

i have not found anything applicable to my performance issue, but maybe i'm not good at gooooogling

any thoughts and suggestions are highly appreciated

cheers efiLabs

[ankursaxena]

@efiLabs I am facing same kind of problem. I working on my linux laptop (ubuntu 18.0). I have run an application in cetral mode of ble. When this application is started to receive the data it receive some 20 packets of 509 bytes chunks and then after it hangs. When i googled it, i realized it may be the problem of throughput.

Is there any api in Qt to tell the peripheral device to send the data in low throughput ?