The current behavior of the pit speed limiter is a bit weird and unrealistic, as well as flawed in its speed tracking. I will list the issues I have noticed, what can be improved (some suggestions have already been made in the past), and also show a custom pit limiter I implemented with a PID controller and IS_AIC packets.

The general idea of the limiter is, of course, to avoid exceeding the speed limit. LFS quite clearly uses a PID controller for this, and a heavily damped one, probably to avoid the slight overshoot that a more reactive controller can exhibit. While I believe some real-life limiters do override the throttle application to track the speed limit, it's quite common to see ignition cut as the way to limit the speed. In LFS, this could easily be done by setting throttle to zero when reaching the limit.

Now, on to the list:

• The limiter is overdamped, causing it to take some time to reach the actual speed limit.
  
• It is too conservative, and often tracks at 78-79 km/h on flat surfaces.
  
• It doesn't handle uphill properly, speed can drop to 76-77 km/h.
  

The way I see it, the PID controller uses a lot of Kd to avoid overshoot, and little to no Ki, causing the speed drop when going uphill. Either that or the actual target is wrong when going uphill, e.g. 80 km/h in 3D space which gets projected to the horizontal plane.

I played around with the AI control packets to make a custom pit speed limiter, here's a comparison video:



Key takeaways from this:

• Using only a PID controller, we can definitely improve speed tracking without overshoot, with less damping, less conservative tracking, and better uphill handling.
  
• The PID controller tracks the speed limit (with a 0.5 km/h margin in my implementation), and cuts to zero throttle if the target value is exceeded.
  
• My implementation uses a high Ki value for better uphill management, and uses Kd to control the smoothness of the tracking, which can lead to pseudo-simulating ignition cut limiters when Kd is too high.
  

The main issue I have with my current implementation is that I have to rely on the velocity vector included in the IS_AII packet, while pit limiters would normally measure speed at the wheels (driven or not, depending on the system). I believe LFS already does that, since spinning the wheels with the limiter enabled does decrease throttle.

And of course, as has already been suggested (again recently), and is shown in the video, it would be really nice to be able to set a custom speed limit (since currently, only Rockingham has a different limit).

As a final disclaimer, I have not tried any car other than the Coil Cup, so results may vary. However, cutting throttle to zero when exceeding the speed limit should work for all vehicles, and could even help avoid the current behavior where shifting up can cause a car to exceed the limit temporarily.

EDIT: A few additional notes:

• Performance is further improved by clamping the derivative term to be negative only, so we don't add excessive throttle when resuming from an "ignition cut". I also tried my implementation with a different car, the McLata GT3 (303CB1), as I know it tends to overspeed when shifting to 2nd gear - no change here, the car jumps from 79.5 to ~81.5 from shifting up due to engine inertia alone, so it would be up to the driver not to overspeed. It did however improve the behavior as the speed reaches the limit (less risk of overspeed, contained within the 0.5 km/h margin).
  
• Yes, I know that the PID I show here is technically very poorly tuned, as it is very twitchy; that is however exactly what I'm going for. "Proper" tuning is in the order of 10x lower values, much less Ki, and Kd used for "better" damping, but then I get results closer to what LFS currently does.