DCC na navestidla

[zdeno]

pro navestidla se blbe pouzivaji klasika DCC pakety, protoze je tam to nestastne parove rizeni. Kdo to vymyslel, povesil bych ho za gule do pruvanu.
---
Tahle norma je idealni pro navestidla, bude nebo ma ji nekdo aplikovanou ??
Pocita nekdo s EXTENDED DCC pakety, tim myslim normu
Extended Accessory Decoder Control Packet Format
The Extended Accessory Decoder Control Packet is included for the purpose of transmitting aspect control to signal
decoders or data bytes to more complex accessory decoders. Each signal head can display one aspect at a time.
{preamble} 0 10AAAAAA 0 0AAA0AA1 0 000XXXXX 0 EEEEEEEE 1
XXXXX is for a single head. A value of 00000 for XXXXX indicates the absolute stop aspect. All other aspects
represented by the values for XXXXX are determined by the signaling system used and the prototype being
modeled.

[fulda]

pro navestidla se blbe pouzivaji klasika DCC pakety, protoze je tam to nestastne parove rizeni. Kdo to vymyslel, povesil bych ho za gule do pruvanu.

Tady hlasitě souhlasím.
A ještě bych vedle něj pověsil toho, kdo zavedl počítání od jedničky a ne od nuly.

Tahle norma je idealni pro navestidla, bude nebo ma ji nekdo aplikovanou ??
Pocita nekdo s EXTENDED DCC pakety, tim myslim normu

Trochu si myslím, že pro ní neexistuje uživatelské rozhraní, takže to nebude žádná sláva.

[zdeno]

tohle je jedine forum, kde se doporucuje DCC na rizeni prislusenstvi. Brnaci nebo eNkari pouzivaji neco jine (MTTBUS).
---
Cetl jsem cele vlakno Ovladani semaforu v technologii dcc + vhodny dekoder a myslim, ze by jsme meli tuto normu EXTENDED oprasit a zkusit to znovu

[fulda]

Ono spíš já a Houmr používáme DCC, všichni ostatní používají MTBUS
Je trochu problém, že si třeba extended paket mohu generovat, to je celkem jednoduché, udělám si na něj i dekodér, to je ještě jednodušší, ale pokud k tomu nebude podpora od někoho dalšího (alespoň v software od freiwalda), tak to stejně nikdo nebude schopnej a ochotnej použít.

[zdeno]

taky si myslim, ze to je scifi
---
Jinak jsem se dival na Freiwalda a on i pro Loconet pouziva parove rizeni, tohle nechapu, proc neni mozne si vybrat, ci chcem nebo nechcem parove rizeni.
Premyslel jsem nad tim a vyslo mi, ze to muzu obkecat. Teda poslem vlakovou cestu a tam si muzu nadefinovat cokoliv.
---
Mozna i ten tvuj enkoder by bylo lepsi nadefinovat na volbu vlakove cesty. Dat tam normalni klavesnici 4x4, udelat planek vlakovych cest a jen vytukas cislo a cesta se navoli komplet i s navestidly. Problem by byl s EEPROM, musel by si dat vetsi procesor. Tady by vubec nevadilo, ze by si nevedel stav vyhybek, proste by se volila vlakova cesta vzdy znova.

[radeksindy]

Každý výrobce to chtěl řešit jinak s ohledem na svoje řešení, části to bylo jedno, protože DCC pro příslušenství nevyužívají. A tak se to v normě objevilo pozdě. S normálními pakety DCC pro příslušenství si lze také poradit a koncového zákazníka vůbec nezajímá, jestli pakety mají nebo nemají párové řízení. Výrobce zajímá jak koncovému uživateli usnadnit využití digitálních komponent pro řízení jeho kolejiště. Bez solidní podpory ze strany SW nebude mít paket použití, jenomže dobré SW si dokáže poradit i se současným stavem. Tak proč to měnit?

[zdeno]

vsak ja vim a taky to uspesne obkecavam, ale je to jako drbani se levou nohou za pravym uchem.
Proto asi vzniknul MTTBUS a jine systemy, aby jsme se mohli drbat jinak a jinde
---
Ono DCC zpetnou vazbu ma a to jsou nase oci, takze ovladani pomoci DCC neni az tak spatne. Potom ale treba pro ty nase oci udelat berlicky, aby videly i tam, kde to neni jinak mozne.

[cernos]

Potom ale treba pro ty nase oci udelat berlicky, aby videly i tam, kde to neni jinak mozne.

a tady s úspěchem používám S88

[zdeno]

Potom ale treba pro ty nase oci udelat berlicky, aby videly i tam, kde to neni jinak mozne.

a tady s úspěchem používám S88

ani nevis, jak si mi nahral na smec.
Pouzivat DCC a S88 je zvracenost, je to sice funkcni, ale proti Loconetu je to krokem zpet. Stratil jsi nejvetsi vyhodu a to jsou ty dva nestastne draty pro data i napajeni. Musis extra tahat dalsi sbernici. Nebylo by lepsi tahat jednu obojsmernou sbernici a k tomu pridat silovy rozvod ??
---
Prave pro toto zacinam do toho tak vrtat a rypat.
Doufam, ze to nevezmes osobne, muj nazor je v tomto naprosto konzistentni a nemam zajem nikoho urazet a provokovat.
Tato debata je jen o DCC a jeho pouziti, bez zpetne vazby.

[fulda]

Ono DCC zpetnou vazbu ma a to jsou nase oci, takze ovladani pomoci DCC neni az tak spatne. Potom ale treba pro ty nase oci udelat berlicky, aby videly i tam, kde to neni jinak mozne.

Pokud neřekneš, že se chci hádat, tak napíšu, že jí normálně má - je definovaná v RP-9.3.2, ale nikdo jí nepoužívá, protože je tak komplikovaná, že to snad ani nejde.

Jinak pokud by jsi to chtěl řešit nějak konstruktivně, tak by asi byl dobrej začátek naroubovat extended pakety do JMRI, kterej hodně lidí považuje za studnici znalostí a pokud tam ta podpora bude, tak si myslím, že se jí pokusí opsat/zreplikovat.
EDIT: problém je, že extended paket NENÍ definovanej pro většinu počítačovejch rozhraní

[zdeno]

Jinak pokud by jsi to chtěl řešit nějak konstruktivně, tak by asi byl dobrej začátek naroubovat extended pakety do JMRI, kterej hodně lidí považuje za studnici znalostí a pokud tam ta podpora bude, tak si myslím, že se jí pokusí opsat/zreplikovat.
EDIT: problém je, že extended paket NENÍ definovanej pro většinu počítačovejch rozhraní

Kurnik, ted nad tim premejslim a ono to ma az tri hacky
Prvni je, samotne programy to musi podporovat,, teda JMRI nebo RailCo.
Druhy je, musi to podporovat dany protokol.
treti je, centrala to musi umet prelozit do DCC.
1/ tohle by slo, treba Sindy by to napisal v Jave (Python) pro JMRI, taky Freiwald by to mohl zabudovat, kdyz by mu nekdo nemecky napisal
2/ tohle je prusvih, nepoznam paket Loconetu, ktrym by se to dalo poslat. Snad jen rozdelenim adres do skupin.
3/ žádná centrala co poznam, vcetne te moji, to nepodporuje. Ja bych to mohl zabudovat, to neni problem.
+
4/ neexistuji periferie, ktere to podporuji, takze jedine madehome.
---
Takze to bude asi jako ta zpetna vazba na DCC, ma to normu, ale je to nepouzitelne.

[radeksindy]

RP 9.3.2. je nepoužívaná z jiných důvodů. Zaprvé to ještě není norma, ale jen návrh, a k samotnému zanormování možná ani nedojde, protože mezitím největší hráči už několik let komerčně prodávají svoje systémy. První rozkol nastal při vzniku prvního návrhu, kdy například Digitrax chtěl systém, který bude zpětně plně kompatibilní a nebude vyžadovat změnu v centrále. Transponding od Digitraxu totiž funguje obdobně jako ten v normě, ale nevyžaduje protor na konci bitů pro modulování zpětné vazby. Sice to vede k omezení na délky přenosu zprávy, ale u Digitraxu se to nepřenáší do centrály, ale k nejbližší zařízení pro zpětnou vazbu a pak po LocoNetu kam chci. Zbytek výrobců nic takového nemá a tak nutně potřebovali zpracování zpětné vazby v centrále. Jenomže nastávaly další rozdíly, např. výrobci se svojí proprietární zpětnovazebnou sběrnicí chtěli jen info z lokomotivy, tak ostatní předpokládali plnohodnotnější oboustrannou komunikaci. Takže RP 9.3.2. je v tuto chvílí více jak 7 let starý polomrtvý návrh, jehož osud je nejasný.

Ukazuje se, že měli pravdu ti, kteří nedoporučovali používat DCC pro příslušenství, ale mít plně oboustrannou komunikaci mezi nemobilními zařízeními (jako je LocoNet). Dnešní diskuze a první návrhy nových norem počítají se sběrnicemi průmyslového typu (asi vyhraje CAN), které jsou hodně odolné na rušení, ale umožňují vložit opakovač a gateway, takže není problém s rozšiřováním. Protože se v roce 2010 k tomuto procesu připojila i NMRA, tak rozšíření stavajícího DCC, případně ke standardizaci zpětné vazby už asi nedojde.

[radeksindy]

1/ tohle by slo, treba Sindy by to napisal v Jave (Python) pro JMRI,

Pokud bude podpora za strany HW, tak se to v JMRI dříve nebo později objeví.

tohle je prusvih, nepoznam paket Loconetu, ktrym by se to dalo poslat.

LocoNet v případě potřeby umožňuje definci vlastního paketu, takže pokud bude vůle, cesta se najde. Ale nebude vůle, protoře není jediný důvod to dělat, viz naše předchozí diskuze o smysluplnosti některých akcí. Není jediný důvod proč posílat paket po LocNetu, překládatho do DCC a pak čekat třeba po S88 reakci To je prostě hovadina. Z toho plyne ...

žádná centrala co poznam, vcetne te moji, to nepodporuje.

... že žádná centrála to nebude podporovat.


Přiznám se že této větě vůbec nerozumím:
.... problém je, že extended paket NENÍ definovanej pro většinu počítačovejch rozhraní......
Může mi někdo vysvětlit, co tím myslíte? Jak souvisí počítačové rozhraní s paketem DCC?

[zdeno]

Přiznám se že této větě vůbec nerozumím:
.... problém je, že extended paket NENÍ definovanej pro většinu počítačovejch rozhraní......
Může mi někdo vysvětlit, co tím myslíte? Jak souvisí počítačové rozhraní s paketem DCC?

---
asi mysli programy
---
Mne se jedna o to, ze ten extended paket je definovany, ale nema zadnou podporu od kohokoliv. Proto jsem byl tak trosku zvedavy, ci by byl k necemu dobry nebo ne. Takovych slepych ulicek poznam z vlastni zkusenosti spoustu, treba muj Denet. Ale nedalo mi to a byl jsem zvedavy na realitu.

[fulda]

Přiznám se že této větě vůbec nerozumím:
.... problém je, že extended paket NENÍ definovanej pro většinu počítačovejch rozhraní......
Může mi někdo vysvětlit, co tím myslíte? Jak souvisí počítačové rozhraní s paketem DCC?

asi mysli programy
---
Mne se jedna o to, ze ten extended paket je definovany, ale nema zadnou podporu od kohokoliv. Proto jsem byl tak trosku zvedavy, ci by byl k necemu dobry nebo ne. Takovych slepych ulicek poznam z vlastni zkusenosti spoustu, treba muj Denet. Ale nedalo mi to a byl jsem zvedavy na realitu.

Myslel jsem to co napsal Zdeno - extended paket je definovanej, ale pokud ho chceš vytvořit, tak klony XpressNetu to nedokážou, klony Loconetu a CAN to dokážou jedině jako paket, kterej vytvoříš uživatelsky a pošleš do DCC s tím, že netušej co to je za paket.
Asi trochu rozproudím diskuzi u Lenze, třeba se někdo chytne.