Results 1 to 9 of 9

Thread: NBP Feature Request

  1. #1
    Tuner in Training
    Join Date
    Oct 2020
    Posts
    18

    Lightbulb NBP Feature Request

    I would like to see a feature added to the NBP setup options to indicate the NBP server is expecting one-way or two-way communication.

    Desired functionality:
    • When in two-way mode (the default), the app behaves exactly as it does now, sending out the periodic client request commands.
    • When in one-way mode, the app does not send the periodic client request commands. It just makes a connection and stays quiet.


    Clarity:
    When I use the term "client request command" I am referring to the ("!KA", "!ALL", etc.) strings sent to the NBP server.

    Reason:
    I have an Arduino based device that can send around 35 NBP packets a second. The problem I have is that the incoming client request commands slow down my serial connection and causes a noticeable slowdown in my packet rate for a few packet cycles. It does not happen on every single request, approximately 1/3rd of them cause a slowdown. I think it has to do with the timing of the command's arrival in the buffer.

  2. #2
    HPT Employee Weston@HPTuners's Avatar
    Join Date
    Jul 2014
    Location
    39.735034, -103.894459
    Posts
    868
    Are you on Android? If so, give it a try with the recent v4.6.3 update...

    There has been an issue with Android where if an app has a receive-only Bluetooth connection (or a two-way connection that just doesn't transmit much), Android will start delaying the incoming data, then those samples will all stack up and process together at the same time. I've found several other Android devs reporting the same issue, but haven't dug through the open source code to figure out exactly why this happens. We've long seen a mild form of this with GPS (even somewhat on iOS too), and had used some timing correction logic there, but this has become much more of a problem for NBP and our upcoming MPVI2 Pro broadcast data, both of which can transmit more data and more frequently, causing the impact of this odd Bluetooth behavior to be much more problematic. I was seeing the data sample lag build up a bit, peaking right when we sent the keep-alive packet, and then return to normal for a bit. Turns out that the keep-alive was not the cause of the problem as it appeared, but rather the solution.

    The good news is that it's now solved in v4.6.3 for NBP, GPS, and MPVI2 Pro. In the case of NBP, we actually send the "!KA" packets more often on Android now, every 3 seconds, because the threshold for the problem seems to be if an app has no transmit activity for 5 seconds. Setting our interval to 5 sec was cutting it a little too close, as the behavior appeared to still occur intermittently. I don't expect that the keep-alive packet would have a noticeable affect on throughput itself, being that it's only a few bytes every few seconds and they can simply be ignored by the NBP server, but it is an effective workaround for the Android BT issue that should avoid the lags we were seeing on the receive side. I suspect that's the root cause of the issue you were experiencing, as it sounds like you had much the same experience as I did.

  3. #3
    Tuner in Training
    Join Date
    Oct 2020
    Posts
    18
    Quote Originally Posted by Weston@HPTuners View Post
    Are you on Android? If so, give it a try with the recent v4.6.3 update...
    Weston,
    Thanks for the reply. I run TrackAddict on iOS (iPhone 8+ v14.2) using a Wi-fi connection to my Arduino project.

    I do not feel like the issue I am having is related to the type of issue you described.

    From debugging my code, I am fairly certain the slowdown I have is in the web server running on my ESP8266 hardware. It seems to just choke up. It takes much longer to respond when I write to the broadcast buffer immediately following the receipt of any inbound messages. I have tried every strategy for ignoring them that I can find and none of them eliminate the slowdown.


    What I am asking for is a workaround to an issue I cannot figure out on my end.

  4. #4
    Tuner in Training
    Join Date
    Dec 2019
    Posts
    39
    Quote Originally Posted by CarmonColvin View Post
    Weston,
    Thanks for the reply. I run TrackAddict on iOS (iPhone 8+ v14.2) using a Wi-fi connection to my Arduino project.

    I do not feel like the issue I am having is related to the type of issue you described.

    From debugging my code, I am fairly certain the slowdown I have is in the web server running on my ESP8266 hardware. It seems to just choke up. It takes much longer to respond when I write to the broadcast buffer immediately following the receipt of any inbound messages. I have tried every strategy for ignoring them that I can find and none of them eliminate the slowdown.


    What I am asking for is a workaround to an issue I cannot figure out on my end.
    Hi Carmon

    have you tried a esp32 yet, this is what im using with wifi and nbp, im not seeing the data backing up

  5. #5
    HPT Employee Weston@HPTuners's Avatar
    Join Date
    Jul 2014
    Location
    39.735034, -103.894459
    Posts
    868
    Quote Originally Posted by CarmonColvin View Post
    Weston,
    Thanks for the reply. I run TrackAddict on iOS (iPhone 8+ v14.2) using a Wi-fi connection to my Arduino project.

    I do not feel like the issue I am having is related to the type of issue you described.

    From debugging my code, I am fairly certain the slowdown I have is in the web server running on my ESP8266 hardware. It seems to just choke up. It takes much longer to respond when I write to the broadcast buffer immediately following the receipt of any inbound messages. I have tried every strategy for ignoring them that I can find and none of them eliminate the slowdown.


    What I am asking for is a workaround to an issue I cannot figure out on my end.
    Ok, no problem. What we'll do is add a metadata type so that the NBP server can request that clients (ie TrackAddict) don't send the keep-alive:

    "@KEEPALIVE:OFF\n"

    Even if the KA packets don't turn out to be the cause of your issue, this should be useful for debugging and in other cases where this protocol is used with multiple clients.

    That will work in TrackAddict v4.6.4 and higher. I don't have an ETA on that release just yet, as there are some other objectives I'm trying to fit into the next update...

  6. #6
    Tuner in Training
    Join Date
    Oct 2020
    Posts
    18
    Thank you. I think this is a great solution.

    Does the "@KEEPALIVE:OFF\n" need to be sent more than once per session?

  7. #7
    HPT Employee Weston@HPTuners's Avatar
    Join Date
    Jul 2014
    Location
    39.735034, -103.894459
    Posts
    868
    Quote Originally Posted by CarmonColvin View Post
    Thank you. I think this is a great solution.

    Does the "@KEEPALIVE:OFF\n" need to be sent more than once per session?
    It should only be needed once... You'll likely still get an initial !KA right upon connect, but then no others after you send that line

  8. #8
    Tuner in Training
    Join Date
    Oct 2020
    Posts
    18
    Quote Originally Posted by moth4017 View Post
    have you tried a esp32 yet, this is what im using with wifi and nbp, im not seeing the data backing up
    The next version of my device will probably be based on the ESP32. I expect to have one to experiment within a few weeks. I have a ton of other projects I have to finish before I can start on it.

  9. #9
    Tuner in Training
    Join Date
    Dec 2019
    Posts
    39
    Hi, i have been testing on track with the accelarator and brake pedel position so far so good , im now looking at height positon to test down force