Skip to content

IoT: 3. First 5 Features for Market Entry

Jump to bottom
Frank Ray edited this page Oct 12, 2026 · 1 revision

Overview

Based on NetPace's current feature set (console app, Ookla server discovery, download/upload/latency testing) and the IoT market analysis, these are the first 5 features to implement to start addressing the IoT market, prioritized by impact and feasibility.

Timeline: 5-6 weeks to IoT MVP

Priority 1: Minimal Data Usage Mode ⭐⭐⭐⭐⭐

Why this is #1:

  • IoT devices have tiny data plans (10-100MB/month)
  • Your current tool downloads/uploads megabytes per test
  • This is a showstopper - you can't even demo to IoT customers without this
  • Relatively easy to implement (you already control payload size)

Implementation:

# Add test profiles
NetPace --profile micro     # 100KB down, 50KB up (< 500KB total)
NetPace --profile small     # 1MB down, 500KB up (< 2MB total)
NetPace --downloadsize 0.1  # Already exists! Just document it
NetPace --uploadsize 0.05   # Already exists! Just document it

What to add:

  1. Pre-defined test profiles (--profile micro|small|medium|large)
  2. Data usage estimation before running test: NetPace --estimate --downloadsize 10
  3. Warning when test will exceed threshold: "⚠️ This test will use ~15MB. Continue? (y/n)"

Code changes:

  • Add TestProfile enum with size presets
  • Add --profile flag to CLI
  • Modify existing --downloadsize/--uploadsize to accept smaller values (< 1 MB)
  • Display data usage in output: "Data used: 847 KB"

Time estimate: 2-3 days

Priority 2: Signal Strength Metrics ⭐⭐⭐⭐⭐

Why this is #2:

  • IoT cares more about signal quality than raw speed
  • A device showing 10 Mbps might have -95 dBm signal (terrible, will drop constantly)
  • This is what differentiates you from generic speed tests
  • Critical for pre-deployment validation

Implementation:

# New flag to include cellular metrics
NetPace --include-signal-metrics

# Output format (add to existing JSON/CSV):
{
  "download_mbps": 5.2,
  "upload_mbps": 1.8,
  "latency_ms": 87,
  "signal_strength_dbm": -72,
  "signal_quality": "excellent",
  "network_type": "LTE"
}

What to add:

  1. Detect if running on cellular connection (vs. WiFi/Ethernet)
  2. Read signal strength from system APIs:
    • Linux: /sys/class/net/wwan0/, mmcli (ModemManager), or AT commands
    • Windows: Use netsh or Windows API
  3. Parse RSSI, RSRQ, RSRP if available
  4. Classify signal: Excellent (> -70 dBm), Good (-70 to -85), Fair (-85 to -100), Poor (< -100)

Libraries to use:

  • .NET: System.Net.NetworkInformation for interface detection
  • For cellular: Shell out to mmcli -m 0 --signal-get on Linux
  • Parse output and include in SpeedTestResult

Code changes:

  • Add SignalMetrics class to SpeedTestResult
  • Add --include-signal-metrics flag (default: false)
  • Add platform-specific signal detection
  • Display signal in output: "📶 Signal: -72 dBm (Excellent)"

Time estimate: 3-5 days

Priority 3: Location Tagging (GPS/Manual) ⭐⭐⭐⭐

Why this is #3:

  • IoT customers need to track "Where was this test run?"
  • Essential for pre-deployment site surveys
  • Enables coverage mapping (Phase 2)
  • Easy win with big impact

Implementation:

# Manual location
NetPace --location "34.0522,-118.2437" --location-name "LA Warehouse"
NetPace --location "Chicago Depot #5"

# Auto-detect (if GPS available)
NetPace --location auto

# Output includes location
{
  "download_mbps": 5.2,
  "location": {
    "latitude": 34.0522,
    "longitude": -118.2437,
    "name": "LA Warehouse",
    "address": "Los Angeles, CA"
  }
}

What to add:

  1. --location flag accepting:
    • GPS coordinates: "lat,lon" or "lat,lon,alt"
    • Address string: "Chicago Depot #5" (store as-is, no geocoding needed yet)
    • auto keyword (detect GPS if available)
  2. --location-name for friendly name
  3. Add Location class to SpeedTestResult
  4. Store in CSV/JSON output

GPS detection (optional for v1):

  • Linux: Read from /dev/gps0 or gpsd
  • Android: If running on Android device, use location services
  • For MVP: Just support manual entry, skip auto-detection

Code changes:

  • Add Location class with lat/lon/name properties
  • Add --location and --location-name flags
  • Include in output formats (CSV, JSON)
  • Display in console: "📍 Location: LA Warehouse (34.05°N, 118.24°W)"

Time estimate: 2-3 days

Priority 4: JSON/CSV Output for Device IDs ⭐⭐⭐⭐

Why this is #4:

  • IoT customers test hundreds of devices - they need to track which is which
  • Current CSV/JSON output exists but doesn't support device identification
  • This enables bulk testing workflows (even manually)
  • Foundation for automated fleet testing (Phase 2)

Implementation:

# Add device metadata to test
NetPace --device-id "device-001" --imei "123456789012345" --sim "8901234567890123456"

# Output includes device info
{
  "device_id": "device-001",
  "imei": "123456789012345",
  "sim_iccid": "8901234567890123456",
  "download_mbps": 5.2,
  "timestamp": "2025-12-07T10:30:00Z"
}

# CSV output
device_id,imei,sim_iccid,download_mbps,upload_mbps,latency_ms,timestamp
device-001,123456789012345,8901234567890123456,5.2,1.8,87,2025-12-07T10:30:00Z

What to add:

  1. --device-id flag: Unique identifier for this device
  2. --imei flag: International Mobile Equipment Identity (15 digits)
  3. --sim flag: SIM card ICCID (19-20 digits)
  4. --custom-field flag: Allow arbitrary key-value pairs for flexibility
  5. Include all metadata in JSON/CSV output

Code changes:

  • Add DeviceInfo class with optional fields
  • Add CLI flags for device metadata
  • Extend SpeedTestResult to include device info
  • Update CSV/JSON formatters to include device columns
  • Auto-detect IMEI if possible (read from modem)

Time estimate: 1-2 days

Priority 5: Quick Test Mode / No-Download Option ⭐⭐⭐

Why this is #5:

  • IoT customers often just need "Can I connect? What's my signal strength?"
  • They don't care about exact speed, just "Is it working?"
  • Reduces test time from 30-60 seconds to 5-10 seconds
  • Saves data (critical for IoT)

Implementation:

# Quick connectivity test (no speed test, just ping + signal)
NetPace --quick

# Skip download or upload individually (already exists!)
NetPace --no-download   # Already supported ✅
NetPace --no-upload     # Already supported ✅

# Combine for fastest test
NetPace --quick --no-download --no-upload

# Output: Just confirms connectivity + signal
✅ Connected to Verizon LTE
📶 Signal: -72 dBm (Excellent)
🏓 Latency: 45ms
⏱️ Test duration: 3 seconds
💾 Data used: 50 KB

What to add:

  1. --quick flag that:
    • Skips server discovery (use first available or cached)
    • Runs minimal latency test (5 pings instead of 20)
    • Optionally skips download/upload (or uses micro profile)
  2. Display "quick test" indicator in output
  3. Optimize for speed: cache server list, parallel operations

You already have:

  • --no-download ✅
  • --no-upload ✅
  • --no-latency ✅
  • Configurable test settings ✅

Just add:

  • --quick preset that combines smart defaults
  • Server caching (save last used server to avoid re-discovery)
  • Documentation for IoT users

Time estimate: 1-2 days

Implementation Order & Timeline

Week 1-2: Core IoT Enablement

  1. ✅ Minimal Data Usage Mode (3 days) - Showstopper fix
  2. ✅ Quick Test Mode (2 days) - Quick win, leverages existing features

Deliverable: IoT manufacturers can test devices without blowing data budgets

Week 3-4: Signal Quality & Identification

  1. ✅ Signal Strength Metrics (5 days) - Key differentiator
  2. ✅ Device ID Tracking (2 days) - Enables bulk workflows

Deliverable: IoT customers can identify signal issues and track individual devices

Week 5: Location & Documentation

  1. ✅ Location Tagging (3 days) - Pre-deployment validation
  2. Documentation & examples for IoT use cases (2 days)

Deliverable: Complete IoT MVP ready for pilot customers

Why These 5 vs. Others

Skipped for now:

  • ❌ Multi-carrier testing - Requires AT command access, harder to implement
  • ❌ Scheduled tests - Need background service/daemon, more complex
  • ❌ Battery monitoring - Platform-specific, nice-to-have not must-have
  • ❌ Bulk device testing - Need these 5 features working first

You can achieve 80% of IoT value with just these 5 because they enable:

  1. Testing without killing data plans ✅
  2. Seeing cellular signal quality ✅
  3. Tracking which device was tested ✅
  4. Recording where test was run ✅
  5. Fast connectivity checks ✅

Bonus: Custom Server Support

You mentioned OpenLibreSpeed or custom servers - this is actually perfect for IoT:

# Use custom speed test server (closer to IoT deployment)
NetPace --server "http://speedtest.mycompany.com"

# Skip Ookla server discovery entirely
NetPace --server "http://10.0.0.50:8080" --quick

Why IoT customers need this:

  • Test against their own infrastructure (not public internet)
  • Many IoT devices are on private APNs (can't reach public servers)
  • Lower latency = more accurate for local deployments
  • Avoids using Ookla servers (licensing concerns for commercial use)

Implementation:

  • Already supported via --server flag! ✅
  • Just document it for IoT customers
  • Add validation for HTTP endpoints
  • Support OpenLibreSpeed API format (if different from Ookla)

Marketing These 5 Features

Before NetPace IoT:

"We manually test cellular connectivity by having techs drive to sites with smartphones, run speedtest.net, and email us screenshots. It takes days and costs thousands."

After NetPace IoT:

"We run NetPace --profile micro --device-id device-001 --location auto --include-signal-metrics on each device. It uses 500KB, takes 10 seconds, and gives us signal strength, speed, and location. We tested 1,000 devices in 3 hours."

Next Steps

Start building! These 5 features are your IoT MVP.

Recommendation: Start with Priority 1 (Minimal Data Usage Mode) as it's the showstopper that prevents any IoT testing today.

Clone this wiki locally