Buddace grazie, leggerò con attenzione, purtroppo, pur essendo venuto a Novegro, ho saputo in ritardo della tua lezione, quello che stai facendo per il nostro settore è importante per diffondere e far conoscere le potenzialità del digitale nel nostro non facile paese.

Tornando al discorso del Can Bus etc…. Certamente tu saprai dare una spiegazione tecnica, ma non riesco a capire come mai le informazioni che transitano ad esempio nel CanBus, non possano in qualche modo essere inviate tramite il binario, usando appunto una frequenza o più frequenze come quelle che vengono usate per tutte le altre funzioni.

Zimo, in un vecchio catalogo, aveva in programma un simile sistema, ritorno delle informazioni tramite binario. Poi non si è saputo più nulla.

Pensi che in un futuro non lontano si possa arrivare a questo?

Non mi sembra una cosa poi così impossibile.

Pure lo zimo voleva un detector ( Paolo P correggimi) collegato al canbus


il bus di estensione (canbus etc..) servirà sempre e comunque il motivo è spiegato nel pdf di cuo ho messo il link

Giovanni,
il punto critico dei sistemi digitali e' proprio il bus di feedback (retroazione).
Se non utilizza un protocollo robusto o non adatto alla dimensione dell'impianto, si possono perdere eventi (transiti sui reed, etc.) e questo porta a una condizione di sistema 'non sincronizzato'.
Tieni conto che quando un plastico diventa "grandicello" si superano i 10/20 eventi (retroazioni) al secondo.
Codificarli sul binario che gia' trasmette il segnale dcc assieme all'alimentazione e' tecnicamente fattibile ma non conveniente per vari motivi tecnici (che alla fine diventano economici).
D'altra parte un sofware di gestione per impianti grandi deve prevedere meccanismi di rilevamento delle condizioni di impianto 'non sincronizzato' e se possibile, recuperare automaticamente la situazione.

Lamps

Ciao Lamps, grazie per il chiarimento, mi hai detto ciò che volevo sapere; la retroazione tramite binario è tecnicamente fattibile. Tu sostieni che ci possono essere problemi tecnici. Domanda: questi problemi a prezzo di un costo maggiore sono superabili?

Insisto su questo perché possedendo un impianto che si estende per l'intero appartamento, oltre la lunga discesa che porta i binari sul plastico in costruzione, avere un "bus" da collegare a tutti i moduli di retroazione diventa scomodo e a mio parere deludente, tecnologicamente parlando.

IL fatto di possedere un binario di buona conduzione elettrica e non poterlo usare anche per questo scopo non mi convince.

Allo stato attuale di progresso tecnologico, dove ogni giorno comunico con la" lontana" America via audio/video in pochi secondi, mi girano non poco, dover stendere chilometri di filo per avere un ritorno di informazione. Capisco che l'esempio non è del tutto appropriato, ma è per dire che non siamo più ai tempi della pietra e del filo.

E' un problema di quantità di informazioni? Oltre il modellismo, la mia seconda passione è l'audio/video. Oggi esiste l'alta definizione e sta per diffondersi il4K, ovvero l'ultra Hd, che prevede una definizione di 3840×2160 pixel. Questo significa che per trasmettere tali segnali occorre uno spazio enorme. Come fanno e come potranno fare le varie reti televisive a farci stare il tutto? Comprimendo!

Questo per dire che c'è sempre una via, a costo di ripetermi a vita, ricordo che: l'uomo tanto può quanto vuole.
Se la retroazione tramite binario non è diffusa è solo perché non si è voluto.

Questa cosa si deve superare, in un modo o nell'altro il sistema lo voglio trovare.

Giovanni

Mi spiace ma non con le tecnologie attuali ... bisognerebbe buttare a mare centraline e decoder DCC (ma anche altri protocolli) e rifondare tutto da zero.

Già!

Purtroppo avete ragione tutti!

Mi occupo di automazione d'impianti e di telecomunicazioni.
Giovanni, i costi ci sono dietro alla parola magica "comprimendo" sono notevoli.
- lato trasmettitore il costo finisce nelle "care" apparecchiature (modulatori dvb-t) e in tutto quello che
c'e' a monte (mux, demux, ponti radio a microonde) e che serve per fare arrivare il segnale dalle regie di Roma/Milano
alle postazioni tipo "Monte Penice".
- lato ricevitore (il televisore in casa), il costo e' ripartito su decine di milioni di pezzi...
E questi costi sono sia di progetto che di materiali impiegati in ogni singolo pezzo prodotto.

Nel caso di quelle apparecchiature e' normale "infilare" su un unico cavo
- l'alimentazione (centinaia di watt)
- il flusso dati trasmesso
- il flusso dati ricevuto
- la telegestione (bidirezionale) degli apparati
lo si fa usando diverse bande di frequenza per ciascuno di questi segnali, ma per farlo occorrono modulatori e demodulatori,
e adottando protocolli di trasferimento "robusti"

Nel caso dei nostri treni il costo delle centrali ma sopratutto dei decoder e dei moduli di feedback aumenterebbe notevolmente.
Occorrerebbe inoltre rivedere tutti i protocolli di comunicazione: il traffico dati sul binario e' fortemente disturbato rispetto
a quello che hai sul bus di feedback dedicato!

Per quanto ne so io i protocolli dei bus di retroazione (ne conosco in dettaglio alcuni ma non tutti) non sono per niente "robusti".
Funzionano tutti sul concetto "spara e spera", ossia spara il messaggio sul bus e spera che il destinatario lo abbia ricevuto !
Non e' un caso che i comandi alle loco vengano ripetuti continuamente e che anche i comandi ai deviatoi vengano trasmessi
dalle 3 alle 5 volte!

L'altra alternativa che hai (ma non con i software standard) e' quella di utilizzare moduli e bus di feedback di tipo industriale,
non connesso alla centrale DCC ma direttamente al PC (tanto le reazioni sono pilotate dal PC e non dalla centrale DCC).

Ecco perche' gia' prima dicevo che nel plastico "grandicello" ho utilizzato un software in grado di capire e recuperare i problemi.

Lamps

E' un problema di affidabilità, di comunicazione e di correzione di errore ... da centralina a apparati il segnale è monodirezionale a bassissima impedenza (visto che è sovraimpresso all'alimentazione) e sicuramente è in grado di giungere fin dove vi è contatto elettrico con disturbi minimi riassorbiti dalla ridondanza delle informazioni.

Il ritorno non può essere così: si tratta di segnali a bassa energia emessi da più di un apparato (potenzialmente tutte le loco, le carrozze con illuminazione, i controller di scambi e segnali, ecc. ecc.) e, molte volte, anche in contemporanea ... ogni segnale dovrebbe 'lottare' contro quello sovrappresso all'alimentazione ma anche con tutti gli altri ... si creerebbe una situazione tipica e simile a quella delle reti ethernet dove devono essere gestite le collisioni e le ritrasmissioni.

Il segnale DCC dalla centralina ai decoder, oltre ad essere potente, non deve lottare contro nessuno: è semplicemente una trasmissione in un solo senso ... come qualcuno che parla con un megafono ad un comizio: chi può ascolta e agisce se l'ordine è rivolto a lui ma non sono previste repliche.

Questo per dare un'idea di perchè i produttori non hanno mai proposto, finora, questa strada ... probabilmente potrà anche essere realizzabile in futuro (quanto lontano non so) ma sicuramente sarà qualcosa di completamente diverso dal DCC (avendo questa tecnologia raggiunto il massimo delle sue potenzialità in termini di 'comunicazione' tramite le rotaie) e renderà obsoleti decoder e centraline attuali (purtroppo aspetto economico, tempo per la comprensione e l'apprendimento, tempo per l'adeguamento saranno sempre grossi freni all'introduzione di nuove tecnologie).

Zimo l'ha già fatto parecchi anni fa.

Il tuo è indubbiamente un lavoro molto interessante, specie se c'è anche la passione, come mi sembra di recepire.
Il problema della compressione, come certamente saprai, esiste anche nel reparto audio, oggi il Dolby Digital e il DTS, specie per il 5.1 e 7.1 si avvalgono di questa tecnologia (escluso il Master Audio che permette la codifica trasparente/lossless senza perdita di informazioni).

E' vero che audio e video hanno i numeri per potersi permettere questo a prezzi umani ma è anche vero che oggi si lavora molto in sinergia e nel caso del modellismo ferroviario, le varie aziende potrebbero avvalersi di componenti usati per altri settori e con poche modifiche ottenere il risultato voluto a prezzi accettabili.



Grazie, con questa spiegazione ho capito in modo chiaro il problema.


Appunto!

E' vero ... anche io speravo nel Railcom ... ma, da quel che so, mi pare che la soluzione abbia dimostrato tutti i suoi limiti ... altrimenti avrebbe avuto sviluppo, consenso e popolarità.

Qualcuno ha aggiornamenti ? Da quel che ho potuto vedere in rete le cose sono ferme da molto tempo ... chi dice per problemi tecnici chi per problemi di royalties/licenze ed altri accordi commerciali.

Ma, infatti, a parte i problemi prettamente tecnici, ci sono problemi di royalties e licenze.
Tecnicamente il problema della presenza ruota e rotaia è già superato = WiFi, idem per le dimensioni dei componenti = vedi palmari e telefonini, resta da risolvere il problema del motore nelle immediate vicinanze = con telaio metallico e dimensioni della loco adeguate è facile fare un contenitore schermato. Sarebbe anche ora di usare dei motori trifasi, pero obbliga tutti ad al digitale (esempio Sinus di Maerklin).
Risolti tutti questi problemi sui veicoli, e sull'hardware della logica di comando e controllo, resta il problema software: ecco qui viene il bello, definito le linee guida generali, che dipendono solo dall'ambientazione ferroviaria che si intende riprodurre, ci vogliono le conoscenze e le capacità necessarie. I sistemi fin qui proposti dai vari produttori, non vanno tanto oltre al comando sequenziale dei treni, con la predisposizione di qualche itinerario. Per riprodurre la vera ferrovia bisogna tenere conto di tutte le situazioni che non siano la successione sequenziale, come da orario, dei treni. E su un plastico è ben più difficile e complicato che nella ferrovia vera. Al vero, in ben determinate situazioni è previsto che intervenga l'uomo, che finita la sua opera, risponda al sistema "ho finito" (es: aggancio e sgancio veicoli; sorpasso di un treno in ritardo). Installare gli sgancia vagoni è un compromesso, non tanto fedele.
Infine, c'è anche un problema pratico, ogni volta che hai 1/2 h di tempo per far girare i treni sul plastico, spendi 20 minuti per accendere e rimettere in fase il sistema, allo stesso modo quando si vuole smettere, è meglio fermare in fase.
Personalmente non credo che nessuno, a livello industriale, si prenda la briga di sviluppare sistemi simili, non ci sono i numeri, quindi non ci può essere una proposta commerciale economicamente valida. Di fatto le apparecchiature a livello industriale esistono da tempo, caso mai vanno ridotte di dimensioni (nell'industria ci sono anche aspetti normativi diversi da soddisfare), però ritorniamo all'inizio del mio post.

Puri motivi commerciali....nulla più esu e lenz hanno sviluppato il railcomplus compatibile con il la prima versione del railcom ma blindato.

Ok ... ma queste, se non erro, sono cose di almeno un paio di anni fa (se non di più ... cfr: http://www.esu.eu/en/support/white-papers/railcomplusr/) ... che fine hanno fatto le soluzioni concrete visto che non se ne parla? Mi sono perso qualche cosa ?

Oltretutto se i benefit saranno (dal link di sopra):

ai fini dell'automazione di cui si parlava risolve poco ... come diceva Lamps (...applausi...) è un protocollo 'spara e spera' al momento limitato allo scambio di informazioni non critiche e che possono essere ripetute più volte fino al successo delle trasmissione. Cosa succederebbe se il decoder dovesse comunicare l'approssimarsi di una tratta occupata e ha meno di un secondo per farlo ?

Le informazioni non critiche effettivamente sono le uniche che veramente servono ... uno su tutte la lettura in corsa delle cv che su un plastico diventa utilissimo li quando si vanno a tarare i decoder per accessori. Per l'automazione oltre all'occupazione può essere sufficiente poter identificare l'indirizzo della macchina in fase di startup e di eventuale recovery se la macchina in questione non segue l'itinerario predefinito.