Gear Detection Hysteresis?

[hamer]

Does the gear detection have any hysteresis?

I'm asking because I'm using the feature to display the current riding mode on an EV and I'm having trouble getting it to update correctly.

If I use a received CAN channel that displays a number from 1-5 based on the selected ride mode the gear indication does not update, even though I see that channel update when I monitor channels.

If I use the max RPM limit for that ride mode it does work, the max RPMs will be 8000, 7970, etc.

I would prefer to use the actual selected ride mode rather than RPM limits in case I want to set them the same for two different modes. But this tells me there is some type of hysteresis in the gear detection screen?

Attaching photos of the settings for that CAN channel and the gear detection setup. Right now I'm only trying to use P, R and 1.
CAN Channel:

RideModeActive.JPG (29.39 KiB) Viewed 5220 times

Working based on RPM limit:

Gear-RPM-Works.JPG (46.46 KiB) Viewed 5220 times

Not working based on selected ride mode:

Gear-RideModeActive-DoesntWork.JPG (45.25 KiB) Viewed 5220 times

[David Ferguson]

I think you just need to make a 2D table, mapping Ride Mode to Gear. There is no need to do Gear detection. The channel Gear is often sent directly over the CAN bus and used for display. Some cars don't do negative numbers, so we often map them using a 2-D table (so a received 9 is turned into -1). Your problem is just like that. You want to change an integer value into a gear (signed value) for display.

Let me know if you need an example.

[hamer]

I was hoping to avoid using up a 2D table for something this simple. I thought that's what the Sensor Values table at the bottom of the gear detection was doing anyways? Just weird that it works with RPM values but not Ride Mode values.

[David Ferguson]

I think the issue is gear detection is made for doing something with several digits of precision, like a gear voltage often measured to the millivolt), and those values are normally in a rising ore falling order where yours are not. You might be able to scale your Ride Mode in the CAN template to have more digits of precision (so multiply by 1000 to get 5000, 2000, 0 and 1000).

Are you using alarms? Any chance you could make alarms for each mode, and just spell it out in plain text what the drive mode is? These could be the lowest priority alarm so others appeared on top.

Or maybe you should consider using display creator, where you can use switches to display different text for a channel value (or change the whole page layout)

[hamer]

HI Dave,

Thanks for the ideas. The multiplier worked, although I only needed to multiply by 100 to get the gear detection to work.

Alarms isn't a bad idea, although we are using them for various temp limits, I'd prefer something a little more obvious for the rider to know exactly what mode they are in.

Thanks again for the help.

[NathanB]

Digging up an old thread.

The method of calculation is looking for an input channel which have values 'between' them.

Single digit integer values will not work but if your CAN signal is multiplied by 10 or 100 then the sensor method works as expected, as Dave had guessed.

The input values would need to be updated to match the modified input channel value e.g
-2 = -20
0 = 0
1 = 10