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.

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.

Quote:

---

Originally Posted by Weston@HPTuners

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.

Quote:

---

Originally Posted by CarmonColvin

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

Quote:

---

Originally Posted by CarmonColvin

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

Thank you. I think this is a great solution.

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

Quote:

---

Originally Posted by CarmonColvin

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

Quote:

---

Originally Posted by moth4017

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.

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