GPI-knak mi használsz és miért pont azt? kimenet (jelzők, váltók) és bemenetre is érdekelne. Én a ledeket PCA 9685-tel tervezem meghajtani. Azért is kérdezgetem, mert épp azon gondolkozom, hogy érdemes-e egyáltalán jelződekódert építenem arduinobol, mert végül is egy 4 jelzős dekóder kb 17 ezer forint, szóval jelzőnként mondjuk 4 ezer talán. Ok, olcsóbb arduinóval, csak nem tudom, megéri-e.
Azt jól értem, hogy az összes vezérlő cucc az valami arduino? Tehát pl a jelző vezérlő 1-3?
I2C busznál mekkora távolságok vannak az eszközök között, és okozott-e a távolság problémát? Állítólag I2C érzékeny a távolságra, bár lehet, hogy freki csökkentéssel megoldható, nem tudom.
Az xpressnet handlertől a master közötti odairányú kapcsolat miért kell, miért nem megy minden át a Z21-en és úgy a DCC-n és aztán a masterhez?
Lehet, hogy még lesz kérdésem. Illetve élőben meg lehet nézni? :-) Tapasztalatokat gyűjtök...
Nagyjából így néz ki most az asztal. Minden saját pcb-vel rendelkezik, saját tervezésű az összes komponens. Kb másfél év munkája volt ezt kidolgozni. A tapasztalatokról, megoldásokról kb. lassan könyvet tudnék írni. Gondolkoztam már, hogy csinálok róla egy videó sorozatot, de még nem volt rá időm. Az Architectúra jelenleg ez:
Az alap elképzelés az volt, hogy MÁV szabvány szerint lehessen jelzőket/váltókat állítani, úgy hogy kapcsolópult ugyan azt mutassa mint a z21 app. Mindent mindenhonnan lehessen megbízhatóan állítani. Idővel sikerült 4 fajta automatizálást kiépíteni. 1- minden manuális, de jelzők a váltóktól függően szabvány szerint működnek. 2- jelzők automatikusan állnak, felhasználó irányítja a vonatokat. A foglaltság érzékelők tudják hol vannak a vonatok, pár kör után 40es, majd megállj jelzést ad, váltókat átállítja és szabad jelzést ad egy másik vonatnak. 3- Az előző fordítottja igazából. A mozdonyokat a program irányítja attól függően milyen jelzést állítunk be. Fokozatosan lassít az állomáson, minden jelzőt figyelembe vesz. Váltókat is a program állítja. 4- teljesen automata üzem. Mindent a program csinál, mi csak hátra dőlünk. :)
Alapból startos z21-ről megy az egész. DCC-t arra használok, hogy fényjelző/váltó kezeléshez a változásokat onnan szedem. A mozdony vezérlést és a visszajelzést arról hogy mit csináltam, azt Xpressneten intézem. Igazából a kapcsolópult kompatibilis a z21-appal is így. Oda vissza minden megjelenik mindenhol.
A Peti által linkelt oldalon lévő eszközdekóder programja és áramköre Lenz-alapú. Sok dekóder egyébként mindkétféle parancsot tudja értelmezni (pl. a Digitools).
>nekem az xpressnet de amennyit látok ebből a DCC-ből egy elég tákolmánynak tűnik
Azt azért ne felejtsük el, hogy mikor alkották ezt meg, milyen hardver állt akkor rendelkezésre, és hogy az előd parancsvezérlő rendszerekhez képest bőven űrtechnika volt. Amire ma használjuk, az százszor több, mint amire anno gondoltak, és tulajdonképpen még mindig működik. A Loconet amúgy sok szempontból problémásabb. Ami egy jövőbemutató megoldás, az az LCC, de ez Európában még teljesen ismeretlen. Pedig váltó- és jelzővezérlésben és pultépítésben nagyon erős lesz.
"A megfelelő üzenet kiküldés úgy néz ki hogy az üzenetet maszkolod 0b1000-al. Tehát: 0 állásnál az üzenet 0b1000, 1 állásnál 0b1001. Így nekem működik, de sajnos nem mindig."
Ez most nem mond ellent annak, amit benbe írt? ("A Roco 1=egyenes, 0=kitérő, a Lenz 9=egyenes, 8=kitérő kódolást használ")
Van ROCO és LENZ cucc is nálad? Mert ha jól értem, a ezeket két különböző módon kell meghajtani vagy nem?
Esetleg egy architektura rajzot feldobhatnál meg pár tapasztalatot :-)
Pl olyanok érdekelnének, hogy mire is használod ezt pontosan (mennyi és milyen dolgot irányítasz vele), az xpressnet jel hogy jut el a központhoz (külön kábel vagy wifi), mik a tapasztalataid az xpressnettel, érdemesebb-e esetleg loconetet vagy mást használni? (nekem az xpressnet de amennyit látok ebből a DCC-ből egy elég tákolmánynak tűnik)
Most működik. Mármint a 0,1 kóddal. Gondolom azért, mert a Multimaus Roco. És most szépen változik a multimaus kijelző jobb felső sarkában a váltóállás ikon és az arduinos dekóderem is szépen érzékeli és kiírja, hogy a 17-es címen állítódott a váltó (a használt xpressnet librarynak 20-as küldök be, 21-et jelez ki a Multimaus és a saját arduinos dekóderem meg 17-et, de ez részletkérdés, majd a címezés módját megnézem, hogy érdemes, kell)
Érdekes, pedig próbáltam sokféle kombinációt de lehet, hogy a kettő közül az egyik mindig rossz volt (pl 8,0 vagy 8,1 stb...) ezért volt, hogy csak az egyik irányba váltott.
Kódot nézem, amit küldtél, kösz! Látom, hogy külön ág van a LENZre és a ROCOra Gondolom, akkor ez a digi központban vagy a "gyári" dekóderekben valahogy le van programozva, hogy ezt lekezelje. Most akkor már nálam is le lesz :-)
Ismerem a problémát, pont a hétvégén sikerült végre befejeznem. Sajnos az okozatot nem tudom megmondani, de van hogy nem áll át a váltó hiába helyes Xpressnet üzenetet küldök. Több részre bontom a megoldást, hogy könnyebben értelmezhető legyen.
Helyes üzenet felépítés: A megfelelő üzenet kiküldés úgy néz ki hogy az üzenetet maszkolod 0b1000-al. Tehát: 0 állásnál az üzenet 0b1000, 1 állásnál 0b1001. Így nekem működik, de sajnos nem mindig.
Helyes parancs beállítása: Erre azt a megoldást találtam, hogy egy while ciklusban kiküldöm az üzenetet, majd 100ms ot várok, beolvasom a váltó jelenlegi állását és ha nem az amit szeretnék, kiküldöm újra, amíg nem áll át megfelelően.
Időzítés problémája: Sajnos így a kiküldés eléggé időigényessé válik. Nekem több arduino kommunikál I2C-n, így van egy ami csak az Xpressnettel foglalkozik. Azért hogy ne emiatt álljuk, a kiküldésre váró parancsokat egy FIFO-ba rakom, így kényelmesen tudok egyszerre több gomb parancsot is küldeni, egymás után. De ha egyen szeretnéd, akkor meg tudod azt is csinálni, hogy a gombok lenyomását figyeled amíg vársz hogy megtörténjen az üzenet kiküldés/feldolgozás a DCC vezérlőben.
Van egy példa kódom amin Arduino MEGA-val lehet debuggolni, meg egypár váltót állítani. Írj egy emailt és átdobom. Én a kapcsolást és a könyvtárat is innen vettem anno: https://pgahtow.de/w/XpressNet
Más a Lenz és a Roco váltódekódereknél az álláshoz tartozó bináris kód. A Roco 1=egyenes, 0=kitérő, a Lenz 9=egyenes, 8=kitérő kódolást használ. A te két sornyi példád nem egyenes-kitérő, hanem azonos álláshoz tartozó Roco-Lenz pár volt, ezért csak egyik irányba áll át a váltód.
Nem címzési probléma, de ez tény, hogy a címzés nem egyszerű és még nem tudok róla mindent. Valemennyire utánaolvastam ennek és a környező címeket is figyeltem. Illetve azóta annyit sikerült elérnem (valójában eddig is csak nem figyeltem, mert a multimauson pont olyan állásban volt a kitérő állítva), hogy állítódik a kitérő a multimauson de csak az egyik irányba (tehát az látszik, hogy ha a multimauson elállítom a kitérő jelet, akkor az ardiunoból érkező xpressnet parancsnak megfelelően visszaáll). Tehát a címeket eltaláltam (illetve korrigáltam a programban) és a küldött értékekkel probléma van
Kicsit bővebben:
DCC dekóder, tehát a fogadási oldal:
Megépítettem még régebben a fordítva irányt is, vagyis egy DCC dekódert. Ez annyit csinál, hogy rákötöm a sínre és dekódolja az ott jövő DCC jeleket, aztán kiválasztja, hogy melyikkel, mit akar csinálni. Tehát mintha sok-sok mozdony és eszköz dekóder lenne egybeépítve vagy mintha egy sniffer lenne. PCA 9685-ök vannak hozzá kötve. Most épp kettő, ezekből nem emlékszem pontosan de kb 10-et egymás után lehet kötni. Mindegyiken 16 led hely van tehát így mondjuk 160 darab led-et meg lehet hajtani. Arra gondoltam, hogy majd ezzel hajtom meg a jelzőket.
Raktam hozzá két kijelzőt is, ahol kiírja, hogy melyik címen, milyen parancsot kapott. Egy Roco 10764+Multimaus-om van most.
Ha a Multimaus-on beírom mondjuk a 25-es címet és váltót állítok, akkor a DCC dekóder mindig 4-gyel kisebb címet kap, tehát a 25-nél 21-et. Csináltam is hozzá két képet. A 21-es porton egy kék led figyel (ezzel szimulálom a leendő jelzőmet), amit a multimaussal állítok.
Xpressnet throttle, tehát a küldési oldal:
Na most megcsináltam azt is, hogy az Xpressnetes arduinot is rákötöttem Roco 10764-re meg a arduino-s "dekóderemet" is a sínre és azt látom, hogy az Xpressnetes arduino-ból átjutnak a jelek (de ez eddig sem volt kétség, mert a mozdony lámpáit pl jól tudom villogtatni) de a váltó jel nem megy oda vissza a multimauson (csak oda). A címzésben van trükk, mert ha a programból a 20-as címet küldöm, akkor a dekóder 17-est jelez de a multimauson meg a 21-esen látom azt a váltót (itt állítódik is de csak az egyik irányba). (itt lehet, hogy bekavar az általam használt xpressnet library de ez részletkérdés)
Na mind1, szóval igen, a címzés trükkös, de ezt megoldom, amit továbbra sem tudok, hogy milyen Xpressnet jelet, jeleket adjak, hogy egy váltó oda-vissza állítódjon. A leírásod alapján, azt gondolnám, hogy tényleg "eszement" ez a dolog és ezt csak az adott dekóder ismeretében lehetne megmondani, hogy az éppen milyen jelet akar.
- X dekóder (X 1-től indul)
- Y csatornájának (Y 0-tól 3-ig megy)
- Z kimenetét (Z pedig 0, vagy 1)
- be, vagy kikapcsolod.
A Z kimenetet úgy érted, hogy két darab független fizikai kimenet lenne? Én azt gondoltam volna (de nem értek hozzá), hogy egy váltó dekóder egy portjához (tehát pl a 55-os címhez (ami mondjuk 52+3) tartozó két kimenet nem független egymástól, hanem egymás negáltjai. Lehet, hogy mindkettőt lehet külön vezérelni? Szóval az előző leírásomban lévő táblázatot továbbra sem értem, sajnos
Próbáld meg 4-gyel odébb nézni. Azaz ha pl. a 7-es váltót állítod, a MultiMauson a 11-est nézd. Hátha a szokásos 4-es eltolás a probléma.
Volt itt már szó többször is az eszközdekóderek címzésének anomáliáiról, keress vissza. Dióhéjban: az NMRA szerint ha egyetlen kimenet címét (amire pl. egy váltó egy tekercsét kötjük) akarod macerálni, akkor
- X dekóder (X 1-től indul)
- Y csatornájának (Y 0-tól 3-ig megy)
- Z kimenetét (Z pedig 0, vagy 1)
- be, vagy kikapcsolod.
Tehát a sínre egyetlen parancsban az X, Y, Z címeket kell kiküldened, plusz az adatot, hogy be-, vagy kikapcs. Eléggé eszement. Emiatt a legtöbb központ
- X és Y-ból egyetlen "egyszerűsített" címet gyúr (azaz fordítva: az "egyszerűsítettből" számol X-et és Y-t);
- Z-t úgy kezeli, mint egyetlen váltó két oldalát (egyenes, vagy kitérő);
- a be- és kikapcsolást elsumákolja (a dekóderre bízza, hogy az csak impulzust adjon ki, váltsa a két kimentetét, vagy egyéb módon működjön).
A gond ott van, hogy ha az "egyszerűsített" címet szimplán X*4+Y képlettel számoljuk, akkor nem lesz 0..3-as címünk (0-s dekóder a szabvány szerint nincs). Ami fura. Emiatt bizonyos központok az (X-1)*4+Y képletet használják.
Magyarul ha Te a 2-es dekóder 3-as csatornájának 1-es kimenetét akarod bekapcsolni (mert a dekóder ilyen formában várja az infót akkor is, ha Te nem így akarod átadni), akkor központtól függően vagy a 2*4+3=11-es címet kell maceráld, vagy a (2-1)*4+3=7-est...
Egy domino(?) szerű irányítópultot raknék össze. Arra gondoltam, hogy a cuccból Xpressnet-tel fog eljutni a központba az adat, egyelőre ezt tesztelném most ki, hogy jó-e ez az irány vagy zsákutca.
A https://github.com/Digital-MoBa/XpressNet/tree/main oldalon található Xpressnet slave library-t használom Arduinoval (egy Roco 10764+arduino nano+egy darab RS485 átalakítót használok). A mozdonynak pl tudom villogtatni a lámpáit (tehát ez olyan, mintha ezen a jövőbeni domino pulton lenne egy darab kapcsoló, amivel fel-le lehetne kapcsolni a mozdony lámpáját.
pl:
// elso nulla: mozdony cím felső byte // a következő kettes: mozdony cím alsó byte, tehát ez a kettes mozdony // a következő nulla: funkció kikapcsot jelent // az utolsó nulla: a nullás funkció a világítást jelenti XpressNet.setLocoFunc(0, 2, 0, 0);
A kettes mozdony világítás bekapcsolás meg nyilván ez pl: XpressNet.setLocoFunc(0, 2, 1, 0);
Tehát a mozdony funkciódekóderét elérem gond nélkül. Ahol elakadtam, az a váltókezelés. Sajnos váltódekóderem még nincs (azt sem tudom, hogy milyet vegyek majd de nyilván veszek, majd azzal tesztelek, csak gondoltam, rákérdezek, hátha valaki tudja a választ...), így egyelőre a multimaus váltóikonján nézem, hogy átváltott-e a váltó. A problémám az, hogy nem tudom, hogy az XpressNet specnek megfelelően (https://wiki.rocrail.net/lib/exe/fetch.php?media=xpressnet:xpressnet-v2.pdf 58. oldal) mit kellene küldenek, hogy ha pl egy váltót oda vissza akarok váltani
Az egyik példában pl azt láttam, hogy ezzel váltogatták oda-vissza a váltót, de nekem erre a multimaus ikonja nem változik:
XpressNet.setTrntPos(0, turnoutNumber, B0000);
XpressNet.setTrntPos(0, turnoutNumber, B1000);
Szóval a kérdés az lenne, hogy mit kell küldeni, mit kell a vastagított részhez írni, hogy a váltó átváltson és vissza illetve mit jelentenek itt a szövegben, hogy aktiválni és szelektálni egy outputot?
Az elmúlt évben vettem egy Digikeijs dr5000központot. Szerettem volna a pályát digikeijs foglaltságjelzőkkel összerakni, de közben a cég megszűnt (csődöt jelentett) és most már nem tudom megvenni. Most van egy szuper jó központom és keresem hozzá a foglaltságérzékelőt. A kitérőket digitoolsos dekóder működteti. Használhatom érzékelőknek is a digitools Digisens -8Rb-t?
Azt hiszem meglesz a megoldás, miért nem csinál semmit az esu dekóder. Nekem ESU lokpilot 3 lehet, a nyák kinézete alapján. Itt a powerpackot két helyre kell kötni. Lásd kép. Még egy 5V-os tápot is kell csinálni. Na, majd ez is sorra kerül valamikor.
Még egy: érdekes, ESU sima dekóderrel (valami LOKpilot v3/v4 lehet) nem is működik. A dekóder feltölti a pakkot, de nem használja belőle a delejt. Mértem a kondi feszültséget, és csak szépen lassan 10-10 másodperc alatt esik belőle 1-1V. Fura. A Gnd-re (szürke nyíl), meg a kék-re (kék nyíl) kötöttem. Mintha csak a dekóder belső működését biztosítaná. Khün dekóderrel, DigiToolsal, LAisDcc-vel meg szépen működik. Érdekes.
Érdekes, nem lett jobb kettő kondival sem. A lassú járásnál ugyanúgy megáll szinte azonnal a mozdony. Bizonyos sebesség felett pedig minden futási táv duplája az eredetinek, azaz ott hozza a papírformát.
Mindegy, nekem így is jó lett :) Bocs, a monológért.
Kicsit továbbgondoltam az előzményben bemutatott töltő áramkört.
Sikerült egy kb DT dekóder méretű (ez volt a viszonyítási alapom) töltőáramkört összehoznom sufnikörülmények között. A vicc, hogy működik. Igaz, egy H0-ás ROCO E40-est lassú menetnél az 1F 2,8V kb fél centit viszi előre, viszont kicsit magasabb sebességnél (1/4) már 5-6 cm-t is halad a mozdony, 1/2 sebességnél meg már 10-12 cm-t is.
Még annyit kipróbálok vele, hogy kettő 1F-os 2,8V-os kondit sorba kötök, és a töltőáramkörön megemelem a töltési feszültséget (egy ellenállás csere).
A step-up ic ugyanis 1,9-vig működik jól. Azaz jelen pillanatban csak a kapacitás kb 1/3-át tudjuk a kondiból kihasználni, a többi benn marad.
Nem sok reményt fűzök a dolgohoz, de hátha! Digikeijs dr5000 vezérlőközpont, usb csatlakoztatása esetén a nem kommunikál a pc-vel, ledje sem világít Valakinek esetleg tapasztalat? Vagy javítható?
Szép tulajdonsága a Next18-nak, hogyha fordítva dugod be, nem megy tönkre. Az "összetartozó" lábak ellentétes oldalon vannak. Üzemszerűen is lehet fordítva használni (pl. az adapter helye miatt), akkor úgy kelll bekötni.
Tetővilágításba építve verhetetlenül lapos tud lenni, egy Plux csatlakozóval szemben :) Viszont ahhoz képest, hogy újabb ötlet, mint a Plux, relatíve kevés kimenettel rendelkezik. Olyan miniatűr az a csatlakozó, lehetett volna oda még 4-6 lábat tenni, aztán lehetett volna az logikai kimenet is... nem így történt. Az ESU most tovább fejlesztette a NEXT18-at, persze nem kompatibilis, de legalább annyi lába van mint a plux-nak.
Nem hangzik rosszul, bár én a next18 használatát nem ajánlom, ha van hely plux22-nek sokkal jobban jársz vele. Next18-al az a probléma hogy a hivatalos szabvány szerint is 2 verziója van, a néma (next18) és a hangos(next18S)(https://dccwiki.com/Locomotive_Interface). A fő különbség a kettő között, ami téged is érint, hogy a hangos dekóderen nincs AUX5 és AUX6, ezeket a lábak a hangszóró kimeneteinek vannak fenntartva. Arról nem is beszélve, hogy az AUX3 és AUX4 is csak logikai kimenet, azaz kell még egy illesztőáramkör ha valamit kapcsolgatni akarsz velük.
Ezzel ellentétben a plux22-n AUX1-AUX7ig minden kimenet teljes értékű, emellett van külön láb a hangszóróknak és a pufferkondinak. Az aljzata miatt néha több helyet foglal(pl. ezért nem ezt rakták anno a Bobo-ba), de ha van neki hely és sok extrát szeretnél, akkor sokkal jobban jársz vele.
Azon törpöltem, hogy egy next18-as dekóder is megfelelő lehet. Ennek összesen 6 kapcsoló kimenete van. A maradék 2, meg a hangszóró. Ezt a dekódert be lehet úgy fabrikálni a felső áramkörbe foglalattal, hogy nem lógna be az utastérbe, a világítás áramkörrel egy szintben lehet.
Következőre gondoltam, ebben minden lenti variáció benne van:
1; irány kiválasztása (előre/hátra)
2; 1-es vezetőállás aktív (menet/zárfény - iránytól függ)
3; 2-es vezetőállás aktív (menet/zárfény - iránytól függ)
4; Fülkevilágítás (menetiránytól függ)
5; Tolatófény: mindkét oldalon egy fehér fény világít lenn, más nem
6; kocsilekapcsoló
Ez így 6 valós kimenet, és megmarad a hangszóró lehetőség is.
Egy kompromisszum maradt, az utastér világítás. Ez bármelyik vezetőállás (1-es 2-es) aktív állapota esetén világítana.
