⚙ ShoddyTechGarage
Home Projects Learning LL8 About Contact
ShoddyHub lane • architecture and hardware plan

Automotive Hardware Prototypes

Hardware is the ShoddyHub planning lane for automotive prototypes, telemetry interfaces, bench hardware, validation scope, and the practical direction of ecosystem integration.

This is the technical plan lane, not the umbrella page or demo surface. ShoddyHub provides the map; Hardware holds the architecture, safety gates, and plan details.

View Current Scope
Open Hardware Demo Hardware Plan PDF
Physical integration lane LL8-first validation Safety-gated workflows Experimental hardware in progress

Where this page fits

The hardware pages are split by intent so the architecture, demo, and repair stance do not compete for the same first screen.

ShoddyHub

Umbrella hardware/product lane for product direction, validation posture, and companion app routing.

Open ShoddyHub

Hardware

Architecture and hardware plan for host platforms, interface tiers, write-path safety gates, and bench validation.

Open Hardware

Hardware Demo

Interactive/static demo showing telemetry context, table operations, and simulated feed behavior without live write paths.

Open Demo

Right to Repair

Philosophy, scope, and policy lane for owner visibility, diagnostics access, and cautious Atlas-family boundaries.

Open Right to Repair

Why hardware matters

Vehicle diagnostics apps do not exist in a vacuum. Data quality, polling speed, connection stability, and safety behavior are directly tied to hardware choices.

  • There is a real difference between “it connects” and “it connects well under load.”
  • Adapter quality changes whether telemetry is stable and trustworthy.
  • Host and interface hardware quality directly affects diagnostics depth and consistency.
  • Safe development requires repeatable behavior, not one-off successful sessions.

Where hardware fits in the ecosystem

ShoddyDrive

Real-time dashboards depend on stable hardware paths. Hardware quality influences responsiveness, confidence, and usability while driving.

ShoddyScan

Diagnostic depth and transport consistency depend on trustworthy interfaces and host-side orchestration.

ShoddyTune

ShoddyTune is the alpha Android companion surface for tuning review and ShoddyHubHardware API/sample-data ingest. Flash and write workflows remain outside this alpha build and require stricter validation before any future expansion.

Atlas Bot

Atlas Bot is a reference and interpretation layer. It helps explain data and workflows but is not a direct hardware control surface.

Current scope

Current work is focused on practical, validated hardware paths rather than broad compatibility claims.

Active

Practical OBD2 access

  • Adapter quality and compatibility evaluation.
  • USB and Bluetooth interface research.
  • Android-friendly hardware paths where practical.
Limited

Platform coverage

  • LL8 is the primary validation platform.
  • Additional Atlas-family behavior is reviewed after verification.
  • Expansion is staged and deliberate.
Experimental

Custom and bench hardware

  • Bench and test-rig development for supported GM platforms.
  • SBC-based host and orchestration concepts.
  • Prototype interface exploration for improved control and reliability.
Current real-world validation is centered primarily on GM Vortec 4200 (LL8). Additional Atlas-family lanes are explored only after behavior is verified.

How the system actually works

There is no single device that safely and reliably does everything alone. The hardware model is layered.

Layer 1: User and app layer

ShoddyDrive, ShoddyScan, ShoddyTune, and future tools handle display, user input, and request flow.

Layer 2: Central brain and host platform

This layer can run on a Linux-capable SBC such as Orange Pi, Raspberry Pi, or similar platforms, or other host setups used for development and validation.

  • Can be powered in vehicle-side or bench-side setups through an appropriate power solution.
  • Runs backend services and diagnostics workflows.
  • Validates conditions before any write path.
  • Handles user confirmations and safety rules.
  • Stores logs, session history, and validation output.
An SBC such as an Orange Pi or Raspberry Pi can serve as the powered central hub of the system, but separate interface hardware is still required for proper ECU communication.

Layer 3: Interface hardware (the translator)

This hardware does protocol-level translation and bus communication. It is the hands of the system.

  • Translates commands into supported vehicle protocol traffic.
  • Communicates over CAN, OBD, and related bus layers.
  • Returns responses to the host or app layer for interpretation.

Layer 4: Vehicle and ECU layer

Current focused controller lanes include P10, P12, and E67 in appropriate validation contexts.

Hardware tiers

Limited

Bluetooth OBD2 adapters

Widely available, but quality varies heavily.

  • Lower-cost clones can be inconsistent, slower, and may misreport or drop data.
  • Higher-quality Bluetooth adapters can work fairly well for basic telemetry, casual monitoring, and light diagnostics.
  • Overall limits still include slower communication than many wired paths and lower suitability for high-speed polling.
  • Not recommended as the default lane for read and write workflows.
Active

USB OBD2 interfaces

Primary focus area for stronger stability and deeper communication reliability.

  • Generally more stable for sustained sessions.
  • Better fit for higher polling rates and deeper diagnostics work.
  • Preferred baseline for advancing reliable interface behavior.
Experimental

Advanced read and write interfaces

In-development lane for controlled ECU interaction and advanced diagnostics paths.

  • Requires stricter validation due to higher risk.
  • Supports ShoddyTune alpha review and sample-data workflows only within guarded boundaries.
  • Flash and write tooling are not part of the current ShoddyTune alpha.
  • Not presented as broad production-ready support.
Experimental

Prototype hardware

  • ESP32-based designs and supporting CAN transceivers.
  • USB-connected interface concepts and breadboard prototypes.
  • Goal is tighter control and reliability than many low-cost adapter paths.
  • Still under development and validation.

Companion compute and SBC platforms

Orange Pi, Raspberry Pi, and similar SBC platforms are used as host-layer compute options for local tools and orchestration services.

What SBC platforms can do

  • Host local software and diagnostics services.
  • Store logs and validation data for repeatable testing.
  • Run offline-friendly tools and bridge services.
  • Coordinate safer ECU workflow orchestration.

Important boundary

SBC platforms are part of the host layer. They are not standalone replacements for proper OBD2, CAN, or ECU interface hardware.

How a write operation works

  1. User requests an action in the app.
  2. The app sends the request to the host platform.
  3. The host validates connection state, voltage, ECU identity, and workflow safety conditions.
  4. If conditions are safe, the host sends the command to interface hardware.
  5. Interface hardware communicates with the ECU.
  6. The ECU responds.
  7. The system logs request, response, and validation context.

Hardware demo preview

The hardware lane now includes an in-site simulation preview so people can see the flow before touching real vehicle hardware.

Hardware simulation walkthrough

This walkthrough shows the local ShoddyHub Hardware simulation surface used for validation and UI proving. It is presented inside the ShoddyTechGarage site so visitors can review the workflow without leaving the project context.

Open Hardware Demo View Full Gallery

The demo route highlights the live simulation flow, key telemetry context, and table-oriented tuning surfaces in one place.

Featured preview screens

A compact preview from the current simulation set focused on status, telemetry, live data, and map operations.

ShoddyHub Hardware demo home overview in simulator mode.

Home overview proves simulator state and connection summary can be scanned before deeper review.

Telemetry snapshot showing runtime metrics and trend preview.

Telemetry snapshot shows trend behavior under simulated load, not just a static value dump.

Live data metrics panel for RPM, trims, MAP, and other key values.

Live data metrics keep fast state visibility near the hardware context that explains the feed.

Table operations panel with map editing controls.

Table operations show the controls that need guarded framing before map-level tuning actions mature.

Hardware plan

Loading plan preview…

Bench testing and validation

ECU bench setups and controlled test environments are used to validate behavior before broader vehicle-side use. This lowers risk, improves reliability, and helps separate repeatable behavior from one-off success.

Safety and compatibility boundaries

  • Not all adapters are equal in quality or reliability.
  • Lower-cost devices may be acceptable for reading but not for advanced operations.
  • Write operations require validated hardware and guarded workflows.
  • Experimental setups are not presented as production-ready.
  • Feature expansion is secondary to safety and verified behavior.
  • Compatibility is never assumed across all vehicles or ECUs.

What is being explored

  • Adapter quality detection and health scoring direction.
  • Polling stability and transport consistency under realistic load.
  • USB communication reliability and session durability.
  • ECU communication behavior across validated lanes.
  • Android integration patterns for practical in-vehicle use.
  • SBC-based local hosting, orchestration, and future hub concepts.
  • Future custom hardware directions after safety and reliability thresholds are met.

What is coming next

Near-term output

  • Verified hardware recommendations by use case.
  • Clearer compatibility guidance for validated lanes.
  • Improved documentation and setup notes.

Ongoing development

  • Expanded test coverage and bench validation depth.
  • Safer and clearer orchestration around advanced workflows.
  • Continued iterative progress from LL8-first validation foundations.

Share your hardware results

If you are using ShoddyDrive or testing ShoddyScan, feedback on adapter stability, polling behavior, and real-world success or failure cases is extremely useful for this lane.

Join Testing Open Dev Hub Open Resources
Non-affiliation notice: References to Orange Pi, Raspberry Pi, and other third-party hardware are descriptive only. ShoddyTechGarage is not sponsored by, endorsed by, affiliated with, or officially connected to those brands. Compatibility notes do not imply partnership.

Quick routes

New here? Start with Projects. Testing? Go to How to Join. Technical? Open Dev Hub. Hardware? Open Hardware Demo.