Troubleshooting custom math variable

I’m trying to create a traction loss indicator gauge.

I have individual wheel speeds from a CAN frame. I am trying to calculate traction loss (rear wheel slip) from the ratio of individual wheel speed and vehicle speed.

The problem is the values for “Wheel Slip RR” and “Wheel Slip RL” are always zero.
I also tried this in gauge math. As soon as I put a reference like ‘Wheel Speed RL’ in the math, the result is always zero.

    <frame id="416">
      <!-- Vehicle Speed -->
      <value targetId="64" name="Vehicle Speed" offset="0" bitcount="12" signed="true" units="km/h"
    <frame id="206">
      <!-- Individual Wheel Speeds -->
      <value name="Wheel Speed RR" offset="6" length="2" signed="true" units="km/h"
      <value name="Wheel Speed RL" offset="4" length="2" signed="true" units="km/h"
      <!-- slip is the ratio of driven wheel speed to vehicle speed (ID64) -->
      <!-- we add 1 to prevent dividing by zero. abs prevents a problem if speed is -1 -->
      <value name="Wheel Slip RR" conversion="'Wheel Speed RR' / (abs(ID64) + 1.0)"></value>
      <value name="Wheel Slip RL" conversion="'Wheel Speed RL' / (abs(ID64) + 1.0)"></value>

I ran this on the simulator environment and found multitude of issues. These will be fixed on next release of RealDash. Some notes:

  • I recommend using targetId 81 for vehicle speed instead of 64. By writing vehicle speed to id 81 (ECU VSS1) allows users to switch between ECU and GPS speed in the settings.

  • There is two main reasons why Wheel Slip conversion does not work. First is that custom value name is generated from ‘name’ and ‘units’ attribute. So you need to use:

conversion="'Wheel Speed RR (km/h)' ..."
  • Making this modification to XML revealed another problem. Each custom value in RealDash uses a hash identification number which is generated from value name. This is done for faster lookup for the values. As it happened, “Wheel Slip RR” generated a hash value that went so far negative that conversion parser refused to parse it.

Currently we have no chance to make a quick fix release for 2.3.9, so expect this to be fixed in 2.4.0.

1 Like