SXXXXXXX_PyBusMonitor1553/doc/Capture-Analysis.md

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)

# 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

# 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

# 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