PlatSim_Genova/_doc/CONFRONTO_TGT_GEN.md

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)

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

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