Originally Posted by
Weston@HPTuners
I took a look at the code in the support ticket and I didn't notice anything that would throttle the data rate, so that's most likely the effective cause: data coming in faster than it can be processed. That would explain why there's no apparent overflow when viewed with a terminal program, but then there's problems when an app like TA is spending CPU time parsing it and logging it. The effective limit will be based on the performance of your bluetooth conditions and your device that's running the app.
I found some opportunities for efficiency improvements in our NBP client code, and have made changes so that it should be able to process it a little faster, and that will be in v4.6.2, which I'm expecting to release within the next week or so...
In either case, the recommendation here would be to add some delay to your loop to limit the sampling rate a bit so that you're not overwhelming the Bluetooth throughput, buffers, or phone's CPU.
Still, that doesn't quite explain why you're seeing it apparently just stop processing new data after running for some time, so that would seem to be the real bug here, and I am still investigating that. I currently have TA connected to the NBP device in my race car and will let it run all day and see if I can replicate that problem...