Results 1 to 5 of 5

Thread: @ Weston@HPTuners NBP issue

  1. #1
    Tuner in Training
    Join Date
    Dec 2019
    Posts
    39

    @ 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.
    Last edited by moth4017; 10-23-2020 at 05:02 PM.

  2. #2
    HPT Employee Weston@HPTuners's Avatar
    Join Date
    Jul 2014
    Location
    39.735034, -103.894459
    Posts
    868
    I've been trying to replicate the issue, but no luck so far... Do you have a sample of the data you're sending?

  3. #3
    Tuner in Training
    Join Date
    Dec 2019
    Posts
    39
    Quote Originally Posted by Weston@HPTuners View Post
    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
    Last edited by moth4017; 10-29-2020 at 07:30 PM.

  4. #4
    HPT Employee Weston@HPTuners's Avatar
    Join Date
    Jul 2014
    Location
    39.735034, -103.894459
    Posts
    868
    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...

  5. #5
    Tuner in Training
    Join Date
    Dec 2019
    Posts
    39
    Quote Originally Posted by Weston@HPTuners View Post
    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
    Last edited by moth4017; 11-02-2020 at 11:30 PM.