Issues with how RaceChrono handles some data channels

I'm working on my own DIY CAN reader with BLE https://github.com/timurrrr/RaceChronoDiyBleDevice

I've noticed that some channels look smooth-ish (such as speed, rpms, accelerator pedal position), but at least the "brake pedal position" channel has jagged edges. See the cyan colored line in https://imgur.com/FEmqGO5 as an example.
Is this something that RaceChrono handles incorrectly?

Also, I can read Lateral acceleration, as well as Longitudinal acceleration, from the CAN bus and send to RaceChrono.
There are two problems with those:
1) When I use either of them in the G-meter for the overlay, nothing is displayed.
2) They are noisy, see https://imgur.com/WtwTsPR. Could RaceChrono have some configurable smoothening for data channels in post-processing? I guess I could apply some smoothing in my CAN reader, but that would introduce some offset/delay. I'm sure many accelerometers (and probably other data channels) would benefit from such a feature.

Comments

  • You get this jagged line or "stairs" when i) the data resolution is low AND ii) the data update rate is high. When circumstances are right, RC will receive same values one or multiple times from your device. It will cause a vertical line in the graph. When a different value is received by RC, it will create a step or "stair".

    The G-meter on the overlay cannot handle anything else than GPS data. It's on my TO-DO list to overhaul this (and some other gauges too). It needs a new overlay editor though.

    RaceChrono does have smoothening and a lot of other filters. It even have a filter to fix the "jagged" data. Unfortunately I haven't figured out how to incorporate this to the UI yet. Instead, these filters are only used in hard-coded manner for specific things, like the accelerations and lean angle calculated from the GPS.
  • Understood, thanks!

    So for data channels such as oil/coolant temps you suggest only sending them when they change? Or could some smoothening be hard-coded for them too?

  • Re: new overlay editor — curious what's the difference between the accelerations calculated from GPS and the ones from accelerometers when it comes to the UI. As long as I can provide both lateral and longitudinal accelerations, I wouldn't expect any difference when it comes to the UI...

  • True, the issue with the acceleration gauge is not about UI. I think you need "combined acceleration" as well as lateral and longitudinal for it to show up.
  • Yeah I've tried adding a "combined acceleration" channel where I calculate "sqrt(pow2(...) + pow2(...)" but still can't see the full G-meter.
  • I'll need to look in to that
  • Related: I noticed that for GPS data, "combined acceleration" is a calculated channel, whereas for CAN data I have to manually define it. Would be great if "combined accelaration" automatically showed up if lat+long are available separately.
  • Added to my TO-DO
  • > The G-meter on the overlay cannot handle anything else than GPS data. It's on my TO-DO list to overhaul this (and some other gauges too). It needs a new overlay editor though.

    @aol_of_RaceChrono, are there any update about that?

    I'm using OBDLink LX and @timurrrr's method so that I can get CAN-Bus signals from my BRZ(ZC6). Thanks, timurrrr!
    https://github.com/timurrrr/RaceChronoDiyBleDevice/blob/master/can_db/ft86.md
    Same as timurrrr, I want to display G-meter by CAN-Bus acceleration signal.
  • @TapoST206 will be fixed in v8.0
  • That's nice!

    I'm waiting for the release.

Sign In or Register to comment.