RaceChrono DIY Bluetooth BLE protocol

edited July 21 in DIY builds

I've been tinkering with the example given on https://github.com/aollin/racechrono-ble-diy-device
with RaceChrono PRO v6.4.1 for Android, and had some feedback/questions.

1) In my testing, RaceChrono always requests a "50 ms" notify interval.
If I correctly understand what it means, this results in a 20 Hz refresh rate.
In my limited testing, it seems that Bluetooth BLE on Bluefruit nRF52832 can easily support 40 Hz refresh rate for a significant number of channels if I just ignore the "notify interval" and notify() on "fake" updates repeatedly without waiting.
I wonder if the refresh rate should be a parameter in the UI?
What is the reason RaceChrono limits CAN updates to 20 Hz?
That arguably removes one of the advantages of listening to CAN over OBD-II.

What's the worst thing that can happen if my DIY device ignores the notify interval on the request and uses a "10 ms" notify interval instead? :smiley:

2) Is one BLE characteristic 0x01 sufficient for data communication?
I'm not super familiar with Bluetooth BLE yet, or with how multiple updates are delivered when using notify().
What happens if the car sends 5 different "allowed" CAN messages 1 ms apart over and over?
With a 50 ms notify interval, we will notify() the characteristic 5 times with a 1 ms interval, and then do nothing for 45 ms.
Does it make the communication for the last CAN PID more reliable because its data is "exposed" for longer?
Or is there something that allows RaceChrono to see past value updates even if a new one came in shortly afterwards?

I wonder if it would be useful to have say 10 characteristics and update them in a round robin way, or something like that.

3) Strange requests in the "Vehicle profile" mode.
I've been looking at what commands RaceChrono sends via characteristic 0x02.
a) When I start a session, I get "DENY ALL", and then "ADD PID" for the set of enabled PIDs.
This makes sense. It's cool to see that RaceChrono is smart enough to only request the same PID once if it's shared by multiple channels.

b) When I enable "Test connection" in "Vehicle profile", I get "ALLOW ALL" — this makes sense, although not clear why you couldn't just reuse the same smart logic from the session mode.

c) When I open "Channel editor", I get TWO "ALLOW ALL" requests.
This is strange. I wonder if the intention was to send "DENY ALL" and one "ADD PID" afterwards, that would be a lot more efficient.

d) When I change the PID in "Channel editor", I get a "ALLOW ALL" request.
Again, if I change the PID, I'd expect to get "DENY ALL" followed by "ADD PID".
Interestingly, I get "ALLOW ALL" even if I hit the checkmark without changing the PID at all.


  • 1) You can ignore it no problem. Just something I ended up using with my KTM bike. You can create your own rate limiter or just disable it if you don't need one.

    2) You'll need to implement both 1 and 2, as RaceChrono expects to have them.

    3) DENY ALL and ADD PID means it wants to receive only the ones that are added. ALLOW ALL means it wants to see all PIDs, it does not know which ones to expect. Two ALLOW ALL is a bug, but it means same as one :)
  • 2) Yeah, I understand that currently RaceChrono requires 1 for data and 2 for filter requests.
    My questions are really
    a) how does it work if I notify() multiple different PIDs in a short succession?
    b) is there any contention or risk of timeouts?
    c) if there are, should RaceChrono change the protocol to use multiple characteristics?

    3) I understand what the requests mean, but my question is whether RaceChrono should be sending different requests. When I'm in the "Channel editor" looking at PID=123, there's really not much value in "ALLOW ALL" over "DENY, then ADD PID 123".
  • 2a) Yes, just shoot away

    2b) No idea

    2c) The hardware I used works better with only one characteristic in notify mode. I get the idea but it just did not work on this hardware.

    3) Well it's not perfect, like I said, there's probably bugs.
  • Re: (3) — can this be fixed in RC v7?
  • aolaol
    edited August 7
    3) Sorry, no. The v7.0 is too far in to testing. Also it's not too severe of a bug, as the device should just blindly follow the commands from RC. When there's ALLOW ALL first, and DENY ALL right after, obviously the ALLOW ALL does nothing. I will look at it when I build the next generation DIY-device.
  • Understood wrt timing. Hope to see it fixed in 7.1 or something. Let me know what is the effective communication channel to report issues like that. This forum thread? Issue on GitHub? Something else?

    Just to clarify, I'm not getting ALLOWALL-then-DENYALL, I'm getting ALLOWALL-ALLOWALL when I would have expected to get DENYALL-ALLOWONE.
Sign In or Register to comment.