Domande da idioti: DCC for a dummy

[Zampa di Lepre]

Moreno quale è stato il tempo di lettura (se hai provato a leggere l'intero contenuto del V3)?

[Moreno Mazzini]

Se leggere l'intero contenuto è il bottone "Leggi tutte le pagine" allora non l'ho premuto. Ho letto sicuramente la pagina dove si imposta l'indirizzo/livelli velocità, e qualche altra cosa. In genere leggere l'intero contenuto quanto dura?
Riguardo la velocità di lettura di una singola cv ho avuto l'impressione che farlo direttamente da un multimaus collegato alla Z21 fosse leggermente più veloce che farlo dal pc.

[Buddace]

Che versione firmware dentro la Z21? Poi la bianca o la nera?

[Zampa di Lepre]

Quello della velocità di lettura può essere un problema.

Per spiegarlo devo fare un passo indietro (utile hai fini divulgativi di questo topic)....

Il DCC ha, ormai, sulle spalle tanti anni (introdotto nell '88 mi pare ... per cui ora son 28!!) e nasce come un protocollo di comunicazione monodirezionale (dalla centralina al decoder) per inviare i comandi di marcia alle locomotive.

Però, almeno in fase di programmazione delle CV, è necessario avere un ritorno indietro (dal decoder alla centralina) se non altro per sapere cosa c'è scritto dentro. Quando la loco è sul binario di programmazione la centralina riesce a misurare l'assorbimento di corrente (o meglio gli sbalzi nell'assorbimento) per cui quando si chiede di leggere una CV (semplifico) il decoder provoca tante micro-attivazioni del motore quanto è il valore presente nella CV interrogata: se c'è scritto 36 il motore verrà rapidamente sollecitato 36 volte e la centralina conterà questi sbalzi e sarà in grado di indicare il valore (questo è anche il motivo per cui non si riescono a leggere le CV di decoder a cui non è connesso un motore ... a meno di non dotarli di una resistenza che ne simuli il carico).

Ovviamente nel corso di questi 28 anni si è cercato di estendere il protocollo DCC e renderlo bidirezionale (dal decoder alla centralina e viceversa) ed è stato sviluppato (non solo ai fini della lettura delle CV) un sottoprotocollo: il RailCom (e poi il RailCom+). Ovviamente affinché funzioni, sia la Centralina che i decoder devono aderire allo standard.
In sintesi la centralina ha la facoltà di chiedere informazioni al singolo decoder (sia che si trovi sul binario di programmazione che su quello di corsa) e gli "lascia la parola" (la centralina si zittisce momentaneamente e si mette in ascolto) affinché il decoder possa inviare, tramite il binario, un segnale in cui è digitalmente codificata la risposta. Va da se che tutto questo avviene con velocità ed efficienza (controllo d'errore) elettronica.

La situazione attuale in termini di supporto del RailCom è abbastanza variegata: in genere tutti i nuovi apparati lo gestiscono ma con gradi di efficienza e livello di supporto differenti. Esistono poi ancora centraline che in fase di programmazione del decoder non lo usano così come esistono decoder "datati" che ancora non lo supportano.

E siamo finalmente arrivati al nocciolo del problema. Prendendo ad esempio un ESU lokpilot V4 per avere una lettura completa del suo contenuto (circa un migliaio di CV) se lo faccio in maniera tradizionale (sbalzi di corrente) impiegherò parecchi minuti (con molteplici possibilità di errore) mentre sfruttando la bidirezionalità me la caverò in una manciata di secondi.

Quello che cercavo di capire, con la domanda sui tempi, è proprio quale strategia usa l'accoppiata Z21 + DecoderPro per leggere le CV: l'usabilità e l'affidabilità del tutto dipendono ance da questo ... la prova di leggere e scrivere una singola CV non è qualificante.

[Moreno Mazzini]

Però, almeno in fase di programmazione delle CV, è necessario avere un ritorno indietro (dal decoder alla centralina) se non altro per sapere cosa c'è scritto dentro. Quando la loco è sul binario di programmazione la centralina riesce a misurare l'assorbimento di corrente (o meglio gli sbalzi nell'assorbimento) per cui quando si chiede di leggere una CV (semplifico) il decoder provoca tante micro-attivazioni del motore quanto è il valore presente nella CV interrogata: se c'è scritto 36 il motore verrà rapidamente sollecitato 36 volte e la centralina conterà questi sbalzi e sarà in grado di indicare il valore (questo è anche il motivo per cui non si riescono a leggere le CV di decoder a cui non è connesso un motore ... a meno di non dotarli di una resistenza che ne simuli il carico).

Ma davvero funziona così? io avevo capito il contrario, cioè la centrale chiede "la cv 1 ha valore 1?", "ha valore 2?" ecc e quando la domanda è corretta ("ha valore 36?) il decoder attiva il motore per far capire che la risposta è "si".
Oppure più velocemente la centrale può lavorare a bit, quindi chiede "il bit 1 vale 1?" e via dicendo.

In generare mi pare di capire che il problema della velocità di lettura è indipendente dalla centrale connessa, giusto?

Per rispondere invece a Buddace per la prova di ieri avevo a disposizione una Z21 (con la Z maiuscola), quindi quella nera; Firmware 1.27.

[Buddace]

Zampa dipende se sulla Z21 c'è il global detector railcom se è usato dalla programmazione è accessibile via pc ed è gestito da JMRI.
Esempio la mia ClaudiaCS non ha il global detector ma con detector railcom esterno leggo velocemente tramite jmri.

[Buddace]

Per rispondere invece a Buddace per la prova di ieri avevo a disposizione una Z21 (con la Z maiuscola), quindi quella nera; Firmware 1.27.

Controllo quella che ho io che firmware monta cosi risolvo un problema al cristo che l'ha comprata.

[Zampa di Lepre]

Moreno mi sa che hai ragione tu ... cercando di semplificare il discorso mi sono impicciato (oltre che andare a memoria di cose che ho studiato più di 15 anni fa).
Ma comunque sia quello che dovrebbe essere palese è che è una cosa lenta e insicura (basta un contatto non perfetto, anche perché la loco si muove un minimo, o un motore non in buone condizioni per non ricevere risposta e quindi interrompere l'intero processo).

Per Nuccio ... infatti volevo proprio capire come, insieme, accedono il decoder: visto che in parecchi si sono lasciati convincere dalla Z21 se si riuscisse a definire una configurazione (senza altro aggiungere) usabile con DecoderPro sarebbe un buon punto di partenza per avere una piattaforma di programmazione decoder condivisa con cui iniziare e portare avanti tanti discorsi.

[Buddace]

Ma davvero funziona così? io avevo capito il contrario, cioè la centrale chiede "la cv 1 ha valore 1?", "ha valore 2?" ecc e quando la domanda è corretta ("ha valore 36?) il decoder attiva il motore per far capire che la risposta è "si".
Oppure più velocemente la centrale può lavorare a bit, quindi chiede "il bit 1 vale 1?" e via dicendo.

E' corretto..il si il decoder lo da assorbendo corrente

[alpiliguri]

Ma comunque sia quello che dovrebbe essere palese è che è una cosa lenta e insicura (basta un contatto non perfetto, anche perché la loco si muove un minimo, o un motore non in buone condizioni per non ricevere risposta e quindi interrompere l'intero processo).

Comunque ho notato che in caso di mancata risposta DecoderPro (a meno che non sia lo SPROG ma dubito), ritenta la lettura 3 volte, poi passa alla CV successiva. Le CV che non sono state lette vengono evidenziate in rosso sulle schermate. A volte basta spostare leggermente la loco e rileggere la sola pagina che contiene le "rosse" per risolvere.
Un ESU v.4 mi prende almeno una decina di minuti, ma gli altri decoder in 2 minuti si leggono interamente. L'enorme vantaggio di DecoderPro è che una volta fatta una lettura completa si salva la configurazione, per gli interventi successivi basta operare sulla singola pagina.

Ciao, alpiliguri.