Diskuzní fórum železničních modelářů

fulda píše:Já ho vidím za 18 Kč doporučená je 0,5€ (12 Kč).

Mas pravdu, v TME je levnejsi (pro mne 20Kc/ks pri 25+ kusech); ja koukl jen do GME a jen zbezne (ted vidim ze jen na objednavku 1000+ks, coz je nanic). Cena ale nebyla hlavni duvod proc jsem navrhoval moznost pouziti Arduina. Zbytek viz vyse.

adix píše:Z technického hlediska je určitě zajímavá možnost realizace úplné rychlostní návěstní sooustavy. Otázkou je použitelnost na modelovém kolejišti. Není asi mnoho kolejišť kde by se využila, myslím také že si málokterý modelář všímá dodržování modelové rychlosti. Druhou otázkou je zpúsob volby návěstí. Manuálně - pro každé návěstidlo x tlačítek podle počtu návěstí? Automaticky? Který software by to uměl využít? Na základě čeho? Je celkem jednoduché udělat závislost na poloze výhybek, a na obsazení následujícího úseku, případně na následujícím návěstidle, tady ovšem je nutná součinnost se softwarem ovládání kolejiště. Ale třeba se pletu a existují jiné možnosti.

JMRI toho umí hodně http://jmri.org/. Protože má definice návěstí pro ČSD/ČD/... http://jmri.org/help/en/html/tools/signaling/AspectSignaling.shtml (asi uprostřed strany) tak je může normálně používat.

Použití rychlostní návěstní soustavy je možné buď individuálním nastavením návěstidla z tabulky návěstidel, nebo v Panel Editoru https://sites.google.com/site/sidloweb/jmri/09-panel-editor, nebo Layout Editoru http://jmri.org/help/en/package/jmri/jmrit/display/LayoutEditor.shtml.

Možnost udělat S-COM dekodér s rychlostní návěstní soustavou beru jako případnou technologickou možnost. Kdo to chce opravdu použít, tak může vzít již existující DCC dekodéry UNI16ARD-NAV-EXT https://sites.google.com/site/sidloweb/elektrika/26-uni16ard-nav-ext nebo UNI16ARD-NAV-MX https://sites.google.com/site/sidloweb/elektrika/28-uni16ard-nav-mx, které nemají výstup na S-COM, ale přímo na LED diody.

adix píše:

sidlo píše:Cílová skupina uživatelů je velmi úzká.

Z technického hlediska je určitě zajímavá možnost realizace úplné rychlostní návěstní sooustavy. Otázkou je použitelnost na modelovém kolejišti. Není asi mnoho kolejišť kde by se využila, myslím také že si málokterý modelář všímá dodržování modelové rychlosti. Druhou otázkou je zpúsob volby návěstí. Manuálně - pro každé návěstidlo x tlačítek podle počtu návěstí? Automaticky? Který software by to uměl využít? Na základě čeho? Je celkem jednoduché udělat závislost na poloze výhybek, a na obsazení následujícího úseku, případně na následujícím návěstidle, tady ovšem je nutná součinnost se softwarem ovládání kolejiště. Ale třeba se pletu a existují jiné možnosti.

Pro toho, kdo z nějakého důvodu nechce DCC a comp, je tady taky možnost:
viewtopic.php?f=7&t=11943
O těch rozšířených návěstních signálech jsem začal uvažovat vlastně kvůli tomu, že jsem si s těmi virtuálními návěstmi uvědomil, jak jsou ty možnosti chudé a že by se dalo vyblbnout daleko více. Na kolejišti by mě to asi vůbec nenapadlo, protože je vidět tak desetina návěstidel, ale na tom panelu to je znát.
Stále přemýšlím, zda PIC nebo Arduino. U picu by byla realizace taky celkem jednoduchá. SMD pic připájet na takový ten univerzál DPS (SMD/TH). K tomu dobastlit stabilizátor a pár rezistorů a je to. Takže fakt dilema.
Zkuste o tom taky popřemýšlet

Tak jsem udělal odhad velikosti RAM a PGM a je jasné že se bude muset použít větší PIC, konkrétně 16F1825 (cenově u TME 31Kč bez DPH v kusovém množství). Takže babo raď

Ondřej píše:Tak jsem udělal odhad velikosti RAM a PGM a je jasné že se bude muset použít větší PIC, konkrétně 16F1825 (cenově u TME 31Kč bez DPH v kusovém množství). Takže babo raď

Pokud ti mohu poradit, podívej se na řadu PIC16F153xx. Je neuvěřitelně nacpaná periferiema za opravdu malé ceny. Pro tebe asi 14 pinový PIC16F323 za dvacku.

---
Edit:
Správně PIC16F15323 jsem myslel

Chybička se vloudí .... Předpokládám, žes myslel PIC16F15323. https://www.microchip.com/wwwproducts/en/PIC16F15323
Celý rodokmen je pak tady: http://ww1.microchip.com/downloads/en/D ... 01835A.pdf

Nechápu, proč se handrkujete o 10 Kč, když dáte za mašinku 5000 Kč. Rozhodující je, jaký MK mi bude vyhovovat a né cena.

tondakladno píše:Nechápu, proč se handrkujete o 10 Kč, když dáte za mašinku 5000 Kč. Rozhodující je, jaký MK mi bude vyhovovat a né cena.

Na to by ti asi nejlépe odpověděli ti, kterým činí nepřekonatelný problém mi poslat pohlednici, aby si mohli stáhnout některý z programů z mé stránky.

fulda píše:

tondakladno píše:Nechápu, proč se handrkujete o 10 Kč, když dáte za mašinku 5000 Kč. Rozhodující je, jaký MK mi bude vyhovovat a né cena.

Na to by ti asi nejlépe odpověděli ti, kterým činí nepřekonatelný problém mi poslat pohlednici, aby si mohli stáhnout některý z programů z mé stránky.

OT: Nekteri nemaji problem s pohlednici, ale s uzavrenosti Jo, je to softwarovy fanatismus ale je muj

Tak po důkladném uvážení jsem se rozhodl, že to napíšu ve wired a každý ať si to uploaduje do čeho bude chtít. Odladěné to bude na Arduino Pro Mini. Kód bude opensource.

Ještě mě napadly dvě věci:
1. Udělat do programu konverzní tabulku, která bude defaultně inicializovaná linárně 1:1 (podle jmri definice) a každý by si mohl předefinovat, pokud bude chtít, jaký scom kód odpovídá jaké návěsti. Bude to v kódu na jednom místě a tak přehledné.
2.Udělat u MCU tři jumpery (propojky....), kterými by se selektovala návěstní soustava podle JMRI setů.
Jaký je váš názor

Keď už sme pri tom, viete o niekom, kto by vyrábal použiteľné návestidlá s rýchlostnými pruhmi?

Spatna velikost )

belgarat píše:Spatna velikost )

I v H0 jsou pruhy tvořené 0402 LED. Do tohoto návěstidla jsem pájel zelené a ty jsou bohužel hodně citlivé na teplo, takže jsem jich spotřebovat asi 2x tolik. Páji se te velmi špatně.

Tak jsem se pustil do programování a hned jsem narazil. Definice protokolu s-com, to je tedy něco.
Nechme stranou, že doba Tb je označena jako perioda, ale velký problém je definice doby mezi pakety. Podle obtázku je min. 3xTb. To je ovšem naprostý nesmysl, protože pokud bych vysílal hodnotu 127 (binárně 1111111), tak nedokážu rozlišit mezipaketovou mezeru od datové oblasti a budu se synchronizovat úplně nesmyslně. V textu sice doporučují mít mezipaketovou mezeru min. 200ms, ale to je také špatně. Pokud bych vysílal nejdelším povoleným časem Tb=30ms, tak je délka možného výskytu nepřetržitých jedniček rovna osmi (sedum bitů dat a před tím jedničkový startbit). Pro detekci musím dát o jeden bit více, takže 9*30ms=270ms. Druhý problém tkví v tom, že přijímač neví, dokud nepřečte první sync bit, jakou hodnotu Tb bude mít vysílač. Jsou dvě možnosti. Jednou je chvíli sledovat signál a zjistit nejkratší blok, z toho vypočíst minimální mezipaketovou mezeru (může být 36-270ms) a podle toho se synchronizovat. Problém nastane v případě, že vysílač vyšle jen pár paketů při změně návěsti, to se nemusí povést odsledovat délku Tb a ještě přijmout dva stejné pakety. Druhá možnost je říct, že minimální mezera je 270ms při jakékoli délce Tb. To ale může narazit na to, že někdo vysílá podle popsané definice.
Asi nezbyde jiná možnost, než vyzkoušet parametry změřit na dekodéru s kódem co je k dispozici na netu.

Odtud plyne moje prosba, pokud jste někdo programoval vysílání, jakým způsobem