PlatSim_Genova/CONFRONTO_TGT_GEN.md

242 lines
9.4 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Confronto Implementazioni tgt_gen()
**Data**: 2026-02-03
**Scopo**: Confrontare la nostra implementazione di `tgt_gen()` con la versione semplificata testata con successo sulla macchina target reale.
---
## 1. PANORAMICA
### Versione Collega (Target Reale - FUNZIONANTE)
- **Righe di codice**: ~60
- **Complessità**: Bassa (essenziale)
- **Testato**: ✅ SU HARDWARE REALE con successo
- **Return**: Boolean (True/False)
### Nostra Versione (Sviluppo)
- **Righe di codice**: ~210
- **Complessità**: Alta (ricca di funzionalità)
- **Testato**: ✅ In simulazione
- **Return**: Dizionario con dettagli completi
---
## 2. CONFRONTO DETTAGLIATO
### 2.1 TIMING E LOOP CONTROL
| Aspetto | Versione Collega | Nostra Versione | Note |
|---------|------------------|-----------------|------|
| **Initial sleep** | 1.0s | 0.0s | Collega: attesa iniziale esplicita |
| **Loop period** | 20ms (0.020s) | 0.5ms | 🔴 DIFFERENZA CRITICA |
| **Iterazioni max** | 500 fisso | Calcolato da timeout | Noi: ~20000 per 10s timeout |
| **Timeout** | Implicito: ~10s (500×20ms) | Esplicito: 10s controllato | ✅ Noi: early exit se timeout |
| **Tempo totale max** | ~10 secondi | ~10 secondi | Equivalente |
**⚠️ ISSUE CRITICA**: Il nostro `period_ms = 0.5ms` è **40 volte più veloce** della versione che funziona sull'hardware reale (20ms).
### 2.2 FASE DI INIZIALIZZAZIONE (Pre-Loop)
| Operazione | Versione Collega | Nostra Versione | Compatibilità |
|------------|------------------|-----------------|---------------|
| **Set STBY mode** | ✅ Sempre (if only_bc) | ✅ Opzionale | ✅ Compatibile |
| **Stimolazione A5** | ✅ 10 messaggi, 10ms interval | ✅ 10 messaggi, 20ms interval | ✅ Simile |
| **Timetag A5** | Incremento +150 | Incremento +150 | ✅ Identico |
| **CommitChanges** | ✅ True | ✅ True | ✅ Identico |
**Valutazione**: Fase iniziale sostanzialmente identica.
### 2.3 LOOP PRINCIPALE - STIMOLAZIONE
| Operazione | Versione Collega | Nostra Versione | Compatibilità |
|------------|------------------|-----------------|---------------|
| **Messaggio stimolato** | **A4 (Nav Data)** | **A4 (Nav Data)** | ✅ Identico |
| **Metodo chiamata** | `theGrifo1553.set()` | `setValue()` con verbose=False | ✅ Equivalente |
| **Timetag increment** | +150 | +150 | ✅ Identico |
| **Timetag wrap** | 0x70ff → 10 | 0x70ff → 10 | ✅ Identico |
| **CommitChanges** | ✅ True | ✅ True | ✅ Identico |
| **Frequenza log** | Ogni 50 iter (debug) | Ogni 50 iter (debug) | ✅ Identico |
**Valutazione**: Stimolazione identica.
### 2.4 LETTURA B9 E DETECTION LOGIC
| Aspetto | Versione Collega | Nostra Versione | Compatibilità |
|---------|------------------|-----------------|---------------|
| **getSingleMessageReceivedSz("B9")** | ✅ Sì | ✅ Sì | ✅ Identico |
| **Campo b9_t_num** | ✅ Letto | ✅ Letto | ✅ Identico |
| **Campo b9_t1_rng** | ✅ Letto | ✅ Letto | ✅ Identico |
| **Campo b9_w12 (timetag)** | ✅ Letto | ✅ Letto | ✅ Identico |
| **Inizializzazione p_tt** | `if p_tt==0: p_tt=t_tt; continue` | `if p_tt==0 and t_tt!=0: p_tt=t_tt; continue` | ⚠️ Noi: check aggiuntivo t_tt!=0 |
| **Condizione detection** | `(t_num>0) OR (p_tt!=t_tt)` | `(t_num>0) OR (p_tt!=0 AND t_tt!=p_tt)` | ⚠️ Noi: check p_tt!=0 aggiuntivo |
**⚠️ DIFFERENZA**: La nostra condizione è più restrittiva (richiede `p_tt != 0`).
### 2.5 RANGE VALIDATION
| Aspetto | Versione Collega | Nostra Versione | Compatibilità |
|---------|------------------|-----------------|---------------|
| **Expected range** | 2536 (hardcoded) | 2536 (configurabile) | ✅ Identico valore |
| **Tolerance low** | -1000 | -1000 (configurabile) | ✅ Identico |
| **Tolerance high** | +200 | +200 (configurabile) | ✅ Identico |
| **Range finale** | [1536, 2736] | [1536, 2736] | ✅ Identico |
| **Metodo check** | `check()` | `check()` | ✅ Identico |
**Valutazione**: Validazione identica (noi più configurabile).
### 2.6 SUCCESS CRITERIA
| Aspetto | Versione Collega | Nostra Versione | Compatibilità |
|---------|------------------|-----------------|---------------|
| **Hit counter** | `hit > 1` (almeno 2) | `hit >= hit_threshold` (default 2) | ✅ Equivalente |
| **Early exit** | ❌ No (commento `#return True`) | ✅ Sì (`break` dopo threshold) | 🟢 Noi meglio |
| **InterruptRequest** | ✅ Gestito | ✅ Gestito | ✅ Identico |
**Valutazione**: Noi ottimizzati (early exit quando raggiunto threshold).
### 2.7 RETURN VALUE
| Aspetto | Versione Collega | Nostra Versione |
|---------|------------------|-----------------|
| **Tipo** | `bool` (True/False) | `dict` con 7 campi |
| **Info detected** | ✅ Sì (boolean) | ✅ Sì (bool + dettagli) |
| **Info hits** | ❌ No | ✅ Sì (count) |
| **Info range** | ❌ No | ✅ Sì (valore) |
| **Info iterations** | ❌ No | ✅ Sì (count) |
| **Info timing** | ❌ No | ✅ Sì (time_to_detect) |
| **Info message_count** | ❌ No | ✅ Sì (B9 messages) |
**Valutazione**: Noi molto più ricchi di informazioni per diagnostica e report.
---
## 3. ISSUE CRITICHE IDENTIFICATE
### 🔴 ISSUE #1: PERIOD TROPPO VELOCE
**Problema**: Il nostro `period_ms = 0.5ms` è **40 volte più veloce** della versione hardware (20ms).
**Impatto**:
- Possibile overload del bus 1553
- Radar potrebbe non fare in tempo a processare messaggi
- Possibile timing mismatch con refresh B9 (periodo 20ms secondo ICD)
**Raccomandazione**: **CAMBIARE `period_ms` da 0.5ms a 20ms** per allinearsi all'hardware reale.
### 🟡 ISSUE #2: DETECTION CONDITION PIÙ RESTRITTIVA
**Problema**: La nostra condizione richiede `p_tt != 0` prima di considerare valido un cambio timetag.
**Impatto**:
- Potrebbe saltare la prima detection se timetag parte da 0
- Logica più conservativa (può essere positivo)
**Raccomandazione**: **MANTENERE** - la logica è più robusta e gestisce edge case.
### 🟢 ISSUE #3: EARLY EXIT MANCANTE NEL COLLEGA
**Problema**: La versione collega continua il loop anche dopo aver raggiunto i 2 hit (codice commentato `#return True`).
**Impatto**:
- Spreco di tempo (continua per tutti i 500 loop)
- La nostra versione è ottimizzata con early exit
**Raccomandazione**: **MANTENERE** la nostra implementazione (early exit).
---
## 4. ALTRE DIFFERENZE NOTEVOLI
### 4.1 Gestione Errori
- **Collega**: Nessuna gestione esplicita
- **Noi**: Try/except su ogni operazione critica + logging
- **Valutazione**: ✅ Noi meglio per produzione
### 4.2 Logging
- **Collega**: Minimale (molti log commentati)
- **Noi**: Dettagliato con livelli configurabili + riduzione spam
- **Valutazione**: ✅ Noi meglio per diagnostica
### 4.3 Configurabilità
- **Collega**: Valori hardcoded
- **Noi**: Parametri configurabili all'inizio script
- **Valutazione**: ✅ Noi meglio per manutenibilità
### 4.4 Timeout Control
- **Collega**: Implicito (fixed iterations)
- **Noi**: Esplicito con check `current_time >= end_time`
- **Valutazione**: ✅ Noi meglio per precisione
---
## 5. SINTESI E RACCOMANDAZIONI
### ✅ COSA MANTENERE DELLA NOSTRA VERSIONE
1. **Return dict** con dettagli completi (essenziale per report e GUI)
2. **Early exit** quando raggiunto threshold (ottimizzazione)
3. **Timeout esplicito** con check su tempo reale
4. **Gestione errori** completa con try/except
5. **Logging configurabile** con riduzione spam
6. **Parametri configurabili** (TARGET_* all'inizio script)
### 🔴 COSA CAMBIARE PER ALLINEARSI ALL'HARDWARE
1. **CRITICO**: Cambiare `period_ms` da **0.5ms** a **20ms**
2. **OPZIONALE**: Rimuovere check `p_tt != 0` nella detection condition (per compatibilità)
3. **VERIFICA**: Test in simulazione con period 20ms
### 🟡 POSSIBILI OTTIMIZZAZIONI FUTURE
1. Aggiungere sleep iniziale 1s (come collega) se necessario per stabilizzazione radar
2. Testare se A5 iniziale è davvero necessario o solo A4 basta
3. Considerare di aumentare `hit_threshold` da 2 a 3-5 per maggiore robustezza
---
## 6. PIANO D'AZIONE PROPOSTO
### Step 1: MODIFICHE IMMEDIATE (CRITICHE)
```python
# In GRIFO_M_PBIT.py, funzione tgt_gen(), cambiare:
period_ms = 0.5 # SBAGLIATO
period_ms = 20 # CORRETTO (allineato a hardware reale)
```
### Step 2: TESTING
1. Eseguire test in simulazione con period 20ms
2. Verificare che timeout 10s funzioni correttamente (~500 iterazioni max)
3. Verificare che early exit funzioni (detection dopo 2-3 iterazioni)
### Step 3: VALIDAZIONE HARDWARE
1. Test sulla macchina target reale
2. Confronto risultati con versione collega
3. Tuning fine se necessario
---
## 7. CONCLUSIONI
### Valutazione Complessiva
La **nostra implementazione è superiore** in termini di:
- ✅ Robustezza (gestione errori)
- ✅ Diagnostica (logging + return dettagliato)
- ✅ Manutenibilità (configurabile)
- ✅ Efficienza (early exit, timeout esplicito)
**MA** ha un **BUG CRITICO**: il period troppo veloce potrebbe causare problemi sull'hardware reale.
### Raccomandazione Finale
**NON sostituire** la nostra implementazione con quella del collega, **MA correggere** il bug del period:
```python
period_ms = 20 # Allineato a versione hardware funzionante
```
Questa modifica rende la nostra implementazione **completamente compatibile** con l'hardware reale mantenendo tutti i vantaggi della versione evoluta.
### Domande per Discussione
1. **Accetti** la modifica da 0.5ms a 20ms?
2. Vuoi testare prima in simulazione o procedere direttamente?
3. Preferisci aggiungere lo sleep iniziale 1s del collega?
4. Il check `p_tt != 0` lo manteniamo o lo rimuoviamo per compatibilità?
---
**Fine del documento di confronto**