Visualizzazione post con etichetta rocrail. Mostra tutti i post
Visualizzazione post con etichetta rocrail. Mostra tutti i post

martedì 21 marzo 2017

La nuova centrale di controllo (3)

Buona serata ai miei lettori!

Settimana intensa, quella appena trascorsa, ma non scevra di soddisfazioni! La mia centrale di controllo ha lentamente preso vita e posso finalmente farvi vedere qualcosa che si muove.

Devo ammettere che la documentazione su come realizzare la comunicazione non è proprio abbondante, sia dal punto di vista dei produttori di centrali (eccezion fatta per Lenz [link] ed una vecchia versione di Sprog [link]), sia dal punto di vista dei programmi di controllo. Capisco molto bene il punto di vista dei produttori commerciali e ritengo siano da elogiare i due che ho indicato per aver rilasciato al pubblico una descrizione -seppur forse incompleta- del protocollo di comunicazione. In giro ovviamente si trovano anche altri dettagli, ma preferisco non avere noie in seguito.

Al contrario proprio non capisco per quale motivo chi sviluppa software di controllo open-source (in questo momento, realmente aperto resta solo JMRI) non abbia previsto un meccanismo, non dico facile, ma almeno umano, per estendere la libreria di centrali di controllo. Pertanto ho dovuto arrangiarmi...

20170319_201433

Qui sopra il sistema di pre-test: in pratica ho fatto in modo di trasferire al PC tutti i comandi che JMRI e Rocrail inviano tramite la porta seriale di uscita sulla Raspberry. Sarebbe stato un gioco da ragazzi se avessi avuto un convertitore USB-seriale adatto al voltaggio della Raspberry. Purtroppo non ce l'ho, quindi dovuto adottare una soluzione più complessa, riciclando la schedina che tempo fa avevo usato per il misuratore di velocità. In primo piano la scheda di programmazione e debug, subito dietro sulla destra quella di conversione, dietro ancora la Raspberry. Grazie ai dati letti in questo modo, ai sorgenti di uno dei due programmi di controllo di cui sopra ed alla documentazione ufficiale trovata in rete, sono riuscito a capire come scambiare i comandi.

20170321_191547

A questo punto ho potuto finalmente programmare in modo adeguato la mia schedina e vedere accendersi i fanali della mia fida 245, che da sempre uso come muletto per queste prove, come potete intravvedere dalla foto qui sopra. Per dimostrarvi che non solo le luci funzionano, ma anche il motore fa il suo dovere, eccovi un piccolo video.


Non sono ancora granché soddisfatto della velocità di reazione e manca del tutto la parte di programmazione e lettura delle variabili di configurazione, quindi c'è ancora del lavoro da fare ma...
eppur si muove!

A presto!

martedì 14 marzo 2017

La nuova centrale di controllo (2)

Buona serata ai miei lettori!

I test della nuova centrale di controllo proseguono bene: il circuito di generazione del segnale DCC comincia ad avere una programmazione più solida ed inizia a trasmettere i primi pacchetti sensati. Quanto al sistema di controllo, non c'è che dire: sono molto soddisfatto dell'acquisto.

20170314_194606

Prima di tutto per le dimensioni: in fin dei conti ho sostituito l'intero cassone con quello che vi posa sopra. Raspberry è così compatta che posso installarla permanentemente dentro al plastico, così qualora lo debba trasportare da qualche parte il tutto sarà autocontenuto. In secondo luogo configurare il sistema è stato veramente facile: le guide presentate sul sito di JMRI (link) e su quello di RocRail (link) sono abbastanza puntuali ed entrambi i sistemi hanno funzionato fin dal primo istante. Come al solito, oltre ai due programmi di controllo, ho installato anche VNC come sistema di visualizzazione da remoto; o meglio, ho solo abilitato VNC, perché questo programma è già preinstallato in Raspbian Jessie, il sistema operativo che ho installato su Raspberry.

raspberry_jmri

Qui sopra potete vedere i primi passi della configurazione di JMRI: essendo abituato a Rocrail il tutto mi risulta un poco alieno, ma alcune cose mi sono piaciute fin da subito. Una su tutte: non appena ho connesso i LocoIO al bus Loconet il sistema ha subito riconosciuto autonomamente tutti i sensori collegati, che sono risultati immediatamente funzionanti.

raspberry_rocrail

Qui sopra invece le prime impostazioni di Rocrail: ho dovuto faticare parecchio di più per configurarlo, soprattutto perché non riuscivo a convincerlo a connettersi al LocoBuffer via porta USB. Alla fine, scovata la giusta configurazione anche questo sistema si è messo a funzionare a dovere.

Il prossimo passo sarà connettere entrambi i programmi alla scheda di generazione del segnale DCC per vedere finalmente muoversi qualcosa. Non vedo l'ora!

A presto!

martedì 10 gennaio 2017

La nuova centrale di controllo (1)

Buona serata ai miei lettori!

Come vi ho raccontato la settimana scorsa, il secondo obiettivo di queste vacanze natalizie, ormai giunte ben oltre il loro termine, era il montaggio della mia nuova centrale di controllo DCC. Il tentativo è quello di eliminare completamente il vecchio, ingombrante e rumoroso PC che utilizzavo per farvi girare RocRail per sostituirlo con qualcosa di decisamente più compatto. Vista la diffusione ormai raggiunta e considerato il fatto che due dei più importanti software di controllo gratuiti -RocRail e JMRI- entrambi la supportano, ho optato per una economicissima Raspberry Pi 3b (link).

20170104_124152

Già da sola questa schedina fa ottime cose: una CPU ARMv8 quad-core 64-bit da 1.2GHz asservita da 1GB di RAM (accoppiata decisamente più performante di quella del vecchio PC), rete cablata e wireless, bluetooth, e tutta una serie di porte decisamente utili, tra cui 4 USB per tastiera e mouse -e magari un monitor touch in futuro per realizzare il pannello di controllo. Il tutto in poco più di 8x5 cm: meno di un cellulare...

Ovviamente non può fare tutto da sola: per questo ho realizzato una scheda figlia -un hat in gergo- battezzata per l'occasione rBooster per generare il segnale DCC, per il tracciato ed il bus loconet, e contemporaneamente derivare l'alimentazione stabilizzata della Raspberry senza dover ricorrere ad un secondo alimentatore. Il grosso chip che vedere sul fondo è lo stesso chip che ho utilizzato per la vecchia interfaccia DCC: può gestire fino a 55W, decisamente sufficienti per un impianto piccolo come Caprazzino.

La soluzione non brilla certo per originalità, dal momento che esiste già una alternativa commerciale (link), ma non vedo perché non dovrei tentare di costruire da solo la mia versione del sistema di controllo secondo i miei desideri. D'altra parte esistono anche persone che si costruiscono da se i rotabili...

Nelle prossime settimane, oltre a lavorare sui restanti deviatoi del piano di stazione di Caprazzino, proseguirò con la programmazione dei due strati -rBoster e Raspberry-. Nel frattempo vi mostro il primo vagito del booster che al momento altro non fa se non inviare sulle rotaie il segnale di idle del DCC. Le tempistiche sono decisamente soddisfacenti ed in linea con le specifiche NMRA -le norme modellistiche americane che dettagliano il funzionamento del DCC.

tek00000

Al momento non mi sono posto scadenze per il completamento di rBooster, ma spero di vederlo in funzione entro l'estate, in tempo per i primi giri di ruota in stazione a Caprazzino.

A presto!

martedì 16 giugno 2015

Tarare le velocità

Buona serata ai miei lettori!

Sull'onda dell'entusiasmo dell'essere riuscito a leggere le CV come si deve questo weekend sono subito passato alla taratura delle velocità delle loco. Però, per fare un buon lavoro, come si vede in questo post con video (link) di Vikas Chander, è necessario uno strumento per misurare la velocità delle loco in scala.

Cercando in giro su internet si trovano varie soluzioni: Vikas utilizza un sistema di Accutrack (link) basato su una barriera a raggi infrarossi da installare su un tratto di binario, ma esiste anche il sistema proposto da Bachrus (link) che si basa sulla lettura della velocità di rotolamento; in questo caso si usa un set di cuscinetti a sfera.

Dal mio punto di vista, il secondo sistema è preferibile: non c'è bisogno di un lungo tratto di binario per permettere alla loco di raggiungere la velocità da misurare, quindi il tutto rimane più compatto. Una soluzione per realizzare in casa questo sistema è quello di sfruttare un vecchio mouse di quelli con la sfera. Questi "topi" infatti usano una coppia di ruote traforate per individuare gli spostamenti della sfera.


Quanto la ruota gira, le lamelle ostacolano il fascio di luce emesso dal led (light emitter) e ricevuto dal rivelatore (light detector). Stessa cosa si può fare per misurare la velocità dei una loco: se la ruota fosse trascinata nel movimento da un assale della loco, basterebbe misurare quanto frequentemente il fascio di luce viene interrotto per conoscere la velocità della loco.

Ovviamente, per permettere la rotazione degli altri assi, sono necessari dei cuscinetti a sfera. E visto che nel cassetto degli attrezzi me ne erano rimasti una decina dal mio piega rotaie, ho iniziato il progetto. Purtroppo però il diametro dei cuscinetti era troppo grande e, visto che ne servono due per asse, sarebbero andati a cozzare contro i tubi lancia sabbia di alcune delle mie loco.

Pertanto sono tornato alla soluzione basata sulla barriera infrarossa. Fortunatamente i sensori IR che ho progettato, realizzato e che vi ho mostrato vari post fa possono essere riciclati per questo scopo. In questo caso il funzionamento è ancora più semplice: per misurare la velocità basta contare quanto tempo passa tra l'interruzione della prima barriera e della seconda.

20150614_143401

Per misurare i tempi e convertirli in una velocità è sufficiente un microcontrollore di bassa fascia: se ne trovano di molto economici in commercio, io preferisco il 12F1840 di Microchip. In questo caso però volevo qualcosa che fosse già configurato per interfacciarsi con il PC via USB, per mostrare il risultato della misura: avendo a disposizione un paio di schede di sviluppo di Xplain di Atmel, la scelta è caduta su quella.

20150614_143743

La potete vedere qui sopra dietro la basetta di sviluppo blu; quattro cavetti la collegano ai sensori: dall'alto alimentazione per i sensori a 5V, massa, e uscita di ciascun sensore. In questa immagine inoltre potete vedere che ho usato due spizze di legno per mantenere la basetta con i sensori ben parallela al binario.

20150614_143608

Il funzionamento del mio tachimetro casalingo è semplicissimo. Una volta programmato e collegato il sistema al PC, con il mio fido cellulare trasformato in controllo remoto per RocRail programmo la loco per farsi un giro sul cappio di ritorno a velocità costante.

20150614_143636

Quando la loco passa davanti al primo sensore si accende un led rosso, che segnala l'interruzione della barriera, ed il sistema inizia a contare in millesimi di secondi.

20150614_143706

Quando la loco passa davanti al secondo sensore, si accende anche il secondo led rosso ed il sistema trasmette al PC la velocità rilevata, tradotta in km/h in scala.

20150614_143834

Il sistema è in grado di distinguere il verso con cui la locomotiva attraversa il tachimetro e lo segnala inserendo il prefisso BWD -backward- se la loco sta andando indietro o FWD -forward- se sta andando avanti. Questo aiuta a verificare la simmetria nelle condizioni di marcia: capita a volte, infatti, di leggere in qualche recensione che il comportamento nelle due direzioni non è esattamente identico.

Ora che ho la possibilità di misurare la velocità delle loco, posso dedicarmi alla taratura. Come suggerito da Chander nel suo post, ho pensato di fissare la velocità media -step 14 su 28- a 30km/h, ovvero alla velocità che un macchinista dove tenere in approccio ad un segnale di prima categoria disposto a via impedita. Per quanto riguarda la velocità minima, ho cercato di scendere fino al passo d'uomo, ovvero 4km/h. Infine, per la velocità massima, basta cercare in rete la velocità massima del rotabile corrispondente.

A questo punto ho provato a sfruttare la capacità dei decoder di regolare automaticamente le velocità dei passi intermedi fissando la velocità minima (CV2), massima (CV5) e media (CV6). Ho fatto qualche prova, ma non sono stato soddisfatto dai risultati. Pertanto ho preferito utilizzare le CV 67-94 e creare una mia personalissima curva delle velocità; per fare questo ho dovuto anche impostare ad 1 il bit 5 della CV 29.

20150614_234944

Prima di tutto ho impostato una curva lineare da 2 a 56. Poi ho misurato con il tachigrafo la velocità della loco agli step bassi (1-3) alla ricerca dei fantomatici 4km/h. Con una curva fatta in questo modo è piuttosto facile trovare il valore giusto: se la velocità non corrisponde esattamente ad uno step, quindi ad un valore pari, allora è sicuramente il valore dispari tra i due step più prossimi. Stessa cosa vale per la ricerca dei 30km/h: in questo caso però la ricerca parte dai valori centrali (13-15). Infine, per quanto riguarda la velocità massima, ho usato ancora una volta una curva lineare, ma questa volta da 2 a 254.


Ottenuti i valori giusti, mi sono scritto un foglio di calcolo con Google Documents che imposta una curva lineare per gli step 1-14 ed una curva quadratica per gli step 14-28. Ho fatto in modo che la pendenza della curva allo step 14 per entrambe le metà della curva sia la stessa: in questo modo non si nota alcuno scatto al passaggio tra i due regimi.

Impostare la velocità per la E 190 322 CFI, che monta un Lenz STANDARD+ è stata una pacchia. In pratica mi sono ritrovato con un valore di 4 per i 4km/h, un valore di 30 per i 30km/h e di 160 per i 160 km/h. Una favola!! La E 191 003 FuoriMuro, che invece monta un Esu LokPilot 4, è stato decisamente più ostico.

Comunque sia, sono finalmente riuscito a fare la prima doppia trazione di Caprazzino: terminata la taratura, la E190 e la E191 si sono comportate ottimamente. Non si sono mai strattonate e hanno superato l'ingresso della stazione nascosta senza alcun problema, a tutte le velocità.

Ora tocca alla distanza di frenatura.

A presto!

martedì 9 giugno 2015

La lettura delle CV (3)

Buona serata ai miei lettori!

Finalmente sono riuscito a sistemare la lettura delle CV sul mio booster. La settimana scorsa ero effettivamente riuscito a leggere le CV in modalità lenta, ma i tempi di acquisizione erano troppo lenti per i miei gusti. La modalità "fastgetcv" offerta da RocRail avrebbe dovuto risolvere il problema, ma in realtà ne ha creato uno nuovo, legato al fatto che il programma leggeva sempre un valore in più rispetto al dovuto.

Lavorando durante il weekend sono riuscito a risolvere il problema.

Prima di tutto mi sono stufato di dover ricompilare tutte le volte TUTTO RocRail anche in presenza di minime variazioni di una porzione di codice secondaria. Di conseguenza, non me ne vogliano a male gli sviluppatori, ho disabilitato la ripulitura del codice a livello di makefile.

Ho pertanto ritoccato il file 'makefile' nella cartella 'rocrail', rimuovendo il comando

$(MAKE) clean PLATFORM=$(PLATFORM) NATIVE=$(NATIVE)$(CS)

dalle righe 162-167 e 171, in pratica da così...

makefile_pre

a così...

makefile_post

(guardate le foto ingrandite se volete vedere qualcosa...)

A questo punto, ogni volta che ricompilo il programma, il sistema si preoccupa soltanto dei file che ho modificato, così da mezzora di compilazione siamo passati ad un minuto. Ora sì che si ragiona!

Bene. Ora tocca alla funzione 'nmragetcvbyte' a cui si fa riferimento alla riga 495 di ddx.c. Questa funzione si occupa di inviare il segnale DCC per la lettura della CV ed aspettare il segnale di ACK corrispondente.

La parte incriminata della funzione parte intorno alla riga 1356, ovvero il ciclo di lettura vero e proprio. Immagino che le sviste di programmazione presenti siano legate ad una sedimentazione di diverse versioni, o almeno lo spero...

Dopo aver rimosso alcune inizializzazioni multiple della variale associata al segnale di ACK, la vera chiave di volta per il mio booster è stato abilitare il ciclo di attesa 'waitMM' anche in modalità 'fastgetcv'. Ovvero ho sostituito questo:

SerialOp.flush(data->serial);
ack = scanACK(data->serial);
sendsize = __createCVgetpacket(cv, value, SendStream, start);
if( value % 10 == 0 || !fastcvget )
  TraceOp.trc( __FILE__, TRCLEVEL_MONITOR, __LINE__, 9999,\
   "PT: sending %d bytes checking value %d...", sendsize, value);
SerialOp.write(data->serial,SendStream,sendsize);
if (start)
  ThreadOp.sleep(240);
else if( !fastcvget )
  ThreadOp.sleep(40);
ack = 0;
/* wait for UART: */
ack=waitUARTempty_scanACK(data->serial);
for( i = 0; i < (fastcvget ? 5:120) && ack == 0; i++ ) {
  ack = scanACK(data->serial);
  if( !fastcvget )
    SerialOp.waitMM(data->serial,5000,100);
}

con questo:

SerialOp.flush(data->serial);
sendsize = __createCVgetpacket(cv, value, SendStream, start);
if( value % 10 == 0 || !fastcvget )
  TraceOp.trc( __FILE__, TRCLEVEL_MONITOR, __LINE__, 9999,\
    "PT: sending %d bytes checking value %d...", sendsize, value);
SerialOp.write(data->serial,SendStream,sendsize);
if (start)
  ThreadOp.sleep(240);
else if( !fastcvget )
  ThreadOp.sleep(40);
/* wait for UART: */
ack = waitUARTempty_scanACK(data->serial);
for( i = 0; (ack == 0) && i < (fastcvget ? 5:120); i++ ) {
  ack = scanACK(data->serial);
  SerialOp.waitMM(data->serial,5000,100);
}

Non è molto diverso, ma è quel tanto che basta per fare la differenza! Ora posso finalmente scaricare il profilo di velocità della mia E191.003 FuoriMuro.

curvaVel_E191

Ed infatti, eccolo qui. Giusto qualche minuto di attesa e finalmente ho sotto mano la curva.
Ora posso sistemare la velocità massima e tutte le intermedie come si deve.

A presto!

giovedì 4 giugno 2015

La lettura delle CV (2)

Buona serata ai miei lettori!

Il lavoro sulla lettura delle CV continua. Durante la scorsa settimana ho ripulito il codice che avevo scritto per il microcontrollore: grazie ad un simpatico oscilloscopio su scheda (link) che mi ha regalato quest'anno mia moglie per il mio compleanno sono riuscito ad acquisire l'andamento temporale della corrente assorbita. Ci ho lavorato un poco su con il mio programma di elaborazione dati preferito (link) ed ho aggiornato di conseguenza i filtri per il segnale di ACK. E questo è il risultato:

20150603.232933.706 r9999c 000028AC impl/ddx 1334 PT: cvget for 0
20150603.232933.707 r9999c 000028AC impl/ddx 1341 PT: enable booster output
20150603.232933.708 r9999c 000028AC impl/ddx 1351 PT: power on cycle
20150603.232933.709 r9999c 000028AC impl/ddx 1353 PT: start polling...
20150603.232933.709 r9999c 000028AC impl/ddx 1367 PT: sending 678 bytes checking value 0...
20150603.232934.610 r9999c 000028AC impl/ddx 1367 PT: sending 216 bytes checking value 1...
20150603.232935.277 r9999c 000028AC impl/ddx 1367 PT: sending 216 bytes checking value 2...
20150603.232935.944 r9999c 000028AC impl/ddx 1367 PT: sending 216 bytes checking value 3...
20150603.232936.017 r9999I 000028AC impl/ddx 1059 PT: ACK detected.
20150603.232936.023 r9999c 000028AC impl/ddx 1405 PT: ack = 1
20150603.232936.023 r9999c 000028AC impl/ddx 1407 PT: disable booster output
20150603.232936.034 r9999I cmdr024C OControl 0211 Program event...value=3

Ok, ora ci siamo anche sui valori. Purtroppo però essendo disattivata la proprietà "fastgetcv", in presenza di valori elevati del valore della CV controllata, i tempi di acquisizione sono troppo lunghi per i miei gusti. Pertanto ho deciso di abilitare "fastgetcv", ma il problema del +1 si è ripresentato di nuovo... 

Però, guardando il log di rocrail, mi sono accorto di un comportamento secondo me anomalo:

20150603.233442.113 r9999c 00002FCC impl/ddx 1334 PT: cvget for 0
20150603.233442.113 r9999c 00002FCC impl/ddx 1341 PT: enable booster output
20150603.233442.114 r9999c 00002FCC impl/ddx 1351 PT: power on cycle
20150603.233442.114 r9999c 00002FCC impl/ddx 1353 PT: start polling...
20150603.233442.761 r9999I 00002FCC impl/ddx 1059 PT: ACK detected.
20150603.233442.762 r9999I 00002FCC impl/ddx 1059 PT: ACK detected.
20150603.233442.763 r9999I 00002FCC impl/ddx 1059 PT: ACK detected.
20150603.233442.764 r9999I 00002FCC impl/ddx 1059 PT: ACK detected.
20150603.233442.765 r9999I 00002FCC impl/ddx 1059 PT: ACK detected.
20150603.233442.766 r9999I 00002FCC impl/ddx 1059 PT: ACK detected.
20150603.233442.767 r9999I 00002FCC impl/ddx 1059 PT: ACK detected.
20150603.233442.768 r9999I 00002FCC impl/ddx 1059 PT: ACK detected.
20150603.233442.796 r9999I 00002FCC impl/ddx 1059 PT: ACK detected.
20150603.233442.797 r9999I 00002FCC impl/ddx 1059 PT: ACK detected.
20150603.233442.798 r9999I 00002FCC impl/ddx 1059 PT: ACK detected.
20150603.233442.799 r9999I 00002FCC impl/ddx 1059 PT: ACK detected.
20150603.233442.800 r9999I 00002FCC impl/ddx 1059 PT: ACK detected.
20150603.233442.801 r9999I 00002FCC impl/ddx 1059 PT: ACK detected.
20150603.233442.802 r9999I 00002FCC impl/ddx 1059 PT: ACK detected.
20150603.233442.803 r9999I 00002FCC impl/ddx 1059 PT: ACK detected.
20150603.233442.804 r9999I 00002FCC impl/ddx 1059 PT: ACK detected.
20150603.233442.870 r9999c 00002FCC impl/ddx 1405 PT: ack = 1
20150603.233442.870 r9999c 00002FCC impl/ddx 1407 PT: disable booster output
20150603.233442.885 r9999I cmdr0105 OControl 0211 Program event...value=4

Perché Rocrail impiega ben 17 passaggi per accorgersi che il segnale di ACK è attivo?
Devo studiare ancora un poco: purtroppo compilare RocRail richiede parecchio tempo, quindi il lavoro procede lentamente.

Nel frattempo, per non tediarvi ulteriormente con la programmazione, che con il modellismo c'entra solo in parte, vi faccio vedere qualcosa di curioso. Ricordate i primi post circa la linea principale di cui quella per Caprazzino è una diramazione?  Se sì, dovreste anche avere presente il fatto che era pensata sul tracciato della vecchia linea Rimini-Novafeltria. Si da il caso che il primo giugno sia andato a Pennabilli con mia moglie ed una coppia di nostri carissimi amici. Partendo da Bellaria, una delle possibili strade è proprio la provinciale costruita sul sedime della vecchia linea.

Pur non avendo la possibilità di fermarmi per scattare le adeguate foto del caso, sono rimasto piacevolmente stupito della quantità di manufatti ancora esistenti. Per dare una idea anche a voi, ecco una piccola carrellata tratta da Google Maps.

Ex stazione di Villa Verucchio




Imbocco galleria a Ponte Verucchio


Ex Stazione di Pietracuta




Ex stazione di Dogana


Potete trovare altre foto qui (link), sul sito di Ferrovie Abbandonate. Seppure in cattivo stato di conservazione, sono sicuramente un'ottima fonte di ispirazione per per il mio plastico. Mi sa proprio che questa estate potrei organizzare una spedizione fotografica per ottenere qualche particolare in più...

A presto!




martedì 26 maggio 2015

La lettura delle CV (1)

Buona serata ai miei lettori!

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.

20150526_215023

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.

BitScope

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!!

martedì 5 maggio 2015

Il sistema di controllo (2)

Buona serata ai miei lettori!

Come promesso la scorsa settimana, negli ultimi giorni, ho fatto qualche prova con AndRoc (link). Devo dire che sono abbastanza soddisfatto: a parte la curva di apprendimento un poco ripida per chi come me è amante dello "sbagliando si impara" piuttosto che del leggere pedissequamente tutto il manuale, il programma è veramente ben fatto. Innanzitutto mi ha permesso di controllare tutto il plastico in maniera chiara da un solo dispositivo. In secondo luogo i tempi di risposta dei comandi inviati sono veramente ottimi. Vero è che per ora sto testando il tutto con una sola loco: vedremo ben più avanti come andranno le cose con più loco ed una tabella oraria degna di questo nome.

Ma veniamo al funzionamento. In questo momento vi sto scrivendo dal tavolo della sala: il plastico ed il sistema di controllo sono alimentati di là in studio ed io vi posso accedere tramite VNC, come vedete da questa foto.

2015-05-05 20.17.53

Sulla sinistra, tra le varie icone, trovano posto quella per far partire il server di RocRail (la terza dal fondo) e la sua interfaccia di controllo RocView (la seconda dal fondo). Facciamo partire il server con un bel doppio click e, avendo cura di aver disabilitato i messaggi di debug, otteniamo questo risultato.

2015-05-05 20.23.25

A questo punto, visto che sono ancora in fase di sviluppo, prima di far partire AndRoc, preferisco lanciare RocView: in questo modo posso controllare dallo schermo del PC che tutto fili liscio.

2015-05-05 20.26.40 HDR

Bene! Pare sia tutto in ordine: il software si ricorda che avevo lasciato il mio convoglio di test -la E190 CFI, un bagagliaio posta UIC-X in livrea MDVE e una semipilota MDVE- sul binario 7, anche se per ora non li "sente" dato che, seppure alimentati, il sistema di controllo è spento, come testimonia il pulsante non premuto a forma di lampadina in alto, sotto la barra dei menù. E' ora quindi di lanciare AndRoc.

2015-05-05 20.28.42 HDR

La schermata di lancio si presenta essenziale ma funzionale. Una volta inserito l'indirizzo del pc che controlla il plastico -basta farlo una volta, l'app se lo ricorda- e la porta a cui connettersi -io ho lasciato quella di default-, il programma si connette al server di RocRail e carica lo schema dell'impianto.

2015-05-05 20.29.10 HDR

Come potete vedere, questo ricalca fedelmente quanto compare sullo schermo del PC (lo vedete meglio nel post precedente). In alto trovate il nome del pannello relativo alla parte che vogliamo controllare: in questo caso 'Nascosta'. Io ho deciso di creare un pannello per ogni livello così da poter gestire meglio le manovre, anche se sarebbe stato possibile fare un unico pannello per tutto il plastico, dato che la struttura non è delle più complicate.

Ora, tenendo premuto il nome del pannello a lungo si accede al menù di controllo.

2015-05-05 20.29.23 HDR

Qui la traduzione dall'inglese ha lasciato un poco a desiderare. "Limitatore" in realtà dovrebbe essere tradotto tutt'al più come "Regolatore", in quanto permette di controllare la marcia di una delle loco sul plastico. Vediamo piuttosto di accendere il sistema. Facendo click su "Sistema" si accede a questa schermata.

2015-05-05 20.29.39 HDR

Anche qui la traduzione non ci viene sempre in aiuto, purtroppo... Accendiamo l'impianto tramite il pulsante "Accendi" e facciamo partire  la modalità automatica con "Accensione automatica". Ora, dato che ho già configurato il sistema per far muovere alternativamente il convoglio di test dal binario 7 al binario 1 e ritorno, transitando per il cappio di ritorno -binario 8-, manca solo di dare il via alla locomotiva.

2015-05-05 20.30.12 HDR

Infatti ora tutto è pronto: il sistema rileva il convoglio sul binario 7 ed in particolare mi sta dicendo che è proprio all'estremo destro. Deduco questo dal fatto che la spia al centro, affianco alla sezione di blocco entro cui è scritto "test >" è accesa con luce rossa: questo vuol dire che su quella tratta c'è assorbimento di corrente. A sinistra c'è inoltre una seconda spia a luce rossa: questa corrisponde al rilevatore infrarosso che sta segnalando occupazione. Le spie sui binari 1-6 sono tutte spente dato che i binari sono vuoti.

Ora posso cliccare su "test": si apre questo menù, che mi permette di controllare la E190.

2015-05-05 20.30.57 HDR

Facendo clic su "loco" si apre questo secondo menù.

2015-05-05 20.31.06 HDR

Seleziono dal menù a tendina "schedule list" -scusate la traduzione incompleta...- ovvero dalla lista delle tabelle orarie la tabella di test e controllo che la loco sia correttamente assegnata alla sezione di blocco SN7, ovvero "stazione nascosta, binario 7".

2015-05-05 20.31.19 HDR

Ora posso premere su "avvia" ed il convoglio si mette in moto. Il percorso verso il binario 8 viene preparato e bloccato, indicato dal colore giallo.

2015-05-05 20.31.29 HDR

Ora il convoglio è entrato nella sezione di blocco, come testimoniato dall'accensione della spia corrispondente al sensore di occupazione. La prima spia resta verde, al momento, perché non ho ancora installato e cablato il sensore infrarosso corrispondente a quel punto di fermata.

2015-05-05 20.31.34 HDR

Viene ora prenotato e bloccato il secondo itinerario verso il binario 1...

2015-05-05 20.31.43 HDR

... che viene percorso dal convoglio di test fino all'ingresso nel blocco. Tre secondi dopo l'ingresso il treno decelera dal 50% al 20% della velocità massima preparandosi all'arresto ed inversione di marcia.

2015-05-05 20.31.52 HDR

L'arresto avviene in corrispondenza del sensore infrarosso che protegge la fine del binario: la spia si accende non appena il convoglio passa davanti al sensore.

2015-05-05 20.32.19 HDR

A questo punto, dopo una decina di secondi di pausa, il convoglio inverte la direzione e ritorna sul binario 7.

20150505_203550

Approfittando di una pausa tra le corse di test, qui sopra potete vedere il convoglio fermo sul primo binario.

La precisione del punto di arresto dipende da due fattori: prima di tutto, la velocità che ha la loco al momento in cui passa davanti al sensore. Questo è piuttosto intuitivo: tanto più va veloce, maggiore sarà lo spazio di arresto, soprattutto se il decoder installato è programmato per simulare accelerazioni realistiche. Ma c'è anche un secondo parametro, più subdolo, che è il tempo di risposta del sistema di controllo: infatti, tanto più tempo impiega il sistema a processare il messaggio inviato dal sensore, maggiore sarà lo spazio percorso dalla loco. Come potete vedere, però, è possibile ottenere una buona precisione: la E190 si è fermata a circa 3cm dalla fine del binario, 5cm dalla fine dell'impianto.

Per oggi è tutto: nelle prossime due settimane sarò molto impegnato per lavoro fuori casa quindi non vi garantisco di essere in grado di scrivere qualcosa puntualmente il martedì. Ho già un po' di materiale pronto: spero di riuscire a trovare il tempo per sistemarlo un poco.

A presto!!

martedì 28 aprile 2015

Il sistema di controllo (1)

Buona serata ai miei lettori!

Sono finalmente arrivato ad un punto importante nella costruzione del plastico: tutto il piano -1, quello della stazione nascosta è finalmente completato. Ho finito anche il cablaggio e la programmazione degli scambi e dei servo-relè. Dopo avere fatto un po' di pulizia e ripulito il piano del plastico dai piani di appoggio, la prospettiva è questa.

20150428_195904

L'alone di luce che vedete a destra è semplicemente un faretto che ho puntato sulla zona degli scambi per lavorare meglio. Questa invece è la vista di infilata della stazione nascosta, con i suoi 7 binari.

20150428_200431

Ma quello di cui voglio parlarvi oggi riguarda il sistema di controllo del plastico, od almeno quanto ho realizzato finora. Quindi la foto più significativa è questa che segue.

20150428_201205

In primo piano in basso vedete il mio vecchio cellulare. Come potete osservare sul suo schermo c'è una replica fedele dell'immagine presente sullo schermo del PC. Avendo deciso di adottare RocRail come programma di controllo -almeno per ora-, e non volendo pagare il dazio per l'applicazione di controllo remoto su iOS -gratis per android...- ho optato per il servizio di controllo remoto offerto da VNC (link). Questo programmino permette di telecomandare un PC via rete anche tramite un cellulare, a patto che su questo siano installati i relativi programmi di controllo: tutto questo, fortunatamente a gratis.

A sinistra dello schermo invece, poco oltre il cappio di ritorno, trovate il booster DCC, altra autocostruzione. Mi permette di controllare tutto il plastico ed eroga una potenza massima di 55W. Al momento è tarato per disconnettersi automaticamente in presenza di assorbimenti superiori a 3A, oltre che in presenza di cortocircuiti. Lo vedete meglio qui sotto.

20150428_200543

Subito sopra, al centro della foto, protetto da adeguata schermatura, c'è l'alimentatore switching principale, acquistato su internet a circa 10€ (link). Era tarato per fornire 12V/10A, ma un comodo regolatore già installato nel circuito stampato mi ha permesso di elevare la tensione in uscita fino ai 14.5V regolamentari, conformemente allo standard NMRA S-9.1 (link).

Poco più a sinistra si trovano due moduli gemelli: sono i rilevatori di corrente. Mi servono come sensori di occupazione di tratta per le 8 tratte in cui è stata divisa la stazione nascosta, ovvero i 7 binari di stazionamento ed il cappio di ritorno.

Subito sopra, dove vedete convergere i cavi piatti in uscita dai rilevatori di correte, c'è un modulo LocoServo di Hans De Loof. Al momento è collegato a tutti i servo motori -in bianco, fissati da staffe ad L in legno- che comandano i deviatoi della stazione nascosta, ma questo cambierà al termine della costruzione del piano superiore. Accanto ai servo motori, si trovano i servo relè per la polarizzazione dei cuori.

Lo schema complessivo attualmente è questo che segue.

13_schema_controllo

Il PC è collegato ad un router WiFi che, oltre a garantire l'accesso alla rete ethernet di casa, permette anche l'accesso wireless. Normalmente il PC ha solo il monitor, seppure anche questo sia opzionale, in quanto tutto si controlla via cellulare tramite il programma VNC di cui vi ho parlato prima.

Una delle porte USB del PC è collegata al LocoBuffer (link): questo permette a programmi come RocRail di interfacciarsi al bus LocoNet per controllare periferiche e ricevere informazioni -ad esempio sulla posizione dei treni- dai sensori sparsi sul plastico.

Al bus LocoNet sono collegati attualmente un modulo LocoServo (link), per il controllo di 8 servo motori e 8 ingressi/uscite generici (I/O) , ed un modulo LocoIO (link) per il controllo di 16 I/O. A LocoServo sono collegati, tramite i moduli servo relè per la polarizzazione dei cuori, gli 8 servo motori per il comando lento degli aghi dei deviatoi.

Lo stesso modulo LocoServo riceve gli ingressi di 2 moduli rilevatori di corrente (link) per il controllo dell'occupazione delle 8 tratte. Questo controllo è utile per stabilire se un treno è presente all'interno di un blocco, ma non permettono di stabilire la posizione precisa del treno all'interno del blocco.

Il modulo LocoIO per ora si interfaccia soltanto ai 7 sensori ad infrarossi che ho autocostruito. Questi sensori mi servono per stabilire la presenza o meno di un treno in un punto esatto dell'impianto: in particolare individuano il punto di fermata dei 7 binari tronchi della stazione nascosta.

Il movimento dei treni sull'impianto è controllato direttamente dal PC tramite il booster DCC. E' il pc stesso, tramite RocRail, a generare il segnale DCC. Purtroppo ho dovuto ritoccare un po' il programma, dal momento che alcuni errori di stesura impedivano un corretto funzionamento a causa di reiterati reset del flusso dei pacchetti di controllo. Fortunatamente RocRail è sia gratis che open-source, ovvero è possibile accedere al listato da cui si genera il programma: questo mi ha permesso di lavorare senza ostacoli.

Un sistema di controllo presente sul booster interviene in caso di cortocircuiti in un tempo trascurabile (31.25ns per chi fosse interessato) e controlla periodicamente che il sistema sia tornato alla normalità prima di restituire il controllo al PC. Nel frattempo il malfunzionamento viene segnalato al PC, il quale, con i suoi tempi, provvede a disabilitare il segnale DCC ed avvisare l'utente.

Sino ad oggi il sistema di controllo è stato testato per oltre 300 ore, di cui 150 consecutive, e non ha generato alcun problema, quindi mi posso ritenere soddisfatto.

Per la prossima settimana spero di essere riuscito a provare 'andRoc', il sistema di controllo remoto di RocRail per Android, così ve ne parlo un po'.

A presto!!