Principio di funzionamento centrale DCC

[Luca]

Ciao a tutti!

Volevo approfondire con voi qualche considerazione circa il funzionamento "logico" di una centrale DCC, in particolare della parte "core", ovvero quella che si occupa di inviare i comandi sul bus DCC.

Tutte le informazioni sul DCC le potete trovare sul sito ufficiale:
http://www.nmra.org/standards/DCC/stand ... CStds.html

in particolare mi riferirò alla S 9.2:
http://www.nmra.org/standards/DCC/stand ... 004-07.pdf

Cominciamo dalle basi:

- un comando DCC è composto da una sequenza binaria (0-1)

- ogni comando è composto (per la centrale) da
* preambolo (almeno 14 bit posti a 1);
* start bit (= 0);
* address byte;

-- serie di
* data byte start bit (= 0);
* data byte;
--

* packet end bit (= 0).

- l'ultimo data byte rappresenta l'error correction data (XOR)

Per quello che riguarda la trasmissione, si trasmette un segnale ad onda quadra con differente periodo per distinguere gli 1 dagli 0.

Una centralina deve gestire (x una modalità  "operativa") due tipologie di comandi:

- comandi continui (es. velocità  delle loco), che vanno periodicamente inviati;
- comandi spot (es. attivazione di un decoder accessori), inviati singolarmente.

Suppongo quindi di mantere in memoria uno stack dei comandi da inviare in maniera sequenziale sul bus; tali comandi avranno un flag che indica se il comando è da ripetere (quindi quando inviato viene rimesso in fondo allo stack) o se è singolo (quando inviato viene rimosso).

Per evitare tempi troppo lunghi di refresh, lo stack dovrà  avere capacità  finita (ecco il limite di gestione loco contemporanea che qualche produttore dichiara, a prescindere dalla potenza del booster).
Mi servirà  quindi un meccanismo per tenere traccia dell'ultima volta che ho modificato un valore dei comandi periodici, in modo da poter eliminare dallo stack la loco che non gestisco da più tempo.

Infine il processo core, eseguito con un timer che imposta un interrupt ogni circa 50us, gestirà  il comando attualmente in trasmissione con un cursore che indica il bit attuale e la parte di questo bit (prima metà , seconda metà  dell'onda quadra) in modo da generare il segnale in uscita.

Che ne dite? Commenti?
bye

[spurn_db]

direi che ci sono un sacco di sorgenti online (compreso di altro livello come SCRP server) che possono chiarirti quale strada seguire sinceramente mi terrei n posti per le loco (da rilasciare quando a velocità  0 da n giri di "posizioni" o manualmente se punti a un sistema a trotthle) e una posizione per gli spot quando inviato cancella la posizione in modo da occuparla di nuovo al prossimo giro

[greenant]

Se hai molto tempo da investire, potresti implementare tutto su fpga, scaricando uno di quei core gratuiti che ti fa da 8051 ed implementando in VHDL la parte relativa alla generazione dell'onda quadra.

Volendo implementarlo in modo classico, secondo me è utile separare fisicamente (su due processori diversi quindi) la generazione dell'onda quadra e il resto della gestione.

Quindi usi un micro poco costoso che ti prende in ingresso i 2 o 3 (o più) byte del messaggio da inviare e ti calcola lo xor e ti crea l'onda quadra.

Suppongo che i vari produttori commerciali facciano così, altrimenti non mi spiego l'utilizzo di più di un micro sulla stessa board

[Luca]

Ciao

grazie per le risposte... mi sono guardato un po' di sorgenti e devo dire che alcuni sono proprio basilari (vedi MiniDCC) visto che loopano in continuo semplicemente inviando anche comandi non necessari (loop su tutte le loco disponibili) a loco non esistenti.

anch'io seguirei invece la strada proposta da Greenant, un Micro che gestisce la parte di comunicazione e il buffer, e un altro che gestisce l'interazione con l'utente e eventuali accessori (palmari, PC). Il dialogo tra i due sarebbe semplicemente la comunicazione dei comandi da inviare.

bye

[Buddace]

Bhe soluzione da sborone non so se utilizzabile e efficiente....pensando in C farei una struttura loco con i vari dati e poi farei una lista di queste strutture. Sotto interrupt mi sfoglio la struttura.

[Despx]

Io a suo tempo con KDCC avevo proprio usato un 16F877 per interfacciarmi ai palmari ed un 16F629 per gestire gli stack, e la generazione del segnale DCC; i due pic parlavano tra di loro con un bus parallelo ad alta velocità  a 8+3 bit.
Questa configurazione mi ha dato talmente tante soddisfazioni che l'ho implementata nella nuova KDCC...con piccole migliorie come l'uso di un più economico 16F876 ed altro...
Ovviamente ha il difetto di impegnare tanti piedini dei pic ma ha il vantaggio enorme che non richiede al 16F629 strane temporizzazioni e l'uso degli interrup tra la generazione del DCC e la ricezione dei dati dal 16F877 inoltre il segnale DCC è continuo e non interrotto per pochi ms tra un pacchetto e l'altro (come avviene su altre centrali in rete) portando a malfunzionamenti di alcuni decoder lowcost come gli esu base.

Con 10 MHz di clock si può programmare con qualsiasi linguaggio ad alto livello (picbasic, C, pascal, ecc) io la vecchia KDCC l'ho programmata interamente in picbasic senza problemi, la nuova invece la programmo in MikroC perchè lo ritengo più performante e completo.

Ciau
Despx

[antogar]

portando a malfunzionamenti di alcuni decoder lowcost come gli esu base

Despx,

ma questi comportamenti dei decoder sono una non-compliance delle centraline (come la NanoX) oppure dei decoder ?

Guardando i doc dello standard NMRA (e da uno scambio con i tecnici ESU) mi è sembrato che fossero i decoder low-cost a non rispettare lo standard... può essere ?

Ciao
Antonino

[Buddace]

Guardando i doc dello standard NMRA (e da uno scambio con i tecnici ESU) mi è sembrato che fossero i decoder low-cost a non rispettare lo standard... può essere ?

Esatto è un problema dei decoder che non supportano lo 0 allungato per il controllo di una locomotiva analogica.
Praticamente tutte le centraline commerciali entry level (lokmaus,compact,select,etc..) usano un solo pic per fare tutto senza alcun problema di sorta.
Vedi anche il buon vecchio zDCC che con un pic solo riceve radio e genera dcc.

[antogar]

Esatto è un problema dei decoder che non supportano lo 0 allungato per il controllo di una locomotiva analogica.

Ho snocciolato questo argomento con il support di ESU e Paco Canada... e sono giunto alle stesse conclusioni anche se un pò incredulo.

Se io compro la Ecos e qualche decoder Lokpilot Basic, poi abilito la funzione di loco analogica... le loco digitalizzate con i basic si fermano ?!?!

[Buddace]

Se io compro la Ecos e qualche decoder Lokpilot Basic, poi abilito la funzine di loco analogica... le loco digitalizzate con i basic si fermano ?!?! ...eppure è tutto dello stasso costruttore!

Non avendo lokpilot non ti so dire ma è pobile che in arrivo di 0 allungati i decoder lo intepretino come errore scartando il pacchetto. Quindi o continuano a stare ferme o a ripetere l'ultimo comando.

[antogar]

Io ho alcuni Lokpilot Basic e in pratica in presenza di "stratched" 0-bit non funzionano... peccato per chè la NanoX è proprio un bel sistemino!

[Buddace]

non funzionan

Cioè? i treni si fermano ? non rispondono ai comandi ?

[antogar]

La loco è ferma, non risponde ai comandi (nè moto, nè funzioni).
In modalità  programmazione, leggo e scrivo CV senza problemi con il Lokomaus e con il minimaus...

[Despx]

Il problema degli zero allungati è vecchio come il mondo; lo chiamo problema perchè, essendo una cosa posticcia per salvare capre e cavoli (loco digitale insieme a loco analogica sullo stesso binario) può creare notevoli problemi sia nella decodifica dei decoder "base" sia nella reazione del decoder ai comandi (leggere tempi morti). La stessa NMRA si potrebbe dire che vada in conflitto con sestessa perchè se da una parte dice che l'invio dei pacchetti deve essere il più velocemente possibile dall'altra ammette gli zero lunghi che di veloce non hanno nulla visto che possono arrivare a 10 ms, un'eternità  nel DCC dove si stà  sui 58 e 116 us (micro secondi).
Sul discorso uno o due pic bhe... è questione di gusti, io, per semplificarmi la vita, avere disponibilità  di spazio nella memoria del pic per futuri uprgade anche corposi e prestazioni eccellenti, preferisco due pic con compiti diversi con un piccolo aumento di prezzo (un po come avviene nei pc con la CPU e le varie schede grafiche, audio ecc).
Non mi piacciono le cose troppo "tirate" come nel caso delle centrali ad un solo pic, le ho provate, e le ho trovate discrete ma delicate, basta sbagliare una temporizzazione tra IN e OUT per avere un segnale DCC non conforme anche usando la regola dei 5 ms accettata dalla NMRA, certamente si può fare tutto con un pic ma solo con la programmazione asm ma...secondo me, visto che siamo già  da tempo nel 21° secolo e l'elettronica costa poco, possiamo anche mandare in pensione l'asm a favore di un linguaggio più evoluto e meno ostico anche se ci vogliono due pic...

Ciau
Despx

[Despx]

PS: x antogar la Nanox è carina ma è limitata ... ti consiglio di aspettare un pochino...

Ciau
Despx