Bump/Travel/Height

@newtonpg I will try to push the envelop.

*ahem* *cough*

Could we have a blog/pin post and have them made public ?

 

Why should we know about their stiffness? I don’t really see how it affects us

 

There is in AMS2 setup, not referring to your real life experience.

 

To make an informed decision whether to run close or not from the bumpstop, if they were packers without any compression it would indeed be advisable to never engage them under normal body movement, but as they have a compression rate the story is a bit different. On some cars you may very well want to run as close as possible to the bumpstop, but without knowing the compression rate it is very difficult to figure it out. Again, real life comparison, which this forum always seem to come back to, will not bring us far into the discussion, as it is more important to know how the game engine model works. That's what we are trying to setup, not a real car. That's why I ask all those questions.

 

i can’t think of too many situations where running on the Bumpstop is beneficial.

You can feel the difference it makes on the track .
like at adelaide running max bumpstop on GT4 which greatly reduces the travel, it’s not a good idea. the car doesn’t react well over the big bumps and it even doesn’t turn well under deceleration into tight corners because there’s not enough load being transferred to front because it’s restricted by stiffness of bumpstop .

 

All I’ve learned is that you don’t want to hit the bumpstops so I just try and avoid that. I also mostly focus on ride height

 

Obviously, on a bumpy track with a car relying mostly on weight transfer and mehcanical grip and next to no aero you don't want that (having said that though the Cayman GT4 comes with minimum bumstop of 30, which is already, based on my understanding from here, quite high). On a high downforce car though, riding very close to the bumpstop on the front is beneficial, as you want as little pitch as possible to maintain your aero platform stable, especially in very high speed corner. You can't always get there by just playing with the suspension stiffness alone and damper can only get you so far to help stabilize. That's where knowing how the bumstop react comes into play, which is hard to figure out without massive time spending testing, that could be resolve if it was available in the setup or just clearly defined somewhere.

 

Running cars on the bumpstops isn’t unheard of in real life racing. In NASCAR it’s relatively common, heck Ray Evernham pioneered the whole concept back in the late 90s with “big bar soft spring” setups when the coil spring would coil bind. When bumpstops became legal with the Gen 5/COT they began using them instead.

From what I’ve seen and done with bumpstops in the game there doesn’t seem to be much of a core issue; as Steel explained, you can have a bigger bumpstop currently than the desired spring travel, so in effect you can add a second spring damper with a large enough bumpstop, although you don’t know the stiffness and damping values. The actual effectiveness of this will depend on the car and if it has rising rate suspension or not, and so forth.

Once the bumpstop height exceeds the default static length of the spring (length at “static” ride height) it will actually extend the spring length. Imagine putting a bumpstop/packer of that size in a damper and you can see it would force the spring to extend/stretch/uncompress.

It’s very important to remember that you cannot arbitrarily cap suspension travel using a bumpstop. You’re simply introducing extra force into the suspension to prevent extra compression. Even with a bumpstop being ridden you will see a suspension travel number as from a mathematical perspective the spring isn’t at zero compression, as it needs a length value to compute the force being produced from a linear stiffness value.

Even if a component is bound it still produces a force, and the maths needs to reflect that. Just that force dramatically increases. Nothing is infinitely rigid.

 

I wasn't referring to AMS2, I was replying to @steelreserv post. :shrug:

 

I honestly don't see how, even if you knew the progressive bumpstop value, you wouldn't have to test running on them at different tracks in different conditions. Especially if you're trying to eek out a concievable advantage on others.
As Carol Smith used to say, there is no substitute for testing.

 

well I did say not too many situations… not none .
And seeing how stiff the modern f1 cars are and the difficulty that poses for drivers and engineers shows that there’s trade off in whatever they do . And they know everything about there car’s properties and still get it wrong .
they still have to put it on the track and test to compare there mathematical simulation to how it feels under the driver .
It’s the same here , you’re testing the extremes and react to how it feels , how does it effect drivability.

I note in the examples you show in page 1, that you’re not running the actual rates in set up menu, but basic unmeasurable units instead .
I would have thought you would want that information to be available first and foremost, before knowing the exact compression of a bump stop .

 

Hi, I was trying this tool for visualizing telemetry in Motec, in particular I'm interested in ride heights. From the shared memory file I see ride heights have their channel but they don't show in the logged file, as if the logger does not save the data coming out of the channels. Is this normal or did I miss something?

 

Ride height is recorded and can be seen in MoTec

 

And which are the channels? Because in the Motec workspace provided in the Github repo, Ride Height is calculated using only Susp Pos channels but it is not correct.

EDIT: I found your workspace with the correct channels, thank you very much!

 

Do we know what physical reference is used to get the height ? Is it different or the same than the one used in the setup screen ?

 

They give the same values so I assume they use the same reference. However, I do not know what the reference is for the ride height

 

@shadow82

AFAIK all AMS2 physics are officially undocumented, most references belongs to PC2 and it seems to have been ported to AMS2, Ride Height among them.

Studing RH in telemetry (Motec, Second Monitor and the dead RST) I've observed (1) stat_start value have nonsense to me but maybe useful don't know (2) parked at box at full brakes (3) parked at box brakes released (4) parked in a "flat" surface. All of those values can be close in some cars to very different in others.

The last measure (item 4) varies constantly each section of the track, lap after lap, and have no use to me.
The very first is used by Second Monitor (maybe due to practical reasons by the author, don't know) as a reference point and is satisfactory for some cars.
Items 2 and 3 are the most useful to me and I pick item 3 (parked at box without brakes) since item 2 give higher suspension and ride height values and are probably influenced by applied brakes.

Anyway, we need to stablish a reference point to the stable position of ride height (and also suspension position) to proceed other calculus.

PS: RH in setup screen seems to be measured with car on jacks

 

Does anyone else sometimes find that the ride height on the HUD changes/refreshes so fast as to be unreadable? Maybe it could instead show a .5 second average or something?