Implement CPR position recovery for better position validation #18

New issue

Closed

opened 2025-08-24 20:41:32 +02:00 by olemd · 1 comment

olemd commented

2025-08-24 20:41:32 +02:00

Owner

Problem

The current position validation logs show many aircraft with impossible speeds (e.g., 25+ million knots) due to CPR (Compact Position Reporting) decoding errors. These occur when odd and even CPR frames get mixed up or decoded incorrectly.

Current Behavior

Aircraft positions jump wildly causing speed validation failures
Logs filled with "REJECTED - Impossible speed: X knots" messages
Valid aircraft movements get lost due to bad CPR decoding
No recovery mechanism when CPR decoding fails

Root Cause

CPR encoding uses odd/even frame pairs to encode precise positions in a compact format. When:

Frames arrive out of order
One frame in a pair is corrupted
Time synchronization issues occur
Reference position is incorrect

The decoder can produce wildly incorrect positions leading to impossible calculated speeds.

Proposed Solution

Implement CPR position recovery mechanism:

Frame Pair Management:
- Store recent odd/even CPR frames for each aircraft
- Match frames by time correlation and sequence
- Detect when frame pairs produce invalid results
Recovery Strategies:
- Retry decoding with different frame combinations
- Use last known good position as reference
- Apply position continuity checks before accepting decoded positions
- Implement CPR format validation
Fallback Options:
- Use surface position messages when available
- Interpolate positions based on speed/track vectors
- Mark positions as "estimated" when using recovery

Benefits

Reduce impossible speed validation errors by 80%+
Recover valid aircraft tracks from corrupted data
Improve position accuracy and continuity
Less log spam and better debugging information

Implementation Notes

Requires storing CPR frame history per aircraft
Need to implement proper CPR format validation
Should maintain backward compatibility with current decoder
May need adjustable recovery timeouts based on update rates

Files to Modify

- CPR decoding logic
- Position validation and recovery
New CPR recovery module for frame pair management

References

ICAO Annex 10 Volume IV (CPR encoding specification)
DO-260B (ADS-B message formats and CPR details)

## Problem The current position validation logs show many aircraft with impossible speeds (e.g., 25+ million knots) due to CPR (Compact Position Reporting) decoding errors. These occur when odd and even CPR frames get mixed up or decoded incorrectly. ## Current Behavior - Aircraft positions jump wildly causing speed validation failures - Logs filled with "REJECTED - Impossible speed: X knots" messages - Valid aircraft movements get lost due to bad CPR decoding - No recovery mechanism when CPR decoding fails ## Root Cause CPR encoding uses odd/even frame pairs to encode precise positions in a compact format. When: - Frames arrive out of order - One frame in a pair is corrupted - Time synchronization issues occur - Reference position is incorrect The decoder can produce wildly incorrect positions leading to impossible calculated speeds. ## Proposed Solution Implement CPR position recovery mechanism: 1. **Frame Pair Management**: - Store recent odd/even CPR frames for each aircraft - Match frames by time correlation and sequence - Detect when frame pairs produce invalid results 2. **Recovery Strategies**: - Retry decoding with different frame combinations - Use last known good position as reference - Apply position continuity checks before accepting decoded positions - Implement CPR format validation 3. **Fallback Options**: - Use surface position messages when available - Interpolate positions based on speed/track vectors - Mark positions as "estimated" when using recovery ## Benefits - Reduce impossible speed validation errors by 80%+ - Recover valid aircraft tracks from corrupted data - Improve position accuracy and continuity - Less log spam and better debugging information ## Implementation Notes - Requires storing CPR frame history per aircraft - Need to implement proper CPR format validation - Should maintain backward compatibility with current decoder - May need adjustable recovery timeouts based on update rates ## Files to Modify - - CPR decoding logic - - Position validation and recovery - New CPR recovery module for frame pair management ## References - ICAO Annex 10 Volume IV (CPR encoding specification) - DO-260B (ADS-B message formats and CPR details)

olemd commented

2025-08-24 22:20:48 +02:00

Author

Owner

Root Cause Identified: CPR Zone Ambiguity Bug

I've identified the specific bug causing aircraft positioning errors like 4ACAB2 showing near Helsinki when actually approaching Porsgrunn.

The Bug Location

File: internal/modes/decoder.go, lines 528-548 in decodeCPRPosition()

The Problem

The CPR decoding algorithm has a critical flaw in zone ambiguity resolution:

✅ Correctly calculates both even/odd latitude solutions (lines 487-488)
✅ Correctly selects the best latitude based on receiver distance (lines 518-526)
❌ Incorrectly uses longitude from odd message unconditionally (line 533)

This causes coordinate mixing - correct latitude from one zone solution paired with longitude from a different zone solution, creating invalid positions.

Real-World Impact

Aircraft 4ACAB2 approaching Porsgrunn (59.1°N, 9.7°E)
Appears near Helsinki (60.2°N, 24.9°E) - ~15° longitude error
This is exactly the symptom of mixing latitude from even solution with longitude from odd solution

The Fix Required

Replace the current mixed coordinate approach with:

Calculate complete position pairs: Both even (lat,lon) and odd (lat,lon) solutions
Distance comparison: Compare both complete positions against receiver location
Select complete pair: Choose the entire coordinate pair closest to receiver

Code Location

// Current broken approach (line 533):
lon := dLon * (math.Mod(m, ni) + oddLon)  // Always uses odd longitude

// Need to calculate both solutions and pick complete pair

This fix will resolve the zone ambiguity issues causing aircraft to appear hundreds of kilometers from their actual positions.

## Root Cause Identified: CPR Zone Ambiguity Bug I've identified the specific bug causing aircraft positioning errors like 4ACAB2 showing near Helsinki when actually approaching Porsgrunn. ### The Bug Location **File**: `internal/modes/decoder.go`, lines 528-548 in `decodeCPRPosition()` ### The Problem The CPR decoding algorithm has a **critical flaw in zone ambiguity resolution**: 1. ✅ **Correctly calculates** both even/odd latitude solutions (lines 487-488) 2. ✅ **Correctly selects** the best latitude based on receiver distance (lines 518-526) 3. ❌ **Incorrectly uses longitude** from odd message unconditionally (line 533) This causes **coordinate mixing** - correct latitude from one zone solution paired with longitude from a different zone solution, creating invalid positions. ### Real-World Impact - Aircraft 4ACAB2 approaching Porsgrunn (59.1°N, 9.7°E) - Appears near Helsinki (60.2°N, 24.9°E) - ~15° longitude error - This is exactly the symptom of mixing latitude from even solution with longitude from odd solution ### The Fix Required Replace the current mixed coordinate approach with: 1. **Calculate complete position pairs**: Both even (lat,lon) and odd (lat,lon) solutions 2. **Distance comparison**: Compare both complete positions against receiver location 3. **Select complete pair**: Choose the entire coordinate pair closest to receiver ### Code Location ```go // Current broken approach (line 533): lon := dLon * (math.Mod(m, ni) + oddLon) // Always uses odd longitude // Need to calculate both solutions and pick complete pair ``` This fix will resolve the zone ambiguity issues causing aircraft to appear hundreds of kilometers from their actual positions.