Bump/Travel/Height

For shure you can but going over 20Hz and using lap time as a reference, the data reported by Motec don`t match with those reported by the hud. You can easily verify by yourself. That's why I`m affraid other channels could also be biased so I run 20Hz only.

 

The game displaying values on the screen and you reading them is obviously limited by the rendering of that hud, the refresh rate of the display and your ability to process visual information.

I don't know what hz the physics engine is using, nor what rate the shared memory is updated at or udp packets sent, but I'd expect these to be updated at higher rates than a value on any hud or display that uses them.

 

Not entirely sure but I think I remember a dev mentioning AMS2 runs at 720Hz.

 

I'm refering to the cockpit hud, not the incar hud. There you can see each lap time in a stint along with potential time of current lap.
Nothing to do with rendering

 

You mean lap times are different? That's not really telemetry.

The lap time deltas figures do seem strange with odd rounding errors causing differences between what the hud says and what is on TT leaderboards, for example, even without considering what data motec is displaying.

The hud lacks sectors times in most of the game modes. The game throws away your lap times bar one etc, it's a mess.

 

Until 60Hz the app seems to work fine, going over 60 start to output weird datapoints, while it can still be correct, he does not inspire the most confidence. So you can at least safely run it a little bit higher than the default of 20, still far from what you would want at a minimum to deal with anything other than the basic drivers input. Anyhow, for now I will try to keep myself away from getting too deep into setup and limit myself to 1-2 clicks max from the default on anything suspension related as the engine seem to struggle modelling any extreme values.

 

Yes, app seems to work well until 60Hz but without any confidence from my side.
Any sample rate above 20Hz give unmatched final lap times between game report and telemetry. Don't know about any other channel though but the lack of confidence persists.

 

Out of curiosity, what ffb are you using?

I started looking at suspension travel rather than ride height in the telemetry app I use and from that I can see the effect the bump stops have, couldn't using ride height! So I stand corrected, the bump stops do work. Still can't feel them through ffb. I use default, default+ I find to "noisy" for my taste, with a dd1. Perhaps I should revisit the settings in the driver. More setup exploration to do...

 

Details in signature below .

 

Good point, I was wondering the same thing. I think it would just be easier for the ultra curious if Reiza made it such that the bumpstops length couldn't exceed the travel limit in the cars that have the option to modify them. At then end of the day, you could techincally run longer bumpstops than you have available travel, it would just means the car in it's natural state would be running on the bumpstops with some level of preload on the bump stops.
Not unheard of, I've actually done that on one of my race cars IRL with some pretty interesting results.

 

McPherson strut front, multilink rear.
Yep as you figured out, you can install the bumpstops in the coilover in the pre-compressed state. The sprung mass of the car will compress the coilover and you can basically run the car with shock resting on the bumpstop in its natural state.

 

There is clearly an issue with how the engine works in those "extreme" condition though, I don't think it should just be brushed. If that is not physically possible in real world and if the engine "auto correct" it, why should those values be allowed in the first place ? When a mathematical model is stress-tested, you purposefully go with extreme values and that would result in showing that there might be a bigger issue in how the model get the calculation for regular values (there is countless examples in the real world history of physics discoveries...).

The result here is clearly showing a problem that is currently very similar to a bug, and surprised quite a few people here, again I don't think this should be glanced over just because it works as expected under "normal conditions"...

 

Respectfully agree to certain degree.
Since AMS2 don't offer to setup bumpstops, it let me suppose its main function is to avoid inelastic reactions at the end of travel wich could lead to imprevisible suspension reactions in normal conditions.
Seting up a car in AMS2 to run on bumpstops is supposedly close (or very close) to a kart with differential.
Wish AMS2 could mod bumpstops as they are in real life. One day.

 

So you confirm that the 2.6 displayed when setting 100 bumpstop is the travel from the bumpstop itself ? I have been told though that bumpstops are more akin to packers without any compression in AMS2, it seems information are conflicting. Can I safely use "normal" values assuming bumpstop will have a defined compression value or not ? And if so what is the compression rate of said bumstop (as we cannot configure them anywhere).

 

@steelreserv Thanks to clarify and also thanks to @shadow82 for inquire.
Now we almost know how bumpstop works in AMS2 even at an "appropriate" progressive rate.

 

I'm not sure what there is to agree to a certain degree. I was just stating how I set up my racecar and what I tested on my racecar in real life. It was an example of what can be done IRL with having the bumpstop be part of the shock travel.