365 lines
10 KiB
Markdown
365 lines
10 KiB
Markdown
# Capture Analysis: GrifoScope vs PyBusMonitor
|
|
|
|
## Summary
|
|
|
|
Comparison of network captures reveals protocol differences between the real radar interface (GrifoScope) and PyBusMonitor implementation.
|
|
|
|
**Date**: December 15, 2025
|
|
**Tool**: `tools/compare_captures.py`
|
|
**Captures Compared**:
|
|
- GrifoScope: Connected to real GRIFO-F/TH radar
|
|
- PyBusMonitor: Standalone mode (GRIFOSCOPE_MODE=True)
|
|
|
|
---
|
|
|
|
## Understanding the Comparison
|
|
|
|
### Important Context
|
|
|
|
The comparison shows **two different scenarios**:
|
|
|
|
1. **GrifoScope Capture** (with real radar):
|
|
- A-messages: Commands GrifoScope **SENT** to radar
|
|
- B-messages: Status radar **SENT BACK** to GrifoScope
|
|
|
|
2. **PyBusMonitor Capture** (standalone):
|
|
- A-messages: Commands PyBusMonitor **SENT**
|
|
- B-messages: **REQUESTS** PyBusMonitor sent (tr=1, no payload)
|
|
- **No radar connected** = no responses received
|
|
|
|
### Why B-Messages Are Different
|
|
|
|
**This is EXPECTED, not a bug!**
|
|
|
|
- PyBusMonitor correctly sends B-messages as **REQUEST (tr=1)** to poll the radar
|
|
- GrifoScope capture shows the **actual status data** the radar sent back
|
|
- Comparing requests vs responses is like comparing questions vs answers
|
|
|
|
To properly validate B-messages, PyBusMonitor must be **connected to the real radar** and we must capture the radar's responses.
|
|
|
|
---
|
|
|
|
## A-Messages: Real Compatibility Issues
|
|
|
|
### Critical Differences
|
|
|
|
| Message | GrifoScope | PyBusMonitor | Issue |
|
|
|---------|-----------|--------------|-------|
|
|
| **A1** | Dynamic (4 variants) | Static `88FF 0000` | Hardcoded vs real parameters |
|
|
| **A2** | REQUEST (tr=1) | Data `000E 8000` | Wrong direction! |
|
|
| **A3** | 3 variants | Static zeros | Missing dynamic data |
|
|
| **A4** | 175 variants | 1 static | No track file generation |
|
|
| **A5** | 172 variants | 1 static | No track file generation |
|
|
| **A7** | 2 variants | Static zeros | Missing mode switching |
|
|
| **A30** | 1 variant | **MISSING** | Not implemented |
|
|
|
|
### A1 Analysis (Master Control)
|
|
|
|
**GrifoScope sends**:
|
|
```
|
|
0000 1E67 DC6D 0000 0000 0000
|
|
0000 1E67 DE6D 0000 0000 0000
|
|
0000 1E67 DD6D 0000 0000 0000
|
|
```
|
|
|
|
**PyBusMonitor sends**:
|
|
```
|
|
88FF 0000 0000 0000 0000 0000
|
|
```
|
|
|
|
**Interpretation**:
|
|
- Word 1: `0000` (GrifoScope) vs `88FF` (PyBusMonitor)
|
|
- `88FF` = All validity flags set to INVALID (0xFF)
|
|
- GrifoScope sends valid data with actual parameters
|
|
- Words 2-3: `1E67 DC6D` (GrifoScope) vs `0000 0000` (PyBusMonitor)
|
|
- These appear to be radar-specific control values
|
|
- PyBusMonitor uses all zeros (safe defaults)
|
|
|
|
**Impact**: Radar may reject commands with invalid validity flags.
|
|
|
|
### A2 Analysis (Designation Control)
|
|
|
|
**GrifoScope**: Sends as **REQUEST (tr=1, no payload)**
|
|
**PyBusMonitor**: Sends **data** `000E 8000` or `080E 8000`
|
|
|
|
**This is BACKWARD!**
|
|
|
|
Looking at ICD:
|
|
- A2 in some modes should be a **poll** (BC asks RT for designation data)
|
|
- GrifoScope correctly sends tr=1 (REQUEST)
|
|
- PyBusMonitor incorrectly sends actual data
|
|
|
|
**Action Required**: Check ICD for A2 direction. Likely needs to be REQUEST in certain master modes.
|
|
|
|
### A4/A5 Analysis (Track Files)
|
|
|
|
**GrifoScope**:
|
|
- A4: 175 unique payloads (dynamic track data)
|
|
- A5: 172 unique payloads (dynamic track data)
|
|
|
|
**PyBusMonitor**:
|
|
- Both have 1 static payload (mostly zeros)
|
|
|
|
**Interpretation**:
|
|
- GrifoScope updates track files with real radar returns
|
|
- PyBusMonitor sends empty/default track data
|
|
- This is expected for standalone mode (no real targets)
|
|
|
|
**For Simulation**: Future target injection feature will populate these dynamically.
|
|
|
|
---
|
|
|
|
## B-Messages: Implementation Gaps
|
|
|
|
### Messages Only in GrifoScope
|
|
|
|
**Not implemented in PyBusMonitor**:
|
|
- B22: Unknown (1 variant)
|
|
- B23: Unknown (2 variants)
|
|
- B24: Unknown (1 variant)
|
|
- B25: Unknown (2 variants)
|
|
- B26: Unknown (1 variant)
|
|
- B27: Unknown (2 variants)
|
|
- B28: Unknown (1 variant)
|
|
- B30: Unknown (1 variant)
|
|
|
|
**Impact**: If these are required by ICD, radar may fail to transition to OPERATIONAL.
|
|
|
|
**Action Required**:
|
|
1. Check ICD section for B22-B30 definitions
|
|
2. Check C++ implementation (`th_b1553_icd.h`) for these subaddresses
|
|
3. Implement if present in ICD
|
|
|
|
### Messages Only in PyBusMonitor
|
|
|
|
**Sent by PyBusMonitor but NOT by GrifoScope**:
|
|
- B1: System Status General
|
|
- B2: System Status Detailed
|
|
- B3: System Status Extended
|
|
|
|
**Possible Reasons**:
|
|
1. Obsolete messages from older ICD revision
|
|
2. Optional messages not used by current radar firmware
|
|
3. PyBusMonitor implementation based on incomplete documentation
|
|
|
|
**Action Required**:
|
|
1. Verify these are in the ICD
|
|
2. Check if radar actually sends responses to these requests
|
|
3. Consider removing if not in current ICD revision
|
|
|
|
---
|
|
|
|
## Validation Plan
|
|
|
|
### Phase 1: Connect to Real Radar ✅ HIGH PRIORITY
|
|
|
|
**Objective**: Determine if PyBusMonitor is compatible with radar
|
|
|
|
**Steps**:
|
|
1. Connect PyBusMonitor to radar network
|
|
2. Run with GRIFOSCOPE_MODE=True
|
|
3. Monitor B7.transition_status for OPERATIONAL state
|
|
4. Capture radar responses using network sniffer
|
|
|
|
**Success Criteria**:
|
|
- Radar reaches OPERATIONAL state
|
|
- B7 shows transition_status = 0x0004 (OPERATIONAL)
|
|
- B4-B21 receive valid responses from radar
|
|
|
|
**If Failed**:
|
|
- Check which B-messages radar responds to
|
|
- Identify which A-messages radar accepts
|
|
- Compare to ICD requirements
|
|
|
|
### Phase 2: Fix A-Message Issues
|
|
|
|
**Priority Order**:
|
|
|
|
1. **A2 Direction** (CRITICAL):
|
|
- Check ICD for correct tr bit usage
|
|
- Modify to REQUEST if required by mode
|
|
- Test with radar
|
|
|
|
2. **A1 Validity Flags** (HIGH):
|
|
- Change from `88FF` (all invalid) to proper flags
|
|
- Set word 0 to match GrifoScope pattern
|
|
- May need to set actual parameter values in words 1-2
|
|
|
|
3. **A30 Implementation** (MEDIUM):
|
|
- Find A30 definition in ICD
|
|
- Implement message class
|
|
- Add to scheduler
|
|
|
|
4. **A4/A5 Dynamic Data** (LOW):
|
|
- This is for future target injection
|
|
- Current static data may be acceptable
|
|
- Depends on radar requirements
|
|
|
|
### Phase 3: Validate B-Message Set
|
|
|
|
**After Phase 1 testing**:
|
|
|
|
1. **Capture radar responses** to PyBusMonitor requests
|
|
2. **Compare response patterns** to GrifoScope capture
|
|
3. **Identify missing responses**:
|
|
- If radar responds to B22-B30 → Implement these messages
|
|
- If radar doesn't respond to B1-B3 → Remove these messages
|
|
|
|
---
|
|
|
|
## Expected Outcomes
|
|
|
|
### Scenario 1: Radar Accepts PyBusMonitor ✅
|
|
|
|
**Indicators**:
|
|
- B7.transition_status reaches OPERATIONAL
|
|
- All B4-B21 receive responses
|
|
- No error codes in status words
|
|
|
|
**Action**: Minor payload tuning (A1 validity flags, A4/A5 defaults)
|
|
|
|
### Scenario 2: Radar Rejects PyBusMonitor ⚠️
|
|
|
|
**Indicators**:
|
|
- B7.transition_status stuck in STANDBY/INITIALIZATION
|
|
- Some B-messages don't receive responses
|
|
- Error codes in status words
|
|
|
|
**Action**:
|
|
1. Analyze which messages radar doesn't respond to
|
|
2. Check ICD for missing required messages
|
|
3. Compare A-message payloads to GrifoScope patterns
|
|
4. Implement missing B22-B30 if radar expects them
|
|
|
|
### Scenario 3: Partial Functionality ⚙️
|
|
|
|
**Indicators**:
|
|
- Radar responds but with errors
|
|
- Some modes work, others don't
|
|
- Timeout issues or intermittent responses
|
|
|
|
**Action**:
|
|
1. Enable detailed logging in RadarController
|
|
2. Monitor transition states
|
|
3. Identify which commands cause errors
|
|
4. Cross-reference with C++ implementation
|
|
|
|
---
|
|
|
|
## Tools for Validation
|
|
|
|
### 1. Network Sniffer (Real-Time Monitoring)
|
|
|
|
```powershell
|
|
# Terminal 1: Run PyBusMonitor connected to radar
|
|
python -m pybusmonitor1553
|
|
|
|
# Terminal 2: Capture traffic
|
|
python tools/network_sniffer.py
|
|
```
|
|
|
|
**Look For**:
|
|
- B-messages with actual data (not REQUEST markers)
|
|
- Error codes in status words
|
|
- Message counts matching GrifoScope patterns
|
|
|
|
### 2. Comparison After Radar Connection
|
|
|
|
```powershell
|
|
# After capturing PyBusMonitor↔Radar traffic:
|
|
python tools/compare_captures.py
|
|
```
|
|
|
|
**This time it will compare**:
|
|
- GrifoScope A-messages vs PyBusMonitor A-messages (both BC→RT)
|
|
- GrifoScope B-responses vs PyBusMonitor B-responses (both RT→BC)
|
|
|
|
**Expected Result**: B-messages should now match or be very similar!
|
|
|
|
### 3. Message Decoder
|
|
|
|
```powershell
|
|
# Decode specific message payload
|
|
python tools/decode_message.py B7 "0081 0000 0000 ..."
|
|
```
|
|
|
|
**Use to**:
|
|
- Interpret transition_status values
|
|
- Check validity flags
|
|
- Verify field values match ICD
|
|
|
|
---
|
|
|
|
## Technical Notes
|
|
|
|
### Protocol Fundamentals
|
|
|
|
**MIL-STD-1553 Roles**:
|
|
- **BC (Bus Controller)**: GrifoScope or PyBusMonitor
|
|
- **RT (Remote Terminal)**: GRIFO-F/TH radar
|
|
|
|
**Message Directions**:
|
|
- **BC→RT**: Commands/parameters from controller to radar
|
|
- A-messages (mostly)
|
|
- B-messages when tr=1 (REQUEST poll)
|
|
- **RT→BC**: Status/data from radar to controller
|
|
- B-messages (response to poll)
|
|
- A-messages when tr=1 (rare, for radar-initiated data)
|
|
|
|
**REQUEST Mode (tr=1)**:
|
|
- Command word has transmit bit set
|
|
- Word count = expected response size
|
|
- **No payload sent** (0 bytes)
|
|
- RT responds with status word + data
|
|
|
|
### UDP1553 Frame Structure
|
|
|
|
```
|
|
[UDP Header 64B: marker=0x1553]
|
|
[Message Block]:
|
|
BEGIN: 0x3C3C
|
|
CW: 2 bytes (rt, tr, sa, wc)
|
|
SW: 2 bytes (status)
|
|
ERRCODE: 2 bytes
|
|
RESERVED: 8 bytes
|
|
[PAYLOAD: wc * 2 bytes] ← Only if tr=0 (BC→RT command)
|
|
~CW: 2 bytes (inverted)
|
|
END: 0x3E3E
|
|
[END: 0x5315]
|
|
```
|
|
|
|
**Key Points**:
|
|
- Payload present ONLY when tr=0 (BC sending data to RT)
|
|
- When tr=1 (REQUEST), payload is empty in BC→RT direction
|
|
- RT response is a separate UDP1553 frame with tr=0, containing data
|
|
|
|
---
|
|
|
|
## Conclusion
|
|
|
|
### Current Status
|
|
|
|
✅ **Working**: PyBusMonitor correctly implements REQUEST polling for B-messages
|
|
⚠️ **Issues**: A-message payloads differ significantly from GrifoScope
|
|
❓ **Unknown**: Whether radar will accept PyBusMonitor commands
|
|
|
|
### Next Steps
|
|
|
|
1. **PRIORITY 1**: Connect PyBusMonitor to real radar and test
|
|
2. **PRIORITY 2**: Fix A2 direction (REQUEST vs data)
|
|
3. **PRIORITY 3**: Implement A30 and B22-B30 if required by ICD
|
|
|
|
### Success Metrics
|
|
|
|
- [ ] Radar reaches OPERATIONAL state with PyBusMonitor
|
|
- [ ] All B-messages receive valid responses
|
|
- [ ] No error codes in radar status words
|
|
- [ ] Can control radar modes (TWS, RWS, etc.)
|
|
- [ ] Track data updates properly
|
|
|
|
---
|
|
|
|
**Document Version**: 1.0
|
|
**Last Updated**: December 15, 2025
|
|
**Author**: Analysis from capture comparison tool
|