Rewrite story with voltage-focused 4G module analysis and add discharge curve visualization

Major story revision based on real-world testing and analysis:

**New Findings:**
- Root cause: Voltage drop below 3.45V (4G module minimum), not power budget
- SimTech SIM7600G-H operates at 3.4-4.2V; hangs below 3.45V threshold
- FEB-4000 battery test: 13.4 Wh usable (54%) above 3.45V threshold

**New Features:**
- Add 3.45V reference line to Energy Output vs. Voltage chart
- Visual indicator for 4G module minimum voltage threshold
- Real discharge curve analysis from 2h 48m FEB-4000 battery test

**Story Changes:**
- Focus shifted from power (watts) to voltage stability
- Include community discussion findings from ClockworkPi forums
- Add detailed FEB-4000 test results with screenshots
- Reframe 4G power manager as voltage-aware solution
- Add battery rating methodology based on usable capacity above 3.45V

**Screenshots Added:**
- feb4000-battery-percentage.png - Full discharge curve
- feb4000-voltage-current.png - Voltage/current trends
- feb4000-energy-output-with-threshold.png - Critical 3.45V analysis

This reflects the actual discovery: not insufficient wattage, but voltage sag under load causing 4G module brownout.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
2025-11-06 15:30:53 +08:00
parent 9a6ceed18a
commit 5b5c2dfa4e
5 changed files with 181 additions and 140 deletions

306
STORY.md
View File

@@ -1,4 +1,4 @@
# Vibe Coding Chronicles: Solving uConsole's Power Crisis with a Pocket-Sized Dev Environment
# Vibe Coding Chronicles: Solving uConsole's 4G Module Voltage Crisis
> **Part of the "Vibe Coding for Work/Life" series** — Real stories of building custom solutions anywhere, using portable devices and modern tools to solve everyday problems.
@@ -6,62 +6,66 @@
Imagine debugging a device's power management issues while lounging in a coffee shop, building the diagnostic tools directly on that same device. No desktop workstation. No "I'll fix this when I get home." Just you, a pocket-sized computer, and the freedom to solve problems wherever inspiration strikes.
This is how I spent one Saturday afternoon solving the uConsole CM5's notorious power hang issue—and discovered something profound about modern development workflows.
This is how I spent one Saturday afternoon solving the uConsole CM5's notorious 4G module hang issue—and discovered it wasn't about power delivery at all. It was about **voltage drop**.
## The Problem: When Innovation Meets Physics
## The Problem: When Innovation Meets Voltage Physics
The [ClockworkPi uConsole](https://www.clockworkpi.com/uconsole) is a hacker's dream: a Raspberry Pi CM5 squeezed into a clamshell form factor with a mechanical keyboard and modular expansion bays. It's the kind of device that makes you want to tinker, customize, and push boundaries.
But there was a frustrating catch. Enable the 4G expansion module on battery power, and the system would randomly freeze—dead in its tracks. The only fix? Physical battery removal and restart.
Forum threads filled with theories: buggy software, faulty batteries, hardware defects. The root cause remained a mystery. Users were stuck choosing between mobility (battery power) and connectivity (4G), but never both reliably.
Forum threads filled with theories: buggy software, faulty batteries, insufficient power delivery. The root cause remained a mystery. Users were stuck choosing between mobility (battery power) and connectivity (4G), but never both reliably.
I decided to investigate—but here's the twist: I'd build all the diagnostic tools **on the uConsole itself**, while running on battery power. If I could solve the problem using the very device experiencing it, that would prove the viability of "vibe coding" as a real-world workflow.
## The Investigation: Following the Electrons
## The Investigation: It's Not Watts, It's Volts
Sitting at a coffee shop with the uConsole on battery power, I started digging. First stop: Linux's sysfs interface, which exposes raw hardware data. The uConsole uses an **AXP228 PMIC** (Power Management IC) to juggle power between batteries, USB, and the system.
Sitting at a coffee shop with the uConsole on battery power, I started digging. First stop: Linux's sysfs interface, which exposes raw hardware data. The uConsole uses an **AXP228 PMIC** (Power Management IC) to manage power.
A few hours of research—datasheets, forum deep-dives, and measurements—revealed the culprit:
A few hours of research—datasheets, forum deep-dives, and real-time measurements—revealed the **actual culprit**:
1. **Battery Configuration**: The two 18650 batteries are wired in **parallel** (not series), meaning they share the load simultaneously without switching[^1].
### The 4G Module's Voltage Requirements
2. **Power Limits**:
- The AXP228 can sustainably deliver ~18-20W from the battery discharge path
- The CM5 + 4G module can peak at **22-25W** during transmission
- This mismatch triggers the PMIC's over-current protection (OCP)
The **SimTech SIM7600G-H** 4G LTE module has strict voltage requirements:
- **Operating Range**: 3.4V to 4.2V (typical 3.8V)[^1]
- **Current Draw**: Up to 2A during GSM/GPRS transmission bursts
- **Minimum Safe Voltage**: **3.45V** to avoid brownout-induced hangs
3. **The IPS™ Circuit**: The AXP228's Intelligent Power Select transparently routes power from USB, AC, or battery. On USB power, it can supplement battery power for combined delivery of ~25W[^2].
### The Voltage Drop Problem
**Key Citations:**
- [AXP228 Product Page - X-Powers](http://www.x-powers.com/en.php/Info/product_detail/article_id/31)
- [uConsole Forum: Battery Configuration Discussion](https://forum.clockworkpi.com/t/understanding-battery-module-pinout-upgrading-battery-module/10260)
- [4G Module Shutdown Issues](https://forum.clockworkpi.com/t/battery-life-not-as-expected-4g-module-shuts-the-whole-thing-down/12633)
When lithium-ion batteries discharge under heavy load:
1. **Voltage sags** due to internal resistance
2. The 4G module draws high current (2A bursts)
3. Battery voltage drops below 3.45V momentarily
4. **4G module browns out** and hangs the USB bus
5. System becomes unresponsive
## The Insight: It's Not the Batteries, It's the Math
**This isn't about total power (watts)—it's about maintaining minimum voltage under load.**
The issue wasn't battery quality or switching—it was simple power budget arithmetic:
### Community History: The Missing Piece
```
CM5 peak power: 15W
4G module peak: 10W
Display + other: 3W
─────────────────────────
Total peak demand: 28W
Forum discussions at ClockworkPi revealed users experiencing:
- CM5 boot failures with 4G module present
- 4G module disconnecting after short operation
- System hangs specifically during 4G transmission[^2]
AXP228 battery max: 20W ⚠️ PROBLEM
AXP228 USB+battery: 25W ✓ Works
```
The pattern was clear: **voltage sensitivity**, not power budget exhaustion.
**Solution**: Reduce CPU power consumption when 4G is active to keep total load within the 18-20W battery budget.
## The Insight: Battery Capacity vs. Usable Capacity
The breakthrough came from building a new diagnostic chart: **Battery Energy Output vs. Voltage**. This discharge curve reveals something critical that percentage-based monitoring misses:
**Not all battery capacity is usable for 4G operation.**
Once voltage drops below 3.45V, the remaining charge is **unusable for 4G connectivity**, even though the battery might show 20-30% remaining capacity.
## Building the Solution: Vibe Coding on uConsole
This is where "vibe coding" shines. Instead of context-switching to a desktop workstation, I built the entire solution **on the uConsole itself**, iterating rapidly with AI assistance.
### Phase 1: Real-Time Monitoring (Next.js 16 + React 19)
### Phase 1: Real-Time Monitoring with Voltage Analysis
I built a battery monitoring web app to visualize the power problem:
I built a battery monitoring web app with a critical new feature: **voltage-based discharge curve analysis**.
**Tech Stack:**
- Next.js 16 with App Router
@@ -72,102 +76,117 @@ I built a battery monitoring web app to visualize the power problem:
**Key Features:**
- Reads directly from Linux sysfs (`/sys/class/power_supply/axp20x-battery/`)
- Displays voltage, current, power, percentage in real-time
- Displays voltage, current, power, percentage, and **energy capacity** in real-time
- **New**: Battery Energy Output vs. Voltage discharge curve
- Separates monitoring (display only) from recording (database writes)
- Buffers up to 1000 readings for retroactive session recording
**Why This Approach?**
By separating monitoring from recording, I could observe battery behavior without filling the database. When I spotted something interesting, I could click "Start Recording [from monitoring start]" to retroactively save the buffered data.
### The FEB-4000 Battery Test: Real Data, Real Insights
![Battery Monitor Interface](.playwright-mcp/battery-monitor-full-interface.png)
*Complete battery monitoring interface showing real-time metrics, interactive charts, and session management*
I conducted a complete discharge test using **FEB-4000 4000mAh 18650 batteries** (100% to ~2%), capturing 4,318 readings over 2 hours and 48 minutes.
### Real-Time Monitoring Dashboard
![Battery Percentage Over Time](story-assets/feb4000-battery-percentage.png)
*Complete discharge curve from 100% to near-empty, showing smooth discharge profile*
The main interface displays live battery metrics with a clean, focused design:
![Voltage & Current Trends](story-assets/feb4000-voltage-current.png)
*Voltage and current trends during discharge—note the voltage decay pattern*
![Battery Status Card](.playwright-mcp/screenshots/battery-status-live.png)
*Real-time battery status showing charge level, voltage, current, power consumption, and monitoring controls*
### The Critical Discovery: Usable Capacity at 3.45V Threshold
The dashboard separates monitoring from recording—you can observe battery behavior live without writing to the database. When you spot something interesting, click "Start Recording" and choose whether to save from now or retroactively from when monitoring started.
Here's the game-changer chart that reveals battery suitability for 4G use:
### Interactive Charts
![Energy Output vs Voltage with 3.45V Threshold](story-assets/feb4000-energy-output-with-threshold.png)
*Discharge curve showing the **3.45V - 4G Module Min** threshold (red dashed line). The chart plots energy output (mWh) against voltage drop, revealing usable capacity for sustained 4G operation.*
Three separate charts provide different perspectives on battery performance:
**FEB-4000 Battery Results:**
- **Total Capacity**: 24,790 mWh (24.79 Wh)
- **Usable Capacity (above 3.45V)**: **13,387 mWh (13.4 Wh)**
- **Unusable Below 3.45V**: 11,403 mWh (11.4 Wh)
- **Usable Percentage**: 54% of total capacity
![Battery Charts](.playwright-mcp/screenshots/charts-grid.png)
*Battery Percentage and Power Consumption charts showing real-time trends*
**This means:** With FEB-4000 batteries, you can only use about **half the rated capacity** for reliable 4G connectivity. Once you hit 3.45V (~50% remaining), the 4G module becomes unstable.
![Voltage and Current Chart](.playwright-mcp/screenshots/voltage-current-chart.png)
*Voltage & Current Trends with dual Y-axes for precise monitoring*
### Rating Batteries for 4G Use
The charts update every 2 seconds, providing immediate visual feedback on power consumption patterns. This was crucial for diagnosing the 4G power issue—I could literally watch the power spike when the modem activated.
The **Energy Output vs. Voltage** chart becomes a **battery rating tool**:
### Session Management
**Good 4G Batteries**: High usable capacity above 3.45V
- High discharge rate (15-20A CDR)
- Low internal resistance
- Voltage stays above 3.45V for majority of capacity
Recording sessions can be named, exported, and managed individually:
**Poor 4G Batteries**: Voltage drops quickly under load
- Low discharge rate (<10A CDR)
- High internal resistance
- Voltage sags below 3.45V early in discharge cycle
![Recording Sessions](.playwright-mcp/screenshots/recording-sessions.png)
*Saved recording sessions with download, edit, and delete options*
**Recommended Batteries:**
- Samsung 25R (2500mAh, 20A CDR) - High voltage stability
- Samsung 30Q (3000mAh, 15A CDR) - Good capacity + voltage
- Sony VTC6 (3000mAh, 15A CDR) - Excellent under load
- LG HG2 (3000mAh, 20A CDR) - Best voltage retention
![Session Editing](.playwright-mcp/session-edit-mode.png)
*Inline editing of session names for easy identification*
### Phase 2: Automatic Power Management (Voltage-Aware)
Each session captures a complete picture of battery behavior during a specific time period. I used this to document the before/after behavior of the 4G power manager.
With voltage identified as the culprit, the power manager takes a different approach:
### Data Export
The app provides flexible export options:
![Export Custom Time Range](.playwright-mcp/export-custom-time-range.png)
*Custom time range selection for targeted data export*
You can export per-session data or select custom time ranges for analysis in external tools like Excel or Python notebooks.
### Phase 2: Automatic Power Management (Bash + udev + systemd)
The monitoring app confirmed the power spikes. Next, I needed automatic mitigation:
**4G Power Manager Components:**
**4G Power Manager Strategy:**
- Reduce CPU frequency when 4G is active to **lower current draw**
- Lower current = less voltage sag under load
- Keep voltage above 3.45V threshold during 4G operation
**Implementation:**
1. **Detection Script** (`4g-power-manager.sh`):
- Detects 4G modem state using multiple methods:
- `wwan0` interface status
- ModemManager state (connected/registered)
- Network traffic analysis
- When 4G active: `powersave` governor + 1.8GHz max (saves 20-30% power)
- When 4G inactive: `ondemand` governor + 2.4GHz max (full performance)
- Detects 4G modem state (wwan0 interface, ModemManager status)
- When 4G active: `powersave` governor + 1.8GHz max
- Reduces total current draw by 20-30%
- **Result**: Less voltage sag, more stable operation
2. **udev Rules** (`99-4g-power-manager.rules`):
- Triggers on USB modem device changes (vendor:product = 1e0e:9001)
- Monitors `wwan0` interface state
- Responds to ttyUSB and cdc-wdm device events
3. **Systemd Service** (`4g-power-monitor.service`):
- Background daemon checking modem state every 5 seconds
- More reliable than udev alone for network activity changes
- Auto-restarts on failure
4. **Installation Script** (`install-4g-power-manager.sh`):
- One-command setup with uninstall option
- Creates logs, sets permissions, reloads services
2. **udev Rules** + **Systemd Service**:
- Automatic triggering on modem state changes
- Background monitoring every 5 seconds
**Testing Results:**
```
Before: CM5 @ 2.4GHz + 4G = 22-25W → System hangs
After: CM5 @ 1.8GHz + 4G = 16-20W → Stable operation
Before: CM5 @ 2.4GHz + 4G = High current → Voltage sag → Hang
After: CM5 @ 1.8GHz + 4G = Lower current → Stable voltage → Reliable
```
## Why This Discovery Matters: Understanding Battery Limitations
The traditional view was:
> "The AXP228 can't deliver enough power (watts) for CM5 + 4G"
The **actual reality**:
> "Battery voltage drops below 4G module minimum under high current load"
**This is why:**
- USB power helps: It reduces battery current draw, keeping voltage stable
- High-CDR batteries work better: Lower internal resistance = less voltage sag
- CPU frequency scaling helps: Reduces total current, preventing voltage drop
### The Battery Selection Problem
Users were buying batteries based on:
- ❌ Capacity (mAh) alone
- ❌ Price and availability
- ❌ "Recommended for uConsole" lists
**They should be selecting based on:**
-**Continuous Discharge Rate (CDR)**: 15A minimum
-**Internal Resistance**: Low (verified by voltage retention tests)
-**Usable capacity above 3.45V**: Measured with the discharge curve chart
## Why Vibe Coding Works: The Magic of Zero Context Switching
Here's what blew my mind: this entire project—from "hmm, why does this crash" to "production-ready solution with installer scripts"—took about **8 hours**. One Saturday afternoon. No workstation. No separate test device. Just me, the uConsole, and a cup of coffee.
Here's what blew my mind: this entire project—from "hmm, why does this crash" to "production-ready solution with new battery rating methodology"—took about **10 hours across two days**. No workstation. No separate test device. Just me, the uConsole, and iterative development.
**The secret sauce:**
1. **Immediate Feedback**: The problem is right in front of you. Build a chart, watch it live, spot the issue, fix it, repeat.
1. **Immediate Feedback**: The problem is right in front of you. Build a chart, watch it live, spot the voltage issue, fix it, repeat.
2. **Modern Tooling**: Next.js hot reload means changes appear in seconds. TypeScript catches bugs before they run. AI assists with boilerplate and research.
3. **Zero Context Loss**: No mental overhead switching between devices. The debugging environment IS the target environment.
4. **Location Independence**: Coffee shop gets boring? Move to a park bench. Train ride? Perfect coding time.
4. **Location Independence**: Coffee shop gets boring? Move to a park bench. Battery testing during a train ride? Perfect.
5. **Constraint-Driven Design**: Limited screen space forces you to build cleaner UIs. Battery consciousness makes you write efficient code.
**The workflow becomes circular:**
@@ -183,19 +202,20 @@ This isn't just faster—it's more *fun*. You're in flow state, building exactly
Ten years ago, solving this problem would've required:
- An engineering workstation
- Oscilloscope and power analyzer
- Cross-compilation setup
- Separate test hardware
- Days of context-switching frustration
Today? A $200 pocket computer and one focused afternoon.
Today? A $200 pocket computer, real-time software monitoring, and one focused weekend.
**This isn't just about professional developers**. Vibe coding opens doors for:
- **Hobbyists**: Build custom dashboards for your home automation without a full dev setup
- **Field Researchers**: Create data collection tools on-site, adapted to real conditions
- **Sys Admins**: Prototype monitoring solutions while physically at the server rack
- **Makers**: Debug hardware projects on the workbench, no desktop required
- **Students**: Learn full-stack development on truly portable hardware
- **Hobbyists**: Build custom dashboards for battery-powered projects
- **EV/Battery Enthusiasts**: Create discharge curve analyzers for battery testing
- **Field Researchers**: Monitor power consumption in remote deployments
- **Makers**: Debug hardware projects with real-time voltage monitoring
- **Students**: Learn full-stack development while understanding electrical engineering
The barrier to entry for "scratch your own itch" development just collapsed. If you can imagine a solution, you can probably build it—wherever you are right now.
@@ -238,16 +258,22 @@ sudo ./install-4g-power-manager.sh
**Key Features:**
**Real-time Monitoring**
**Real-time Voltage Monitoring**
- Live battery metrics updated every 2 seconds
- Interactive charts (percentage, power, voltage, current)
- Visual indicators for charging/discharging state
- **NEW**: Battery Energy Output vs. Voltage discharge curve
- Visual indicators for 3.45V threshold
**Smart Recording**
- Separate "Monitor" (display only) from "Record" (save to DB)
- Option to record from "now" or retroactively from monitoring start
- Session management with custom naming
**Battery Rating Tool**
- Discharge curve analysis for battery selection
- Calculate usable capacity above voltage thresholds
- Compare different battery models
**Data Export**
- Per-session CSV export
- Custom time range export
@@ -255,7 +281,7 @@ sudo ./install-4g-power-manager.sh
**4G Power Management**
- Automatic CPU frequency scaling when 4G is active
- Prevents system hangs on battery power
- Prevents voltage sag and system hangs
- Transparent operation with logging
**Easy Uninstall**
@@ -263,23 +289,15 @@ sudo ./install-4g-power-manager.sh
sudo ./install-4g-power-manager.sh uninstall
```
## Lessons Learned: The Power of Constraints
## Lessons Learned: The Power of Voltage Awareness
Working exclusively on the uConsole taught me valuable lessons:
1. **Constraints Breed Creativity**: Limited screen space forced better UI design
2. **Performance Matters**: Running on CM5 made me optimize database queries
3. **User Testing is Instant**: I'm the user—feedback is immediate
4. **Portability Enables Focus**: No distractions, just flow state coding
**Battery Recommendations:**
For optimal performance, use high-drain 18650 cells:
- Samsung 25R (2500mAh, 20A CDR)
- Samsung 30Q (3000mAh, 15A CDR)
- Sony VTC6 (3000mAh, 15A CDR)
- LG HG2 (3000mAh, 20A CDR)
Avoid generic/unbranded cells with <10A discharge rating.
1. **Measure the Right Thing**: Watts aren't everything—voltage stability matters
2. **Visual Tools Reveal Truth**: The discharge curve made the problem obvious
3. **Constraints Breed Creativity**: Limited screen space forced better UI design
4. **User Testing is Instant**: I'm the user—feedback is immediate
5. **Portability Enables Focus**: No distractions, just flow state coding
## What's Next: More Vibe Coding Stories
@@ -301,7 +319,8 @@ Want to share your vibe coding story? Tag it `#VibeCodingChronicles` and let's b
1. **Get the Hardware**: [uConsole CM5 from ClockworkPi](https://www.clockworkpi.com/uconsole)
2. **Clone the Repo**: `git clone https://hiwifi.denq.us:8418/denq/battery-monitor.git`
3. **Follow the README**: Complete setup guide included
4. **Share Your Mods**: The code is GPL v3—fork it, improve it, share it
4. **Test Your Batteries**: Use the discharge curve to find the best batteries for 4G
5. **Share Your Results**: Submit battery test data to help the community
**Questions? Issues? Contributions?**
- ClockworkPi Forum: [https://forum.clockworkpi.com/c/uconsole](https://forum.clockworkpi.com/c/uconsole)
@@ -311,7 +330,7 @@ Want to share your vibe coding story? Tag it `#VibeCodingChronicles` and let's b
There's something profoundly satisfying about identifying a problem on a device and building the solution **on that very device**. No "I'll fix this later." No context switching. Just pure, focused problem-solving in the moment.
The uConsole CM5 now runs stably on battery with 4G active. The battery monitor provides real-time insights into power consumption. And the entire solution—from diagnostic web app to system-level power management—was built in one focused afternoon session.
The uConsole CM5 now runs stably on battery with 4G active. The battery monitor provides real-time insights into voltage behavior. And the entire solution—from diagnostic web app to system-level power management—was built in one focused weekend.
**This is vibe coding**: Building custom solutions with joy, anywhere inspiration strikes. Not because you have to, but because you *can*.
@@ -325,33 +344,39 @@ The tools are here. The hardware is affordable. The only question is: what will
## Technical Appendix
### Power Budget Analysis
### Voltage vs. Power: Why Both Matter
| Component | Idle | Normal | Peak |
|-----------|------|--------|------|
| CM5 CPU | 2W | 8W | 15W |
| 4G Module | 0.5W | 3W | 10W |
| Display | 1W | 2W | 3W |
| Other | 1W | 2W | 2W |
| **Total** | **4.5W** | **15W** | **30W** |
| Metric | Importance | Impact on 4G Stability |
|--------|------------|------------------------|
| Total Power (W) | System-wide load | Triggers PMIC over-current protection |
| Battery Voltage (V) | Module brownout threshold | **Direct cause of 4G hangs** |
| Current Draw (A) | Causes voltage sag | High current → voltage drop |
| Internal Resistance (mΩ) | Voltage stability | Low resistance = stable voltage |
**AXP228 Limits:**
- Battery discharge path: ~18-20W sustained
- USB + battery: ~25W sustained
- Peak spikes: Handled briefly, then OCP triggers
### FEB-4000 Battery Detailed Results
**With 4G Active @ 1.8GHz:**
- CM5: ~8-10W (reduced from 12-15W)
- 4G: ~5-10W (during transmission)
- Other: ~3W
- **Total: ~16-23W** (within limits)
**Test Conditions:**
- Battery: FEB-4000 4000mAh 18650 (2 cells in parallel)
- Load: uConsole CM5 + 4G module active
- Duration: 2h 48m 26s
- Readings: 4,318 data points
**Voltage Thresholds:**
- Start: 4.028V (100%)
- 3.45V Crossed: 2h 5m into discharge (54% capacity consumed)
- End: ~3.3V (near protection cutoff)
**Energy Breakdown:**
- Total Energy: 24.79 Wh
- Usable (>3.45V): **13.39 Wh (54%)**
- Unusable (<3.45V): 11.40 Wh (46%)
### API Endpoints
The battery monitor provides a RESTful API:
```
GET /api/battery # Current battery data
GET /api/battery # Current battery data (includes capacity)
GET /api/battery?save=true # Save current reading to DB
GET /api/battery/history # Query historical data
GET /api/battery/sessions # List all sessions
@@ -373,17 +398,20 @@ interface BatteryData {
status: string; // "Charging", "Discharging", "Full"
health: string; // "Good", "Unknown"
acConnected: boolean; // true if AC adapter connected
capacityFull: number; // calibrated full capacity (Wh)
capacityNow: number; // current capacity (Wh)
capacityDesign: number; // design capacity (Wh)
}
```
---
**Tags:** #uConsole #RaspberryPi #VibeCoding #NextJS #BatteryManagement #PowerManagement #IoT #PortableComputing #AIAssistedDevelopment
**Tags:** #uConsole #RaspberryPi #VibeCoding #NextJS #BatteryManagement #VoltageAnalysis #4GModule #IoT #PortableComputing #AIAssistedDevelopment
**License:** GPL v3 (same as uConsole hardware designs)
---
[^1]: Battery Configuration - [ClockworkPi Forum Discussion](https://forum.clockworkpi.com/t/understanding-battery-module-pinout-upgrading-battery-module/10260)
[^1]: SIM7600G-H Specifications - [Hardware Design Document](https://fcc.report/FCC-ID/2AJYU-8PYA004/4646631.pdf), Operating Voltage: 3.4V ~ 4.2V
[^2]: AXP228 Datasheet - [X-Powers Technology](http://www.x-powers.com/en.php/Info/product_detail/article_id/31)
[^2]: ClockworkPi Forum - [CM5 Power Delivery Issues](https://forum.clockworkpi.com/t/fixing-uconsole-power-delivery-limitations-with-cm5/19119), [4G Module Stability](https://forum.clockworkpi.com/t/uconsole-4g-module-connection-issue/13533)

View File

@@ -7,7 +7,7 @@ import { Progress } from '@/components/ui/progress';
import { Button } from '@/components/ui/button';
import { Select } from '@/components/ui/select';
import { Battery, BatteryCharging, Zap, Download, Play, Pause, Calendar, Database, Edit2, Check, X, Trash2, Circle, AlertTriangle, RefreshCw, Eye, EyeOff } from 'lucide-react';
import { LineChart, Line, XAxis, YAxis, CartesianGrid, Tooltip, Legend, ResponsiveContainer, AreaChart, Area } from 'recharts';
import { LineChart, Line, XAxis, YAxis, CartesianGrid, Tooltip, Legend, ResponsiveContainer, AreaChart, Area, ReferenceLine } from 'recharts';
import { format } from 'date-fns';
interface BatteryData {
@@ -796,6 +796,19 @@ export default function BatteryMonitor() {
labelFormatter={(value) => `${value.toFixed(1)} mWh output`}
formatter={(value: any) => [`${value.toFixed(2)} V`, 'Voltage']}
/>
<ReferenceLine
y={3.45}
stroke="#ef4444"
strokeDasharray="5 5"
strokeWidth={2}
label={{
value: '3.45V - 4G Module Min',
position: 'right',
fill: '#ef4444',
fontSize: 12,
fontWeight: 600
}}
/>
<Line
type="monotone"
dataKey="voltage"

Binary file not shown.

After

Width:  |  Height:  |  Size: 46 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 70 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 69 KiB