bluetooth LE receive bandwidth
-
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
-
@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 ?