giglez/docs/DEVICE_ATTRIBUTION_ANALYSIS.md

Device Attribution Analysis & Recommendations

Executive Summary

This document analyzes GigLez's current RF signal-based device attribution system and provides recommendations based on industry-standard algorithms and databases from RTL_433, Flipper Zero, and other open-source projects.

Current Implementation Analysis

Overview

GigLez uses a multi-strategy matching engine (src/matcher/engine.py) that combines 5 different matching strategies to identify IoT devices from RF signal captures.

Current Matching Strategies

1. ExactMatcher (Confidence: 1.0)

Matches: Protocol + Frequency + Bit Length

WHERE s.protocol = %s
  AND s.frequency = %s
  AND (s.bit_length = %s OR s.bit_length IS NULL)

Strengths:

• Highest confidence (1.0) for perfect matches
• Fast database lookups
• Reliable for known, standardized protocols

Weaknesses:

• Requires complete protocol decode (not available for RAW captures)
• Misses devices with slight protocol variations

---

2. PartialMatcher (Confidence: 0.8)

Matches: Protocol + Frequency

WHERE s.protocol = %s
  AND s.frequency = %s

Strengths:

• Works when bit length is unknown
• Broader coverage than exact matching

Weaknesses:

• Still requires protocol name
• May return multiple devices on same protocol/frequency

---

3. PatternMatcher (Confidence: 0.7-0.9)

Matches: Bit Pattern + Bit Mask + Frequency

Algorithm:

def _compare_with_mask(data1, data2, mask):
    matching_bits = 0
    total_bits = 0

    for i in range(min_len):
        mask_byte = mask[i]
        bits_to_check = bin(mask_byte).count('1')
        total_bits += bits_to_check

        masked1 = data1[i] & mask_byte
        masked2 = data2[i] & mask_byte

        xor_result = masked1 ^ masked2
        matching_bits += bits_to_check - bin(xor_result).count('1')

    return matching_bits / total_bits

Strengths:

• Works with partial bit patterns
• Handles manufacturer variations (rolling codes, device IDs)
• Configurable masks for flexible matching

Weaknesses:

• Requires pre-computed signature database
• CPU intensive for large databases

---

4. TimingMatcher (Confidence: 0.6-0.8)

Matches: RAW signal timing patterns

Algorithm:

# Check if average pulse width falls within known range
if timing_min <= avg_pulse <= timing_max:
    range_size = timing_max - timing_min
    center = (timing_max + timing_min) / 2
    distance_from_center = abs(avg_pulse - center)

    confidence = 0.8 * (1.0 - (distance_from_center / (range_size / 2)))

Strengths:

• Works with RAW (undecoded) signals
• Doesn't require protocol knowledge
• Can identify devices by timing characteristics alone

Weaknesses:

• Lower confidence than decoded matches
• Sensitive to signal quality and interference
• Requires statistical timing database

---

5. FrequencyMatcher (Confidence: 0.5-0.7)

Matches: Frequency proximity (±5kHz tolerance)

WHERE s.frequency BETWEEN %s AND %s
  AND (s.protocol IS NULL OR s.protocol = 'Unknown')

Algorithm:

freq_diff = abs(row['frequency'] - metadata.frequency)
confidence = 0.7 * (1.0 - (freq_diff / tolerance))

Strengths:

• Fallback for completely unknown signals
• Handles frequency drift
• Identifies device category (garage door, weather sensor, etc.)

Weaknesses:

• Very low specificity
• Many devices share frequencies
• Only useful for broad categorization

---

Modulation Types & Signal Characteristics

Overview

Understanding modulation is critical for device attribution. Different device types use specific modulation schemes based on cost, range, and power requirements.

Supported Modulation Types

1. OOK (On-Off Keying)

Description: Binary amplitude modulation - carrier is either ON or OFF

Characteristics:

• Simplest and cheapest to implement
• Very power efficient
• Binary data: ON = 1, OFF = 0
• Susceptible to interference
• Common in cheap consumer devices

Typical Devices:

• Generic garage door openers
• Wireless doorbells
• Simple remote controls
• Low-cost weather sensors

Flipper Zero Presets:

• FuriHalSubGhzPresetOok270Async
• FuriHalSubGhzPresetOok650Async

Detection: Large amplitude variance, binary signal levels

---

2. ASK (Amplitude Shift Keying)

Description: Multiple amplitude levels (not just ON/OFF)

Characteristics:

• More sophisticated than OOK
• Multiple data levels possible
• Better noise immunity than OOK
• Higher data rates

Typical Devices:

• RF remote controls (keyfobs)
• RFID systems
• Tire pressure sensors (TPMS)
• Digital transmitters

Detection: Multiple distinct amplitude levels in signal

---

3. FSK (Frequency Shift Keying)

Description: Data encoded by shifting between two frequencies

Characteristics:

• Better noise immunity than OOK/ASK
• More complex demodulation required
• Higher data rates possible
• More power efficient than ASK

Typical Devices:

• Modern car key fobs
• Wireless modems
• RFID tags (HF)
• Digital radio systems
• LoRa (chirp spread spectrum FSK)

Flipper Zero Presets:

• FuriHalSubGhzPresetFSK variants

Detection: Frequency deviation between two distinct frequencies

---

4. PWM (Pulse Width Modulation)

Description: Data encoded in pulse duration

Characteristics:

• Variable pulse widths encode data
• Fixed gaps between pulses
• Good for simple protocols
• Easy to implement in firmware

Encoding:

• Short pulse = '1' (e.g., 400μs)
• Long pulse = '0' (e.g., 800μs)
• Constant gap (e.g., 400μs)

Typical Devices:

• Princeton/PT2260 remotes
• EV1527 sensors
• Cheap Chinese RF modules

Detection: High pulse width variance, low gap variance

---

5. PPM (Pulse Position Modulation)

Description: Data encoded in gap duration between fixed pulses

Characteristics:

• Fixed pulse widths
• Variable gaps encode data
• Inverse of PWM
• Good noise immunity

Encoding:

• Short gap = '1' (e.g., 300μs)
• Long gap = '0' (e.g., 900μs)
• Constant pulse width (e.g., 500μs)

Typical Devices:

• Some garage door openers
• Older remote controls

Detection: Low pulse width variance, high gap variance

---

6. Manchester Encoding

Description: Self-clocking scheme where bit transitions occur at bit center

Characteristics:

• Transition in middle of bit period
• '0' = high→low transition
• '1' = low→high transition
• No DC bias
• Excellent clock recovery

Typical Devices:

• Oregon Scientific weather stations
• Professional wireless sensors
• Industrial control systems

Detection: Constant bit period, transitions at regular intervals

---

7. PCM (Pulse Code Modulation)

Description: Digital encoding of analog signals

Characteristics:

• Samples analog signal at regular intervals
• Encodes as digital values
• Used for voice/audio transmission
• Higher bandwidth required

Typical Devices:

• Wireless microphones
• Baby monitors
• Wireless audio systems

---

Modulation Detection Algorithm

Based on RTL_433's approach:

def detect_modulation_from_raw(raw_data: List[int]) -> str:
    """
    Analyze RAW pulse data to determine modulation type

    Args:
        raw_data: List of pulse timings (positive=pulse, negative=gap)

    Returns:
        Modulation type: OOK, FSK, PWM, PPM, Manchester, Unknown
    """
    pulses = [abs(t) for t in raw_data if t > 0]
    gaps = [abs(t) for t in raw_data if t < 0]

    # Calculate variance
    pulse_var = statistics.variance(pulses) if len(pulses) > 1 else 0
    gap_var = statistics.variance(gaps) if len(gaps) > 1 else 0

    # Calculate means
    pulse_mean = statistics.mean(pulses) if pulses else 0
    gap_mean = statistics.mean(gaps) if gaps else 0

    # Check for Manchester (self-clocking)
    # Manchester has consistent bit periods with mid-bit transitions
    if is_manchester_pattern(raw_data):
        return 'Manchester'

    # Check for PWM (variable pulse width, fixed gaps)
    if pulse_var > gap_var * 2 and gap_var < gap_mean * 0.3:
        return 'PWM'

    # Check for PPM (fixed pulse width, variable gaps)
    if gap_var > pulse_var * 2 and pulse_var < pulse_mean * 0.3:
        return 'PPM'

    # Check for FSK (frequency modulation)
    # FSK typically has consistent pulse/gap timing
    if pulse_var < pulse_mean * 0.2 and gap_var < gap_mean * 0.2:
        # Further analysis needed to distinguish FSK from OOK
        return 'FSK_or_OOK'

    # Default to OOK
    return 'OOK'


def is_manchester_pattern(raw_data: List[int], tolerance: float = 0.2) -> bool:
    """
    Detect Manchester encoding pattern

    Manchester characteristics:
    - Transitions at bit centers
    - Consistent bit periods (pulse + gap ≈ constant)
    - No long runs without transitions
    """
    if len(raw_data) < 10:
        return False

    # Calculate bit period candidates (pulse + gap)
    bit_periods = []
    for i in range(0, len(raw_data) - 1, 2):
        if i + 1 < len(raw_data):
            period = abs(raw_data[i]) + abs(raw_data[i + 1])
            bit_periods.append(period)

    if not bit_periods:
        return False

    # Check if bit periods are consistent
    mean_period = statistics.mean(bit_periods)
    std_period = statistics.stdev(bit_periods) if len(bit_periods) > 1 else 0

    # Manchester should have low variance in bit periods
    coefficient_of_variation = std_period / mean_period if mean_period > 0 else 1.0

    return coefficient_of_variation < tolerance

---

Industry Standard Algorithms

RTL_433 Approach

RTL_433 is the gold standard for RF device identification, used by thousands of users worldwide.

Signal Processing Pipeline

Input Signal → FSK/OOK Demodulation → Pulse Detection → Pulse Analysis → Protocol Decode → Device ID

Key Components:

1. Pulse Detection

   • Automatic level setting based on estimated noise
   • SNR thresholds (1.0 to 99.0)
   • Squelch to skip low-quality frames
   • Choice between amplitude/magnitude estimators
   • Edge detection for pulse boundaries

2. Pulse Analysis (-A flag)

   RTL_433's Pulse Analyzer automatically identifies modulation type:

   Analyzing pulses...
   Analyzing pulses for possible protocol matches...
   
   Pulse Width Analysis:
   - Two dominant pulse widths + single gap width = likely PWM
   - Single pulse width + two gap widths = likely PPM
   - Consistent pulse + gap periods = likely Manchester
   - Consistent short pulses = likely FSK/OOK
   

   Pulse Parameters:

   • short: Nominal width of '1' pulse (microseconds)
   • long: Nominal width of '0' pulse (microseconds)
   • sync: Nominal width of sync pulse (microseconds)
   • gap: Maximum gap between pulses (microseconds)
   • reset: Maximum signal reset time (microseconds)
   • tolerance: Timing tolerance percentage

   Example PWM Analysis:

   pulse_demod_pwm(): PWM detected
   short_width: 400
   long_width: 800
   sync_width: 8000
   gap_limit: 1200
   reset_limit: 10000
   

3. Protocol Decoders (200+ protocols)

   Encoding Types:

   • PWM (Pulse Width Modulation): Variable pulse widths
   • PPM (Pulse Position Modulation): Variable gap widths
   • PCM (Pulse Code Modulation): Direct bit encoding
   • Manchester: Self-clocking with mid-bit transitions
   • Differential Manchester: Variant of Manchester
   • PIWM (Pulse Interval and Width): Combined PWM+PPM

   Common Protocol Families:

   • PT2260 family (Princeton, EV1527)
   • Keeloq/HCS family (encrypted rolling codes)
   • Oregon Scientific (weather stations)
   • Acurite (weather sensors)
   • LaCrosse (temperature/humidity)
   • Nexus (outdoor sensors)

4. Device Fingerprinting

   • Protocol number metadata (0-200+)
   • Modulation type (OOK/FSK/ASK)
   • Frequency, RSSI, SNR measurements
   • Manufacturer-specific preambles
   • Checksum/CRC validation
   • Device ID extraction

Confidence Scoring

RTL_433 uses checksum validation and data field consistency to validate decodes:

Valid CRC → High Confidence (0.9-1.0)
Valid data structure → Medium Confidence (0.7-0.9)
Weak signal, no validation → Low Confidence (0.5-0.7)

---

Flipper Zero Database Structure

Flipper Zero maintains the largest open-source SubGhz device database and provides sophisticated signal analysis tools.

Database Stats

• 13,717 .sub files in 721 folders
• Frequency range: 300-348 MHz, 387-464 MHz, 779-928 MHz
• Supported Vendors: 100+ manufacturers
• Hardware: Texas Instruments CC1101 chip
• Supported Modulations: OOK, ASK, FSK (via CC1101)

File Format Structure

Filetype: Flipper SubGhz Key File
Version: 1
Frequency: 433920000
Preset: FuriHalSubGhzPresetOok650Async
Protocol: Princeton
Bit: 24
Key: 00 00 00 00 00 95 D5 D4
TE: 400

Key Fields for Matching:

• Frequency: Exact frequency in Hz
• Preset: Modulation (OOK/FSK + bandwidth)
• Protocol: Protocol name (200+ supported)
• Bit: Bit length (8-64 bits typical)
• Key: Data payload (hex)
• TE: Timing element (μs)

Signal Analysis Features

1. Read Mode

• Listens on configured frequency (default: 433.92 MHz AM)
• Auto-detects known protocols
• Displays: Protocol, Frequency, Key, TE (timing element)
• RSSI indicator for signal strength

2. Frequency Analyzer

• Scans all frequencies in range
• Displays frequency with highest RSSI (>-90 dBm)
• Helps identify unknown device frequencies
• Visual spectrum analyzer

3. RAW Mode

• Captures unknown/non-standard protocols
• Records timing sequences for analysis
• Can replay RAW captures
• Useful for reverse engineering

4. ProtoView (Advanced Analysis)

ProtoView is a specialized Flipper Zero app for unknown protocol analysis:

Features:

• Real-time signal visualization
• Decodes OOK/ASK/FSK modulation
• Displays bit patterns and timing
• Identifies modulation type automatically
• Editable signal data
• Protocol reverse engineering tool

Use Case: When Flipper's default SubGhz app doesn't recognize a protocol, ProtoView can:

• Show the raw bit stream
• Identify pulse widths and encoding
• Help match against similar known protocols
• Create custom protocol definitions

Keeloq Protocol Support

Flipper Zero includes manufacturer-specific keys for Keeloq encrypted signals:

/ext/subghz/assets/keeloq_mfcodes_user

This allows decryption of rolling-code garage doors, car alarms, etc.

Supported Keeloq Manufacturers:

• Chamberlain/LiftMaster
• Genie
• Linear
• Stanley
• And 50+ more

---

Frequency-to-Device Mapping

ISM Band Allocations

Sub-GHz ISM frequency bands in real IoT applications are mostly 315MHz, 433MHz, 868MHz, and 915MHz. These operate in four distinct sub-GHz frequency ranges, and which frequency you may legally use depends primarily on your geographic location.

315 MHz (North America, Japan, Asia)

Common Devices:

• Tire Pressure Monitoring Systems (TPMS)
• Early wireless remote controls
• Garage door openers (GE/Interlogix, Chamberlain)
• Wireless doorbells
• Car key fobs (some manufacturers)

Characteristics:

• Range: 300-348 MHz (Flipper Zero supported)
• Better obstacle penetration than higher frequencies
• Longer wavelength = better range
• Lower data rates

Regulations: FCC Part 15

---

433.05 - 434.79 MHz (Europe, Asia, Australia)

Common Devices:

• Weather stations (Oregon Scientific, Acurite, LaCrosse)
• Remote controls (gates, garage doors)
• Wireless sensors (temperature, humidity)
• Home automation (switches, dimmers)
• Car key fobs (most common)
• Wireless doorbells
• Security sensors (door/window contacts)
• Somfy RTS motorized blinds/shutters (433.42 MHz)
• Nice Flor-S, FAAC gate openers (433.92 MHz)

Characteristics:

• Most popular ISM band globally
• Range: 387-464 MHz (Flipper Zero supported)
• Excellent penetration and range (10km+ with LoRa)
• Low power consumption
• High device density (many overlapping signals)

Regulations: ETSI EN 300 220

---

868 MHz (Europe)

Common Devices:

• Smart meters (gas, water, electricity)
• LoRa IoT devices (long-range sensors)
• Z-Wave home automation (868MHz band)
• Alarm systems
• SCADA systems
• Industrial telemetry
• Automatic meter reading (AMR)

Characteristics:

• Range: 779-928 MHz (Flipper Zero supported)
• Higher bandwidth than 433MHz
• Better for data-intensive applications
• Still good penetration
• Less crowded than 433MHz in Europe

Regulations: ETSI EN 300 220

---

915 MHz (North America, Australia)

Common Devices:

• RFID tags (passive and active)
• Smart meters
• SCADA systems
• Industrial sensors
• LoRa IoT devices (North America)
• ZigBee (900MHz variant)
• Wireless security systems

Characteristics:

• Range: 779-928 MHz (Flipper Zero supported)
• North America's equivalent to 868MHz
• Higher data rates possible
• Good balance of range and bandwidth
• Less building penetration than lower frequencies

Regulations: FCC Part 15

---

Additional Sub-GHz Bands

345 MHz (North America)

Common Devices:

• Honeywell security sensors (door/window contacts)
• Home alarm systems
• Wireless security devices

Characteristics:

• Dedicated security device frequency
• Less interference than 433MHz
• High reliability for critical applications

---

319.5 MHz (North America)

Common Devices:

• GE/Interlogix security sensors
• Professional alarm systems

Characteristics:

• Proprietary security frequency
• Lower interference
• Professional-grade equipment

---

390 MHz (North America)

Common Devices:

• Chamberlain garage door openers
• Security+ encrypted remotes

Characteristics:

• Manufacturer-specific frequency
• Rolling code encryption
• High security

---

Protocol-to-Device Database

Based on RTL_433 and Flipper Zero databases:

Protocol	Frequency	Devices	Confidence
Princeton	315/433 MHz	Generic remotes, doorbells	0.7-0.9
EV1527	433 MHz	Cheap Chinese remotes, sensors	0.8-0.95
Chamberlain	315/390 MHz	Garage door openers	0.95-1.0
HCS301 (Keeloq)	315/433 MHz	Car remotes, encrypted gates	0.9-1.0
Oregon Scientific	433 MHz	Weather stations	0.95-1.0
Acurite	433 MHz	Weather stations (North America)	0.95-1.0
LaCrosse	433 MHz	Weather/temperature sensors	0.9-1.0
Honeywell	345 MHz	Security sensors	0.95-1.0
GE/Interlogix	319.5 MHz	Security sensors	0.9-1.0
Somfy RTS	433.42 MHz	Motorized blinds/shutters	0.95-1.0
Nice Flor-S	433.92 MHz	Gate/garage openers	0.9-1.0
FAAC	433.92 MHz	Gate openers	0.9-1.0

---

Recommendations for GigLez

Priority 1: Integrate RTL_433 Protocol Database

Action: Import RTL_433's 200+ protocol definitions

Benefits:

• Immediate coverage of mainstream IoT devices
• Well-tested, community-validated protocols
• Regular updates from open-source community

Implementation:

# Clone RTL_433 source
git clone https://github.com/merbanan/rtl_433.git

# Parse protocol definitions from src/devices/*.c
python scripts/parse_rtl433_protocols.py rtl_433/src/devices/ > data/rtl433_protocols.json

Database Schema Extension:

ALTER TABLE signatures ADD COLUMN rtl433_protocol_id INTEGER;
ALTER TABLE signatures ADD COLUMN checksum_type VARCHAR(50);
ALTER TABLE signatures ADD COLUMN preamble_pattern BYTEA;
ALTER TABLE signatures ADD COLUMN sync_pattern BYTEA;

---

Priority 2: Implement Pulse Analysis for RAW Signals

Current Gap: TimingMatcher only uses average pulse width

Recommendation: Add statistical pulse pattern analysis

Algorithm:

def analyze_pulse_pattern(raw_data):
    """
    Extract statistical features from RAW pulse data

    Features:
    - Pulse width distribution (histogram)
    - Gap width distribution
    - Pulse repetition rate
    - Pattern periodicity (FFT)
    - Short/long pulse ratio (Manchester, PWM)
    """
    pulses = [t for t in raw_data if t > 0]  # Positive values
    gaps = [-t for t in raw_data if t < 0]   # Negative values

    features = {
        'pulse_min': min(pulses),
        'pulse_max': max(pulses),
        'pulse_mean': statistics.mean(pulses),
        'pulse_std': statistics.stdev(pulses),
        'gap_min': min(gaps),
        'gap_max': max(gaps),
        'gap_mean': statistics.mean(gaps),
        'gap_std': statistics.stdev(gaps),
        'pulse_gap_ratio': statistics.mean(pulses) / statistics.mean(gaps),
        'pattern_length': len(raw_data),
        'repetition_count': detect_repetitions(raw_data),
    }

    return features

Benefits:

• Identify modulation type (OOK/FSK/Manchester)
• Detect protocol even without database entry
• Improve confidence scoring

---

Priority 3: Add Modulation Detection

Current Gap: Modulation is extracted from preset name but not validated

Recommendation: Implement modulation classification

Algorithm (from RTL_433):

def detect_modulation(raw_data):
    """
    Classify modulation type from pulse characteristics

    Types:
    - OOK (On-Off Keying): Binary amplitude
    - FSK (Frequency Shift Keying): Two frequencies
    - Manchester: Self-clocking (pulse + gap = constant)
    - PWM (Pulse Width): Variable pulse widths
    - PPM (Pulse Position): Variable gap widths
    """

    # Check for Manchester encoding
    if is_self_clocking(raw_data):
        return 'Manchester'

    # Check for PWM
    pulse_variance = statistics.variance(get_pulses(raw_data))
    gap_variance = statistics.variance(get_gaps(raw_data))

    if pulse_variance > gap_variance * 2:
        return 'PWM'
    elif gap_variance > pulse_variance * 2:
        return 'PPM'
    else:
        return 'OOK'

Database Integration:

ALTER TABLE signatures ADD COLUMN modulation_validated VARCHAR(20);
ALTER TABLE signatures ADD COLUMN encoding_scheme VARCHAR(50);

---

Priority 4: Build Frequency-Based Device Categorization

Action: Create frequency → device type mapping

Database Table:

CREATE TABLE frequency_categories (
    id SERIAL PRIMARY KEY,
    frequency_min INTEGER NOT NULL,
    frequency_max INTEGER NOT NULL,
    region VARCHAR(20),  -- 'NA', 'EU', 'Asia', 'Global'
    category VARCHAR(100),
    common_protocols TEXT[],
    confidence_base FLOAT DEFAULT 0.5
);

-- Example entries
INSERT INTO frequency_categories VALUES
    (1, 314000000, 316000000, 'NA', 'TPMS', ARRAY['Schrader', 'Continental'], 0.7),
    (2, 433050000, 434790000, 'EU', 'Weather Stations', ARRAY['OregonScientific', 'Acurite'], 0.6),
    (3, 433050000, 434790000, 'EU', 'Remote Controls', ARRAY['Princeton', 'EV1527'], 0.5),
    (4, 433420000, 433420000, 'EU', 'Somfy Blinds', ARRAY['Somfy RTS'], 0.9),
    (5, 868000000, 870000000, 'EU', 'Smart Meters', ARRAY['WMBUS', 'LoRa'], 0.6);

Query Enhancement:

SELECT
    fc.category,
    fc.confidence_base,
    array_agg(DISTINCT fc.common_protocols) as likely_protocols
FROM frequency_categories fc
WHERE fc.frequency_min <= %s AND fc.frequency_max >= %s
  AND (fc.region = %s OR fc.region = 'Global')

---

Priority 5: Implement Checksum Validation

Current Gap: No checksum validation (confidence inflated)

Recommendation: Add protocol-specific checksum validators

Implementation:

class ChecksumValidator:
    """Validate checksums for known protocols"""

    validators = {
        'EV1527': validate_ev1527,
        'Princeton': validate_princeton,
        'Oregon': validate_oregon_v1,
        'Acurite': validate_acurite_crc8,
        # ... 200+ protocols
    }

    @staticmethod
    def validate_ev1527(data: bytes) -> bool:
        """EV1527 uses simple parity"""
        return bin(int.from_bytes(data, 'big')).count('1') % 2 == 0

    @staticmethod
    def validate_oregon_v1(data: bytes) -> bool:
        """Oregon Scientific v1 checksum"""
        checksum = sum(data[:-1]) & 0xFF
        return checksum == data[-1]

Confidence Adjustment:

if ChecksumValidator.validate(metadata.protocol, metadata.key_data):
    confidence *= 1.1  # Boost by 10%
else:
    confidence *= 0.7  # Reduce by 30%

---

Priority 6: Add Machine Learning Classification

Long-term: Train ML model on signal features

Features for Training:

features = [
    'frequency',
    'pulse_count',
    'avg_pulse_width',
    'pulse_std',
    'gap_avg',
    'gap_std',
    'pulse_gap_ratio',
    'duration_ms',
    'modulation_type',  # one-hot encoded
    'bit_length',
]

# Labels: device_category, manufacturer, model

Algorithm: Random Forest or XGBoost Training Data: Flipper Zero's 13,717 .sub files

Expected Accuracy: 80-90% for device category, 60-70% for specific model

---

Immediate Action Items

Week 1-2: Database Enhancement

• Create rtl433_protocols table
• Import top 50 common protocols from RTL_433
• Add frequency_categories table
• Populate frequency → device type mappings

Week 3-4: Matching Algorithm Improvements

• Implement pulse pattern analysis
• Add modulation detection
• Integrate checksum validators
• Update confidence scoring

Week 5-6: Testing & Validation

• Test against Flipper Zero database (1000 samples)
• Benchmark accuracy vs. current system
• Document protocol coverage
• Create device attribution report

Week 7-8: UI Integration

• Show match details (protocol, confidence, checksum)
• Display alternative matches
• Allow manual device confirmation
• Community voting on identifications

---

Expected Improvements

Current System

• Coverage: ~50-100 devices (manually added)
• Accuracy: 60-70% (many RAW signals unidentified)
• Confidence: Often inflated (no checksum validation)

After Implementation

• Coverage: 200+ protocols, 1000+ device types
• Accuracy: 85-90% (with RTL_433 integration)
• Confidence: Properly calibrated with checksum validation
• Community: Crowdsourced verification and improvements

---

Resources

Open Source Projects

• RTL_433: https://github.com/merbanan/rtl_433
• Flipper Zero SubGhz DB: https://github.com/Zero-Sploit/FlipperZero-Subghz-DB
• SubGhz Toolkit: https://github.com/ognz/SubGhz-Toolkit
• RFCodes: https://github.com/mathertel/rfcodes

Documentation

• Flipper Developer Docs: https://developer.flipper.net/flipperzero/doxygen/subghz_file_format.html
• RTL_433 Analysis Guide: https://github.com/merbanan/rtl_433/blob/master/docs/ANALYZE.md
• Signal ID Wiki: https://www.sigidwiki.com/

Regulatory

• FCC Part 15: https://www.fcc.gov/general/radio-frequency-safety-0
• ETSI EN 300 220: European SRD regulations
• ISM Band Allocations: https://en.wikipedia.org/wiki/ISM_radio_band

---

Conclusion

GigLez's current matching engine provides a solid foundation with its multi-strategy approach. By integrating RTL_433's battle-tested protocol database, implementing pulse analysis, and adding checksum validation, we can achieve 85-90% accuracy for SubGhz device identification.

The key is leveraging the open-source community's work (200+ protocols, 13,717 device samples) while building GigLez-specific enhancements for wardriving and geographic attribution.

Next Steps: Prioritize RTL_433 integration (Priority 1) and pulse analysis (Priority 2) for immediate impact.