radeksindy píše:Ano, nemá rozlišovat co v něm je. Ale už píšu asi podesáté, že firma Uhlenbrock porušila jak LocoNet normu, tak DCC normu. Tu první tím, že odfiltrovává paketu pro ovládání funkcí F9 a vyšší a tu druhou tím, že tyto data k vyšším funkcím ukládá v centrále a zachází s nimi jako s obnovovanými daty.
1) Podotykam, ze debata od zacatku byla o paketu OPC_IMM, nikoliv o paketu, ktery je mimo ramec LocoNetu PE, takze je zbytecne opakovat neco na co jsem se ani neptal a bylo jiz zmineno drive v jinych vlaknech.
2) Pokud tedy nema rozlisovat co v nem je a je tam ten "tunel", tak celkem logicky tam nemuze dochazet k odfiltrovani paketu. Ten "tunel" je tam od toho, aby nemohlo dojit k naruseni prenosu paketu, to je hlavni funkce "tunelu". Jinak bych se pokusil celou tvou konverzaci shrnout do tohoto zaveru:
Opravdu veris svemu popisu, ze dotycna firma nejdrive podle normy LocoNetu PE implementovala OPC_IMM paket (tva citace: Paket, který umožňuje posílat F9 a vyšší funkce po LocoNetu, byl součástí normy LocoNetu od první verze a umí je zpracovat všechny centrály s LocoNetem.) a pak z nejakeho neznameho duvodu se rozhodla, ze tam implementuji (to znamena extra naklady a usili) novy paket mimo LocoNet PE normu a jeste navic tam zavedou filtr, ktery zamerne filtruje (u paketu OPC_IMM) pouze funkce F9 a vyssi, takze si krome extra nakladu a casu na vyvoj jeste "vyrobi" nekompatibilitu s nekterymi LocoNet ovladaci. Opravdu se domnivas, ze to tak je ?
radeksindy píše:Pokud měl dotaz znít, k čemu se obecně ještě paket kromě vyšších funkcí používá, tak je to třeba inicializace DCC systému.
Co tim myslis konkretne, opet by se hodil lepsi technicky popis.