Before evaluating TurboAssist, it is worth understanding why the round-trip combined MPG came in at 12.64 — lower than many comparable setups. The telemetry reveals four stacked penalties, not one.
The outbound trip (descending 5,100 ft, no strong headwind) returned a respectable 14.52 mpg — entirely consistent with the tow + ProPower model. The return trip (ascending, 7 mph headwind, 91°F ambient) came in at only 11.19 mpg, pulling the composite down. This asymmetry is the real story.
The return trip log captured outside temperature — a channel absent from the outbound CSV. The findings are significant.
The 3.5L EcoBoost is documented to enter protective fuel enrichment above ~86°F OAT to manage turbocharger inlet temperatures. With 70% of moving time above that threshold on the return, a conservative 5–8% additional fuel consumption is attributable to open-loop rich operation alone — roughly 1.1–1.8 gallons of the 24.97-gallon return total. This is invisible in the RPM and load data but directly readable in the elevated fuel rate at equivalent speeds versus the outbound run.
The return trip began at near sea level (dense air, maximum turbo charge density) and climbed to 5,000 ft Prescott. Conversely, the outbound started at altitude. This means the hardest sustained climbs on the return happened as air density was dropping toward its minimum — turbos working harder for diminishing return, charge air cooling less effective in high ambient, and barometric pressure declining concurrently. The return log's Barometric Pressure channel confirms this gradient. The outbound "earned" its altitude gain for free as gravitational potential energy on descent; the return paid the full toll in fuel.
Together, heat enrichment + altitude climb account for an estimated 2–3 mpg of the 3.33 mpg gap between outbound and return, beyond the pure grade and wind contributions. The 12.64 round-trip composite is thus a reasonable — if unflattering — result for this specific route, temperature window, and payload. A cooler-season run of the same route would likely show 13.5–14.5 mpg combined.
The TurboAssist proposal centers on keeping the PowerBoost within its BSFC efficiency island (1,800–2,800 RPM). The actual RPM distribution across both trips reveals a counterintuitive finding.
| RPM Band | Outbound % time | Return % time | Outbound fuel rate | Return fuel rate |
|---|---|---|---|---|
| <1,000 RPM | 8.7% | 4.1% | 0.07 gal/hr | 0.17 gal/hr |
| 1,000–1,400 RPM | 9.7% | 7.3% | 2.67 gal/hr | 2.31 gal/hr |
| 1,400–1,800 RPM | 61.6% | 59.4% | 4.10 gal/hr | 4.50 gal/hr |
| 1,800–2,200 RPM (island) | 10.5% | 20.4% | 5.40 gal/hr | 5.94 gal/hr |
| 2,200–2,800 RPM (island) | 5.6% | 6.0% | 4.17 gal/hr | 9.39 gal/hr |
| >2,800 RPM | 3.9% | 2.8% | 2.02 gal/hr | 5.46 gal/hr |
Mean RPM is 1,464 outbound and 1,684 return. The engine runs below 1,800 RPM for 80% of outbound moving time and 71% of return moving time. The "efficiency island" as defined in the TurboAssist proposal (1,800–2,800 RPM) is reached only 16% and 26% of the time respectively. Counterintuitively, fuel rate is higher inside the island than outside — because entry into the island coincides with grades and acceleration events, not cruise. The truck is not "drifting out" of the island by climbing too high in RPM; it is largely operating below the island at very light throttle cruise.
This suggests the BSFC trigger condition in the OWASYS logic should be defined by engine load percentage and boost pressure (both available via OBD PIDs 43 and 0B), not primarily by RPM band. The outbound log's Absolute Load channel shows 32.4% of moving time above 70% load — those are the intervention windows where TrekDrive assist would pull the engine back toward lower throttle opening. Load-based triggering aligns with how BSFC islands are actually shaped on a turbocharged direct-injection engine: they form diagonally across the RPM/torque map, not in a pure RPM band.
The proposal's core energy balance claim — that intermittent TrekDrive at ~50% duty can achieve net-zero battery depletion while holding the ProPower charging loop active during State B — is evaluated against the round-trip telemetry.
| Energy source / sink | Rate | Active condition | Round-trip contribution |
|---|---|---|---|
| ProPower (State B) | +5.8 kW | PP ON, TrekDrive OFF | +48.6 kWh (8.38 hr) |
| Solar (partial cloud) | +1.8 kW peak | Daylight, ~50% effective | +7.6 kWh |
| Regen braking | Up to 30 kW | Descents, deceleration | +3–8 kWh est. |
| TrekDrive (State A) | −15 kW | High load trigger, ~3.5% time | −5.0 kWh (0.33 hr) |
| Net battery change | +54–58 kWh (strong positive) |
At the actual high-load duty cycle observed in this telemetry (~3.5% of moving time above 2,800 RPM, ~30%+ above 70% load), TrekDrive assist would consume approximately 4–6 kWh per round trip in State A. ProPower in State B replenishes 48+ kWh. The 77 kWh LightShip battery would end the round trip with a net surplus of 45–55 kWh relative to start. The net-zero concern in the proposal is more relevant for flat-terrain routes where TrekDrive duty cycle could rise — this Prescott route has sufficient descent-and-cruise time to more than compensate.
The proposal cites a 15–20% fuel efficiency improvement. Applying that to the drivetrain portion only (38.10 gal of the 44.12 gal total — the 6.03 gal ProPower fuel is invariant to TrekDrive assist):
The 15–20% figure likely reflects the efficiency gain achievable during the fraction of time the engine is at high load — not a uniform improvement across all operating conditions. Since the engine is at high load ~30–35% of moving time (Absolute Load >70%), a 20% improvement during those windows translates to roughly 6–7% overall drivetrain saving in practice. To reach the full 15–20% overall improvement, TrekDrive would need to materially reduce fuel consumption during moderate-load cruise as well, not just during acute high-load events. This is achievable if the OWASYS logic is tuned to maintain load below ~65% continuously, rather than only intervening at crisis thresholds.
The State A/B interleaving is the most technically demanding piece of the proposal. The current hardware constraint — NACS connector presence blocking Road Mode — is the primary engineering gate. Once that software restriction is lifted, the OWASYS arbitration logic must manage NACS on/off transitions quickly enough to avoid voltage transients on the LightShip HV bus when switching between charging and TrekDrive motoring modes. A soft ramp (500ms–1s) on both ingress and egress from each state is advisable to protect BMS cell balancing and avoid contactor wear.
Current LightShip software restricts TrekDrive activation/deactivation to a standing-still condition. This constraint must be completely removed for TurboAssist to function. Additionally, the proposal correctly identifies the need to separate motor mode from regenerative braking mode as independent commands — the current combined-toggle architecture would cause TrekDrive regen to fire during State B cruise (where the engine is already in its efficient operating range and trailer braking force is unwanted). This is a non-trivial firmware change requiring thorough validation of edge cases, particularly during grade transitions where state could toggle rapidly.
The proposed ESP32-CAN-X2 bridge ($55) is adequate for Phase 1/2 validation. For production, the MRS Electronic CAN Gateway is the right call — it handles automotive CAN timing requirements, supports 500kbps and 250kbps simultaneously, and is designed for in-vehicle thermal environments. The wiring run from OBD port → bed EVSE → AeroHub should be shielded twisted pair CAN (120Ω terminated at both ends) to prevent RF interference from the inverter switching noise.
One recommendation beyond the proposal: add outside air temperature (OBD PID 46) to the data stream. As demonstrated in the return trip telemetry, OAT above 86°F changes the effective BSFC map — the engine enriches open-loop, raising the fuel rate at equivalent load. The OWASYS lookup table should incorporate an OAT correction layer so TrekDrive assist is more aggressive on hot days, when the enrichment penalty is largest and the benefit of load reduction is greatest.
The proposal's most commercially significant claim is that TurboAssist scales to pure ICE vehicles (standard EcoBoost, 6.2L Silverado, 5.7L Hemi). The gear-hunting problem is real and documented: a 10-speed automatic at highway towing load oscillates between 8th, 9th, and 10th gears on minor grades, producing RPM excursions of 400–600 RPM and momentary fuel rate spikes.
The pure ICE application may actually show a larger absolute benefit than the PowerBoost case, precisely because the PowerBoost's native MGU already partially smooths torque requests. A pure ICE truck has no electric buffer — every grade load directly hits the transmission shift logic. TrekDrive's ability to "clip the peak" and hold the transmission in overdrive is high-value here. Transmission gear status (PID 0A or manufacturer-specific) plus engine load would be the two-signal trigger. The LightShip's 30 kW regen capacity also means significant energy can be harvested on descents that currently dissipates entirely as heat in the trailer's axle brakes.
| Claim / Component | Assessment | Confidence |
|---|---|---|
| Net-zero battery on Prescott route | Strongly achievable — PP surplus overwhelms TrekDrive draw | High |
| 15–20% efficiency gain (overall) | Achievable at upper bound only with continuous load management, not threshold-only triggering | Medium |
| 15–20% gain during high-load events | Plausible — engine at 70%+ load shows highest BSFC penalty | High |
| RPM island as primary trigger | Needs revision — engine runs below island 70–80% of time; load is better primary signal | High (data-based) |
| OAT correction in BSFC table | Not in proposal — missing variable, return trip shows material enrichment effect | High (data-based) |
| In-motion TrekDrive toggle | Requires firmware change — highest engineering risk in the program | Medium |
| NACS concurrent/interleaved operation | Requires LightShip software constraint removal — feasible but gated on firmware | Medium |
| ESP32 CAN bridge (Phase 1) | Appropriate and sufficient for data mapping phase | High |
| ICE vehicle scalability | Strong case — potentially larger benefit than PowerBoost due to absence of native MGU | High |
| 12.64 mpg baseline (expected?) | Yes — heat, altitude climb, headwind, and ProPower load fully explain the result | High |
The TurboAssist concept is sound and the energy math on this specific route is favorable. The two modifications recommended by this analysis are: (1) replace RPM-band as the primary trigger with engine load percentage (OBD PID 43), with OAT correction applied to the BSFC lookup table; and (2) treat in-motion TrekDrive toggle and motor/regen mode separation as the critical path items in the firmware development plan, since everything else in the system architecture depends on those two capabilities being reliable and safe.