Intermediate value when changing gears

General
1

Hi All

i am using the realdash internal calculation (based on vss, gear ratio and rpm) to show the gear position in the dashboard.

This works perfectl fine. There is just a cosmetic issue that i would like to adjust. While you press the clutch and for example are going to Change from 2nd to 3rd gear, the calculation shows the wrong gear (4th) while the clutch is not yet released. As soon as you release the clutch the gear is shown correctly.

Is there a way to have the system show N intermediately instead of the „wrong“ gear?

i am also open in „delaying“ the calculation to make this work.

Regards

2

I want to know if this is possible on my UK Suzuki Swift Sport (2023 year).

3

We have solved this by having Neutral switch read from the transmission. The switch input will always override the gear calculation and show ‘N’ instead.

If it is not possible to use Neutral Switch input, You could try to add some value smoothing into the gauge that is showing the gear. This can be done in ‘Look’n Feel->Special->Value Smoothing’. This has its limits though, if you hold down the clutch for a long time and RPM drops, eventually a ‘wrong’ gear is displayed.

1 Like
4

Thanks for this really helpful reply. :slight_smile:

Is it possible for me to find out if the OBD2 reader gets this value from my car? Is there a way to see all the data RealDash receives via the reader?

(My car has keyless start plus stop/start and knows when the clutch is pushed down to make both these things work. I just don’t know if this information is pushed out via the OBD2 port.)

1 Like
5

The problem with OBD2 is that data is received only per request. So in order to get the RPM, RealDash must send a request for RPM and then gets an reply that contains the data. Same thing applies to any other data, like Neutral switch for example.

These values are not part of the SAE standard of values that are read from the OBD2. Wikipedia has a nice article about standard PIDs:

OBD-II PIDs - Wikipedia

These standard PIDs do not include any toggle switches etc, but basically only basic diagnostics values. That what OBD2 port is there for.

While its possible to read custom values from the OBD2 port, it would require for you to know manufacturer specific request (PID) in order to read the data. These databases exist, but are very expensive to get into and their licenses do not allow usage of that data outside of the vehicle service purposes.

So OBD2 is not very good for displaying real time data from your vehicle as it is for diagnostics purposes. Some vehicles send data very quickly to OBD2, but some are very sluggish. Imagine a situation:

  • You want to know 10 different values from your vehicle.
  • Lets set a round trip time for messages being 20 milliseconds. This includes:
    • RealDash sends a command to adapter
    • Adapter sends the request to vehicle bus
    • Vehicle responds and adapter parses the reply to common OBD2 format.
    • Adapter sends reply to RealDash.

Now, asking RPM takes 20 milliseconds. So you get RPM 50 times per second. Not too bad. But ask 10 total values, the update rate of RPM drops to 5 times per second. Still maybe reasonable, but in real life very few cars have 20ms roundtrip. It could be more like 100ms.

There are ways around this, like multipid requests, custom PIDs that contain multiple sensor values in single request, etc. Problem is that support for these (and actual PIDs) are vehicle specific and that information is very hard to find.

So, while OBD2 is an easy way to get started reading vehicle data, its far from optimal to use as real time data display. This is why I always say, that if you are serious about display customization, forget OBD2 and use direct CAN connection. If your vehicle stock ECU has no CAN support, leave it as it is and try to enjoy whatever data you get.

Of course, interpreting CAN frames and their contents can also be very time consuming and difficult. But at least you will have fast response and pretty much everything imaginable will be available. But any day it beats digging out custom OBD2 PIDs and having a sluggish and slowly responding dash at the end.

2 Likes
6

Wow, that’s hugely helpful! Reading that link after sending this…

So if the RealDash dashboard is designed just to show the gear number it’s only requesting the vehicle speed and RPM from the OBD2. But if RealDash shows loads of other things too it has to send many more requests, which will slow everything down? RealDash isn’t requesting all this data anyway but just throwing it away?

Is there not a way to scan all possible PIDs outside the SAE Standard using RealDash or is that a silly question?

7

No, there is no way unless you know what you are asking for from the adapter. You can use the RealDash OBD2 monitor to ask support for standard PIDs, but thats pretty much all.

Typical custom PID request consists of two parts, you first have to set a header and then make a request. Say for example:

ATSH7DF
221131

The ATSH7DF sets the header to 7DF and 221131 makes the custom PID request. Typically if you just send a request like 221131 without setting the header first, you get no reply. Header is basically telling that this request needs to go directly to a certain module on the car.

So you can see that its quite complicated to get custom PIDs working, and to make matters worse, setting/resetting the headers slows down the communication even more (remember the round trip time).

This is my understanding of OBD2. I’m not saying that I know it all, it could well be that I just do not understand everything about it and there is an simpler/faster way to read the data. If anyone knows better, you are very welcome to help make OBD2 connection in RealDash better.

But I hope this helps to clarify that when you ask us for help trying to figure out how to read a certain custom value over OBD2, its actually quite a big ask.

3 Likes
8

i will try it with the value smoothing thank you!

@nssimpson
i am suggesting you to do the same approach as i did, using realdash in a Hybrid mode :slight_smile:

I get some Data from a CAN Adapter, and some of the Data through OBD2 :slight_smile:

this way i can make the best out of the available hardware that i currently have.

9

Thanks, that sounds way too complicated. I’ll see if I can figure it out using value smoothing. :slight_smile:

I’m a driving instructor so just trying to help pupils know what gear they’re in (or not in if they’re coasting).

1 Like
10

I’m trying to get the speed to exactly match my car. Not quite figured out the percentage or the way it does the rounding to a whole number.

Is there a way to make the speed round up or round down depending on what I need it to do? (Eg. 1.5 round down to 1?)

11

You can use Gauge Math as abs(V)

12

Does abs just remove the negative sign?

By adding 3.4% to the speed it gets RealDash close to my car’s displayed speed. However RealDash is 1mph slower at slower speeds and 1mph faster at higher speeds.

I think it’s a rounding issue.

Is there a way to make RealDash round the hidden decimal differently?

13

Yes, my bad. Try floor(V) to round down or ceil(V) to round up.

14

Brilliant! I’ll try this. :grin::+1:

15

Out of interest, will this round up the kph value or the final mph value?

Edit: I’ve just played around with this and it rounds up the kph before it then converts to mph, which then shows however many mph decimal places you ask to see. If the OBD standard outputs the speed in kph with no decimal places then using ceiling/floor therefore won’t do anything.

When showing 0 decimal places of the calculated mph does RealDash simply cut them off or does it do 5/4 rounding? Could a new setting be added to allow users to decide how to round?

I guess another workaround is to switch RealDash to kph and then convert to mph using the gauge math. Then ceiling/floor hopefully will work since a final internal conversion to mph won’t be carried out.

16

Using kph, adding 3.4% and ceiling is working. I just need to tweak the values but they’re practically bang on.

Instead of switching dashboard to global kph is there a way of keeping it set to mph but editing the individual dashboard to use kph as an input instead of your converted vehicle speed?

17

Also in gauge math can I use:

Round(V, MidpointRounding.AwayFromZero)

18

One option is to use custom XML file that writes the speed value to another input, for example, change line:

<command send="010d" skipCount="0" targetId="81" units="km/h"></command> <!-- speed -->

To

<command send="010d" skipCount="0" name="OBD2: My custom speed" conversion="V*0.62*1.034"></command> <!-- custom speed -->

That would create a new input that receives the vehicle speed, and as units=“km/h” has been removed, no units conversion is made by RealDash. Also note how conversion is used to convert it to miles per hour (*0.62) and scaled to your percentage (*1.034).

By doing that, a new ‘ECU Specific’ input value named “OBD2: My custom speed” will appear into RealDash, which you can then link into your speed gauge.

19

Hi, thanks for that. I’ll give it a try.

Will this break any dashboards that try to use the default converted mph speed?

Question: do I have to remove the original line or can that be left in place so dashboards work when I don’t edit the input to my custom speed?

20

If you replace the line, other dashboards will not see the speed from the vehicle. It is possible to use input mapping to map your custom speed value to vehicle speed:

  • Go to ‘Settings->Units & Values->Input Mapping’
  • Map your custom speed value to ‘Vehicle Speed’

I think you should be able to use both lines. Never tried it myself, but give it a go.