Core Features
Raspberry Pi Hardware Diagnostics
Provides quick, full, and individual diagnostic workflows for checking CPU temperature, memory availability, storage, power conditions, networking, USB devices, and kernel errors.
The full suite adds availability checks for GPIO, I2C, SPI, UART, and camera utilities. Manual inspection guidance covers physical components that software cannot fully verify.
LD19 LiDAR Detection & Validation
Automatically discovers compatible wired serial ports and validates LD19 sensor data through the D300 development kit at 230400 baud.
The application checks packet integrity, rotations, angular coverage, distance readings, and stream continuity. Detection requires valid sensor packets, preventing a connected USB adapter from being mistaken for a working LiDAR.
Guided Distance Testing
Walks users through measurements at 0.5 m, 1.0 m, and 2.0 m. Each step prompts the user to reposition a target before collecting readings and comparing the measured distance against a ±10% tolerance.
Completed results remain available throughout the sequence, making it easier to review measurements and identify inconsistent readings.
Evidence-Based Reports
Exports diagnostic sessions as JSON and plain-text reports containing device information, timestamps, individual results, collected evidence, and recommendations.
Results distinguish between passed checks, warnings, failures, unavailable interfaces, untested components, and checks requiring manual inspection.
Development Process
The Challenge
Hardware preparation involves several disconnected tasks: inspecting Linux system information, interpreting power warnings, checking interfaces, and decoding sensor data.
The challenge was bringing these tasks into an accessible desktop application while keeping the interface responsive and ensuring that missing tools, restricted permissions, or incomplete measurements never appeared as successful hardware checks.
The Solution
- Modular Diagnostic Architecture: Separated the interface, diagnostic checks, serial communication, result models, and report generation into dedicated modules. This keeps hardware logic independent of presentation and supports focused testing.
- Streaming Protocol Parser: Implemented incremental decoding of 47-byte LD19 packets with CRC-8 validation. The parser handles fragmented reads, rejects corrupted frames, and resynchronizes when valid data returns.
- Background Processing: Used Qt workers and signals to run diagnostics without blocking the interface. Progress and completed results appear as checks finish.
- Native Interface Design: Built a graphite-and-copper interface with bundled typography, geometric status markers, and detailed evidence panels. Status labels accompany visual indicators so results remain understandable beyond color alone.
Reliability & Performance
Because the application interacts with physical hardware and operating-system tools, predictable execution and accurate interpretation are central to its design.
Controlled Diagnostic Execution
System commands run without a shell and use execution timeouts. Diagnostics inspect system information and sensor data without stress testing hardware, changing configuration, or writing test patterns to devices.
Serial Connection Recovery
Handles disconnected devices, permission failures, busy ports, missing sensors, and invalid packets. Bluetooth virtual COM ports are excluded from LiDAR discovery.
Explicit Verification Limits
A passed result applies to the specific condition checked. Interface availability does not establish physical connector health, and automated software tests do not replace testing on a real Pi or sensor.
Automated Regression Coverage
The project includes 28 passing automated tests covering diagnostic decisions, report exports, packet parsing, serial failure handling, guided distance workflows, and repeated GUI runs.
Key Takeaways
Building JavaChip strengthened my experience in native desktop development, hardware communication, binary protocol parsing, and automated testing.
The project demonstrates how low-level device information can become an accessible diagnostic workflow while preserving the evidence and limitations behind each result. It also reinforced the importance of separating software verification from physical hardware validation.