Předchozí tři články byly úvodem na vysvětlení, aby čtenář pochopil a měl představu o předpokladech, z kterých jsem vycházel. Denet je sběrnice postavená na železe Loconetu a využívá DCC protokol. Dlouho jsem si lámal hlavu, jak to udělat a nakonec mne napadla velmi jednoduchá myšlenka a to, proč nepoužít přímo DCC protokol i pro Denet. Tím okamžikem se všechno strašně zjednodušilo a výsledek mne mile překvapil. Bylo třeba vyřešit spoustu drobných, ale důležitých problémů.
Denet systém nemá žádnou ústřednu, jen převodník z signálového DCC na silový DCC. Pro komunikaci využívá jak DCC, tak i Denet. Zpětná vazba může jit, už z principu DCC, jen přes Denet, ale to bohatě postačí. Každé zařízení (periferie) má přístup od DCC, které zabezpečuje i napájení a na Denet, který umožňuje i zpětnou vazbu. Je možné Denet periferie řídit jak z ruky nebo panelu, tak i přes počítač, pro který je vytvořen převodník Denet/RS232.
Sériová komunikace má jeden velký problém a to je synchronizace a identifikace prvního bajtu. U Loconetu se to řeší pomocí OPCODE a u DCC pomocí preambule. Já to řeším devítibitovým režimem a tzv. multiprocesorovým režimem pomocí SM2, který umí asi jen Atmel rodiny x51. Režim SM2 spočívá v tom, že přerušení od příjmu se vyvolá, jen když je RB8 v logické jedna. Pokud je RB8 v logické nule, přerušení se nevyvolá. Tím zredukuji počet vysílaných bajtů na tři, čtyři nebo pět podle režimu adresace a stupně řízení rychlosti u Huga a tři nebo čtyři u příslušenství. Rychlost sběrnice je stejná jako u Loconetu, z důvodu zaměnitelnosti ovladačů mezi Denetem a Loconetem.
Další velký problém je řízení přístupu na sběrnici, kdy je potřeba zamezit společnému vysílání několika zařízení. Loconet to řeší pomocí CD backoff a náhodné prioritě v rozmezí od 1560µS do 1860µS. V tom je započítán i CD. Já jsem na to šel úplně opačně. Zjistil jsem si nejkratší možný čas na zhození TxD a nutný počet instrukcí na jeho vykonání. Jsou to přesně 4 strojové cykly. Opuštění časové smyčky a zápis na „sbuf“. Zhozením TxD, start bitem, se zablokují ostatní periferie a nemohou vysílat. Tím mi vyšel čas 6 strojových cyklů na velmi bezpečné rozdělení časových úseků pro jednotlivé periférie. Protože periferií může být až 511, je priorita přístupu rozdělená od 4µS do 1600µS. To je největší možný čas přístupu u periferie s adresou 511. Čas přes 1.6mS se zdá být velký, ale to klame, protože nejvíc se budou používat (v zájmu provozovatele) nižší adresy a ty jsou velmi rychlé. Stavím si malé domácí kolejiště a zatím tam mám 38 periferií.
Další problém je zpětná vazba, protože DCC ji vůbec nepodporuje. Já jsem si to vyřešil tak že při jakékoli změně na svých vstupech, pošle periferie paket příslušenství podle normy DCC „100f ffff“
nebo „1011 ffff“
a nastaví bity „f“ do hodnot podle stavu na svých vstupech.To znamená určitou automatizaci detekce obsazení, která není na obsluze vůbec závislá.Vyhodnocení detekce obsazení, návěstidla nebo vyhybky je součástí protokolu a zároveň je potvrzeno vykonání příkazu, zpětným paketem o změně stavu. Není kontrolován skutečný stav, pouze stav ovládacího pinu. Rychlost komunikace je taky velmi rychlá, při trojbajtovém režimu je to 33 bitů (9+1+1 x 3) 16548/33 = 501 je teoretická rychlost bajtů za vteřinu. Loconet má teoretickou rychlost 416 bajtů za vteřinu. To je ovšem velmi nepřesné, protože priority přístupu na neřízenou sběrnici velmi snižují přenosovou rychlost u obou systémů.
Ovládání lokomotiv přes Hugy je samostatná kapitola z důvodu spojení adresy Huga a loko. Řeším to spojením obou do logického celku, kdy loko má stejnou adresu jako Hugo. Tím je zablokováno křížové ovládání lokomotiv. Tady byly problémy tři.
První je počet přístupů na Denet, aby loko dostávala stále aktuální údaje. Ideální stav, který jsem určil empiricky je desetkrát za vteřinu. Teda pouze desetkrát za vteřinu může Hugo vysílat, jinak dochází k přehuštění a ztrátám dat. Při počtu 50 přístupů se to seká na 12 Hugech a 20 příslušenství. Při 80 x vteřině je to 12 Hugů samostatně. Odhaduji teda, že 10x /sek. stačí na asi 50 různých ovladačů současně. Počet napájených ovladačů je kolem 25, protože RJ12 má mezní proud okolo 500mA a zařízení berou okolo 20mA. Řešením je použít více větví na rozvětvení Denetu, ovšem první rozdělení sběrnice musí být velmi kvalitní. Tento problém má i Loconet, tam se to zas řeší větším počtem centrál.
Druhy je určitá inteligence Huga, kdy se musí nahradit funkce centrály a po každé změně se příkaz musí poslat několikrát, aby bylo zajištěno, že příkaz dojde a bude vykonán. Je to řešeno proměnnou časovou hodnotou, která se počítá od každé změny. Tato hodnota je po změně 500mS a logaritmicky narůstá v řade 1, 2, 4, 8, 16, 32, 64, 128 sekund, kdy se potom ovladač vypne a vůbec nevysílá. Zároveň přejde do úsporného módu, kde odebírá jen 2mA. Vzbudit se může jen vytáhnutím a znovu zastrčením RJ12. Teda tvrdým resetem. Čas nad čtyři minuty mi připadá dostatečný na bezproblémové ježdění. Pouze demo provoz, při kterém se jezdí dookola do němoty, tento, režim neumožňuje.
Třetí je adresace , kde adresa u loko nad 127, by mi dělala obrovské problémy, při mém způsobu určení priority. Proto používám jen adresy do 1 do 60 a pro příslušenství adresy nad 61, aby loko měly velkou prioritu přístupu na sběrnici.
Realizace je na Pietrikovém webu. To je starší verze určená jen pro příslušenství.
Na Railnet to dávám proto, že mi chybí zpětná vazba od Vás čtenářů a to mi Pietrikov web neumožňuje.
ahojte, kde bych nasel tu praktickou realizaci, nebo nejake zdrojove kody lokonetu pro jednocipy?
ahoj, jsi trochu mimo, loconet neni tak jednoduchy. *** system denet je varianta na zeleze loconetu. *** pokud mas zaujem o studium, napis mi osobne. *** ahojz