confronto procedura alberto con mia per tgt_gen.
This commit is contained in:
VALLONGOL
parent
0d17dc4751
commit
49e3c471d6
241
CONFRONTO_TGT_GEN.md
Normal file
241
CONFRONTO_TGT_GEN.md
Normal file
@ -0,0 +1,241 @@
|
||||
# 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**
|
||||
@ -678,7 +678,7 @@ def tgt_gen(interface, timeout_sec=None, expected_range=2536, range_tolerance=(1
|
||||
logging.info(f'[tgt_gen] Interface type: {type(interface)}, has getSingleMessageReceivedSz: {hasattr(interface, "getSingleMessageReceivedSz")}')
|
||||
|
||||
# Configuration
|
||||
period_ms = 0.5 # Loop period in milliseconds (reduced for faster simulation)
|
||||
period_ms = 20 # Loop period in milliseconds (aligned with real hardware)
|
||||
timetag_increment = 150 # Timetag increment per iteration
|
||||
timetag_wrap = 0x70ff # Timetag wrap point
|
||||
timetag_reset = 10 # Timetag reset value after wrap
|
||||
|
||||
Loading…
Reference in New Issue
Block a user