ScopeAI

ScopeAI turns any laptop into an AI-powered oscilloscope — plug in a circuit, get a diagnosis.

Comment

Inspiration

One of our team members, Shaurya, is a working electrical engineer. He tried using some LLM to diagnose a faulty circuit. It gave him generic advice that was completely wrong.

That's when it clicked: AI can reason about circuits in text, but it can't diagnose actual problems without real data. There's a fundamental gap between what LLMs can do and what they need to do.

We watched Purdue ECE 201 students stare at breadboards in confusion—no error messages, no feedback, just guesswork. Professional oscilloscopes cost $200–$2,000. There had to be a better way.

We decided to build a tool that captures electrical signals, trains a model on real circuit faults, and backs every diagnosis with actual data.

What It Does

ScopeAI turns any laptop into an AI-powered oscilloscope with built-in diagnostics.

You plug a circuit into an AD2, and ScopeAI:

  1. Captures the signal
  2. Extracts 5 features (frequency, amplitude, jitter, spectral spread, zero-crossing rate)
  3. Runs ML classification to identify the circuit mode and detect faults
  4. Uses GPT-4o with tool access to explain what's wrong and suggest fixes in plain English

Live dashboard shows:

  • Real-time waveform visualization
  • Signal metrics with trend deltas
  • ML diagnosis badge and confidence
  • AI chat interface where you can ask questions, capture new readings, or adjust power supply voltage

Example: Swap a timing resistor for a 10× larger value. Waveform changes. ML immediately flags "R_too_high" with 66% confidence. GPT-4o explains: "Your oscillator slowed from 200 Hz to 47 Hz. This matches a timing resistor that's ~10× too large. Swap R2 for a 2.2kΩ resistor."

How We Built It

Step 1: Hardware & Signal Acquisition

Connected the AD2 via USB to capture signals at 44.1 kHz. Configured 5V programmable power supply and built a fallback simulation mode so the project can be demoed when hardware isn't available.

Step 2: Feature Engineering

Designed 5 features that capture what electrical engineers actually look at:

  • Frequency, amplitude, jitter, spectral spread, zero-crossing rate

Used identical feature extraction logic for both training and live inference to avoid scale mismatches.

Step 3: Data Collection

Built a data collection tool with safety checks, countdown timers, and batch mode. Collected 520 real samples of the NE555P oscillator covering nominal operation and fault classes (oversized resistor, undersized resistor, missing capacitor, no oscillation).

Step 4: ML Model Training

Trained a RandomForest classifier on 520 samples across 13 fault classes. Used cross-validation to ensure robustness and exported the model for production use.

Step 5: LLM Grounding

Integrated GPT-4o to explain ML predictions with real data. Don't ask the LLM to diagnose blind. Give it ML predictions and metrics, then ask it to explain. Built two modes. Auto-diagnosis caches responses by fault type. Interactive chat gives the LLM tools to capture readings, analyze waveforms, and adjust power supply.

Step 6: Frontend Dashboard

Built a live dashboard showing waveform, signal metrics, ML diagnosis with confidence, and AI chat. Sidebar controls for circuit mode, capture interval, and simulation mode.

Challenges We Ran Into

Recording Offset from ECE Kit Equipment

When we started data collection using the standard ECE kit equipment at WALC, we noticed a consistent recording offset. The captured waveforms had phase shifts and noise artifacts that made feature extraction inconsistent across samples. Same circuit, same faults, different recordings.

Solution: We pivoted to BHEE and used their professional-grade oscilloscope and signal conditioning equipment. This gave us clean, noise-free waveforms that matched the physics we expected. The difference was immediate. Feature distributions became stable and reproducible, and our model converged perfectly.

Lesson learned: Quality matters more than quantity. We found that 200 clean samples from professional equipment gave us better results than 1,000 noisy samples from consumer hardware would have.

Feature Scale Mismatch Between Training and Inference

Early builds had features extracted slightly differently during training versus live capture. Jitter in training ranged 0 to 20 ms, but live captures hit 0 to 50 ms. Model predictions were unreliable.

Solution: Enforced identical extraction logic in both pipelines. Added assertions to validate feature ranges. Tested end-to-end in simulation mode before touching real hardware.

AD2 SDK Availability

WaveForms SDK is proprietary and platform-specific. If demo laptop didn't have it, the app crashed.

Solution: Built simulation fallback directly into the capture module. If the AD2 isn't detected, the app prints a warning and switches to synthetic waveform generation. All features still work.

Time Pressure: Ship vs. Polish

36 hours is not much time. There were endless configuration options and features we could add.

Solution: Ship the MVP. No fancy animations, no theme customization, no "nice-to-have" features. Information-dense, focused, fast.

Accomplishments That We're Proud Of

Clean Data, Fast: Collected 200 real samples from professional equipment in just 2–3 hours. Data quality was pristine. No ambiguity. No mislabeling.

Full MVP Shipped in 36 Hours: Full stack working end-to-end.

  • Hardware integration (AD2 via WaveForms SDK)
  • Feature extraction pipeline (5 hand-engineered features)
  • ML classifier (RandomForest model saved for deployment)
  • LLM integration (GPT-4o with tool calling)
  • Live dashboard (Streamlit, two-column layout, auto-refresh)
  • AI chat interface (multi-turn, with hardware tool access)

Strong Feature Engineering: Spent time on domain-driven feature design (frequency, jitter, spectral spread, zero-crossing rate, amplitude) rather than hyperparameter tuning. Features are interpretable and physically meaningful.

What We Learned

Clean, high-quality data matters more than scale. We collected 200 real samples and got strong results because they were properly labeled and had no ambiguity. Internet-scale training data would have given us hallucinations.

Focus on feature design before you tune your model. Good features on a simple classifier beats weak features on a complex one. We spent more time on feature engineering than hyperparameter optimization.

Large language models aren't diagnosticians. Asking GPT-4o "diagnose this circuit" gives generic advice. Asking it "explain this ML-verified fault with these metrics" gives precise, actionable diagnosis. The difference is in what you feed them.

Pairing ML with LLM transforms the whole thing. Circuit diagnosis goes from guesswork to data-backed reasoning. The combination is stronger than either one alone.

Domain expertise matters. Shaurya's electrical engineering background shaped everything. He designed the circuit modes, guided feature selection, and helped us collect clean data. Technical chops plus domain knowledge equals better product.

What's Next for ScopeAI

  • Collect more training data across different circuit types and hardware configurations to strengthen the model's versatility
  • Expand fault coverage (solder bridges, broken traces, component tolerance outliers, power supply issues)
  • Add circuit schematic upload/selection to give the LLM circuit context
  • Build educational content: embed best practices for circuit debugging into the LLM reasoning
  • Create a mobile app with local model inference so users don't need an oscilloscope or external API

Built With

Share this project:

Updates