A már többször emlegetett Paco oldalon van egy teljesen jó rádiós vezérlő. próbáld ki azt.

Már többször is gondoltam a Paco félére. Sőt néztem az OpenDCC oldalán is a vezeték-nélküli vezérlőt bár az kicsit komolyabb szerkezet. Ez maradna a "B" verzió Valami olyan megoldást keresek amivel a jó bevált Multimausom működne.

Jól értem, hogy az XpressNet busz meghosszabbítása a feladat? Direktbe akarod rákötni a Multimouse-t? A leírás szerint 1000m hosszú lehet az XpressNet busz, ebbe nem férsz bele?

Igen arra gondoltam, hogy a buszt hosszabbítani. Érdekes nem tudtam ezt az 1000m-t. Saját magam raktam össze kábeleket, és ami kb. 3m fölött volt nem akart működni :S Abból gondoltam, hogy 10-15m kábel nem fér bele.

Most néztem a Lenz oldalát és tényleg mennie kéne. 100m tuti. Lehet szerzek valami jobb kábelt és csatlakozókat.

Azt kérdezném tőletek, hogy a Paco-féle fényjelző vezérlőket, hogyan lehetne ráhúzni a magyar 4 fényű jelző rendszerre?
Mert Paco 2 fényűt programozott alapból, illetve a RENFE 3 fényű változatát. Ezt a 2 fényűt duplázva lehetne megoldani a magyart? Mert tartok tőle, hogy nem éppen ekvivalens!

JVND: Te több dolgot is megépítettél már, ahogy olvastam itt és a hobbivasúton is. Tudsz másik oldalt, ahol található magyar fényjelzővezérlés?
Illetve milyen tapasztalataid vannak az épített eszközökkel?

Köszi
Üdv
Zsolt

http://usuaris.tinet.cat/fmco/dccacc_en.html#sem16f84

Én ezt a felsőt csináltam meg. 1 Dekóderre 4fényű jelzőből 2 öt, tudok vagy 4+1fényű vezérlek vele plusz az előjelzőt hozzá. A PDF fájlba benne van hogy lehet CV vel egyesével felprogramozni. Így az összes jelzést ki tudom rá vezérelni.

http://usuaris.tinet.cat/fmco/download/UniSemaf648_manual.pdf

De a sima egyszerűt is fel lehet így programozni:

1 vörös
CV 35 -> 15 /kivezetés 1
36- > 1

2 Zöld
CV 39- > 15 / 2kiv
40 -> 2
3 egy sárga /3 kiv
CV 43 -> 15
44-> 4
4 sárga- zöld /4&2
CV 47-> 15
CV 48-> 10
5 sárga-Sárga /4&3
cv 51 -> 15
CV 52 -> 12

A linkelt PDF 28 oldala remélem segít a programozásban. És akkor tudod folytatni Cv 55-59 stb.

Köszi Csabaa,
ez a kapcsolás 16F84-et ír, van ennek valami újabb PIC változata? Ez egy régi és viszonylag drágább PIC. Az láttam, hogy még a 16F628-ast írta, azzal is megépíthető egy egyszerű cserével és nem is kell szerkezetileg módosítani a programon? Max az alap config-on.
Nem tudom.

Az XpressNet fizikailag RS485-ös busz (lásd meghajtó IC-k). Itt arra kell figyelni, hogy a busz végén meglegyen a lezáró ellenállás (120 ohm. -továbbá van még 4.7K-s le és felhúzó ellenállás Paco oldalán is.-) Érdemes úgy csinálni, hogy lehetőleg ne csillagpontos legyen, azaz az elosztóktól rövidebb kábel menjen az eszközök felé. (Ilyen távolságokkal még nem kísérleteztem, de a szabványban -ha jól emlékszem-vannak ilyenirányú rajzok.) Gyakorlatban a központ NYÁK-jára raktam egy lezáró és fel/lehúzó ellenállást; az ellenoldalit még nem kellett alkalmaznom, mert csak néhány méteres kábelek kellettek. Viszont ha hosszabb akkor mindenképpen szükséges a lezáró. (elvileg az RS485-ös szabvány 2.5 km-ert enged meg de ennek most nem néztem utána, csak emlékezetemben ez a szám maradt meg.)

Közben beleolvastam az asm-be és láttam, hogy 16F648A-ra van írva, csak a választás miatt miatt először nem vettem észre!

Igen, gyakorlatilag egy teljes terepasztal vezérléséhez szükséges dolgokat megépítettem és bár helyhiányban szenvedek, azért ideiglenes pályákon alkalmazom az áramköröket. (Más modellezőtársak terepasztalain is kifogástalanul mennek.)
Fényjelző dekóder: Amiket látsz, annak az alapja a MERG féle eszközdekóder. ez van továbfejlesztve. (lehet, váltó, fényjelző- motoros váltó dekódert kihozni belőle.) Régebben 16F84-el csinálták de mostanság a 16F628, 648 PIC-eket alkalmazzák. Csak ilyet érdemes építeni. A firmware része variálható, ha valaki kedvet érez belenyúlni a programjába. A DCC dekódoláshoz nem kell nyúlni, az jó ahogy van, de utána szabadon variálható a meghajtó rész.
Ha megnézed az "aspektusos" programozását, akkor láthatod, hogy bármi kihozható belőle, (mint ezt már írták előttem). Mondjuk kell hozzá egy délután, hogy megértse pontosan az ember, hogy ez az egész miért jó, valamint bele kell ásnod magad pl. a TrainController lelkivilágába, de utána már megvalósítható e jelzéskép és vezérlés. (Jó ha van tapasztalt TC-s ismerős a közelben, mert több trükköt el tudnak mondani.)
Az eszközök megbízhatóak még nem nagyon romlottak el, (a saját tervezésű NYÁK-ot viszont gyártatom.)

Holnap lesz egy kis időm belevetem magam az RS485 rejtelmeibe. Kábeles megoldást nem adom fel. Olyat nem sokat találtam h modellezésbe csináltak volna ilyet. De 1-2 RS485 adó-vevő komplett készüléket már találtam. Ha ezekre rákötném az A-B vajon működne ???

Köszönöm.
Én csak egy Ecos2-vel fogom az egész asztalt irányítani, a TC-t nem terveztem (még). Megépítettem egy egyszerű 4-es szervo vezérlőt a Paco-ról és klasszul megy. Az inkább meglepett, hogy a központ kikapcsolás után elfelejtette az eszközt. Biztos valamit rosszul konfiguráltam, mert az elemek a központban teljesen jók, mégis bekapcsolás után nincs benne egy sem a korábbiak közül.

A program kódot olvasgatom egy ideje, szeretném megérteni a DCC üzem kódolását asm-ben is, de elég lassan haladok a visszafejtéssel.
A meghajtó- és a dekódoló részeket hogy találom meg gyorsan?
Csináltam egy fénysorompó villogtató és rudazat állító vezérlőt is az asztalhoz. Az egyik 12F683-as és PWM-mel hajtom a motort, a villogtató meg 12F629-es, erre tervezem rákötni a HALL IC-ket is a vezérléséhez.
DE!
Szeretném kiegészíteni a programot, hogy DCC-t is értelmezze, de ezt csak saját szórakoztatásra.
Szóval most minden segítség jól jön. Eddig mindent megtanultam az információ morzsákból, csak ez a DCC egy kicsit kifogott rajtam. Picit bonyolultabb mint gondoltam. Pedig a szabvány teljesen világos.

Tudsz ajánlani, eddig még nem kellett, de a mennyiséget elnézve már megérné nekem is gyártatni.

Az S88-as visszajelentő modulját tudom majd használni az Ecos2 központtal, ugye jól sejtem?

Mivel az S88 szabványos ezért működnie kell. Gyakorlatban még nem próbáltam.

Szia. Ugyanolyan IC-ket használnak, 75176, MAX485, stb. úgyhogy mennie kell. (Nem kell hozzá külön áramkör.)

Ha megnézed a interrupt rutint, az rakja össze a 4 (6) byte-ból álló packet-et és "szól" a főprogramnak, hogy jött egy új packet. Utána egy ugrótáblára kerül a vezérlés és a csomagban megkapott bitek szerint ugrik az egyes funkciókhoz. A MERG-es kód még sorszámozva is van.

Köszi. Át fogom nézni akkor a MERG alapot, mert nagyon érdekel a téma.
Ilyenkor jönne jól egy programozó aki még a DCCt is ismeri.
Gyorsabban megy a megértése...

Elviekben működnie kell, de mivel nincs S88 szabvány így előfordulhatnak problémák. Én mértem ECOS központot, és ahogy DCC-ben nem tartja pontosan a szabványt, úgy előfordulhat, hogy S88-on sem. DCC-ben hála a szuper RTOS-ének, olyan jitter van benne, hogy én szégyelltem volna kiadni így az ESU helyében. Dehát a marketingesek már biztos kiadták volna, amikor a mérnökök még dolgoztak volna rajta.

Ha képfrissítés, vagy komoly grafikai feladatot végez az ESU Ecos, akkor néha a 116us-es impulzus simán 120-125...
S88-at, ugyan úgy olvas mint az én általam fejlesztett központ. A clock-ot ráérő processzor időben generálom, azaz gyakorlatilag "random" időközönként vannak az impulzusok a clock-on.
Az S88-N szabvány kezdemény is csak az órajel impulzus szélességét specifikálja, annak frekvenciáját nem, így elviekben ilyen trükk szabadon végezhető.
Én kapcsolatban vagyok Wolfgang Kuferrel (OpenDCC) és Kersten Tams-al (Tams Elektronik) is az S88-N szabvány kezdemények gazdáival, és az ESU nem kért tőlük engedélyt az S88-N használatára (annak használata engedély köteles). így nem valószínű, hogy a Paco az S88N használattal 100%-osan működik a nem S88-N szabványú ESU ECOS-szal.

Vagyunk itt egy páran, akik már egy ideje gyűrjük a digitális vasútmodellezés és a programozás témát. Csak ebben a topikban legalább 10 ember van, aki biztos tud Neked segíteni, ha felteszed a kérdést.

Köszönöm Topi, és élek is a lehetőséggel.

Az világos, hogy a byte-ok egymás után így jönnek: preambulum, address, data, errorcheck.
Ha át akarom állítani az egyik váltóm, akkor az address az ő CV-jében tárolt címe. Viszont a datában mit-hogyan kell küldeni. Van pl a 4 szervos vezérlő. Datában küldöm a szervo egyik-másik pozícióját!? Vagy egyszerre a data byte-on átküldöm mind a 4 szervo pozícióját? És az Errorcheck-et miből és hogyan számolja ki a rendszer?

Éppen tegnap voltam bent nálatok a HEStore-ban az S88-as PACO alkatrészekért, úgyhogy hamarosan kiderül működik-e.

A szervovezérlőjét megépítettem és hibátlanul működik a négy motorral.
CV olvasáskor előfordul, hogy néha hibát jelez és újra kell próbálnom, de ezt tapasztaltam a saját egyszerű szervovezérlőm PICKIT3-mal írásakor. A motorok nagyon bele tudnak rondítani a rendszerbe. Pedig tele pakoltam 100nF-os hidegítőkkel az alaplapot, ennek ellenére egy erősebb motor rándulásnál kiakad!
Összességében viszont működik rendesen.

ECOS2-t szívesen felajánlom mérésre, ha azt még nem mérted. Úgy értettelek, hogy az első kiadást tesztelgetted. Engem kifejezetten érdekelnek ezek a dolgok...

Namost. Jól írod, preamble, data, errorcheck egy DCC frame felépítése.

Váltók állításáról a NMRA DCC S9.2 dokumentum ír részletesen. Ez megtalálható az NMRA.org címen: NMRA DCC S9.2
Itt, ebben a doksiban megtalálod a baseline packet-et, ami jó a kezdéshez ha mozdonyok irányításáról van szó.

És a váltók irányításáról a NMRA DCC S9.2.1 doksi szól, letölthető itt: NMRA.org
Ebben a 9. oldalon megtalálod, miképpen lehet a váltót irányítani a "Basic Accessory Decoder Packet Format" részben.
Lényegében az alábbi történik hagyományaként a Maerklin ápolgatta tri-state enkóderek korából (Maerklin-Motorola formátum).

{preamble} 0 10AAAAAA 0 1AAACDDD 0 EEEEEEEE 1
Elsőként megmondod, hogy melyik AAAAAAAAA (9-bit) kezdőcímű váltót szeretnéd állítani, majd mondod meg, hogy melyik kimenetet szeretnéd aktiválni (DDD) és végül, hogy melyik végállásba (C).
Arra figyelj: Általában a 9 bites cím mögé szokták tenni a DDD-t. Így a címkiosztás is változik. Ha az A végére teszed a D-t, akkor külön-külön címe lesz minden egyes kimenetnek. Ebben az esetben 4 címet foglal el a váltó dekóder (mindenki így csinálja).
Első váltó: 1,2,3,4 címet foglalja el
Második váltó: 5,6,7,8 címet foglalja el.

Azt, hogy melyik alap címen (A) belül, melyik párra (D) vonatkozik a parancs, azt bit shiftelgetéssel kell visszalakítani. Példa: 187-es váltócím
Melyik váltó dekóder: 187/4 = 46 (csonkolásos osztás, nincs kerekítés - 187/4 = 46.75 azaz 46. ez lesz az A)
Melyik kimenete: 187%4 = 3 (% az moduló, azaz maradékképzés, ez lesz a C)

Arra figyelj, hogy mint áldalában minden hosszú DCC címnél, itt is a cím egy része egyes komplemensben van (invertált bitek).

Szerk: Az A=0 broadcast, azaz mindenkinek szóló parancs. Ez gyakorlatban annyit jelent, hogy egy váltónak egyszer van a saját címe amire hallgat, másodsorban pedig a 0-ra is.
Gyakorlatban nekem még sosem volt olyan, hogy a váltóknak broadcast-ban adtam ki váltás parancsot, de NMRA szabványnak megfelelés miatt tudnia kell. Én 96MHz-es ARM alapú saját fejlesztésű központom soha nem ad ki broadcast váltó parancsot, nem is volt rá szükség.

Tehát ezek szerint, három biten összesen 4 címet lehet vele kezelni? Mert, hogy engedné a 8 különbözőt is 2^3 vagy rosszul értettem?


Tehát a C vagy 1-es vagy 0-ás. Ez a két állás.


Miért csak egy részét képezi egyes komplemensbe? Mi a nagy trükk?

Közben megtaláltam, és rosszul értettem. Csak 2 biten tárolja a kimeneteket!
És akkor már értem miért nem készít senki 4-esnél több kimenetű vezérlőt.

Azt tudom, hogy a kommunikáció során az 1 és 0 más impulzushosszon érkezik.
Jó értem, hogy a dekódoláskor be kell állítani egy Timert, ami fut egy adott frekvencián és amikor megérkezik az INT lábra a preamble akkor onnantól fogva kezdődik az összehasonlítás, annak megállapítására, hogy 1 vagy 0 érkezik?

Az a "gond", hogy mindig van preamble. Vannak olyan digit központok, amik csak preamble-t sugároznak, ha nincs mondanivalójuk (pl. Maerklin Central) de ez NMRA DCC szerint nem helyes, mert ilyenkor IDLE csomagot kell sugározni.
Sajnos ebben eltérnek a központok. Van régi Intelliboxom, van új Intelliboxom, van Maerklin Central (2)-om, van ESU és Roco központom. Sokan rúgják fel az IDLE packet szabályt. (Persze okkal tehetik, mert multiprotokoll központnál egyszerűbb 1-est sugározni MM formátumra váltáskor, mint IDLE csomagot.)

Detektálása a jelnek nagyon egyszerű: Mindig, folyamatosan hallgatod a vonalat. Minden felfutó él után háromnegyed hosszú impulzus idő múlva (compare interrupt, vagy kontrollált overflow) megnézed, hogy a láb magas vagy alacsony. Ha rövid impulzus volt, akkor a háromnegyed idő múlva a pin-en nulla lesz, ha hosszú impulzus volt, akkor 1.

Ez egy alap DCC vétel séma, ennek megvannak az előnyei és a hátrányai is. Ennél én már sokkal fejlettebb módszert használok, mert a zajérzékenysége ennek a módszernek csak nagyon sok "hulladék idővel" (azaz felelsleges műveletekkel) javítható. Ezen módot most nem osztom meg.
Amire Neked kell, arra a háromnegyedes módszer azért jó, mert úgyis zárt a környezet (nincsen szakadozó jel, a kerék szikrázás miatt)
Benne van a DCC speckóban, hogy hány 1-es bit után a byte start milyen csomagot jelent. Basic csomag struktúrát olvasgasd.

Igen-igen, olvasgatom és egyre több minden világos belőle, illetve Paco is "szerencsémre" ezeket a neveket használta a feldolgozó algoritmusokban így gyorsan megtaláltam mindent.

Most már az 1/0 olvasást is értem, ő is 64us és 90us között 77us-nél nézi meg, hogy milyen állapotban van a bemenet.

Lenne egy hardveres kérdésem is!
Az egyik szervo dekóder változat a bejövő DCC jelet az egyenirányító előtt veszi le a PIC lábára egy ellenálláson keresztül, a másik meg optocsatolóval. Megépítettem mindkettőt és rá kellett jönnöm, hogy az opto-s változatból nem tud olvasni a központ, mivel nincs visszajelzés. Az ellenállásosnál ezzel nincs is gond. Viszont én szeretném a leválasztott táp-os megoldást, hogy ne a központ teljesítményét húzzam.
Tehát ebben az esetben úgy kell átterveznem a kapcsolást, hogy vissza is beépítek egy optokaput!

Csakhogy ahány kapcsolás annyi kapu! Mi a különbség a 4N35, 6N137, TLP521 kapuk között. Miért találok olyan áramkört, ahol az írás irányában 6N137 van, vissza meg vagy TLP, vagy 4N35.
Mitől függ, hogy milyet választhatok? Mert bevallom a tech_data lapokon nem találtam olyan dolgot, ami nagyon lényeges eltérést jelent szerintem.

Vétel irányban 4N35-öt felejtsd el. A DCC 8 KHz-éhez az lassú. Adás irányban (ACK-hoz) jó a 4N35, mert ott csak lassú jel van, igazából csak egy impulzus, nem adat.
Attól még, hogy ellenállásos a jel levétele, még nem lesz olvasható. Arra külön ACK szekvencia kell (lásd Service Mode adatlap, NMRA.org)

Optocsatolásra akkor van szükség, ha galvanikusan le kell választani, és/vagy a tápja nem DCC jel. Ha külön táplálod, akkor minden esetben le kell választani optóval. Én magam részéről az optós változatot ajánlom, ha olvasás kell, akkor meg még egy optó kell, csak a másik irányba, és az fogja generálni az ACK szekvenciát.