AIM MXX - Dash Bracket Recommendation for You

skeeler — Mon, 27 Apr 2026 14:59:12 GMT

Hey all, been looking around for awhile for a new mounting bracket for my AIM MXS Dash, and had some information to pass along. Hopefully this will help some you looking for mounting options as well.

Ending up stumbling along and ordered a universal bracket from TrailBrake.com. With some simple modification/bending/painting, mounted perfectly to my Cayman R steering column cover.

https://trailbrake.com/mxx-universal...BA4oBbrOjtX4I5

Hope this helps!

Armchair analytics with AI and VBOX

ShakeNBake — Sun, 26 Apr 2026 17:29:33 GMT

Teaching a logger to tell oversteer from understeer, validated wet and dry at COTA

It's 58.84 seconds into a wet lap at COTA. My friend is exiting a moderate right-hander at 106 km/h in his GT4 RS, the lateral g sensor reading just 0.15, barely cornering. But the car is rotating at 44 �/s. The rear is swinging round much faster than the available grip should allow. His hands are already moving — the wheel snaps from +117� of right lock through zero to -37� of opposite lock in half a second, catches the slide, and the car settles. Total event: about 0.6 seconds.

That whole sequence is in the data. But his VBOX didn't tell him any of that. We had to teach it to...well ask an AI to teach us to teach the HD2. I'm an engineer and could have probably figured this all out if I was willing to spend a lot more time, but since I now build AI tools for work I wanted to see how much help I could get from Claude on this Journey. Here's how that went, what came out, and what we learned about which channels belong on the live overlay versus which only make sense post-session.

The setup

A 2024 Porsche 718 Cayman GT4 RS street, on sticky tires, with a RaceLogic VBOX HD2. Two sessions at COTA from my friend's track days: a dry day with a 2:16.80 fastest lap (he will tell me to tell you he's gone faster - he's a ridiculously talented driver), and a session in visibly wet pavement and rain across roughly seven laps. Same driver, same car, same track, very different grip.

Standard logging gives you raw inputs: yaw rate, lateral g, wheel speeds, pedals. What it doesn't give you is interpretation. That 44 �/s yaw spike, was that a fast corner, an oversteer slide, or a steering jab the driver self-corrected? The plan was to derive that interpretation from the raw signals using textbook chassis maths, with help from Claude, Anthropic's AI assistant, on working out the formulas and checking them against thousands of samples from example sessions. Then get those formulas working in the VBOX's Scene Editor and see whether they held up across two grip envelopes. Claud was also able to show me data plots to convince me it was working, and create tests to audit results.

One detail to flag up front: the lateral g sensor coming through the car's CAN bus has a hard limit of �1.27 g, which sticky tires at COTA exceed regularly - about 7% of the dry session is at the rail. VBOX provides a second lateral g channel computed from GPS that doesn't have that limit. Why not just use the GPS one all the time? Because the CAN sensor is the actual factory-calibrated accelerometer in the stability control system, sampled cleanly, more accurate, faster-responding. The GPS version is computed from heading rate � speed, so it picks up GPS noise on both inputs. Inside the rail, CAN is more accurate. Outside the rail, CAN is wrong by definition. Every chart in this article uses a hybrid: CAN below the rail, GPS above. Without it, the dry-session big-corner moments would silently underreport their magnitude.

The core channels

A handful of derived channels carry most of the work:

Yaw_Err_Calc is the central one. The car is rotating at some rate; the accelerometer says it's pulling some lateral g. Those two should match in a steady-state corner. If the body is spinning faster than that, the rear is stepping out: oversteer. If slower, the front is washing wide: understeer.

Counter_Steer fires only when the car is yawing meaningfully, the driver is applying opposite steering to the direction of yaw, and the yaw error confirms a real imbalance. The combination is the cleanest oversteer fingerprint in the data.

Driver_Limit is a "how hard is the car working" index combining wheel slip, yaw error, and total g. Calibrated against my friend's fastest dry lap so its color bands match meaningful effort levels.

Here are dry and wet laps side by side (the most eventful ones), with oversteer, understeer and steering correction. The dry session is more active as you'd imagine in a street car on a 2:17 lap. The wet session has more dramatic slides, but the driver was not trying to push things, and running on slicks.

(That is sensed from wheel slippage, not from the car reporting - which it does not in the data I have access to)

To check the formulas were doing real physics, Claude bucketed every cornering sample by what my friend was doing as a driver. The dry session passed every check: hard braking sat at zero (straight-line braking, no rotation), neutral cornering sat at zero, trail-braking skewed slightly positive (a touch of rotation as front load increases , physically correct), full-throttle exits skewed slightly negative ... slight understeer at corner exit, which on a mid-engine RWD on sticky tires is just the fast way around. Useful coaching feedback we hadn't asked for.

Anatomy of two slides

Here's the biggest oversteer-and-catch event in the dry data: t=427.92, an eight-second left-hander where my friend is working the car at the grip limit, on throttle, with significant opposite lock dialled in.

True peak lateral g: about 1.6 (the CAN sensor was clipped at 1.27 for much of the moment, the hybrid channel reveals the actual value). Yaw peaks at 34 �/s, the yaw-error reading at +15.7. This is high-grip oversteer: tires at their physical limit, driver at the limit of control, formula correctly identifies it.

Now the rain event:

Lateral g hovers around 0.5 g pre-slide, dropping to 0.15 g and reversing as the rear breaks loose. Yaw rate climbs to 44 �/s. Steering goes from +117� of right lock to −37� of opposite in 0.5 seconds. Yaw-error peaks at +41.5.

Side by side: same driver, same car, same track, same formula. In dry, the body rotates fast (peak 34 �/s) at the same instant grip is at its highest (1.6 g). In wet, the body rotates faster (peak 44 �/s) while grip has collapsed to 0.15 g. The wet event is a much more extreme imbalance, even though the actual lateral force on the car was lower. The channel correctly identifies both as oversteer, scales with severity, works across grip envelopes.

Validating against rain

Beyond that single event, the rain session is the broader test. If the formulas are doing real physics, slides should still be detected at lower grip , just at lower g levels.

The histogram shifts dramatically. In dry, slide events cluster between 0.9 and 1.5 g , tires working hard. In rain, the entire distribution shifts left: peak slide activity at 0.7–0.9 g, plenty of events as low as 0.3–0.5 g, and zero events above 1.3 g because the car never reaches that grip level. Slide rate roughly doubles — consistent with the car frequently exceeding available grip on the wet surface.

What this confirms is that lateral g is the wrong question for "is the car at the limit." It's not "above 1.2 g?", it's "using all the grip available right now?" The yaw-error channel captures the second question regardless of conditions.

Per-wheel detail

Four individual wheel-slip channels live in post-session territory, too many traces for a video overlay, rich material for Circuit Tools.

Three findings: the rear-left is the cleanest reference wheel (within �5% slip 95–99% of the time, both sessions). The dry session showed a lopsided rear, the right rear spinning twice as much as the left, the open-diff signature on a left-handed track. And the rain session has a strong right-side bias, with right-front slip at four times the left-front, partly because COTA is mostly left-handed (right wheels are usually outside under load), partly because the right-front briefly went airborne over a kerb at one point and read +44% slip momentarily, a moment my friend would never have spotted from in-car video.

Live overlay vs Circuit Tools

A consistent finding emerged: most analytical channels don't belong on the live overlay.

A driver's attention budget at speed is essentially zero. A bar that's green most of the time tells him nothing he could act on. The settled pattern is five live elements only: speed and gear; Driver_Limit as a vertical bar with green/yellow/orange/red bands; Handling_State as a 5-state icon; binary indicator icons for Counter_Steer, TC_Active, PSM_Active that light up only when active; and optionally an Oversteer_Index magnitude bar.

Everything else lives in Circuit Tools where you can scrub through the timeline. The reframing: the live overlay's job isn't real-time analysis. It's making moments findable for later review. Counter_Steer lighting up doesn't help my friend in the cockpit — he already knows he caught something. But after the session, scrubbing through and seeing exactly where it fired tells him which moments to review on video.

The AI angle

We went through five iterations before reaching the final set. Two wrong turns texture the AI-collaboration story honestly.

The Scene Editor kept rejecting formulas with the error "An item with the same key has already been added." Claude spent two rounds chasing what it thought was an Abs value function bug, building elaborate workarounds. The hypothesis was wrong; ABS value was fine. The actual rule that the editor trips when a single formula tries to combine two derived channels with matching units (like �/s) that both trace back to the same raw input — only emerged after my banging against the wall for a time.

Claude also confidently invented Scene Editor functions that don't exist like Lag, Prev, Delay, based, presumably, on conventions from other telemetry systems it had seen. There was no good source; Claude had been guessing from training data into a UI it couldn't see. The hybrid lat-g formula in its final form uses no previous-sample access at all, because VBOX already exposes a built-in GPS lateral channel that solved the problem trivially once we found it.

The iterative process suggests a useful frame for AI assistance on this kind of work. Claude does two distinct things at different moments. One is translating textbook into channels — generating formula candidates, working out what each piece means physically. That works well. The other is data-checking — running formulas against thousands of samples and finding the cases where they don't behave the way physics says they should. That also works well, and is what makes the difference between "this looks right" and "this is right."

What Claude couldn't do alone was understand the firmware. Every function it proposed had to be tested on the actual unit, and several rounds of formulas died because the editor rejected them in ways no documentation predicted. Iterative, cooperative, with all sides occasionally wrong.

All of the diagram you see here were generated on the fly by Claude, just by looking at VBO output files from the HD2 and running its own simulations of the proposed new maths channels. It did all of the analysis and spotting. Kind of amazing.

Takeaway

Telemetry vendors give you the inputs. The interpretive layer — the channels that actually say "this is oversteer, this is understeer, this is approaching the limit" — is what professional teams build for themselves. With AI help, that layer is now within reach for drivers whose primary experience with a track is at the wheel rather than at a workstation.

You don't have to be a vehicle-dynamics engineer to ask what your car is actually doing through a corner and get back a real answer supported by data. The tools are there. The conversation is the unlock.

Next Steps

We're going to install this scene and math channels in that same 4RS and see if we can use it to improve our skills at other tracks.

Garmin Catalyst

mdirads — Wed, 15 Apr 2026 01:11:29 GMT

I have a question regarding the original Catalyst. The device has internal storage of some capacity (I am not certain what it is), and it has two micro SD slots. I spoke with customer service and my understanding is that user profile data is stored on the internal drive. It was not clear to me from my conversation with customer service where the driving data is stored. I removed both micro SD cards and the driving data is still on the device but the video recordings are not available without an SD card inserted, so the driving data is stored in some capacity on the internal storage. My question is how much driving data is stored on the internal drive? At some point in time, that storage capacity will be exceeded.

I would like to have all historical driving data available to me for review. Is that goal possible? If the driving data is restricted to the internal drive, at what point will that data be overwritten? Does the driving data ever get stored on the micro SD cards?

Customer service rep advised me to purchase two 512 GB micro SD cards so that �I don�t have to worry about it�. Is that the plan?

In summary....
1. where is the driver profile stored?
2. is the driving data stored on the internal drive and is it possible to run out of capacity for driving data storage?
3. are the micro SD cards only used for video storage, or is the driving data also stored on the micro SD cards?

Rennlist - Porsche Discussion Forums - Data Acquisition and Analysis for Racing and DE