# 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**