@ Weston@HPTuners NBP issue

Hi Weston

Im havng issues sending more than one data channel via NBP , its a timeout/buffer issue, if i send 2 channels at the same time the track Addict NBP disconnect around 3 minutes on average , yet if i just send one channel i get doubule the time out , i have tried different strings with no different results. it feels like a buffer issue on the track addict app but cannot test this.

1 NBP channel 10 minutes appoxermatly
2 NBP channels 3 minutes appoxermatly

Any help apperciated , using a samsung xcover4

cheerrs
Mark

PS i have also tested my interface against another monitor (https://play.google.com/store/apps/d..._wifi_terminal) and it works ok. no time out issues.

I've been trying to replicate the issue, but no luck so far... Do you have a sample of the data you're sending?

Quote:

---

Originally Posted by Weston@HPTuners

I've been trying to replicate the issue, but no luck so far... Do you have a sample of the data you're sending?

---

i have sent the code to your support email,

but the 2 strings were

char input[] = ""Throttle Pedal""; // J
resultacc1 = constrain(resultacc1, 0, 100); //i input value from sensor 0 to 100 %

tm=millis()/1000.00,2;

serialBT.print("*NBP1,UPDATE,");serialBT.println(t m);
serialBT.print(J);serialBT.print(",");serialBT.pri nt(""%"");serialBT.print(":");serialBT.println(i) ;
serialBT.print("#");


second chaneel same codes as above but with
char input[] = ""BRAKE""; // J

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...

Quote:

---

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...

---

Hi the main problem was with Wifi (802.11) the Bluetooth one was more reliable.

I retried the wifi version with a 200 milli second delay beween each message but the time out of about 3 minutes was still the same

Regards

Mark