# 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