Sono finalmente ritornato da tre settimane molto intense di trasferte di lavoro, prima a Napoli poi a Mosca. Questo weekend l'ho passato a riposarmi un poco lavoricchiando intorno al mio booster. Vorrei infatti che fosse in grado non solo di programmare correttamente anche i decoder digitali, ma anche di leggere le variabili di configurazione, le famose CV. Questo mi serve soprattutto per sistemare la curva di velocità dell'ultimo regalo che mi ha fatto mio padre: la E 191 003, ovvero la Vectron di FuoriMuro.
Si dà il caso, infatti, che la suddetta loco sia decisamente corsaiola: da alcune recensioni che ho letto, la velocità massima in scala è di 295km/h quando in realtà dovrebbe assestarsi su un ben più modesto 160km/h. Avevo già predisposto HW e SW del booster per questa possibilità, ma il sistema si è sempre rifiutato di funzionare a dovere, quindi questo weekend ho deciso di mettermi seriamente al lavoro per sistemare il problema.
Partiamo dalla teoria.
La maggior parte dei sistemi DCC tradizionali si basano su un sistema di trasmissione unidirezionale: dalla centrale ai decoder. Fanno eccezione almeno due soluzioni interessanti: il sistema RailCom (link) e BiDiB (link). La prima soluzione, introdotta dal Lenz nel 2000, prevede l'interruzione del flusso di pacchetti dati DCC tramite un cutout device, un apposito circuito elettronico, per far sì che il decoder installato sulla loco possa inviare alla centrale informazioni utili. La seconda soluzione, inizialmente proposta da Lenz e Tams nel 2009 e successivamente sviluppata da un gruppo di lavoro indipendente, invece è un vero e proprio protocollo di trasmissione dati bidirezionale.
In alternativa a queste soluzioni, il protocollo DCC tradizionale permette un'unica forma di trasmissione dati dai decoder alla centrale: il cosiddetto Acknowledge -meglio noto come Ack-. Il segnale di Ack viene normalmente inviato da un decoder che voglia notificare alla centrale il riconoscimento di un segnale di programmazione. E' un semplice segnale on-off: se viene trasmesso la risposta è positiva, altrimenti è negativa. Cosa centra quindi con la lettura? Semplice, dal momento che con questo sistema non c'è modo di leggere un valore, la centrale manda una serie di pacchetti DCC chiedendo al decoder se il valore della CV X è Y: se è così, il decoder risponde con un ACK.
E cosa fa il decoder per mandare il segnale di ACK se non ha a disposizione un sistema come RailCom o BiDiB? Fa l'unica cosa che ha a disposizione per inviare un segnale: assorbe corrente accendendo brevemente il motore della loco. In questo modo, se la centrale è in grado di tenere sotto controllo il consumo di corrente, è anche in grado di rilevare il segnale di ACK. E il mio booster fa esattamente questo: qui sotto potete vedere un grafico del consumo di corrente rilevato.
Ogni riga orizzontale del grafico vale 500mV, mentre ogni riga verticale vale 1ms. Per comodità di lettura ho applicato uno scostamente verticale di 1V, quindi all'estrema sinistra il grafico riporta valori compresi tra 0 e 50mV. Potete anche osservare un aumento del consumo per circa 6ms, del tutto compatibile con lo standard NMRA 9.2.3 (link) che prevede un aumento di almeno 60mA per 6ms. Il sistema di rilevazione di corrente del mio booster converte la corrente in volt in proporzione praticamente 1:1, quindi 60mA corrispondono a 60mV.
Ed ecco dove stava il problema: io avevo imposto come corrente di soglia contro i corto circuiti una corrente di 1A, ovvero 1V. Bene: vedete quel picco quasi al centro dello schermo? Ecco, è proprio superiore ad 1V. E questo succede praticamente tutte le volte che una loco manda il segnale di ACK a causa delle interferenze elettromagnetiche. Applicando lo standard NMRA 9.2.3 alla lettera, un assorbimento di 1A è sicuramente superiore a 60mA, quindi non mi posso certo lamentare. Però devo ammettere che non mi aspettavo così tanto! Pensavo, e qui mi sono sbagliato, che si trattasse di 100mA al massimo, conformemente a quanto mostrato sul sito opendcc.de (link).
Portando la soglia contro i corti a 2A e ritoccando un poco i filtri per evitare quei fastidiosi picchi di corrente, il booster ha iniziato a rispondere correttamente a tutti i segnali di ACK inviati dalla loco. Problema risolto? In buona parte sì, tranne per il fatto che RocRail, scrive il valore giusto della variabile sul decoder, ma legge sempre uno in più. Ovvero, se nella CV 1 -ovvero nell'indirizzo della loco- scrivo 3, RocRail legge 4; se scrivo 4, leggo 5 e così via...
Ok, c'è ancora del lavoro da fare. Possibile che sia il software?
Già altre volte ho trovato qualche errorino sparso qua e là.
Mi occuperò di questo il prima possibile, e vi farò sapere.
A presto!!
Nessun commento:
Posta un commento