Tim Wilson

Here's plots also showing the button events saved to car state for the segments A and B ```cpp # send on change struct ButtonEvent { pressed @0 :Bool; type @1...

So neither the CAN ACC button press for res/accel or the cereal car state res/accel button press is being set in a way that corresponds to the set speed increases....

I notice that the CS.buttonEvents is only set if the conditional on line 170 of gm/interface.py runs, causing most frames to not have any data about the unpressed status of...

If the problem isn't something to do with ret.buttonEvent not being set each iteration, then it should be in controls or drive helpers:   

I'm speculating but it seems to be typical for GM ACC, so I would think it applies to all GM.

 Okey dokey!

Installing. I'll test in the morning. Looks like I'll be pressing the resume button in different scenarios. Stopped, engaging, increase set speed, resume behind lead?

Ack! That explains all the `CAMERA` I was seeing!

It's more of a sidenote that the torque controller was already fetching the other (traditional) custom FF functions. The point here is that this should be added to improve performance...

~~Shall I add the Volt and Acadia torque FF functions to this PR with routes? The Acadia route will be recorded on a C2 with commatwo_master; the Volt will use...