| |
|
| Forum selezionato:
| Tecnica Digitale |
| Discussione: |
E' veramente utile?
|
|
Accessi: 17957
Interventi: 43 |
| Intervento di: ttales70 |
|
Invio Messaggio privato interno | Visita Home Page | Profilo | |
|
Del : 10/09/2001 Ore: 21:27:08
| Se effettivamente succede questo (durante un itinerario si perde delle commutazioni), io penso pero' debba imputarsi all'IB, perche' con la mia centrale anchessa autocostruita (collegata al PC) non succede mai. Potrebbe essere dovuto al multiprotocollo che gestisce la IB. Forse proprio perche' manda segnali DCC miscelati con Marklin. Il protocollo DCC prevede tra un pacchetto ed un'altro un determinato tempo prima del pacchetto successivo (di solito composto da tutti bit a 1) e forse la IB utilizza questo spazio per inviare segnali in modalità marklin quindi magari e questo il motivo. forse alternando un pacchetto ad un 'altro in rapida successione non fornisce un segnale a norma ai decoder DCC molto piu sofisticati nella decodifica dei pacchetti digitali (ma con molte funzioni in più rispetto a i marklin), in quanto vengono gestiti da microprocessori, mentre quelli marklin è una cosa meccanica che forse non risente di segnali anomali (mal formulati) l'integrato Motorola che decodifica dovrebbe essere più o meno composto da reti combinatori, porte ecc..... Questo difetto avviene anche se si setta la IB afunzionare solo con il protocollo DCC? o solo quando lavora con il doppio protocollo? Comunque la intellibox è un buon prodotto. Io avendo un vecchio pc ho optato a fare una centralina autocostruita che gestisce pero' solo protocollo DCC. Se avete moduli compatibili marklin, se puo' essere utile, posso dirvi che sono di facile riproduzione. Gia che ci sono qualcuno di voi ha documentazione sul protocollo marklin (no X50, cioe quello che si usa per comandare la IB tramite PC) vorrei dargli una studiata.
a presto
Alessandro
|
| Intervento di: Amministratore |
|
Invio Messaggio privato interno | Visita Home Page | Profilo | |
|
Del : 12/09/2001 Ore: 13:48:55
| L'intervento di Alessandro mi ha fatto ripiombare nel buio più assoluto e le mie poche idee sono ritornate allo stato confusionale.
Credo che a questo punto abbiamo assodato che il digitale e utile e quindi sposto la discussione su un nuovo argomento.
Saluti e grazie a tutti i partecipanti alla discussione.
Ho visto qualcosa sul sito www.modeltreno.it a proposito del documentazione sul protocollo marklin (no X50, cioe quello che si usa per comandare la IB tramite PC) ma quando ho aperta la pagina non me l'ha visualizzata forse per una temporaneo interruzione del server
webmaster di
www.fermodellismo.it
|
| Intervento di: Amministratore |
|
Invio Messaggio privato interno | Visita Home Page | Profilo | |
|
Del : 13/09/2001 Ore: 14:39:06
| Mi è arrivata questa email che pubblico di seguito che dovrebbe chiarire tutto quello che si è detto sui problemi dei decoder per scambi in formato DCC con la Intellibox
Mi premetto di scriverti al riguardo in quanto, essendo probabilmente colui
che ha lavorato di più allo sviluppo della IB, ritengo di avere voce in
capitolo.
Perdonami se non mi iscrivo al tuo/vostro forum ed invece preferisco
scriverti direttamente.
Dunque:
1)
noi (chi ha lavorato al progetto Intellibox) preferiamo usare la sigla "IB"
per Intellibox. "IBX" identifica invece una gruppo di discussione, presente
su Yahoo, dedicato appunto alla IB - IBX sta per "IB eXchange";
2)
se si usano decoder Arnold S4 con la IB, provando ad attivare un itinerario
(da PC oppure a mano, se già si dispone del "MEMO mode") avviene quanto segue:
- il decoder riceve dalla IB il comando di accensione di una sua uscita;
- a questo punto il decoder, per un tempo di circa 1 secondo, nel mentre
continua a tenere accesa l'uscita appena interessata dal comando,
(erroneamente) _NON_ decodifica alcun altro comando, inclusi eventuali
altri comandi a lui indirizzati. In particolare, non decodifica
comandi di spengimento, né comandi di accensione di una _ALTRA_ sua
uscita (cosa che farebbe implicitamente spengere l'uscita precedente-
mente attivata);
- dopo un certo tempo, di norma inferiore al "secondo" sopra citato, la IB
comanda il prossimo dispositivo elettromagnetico inserito nell'itinerario.
Orbene: se questo secondo dispositivo da commutare è collegato allo stesso
decoder S4 interessato dal comando precedente, stante quanto appena detto
il comando stesso non verrà eseguito.
Ergo: si "perde" un comando di commutazione.
E' chiaro poi che questo "problema" non è limitato ai soli itinerari: anche
comandi molto rapidi impartiti a mano tramite la IB o apparecchi ad essa
collegati e rivolti ad uno stesso decoder S4 incorrono nello stesso problema.
Cosa si può fare per ovviare a ciò? (A parte... beh, rinunciare ad
impiegare gli S4!)
Dato che il tempo di attivazione di una uscita dell'S4 non è un parametro
programmabile (almeno per quanto mi è dato sapere), non resta che aumentare
il tempo che intercorre, nella IB (MEMO mode) o nel PC (attivazione di un
itinerario da PC), tra due comandi per dispositivi elettromagnetici.
Nella IB - con riferimento ai soli itinerari - si può intervenire sulla SO
(Special Option - chi ha una IB dovrebbe sapere di cosa sto parlando) #450
alzandone il valore: da 10 a, per esempio, 20 (la SO #450 va interpretata
in unità da 50 ms circa ed indica appunto il tempo che intercorre tra due
successivi comandi di un itinerario - dunque il valore 20 indicherebbe
appunto 1 secondo).
Ovvio che questa modifica alla configurazione della IB nulla potrà al fine
di risolvere le "mancate commutazioni" nel caso di comandi impartiti a mano
a grande velocità: in questo caso deve essere l'utente a sforzarsi di non
impartire più di un comando al secondo (circa) ad un S4.
A nulla serve poi intervenire sul tempo minimo o massimo di commutazione
(altri parametri configurabili della IB). Infatti, per come vengono
comandati i decodificatori per dispositivi elettromagnetici DCC, modificare
questi tempi non sortirebbe l'effetto sperato.
E' però possibile che in futuro, con una nuova versione del software della
IB, introducendo un nuovo (e facoltativo) "stile" per quanto concerne il
come la IB invia comandi a questi decoder DCC, si riesca ad aggirare quel
che secondo me è una "pecca" dei decoder S4 - e, per quanto ne so, solo di
questi decoder (non, per capirci, dei Lenz, Digitrax, ecc...).
Spero di aver contribuito alla comprensione del "fenomeno".
Saluti,
Stefano
webmaster di
www.fermodellismo.it
|
| Intervento di: ttales70 |
|
Invio Messaggio privato interno | Visita Home Page | Profilo | |
|
Del : 13/09/2001 Ore: 14:58:07
| Bene, quindi siamo giunti alla conclusione che il problema non sono i decoder DCC, come pensavo, ma il solo decoder S4. Difatti da tempo sto lavorando su un nuovo software da inserire nel microprocessore che controlla il mio decoder DCC, che nel mentre attiva un'uscita continua a vedere se arrivano altri pacchetti a lui indirizzati. Si spera che tutti gli altri produttori quindi non facciano l'errore generato dal decoder S4 in questione.
a presto
Alessandro.
|
| Intervento di: gabriele |
|
Invio Messaggio privato interno | Visita Home Page | Profilo | |
|
Del : 25/09/2001 Ore: 12:52:16
| Possiedo un impianto digitale da circa 8 anni. Attualmente utilizzo il formato DCC.
Sono convinto che il vantaggio maggiore di un sistema digitale sia il comando e il funzionamento dei motori oltre che la possibilità di sonorizzare i modelli. Attulmente con la regolazione automatica del carico, la frequenza del motore a 22Khz e più (sino a 36 Khz) a la possibilità di adattare i singoli parametri del decoder al singolo modello la, dolcezza di funzionamento anche alle basse velocità (salvo problemi di contatto bordino/ruota ovvero ruota/prese di corrente)è ineguagliabile dai sistemi di alimentazione tradizionali.
Tuttavia alcuni problemi si pongono, ad esempio quello relativo alla gestione della tratta di binario avanti ad un semaforo disposto al rosso, argomento questo troppo spesso sorvolato dalle ditte costruttrici in quanto di non facile soluzione.
|
Fermodellismo IT
|
|
|
|
