Off lenne a kimitépítettben ezért válaszolok itt:

Sikerült beállítani, először lassú menetben nagyon szaggatottan ment, de most már csak a nagyon lassú menetnél van némi rángatás, de az is csak egyik irányba és csak ha terheletlenül önmagában megy a mozdony. Lehet hogy még lehetne állítani rajta, de ez már így is szuper. Meg nekem csak ez a 3db egyenes vágányom van, majd még hangolgatunk rajta bátyámnál. Nála legalább egy "dilikör" van. Lefordítottam amúgy a MERG-es CV leirást magyarra, de az most nincs itt nálam, csak otthon. Ha érdekel át tudom küldeni.

csak kiváncsiságbol kérdeztem , mert anno én is rendeltem 872es picet, hogy osszerakom a dekodert. de elotte a 16f84essel probálkoztam ,de párszor az idegeimre ment. elég gyorsan elfelejtettem a merget. azota csak zimo dekodereket vásárolok, van hangos is, meg mini . én TT ben utazom ezért számít a nagyság meg az ,hogy tudják az ABC funkciot, az automatikát is arra terveztem, hogy a dekoderek abc sek lesznek.

őő, de ugye nem az F84 -be akartad tölteni a 872-es programját ? Amúgy van 16F84 -es, vagy 628 -asra való működő dekóderem is, de az csak próbapanelen drótokkal lett megépítve. És a drótok lettek bedugdosva a dekóder aljzatba. De működött végülis.

na azt azért nem, ha építeni is fogok dekodert csakis a 12f629es johet számításba a nagysága végett. de azt majd a gyermekeim terepasztalára. most hanyagolnom kell, más kot le.komplett tisztítorendszert készítek a barátom kertitavához.
kapok érte egy elektromos rollert! és utána johet a tuning!!!
kicsit offra sikeredett!

Nem teljesen ttl, meg digitális de lenne egy kérdésem: adott egy bühler motor, H0 modellbe lett véve, ment is egy darabig, de eléggé meleg. Az normális hogy üresjáratban, kivéve a modellből 12V -on 1A -t vesz fel ?
6V -on meg kb 600mA -t. És 6V on járatva is forró lesz pár percen belül. Mindezt üresben.

Dzsolt !

Elkezdtem írni egy saját dcc dekódert, az alapokkal megvagyok, szimulátorban már megyeget. Csak odáig vagyok még meg, hogy a beérkező adatbiteket byteokba pakolgatom. C ben írtam, 16Mhz kell neki legalább, mivel a kódom nyilván nem optimális még. Nem akarok, és nem is tudok a digitoolsos dekóder babérjaira törni ne aggódj Én úgy olvasom be a biteket, hogy kb 20uS -enként mintát veszek a sinjelből. És ha megvolt a sínjelnél két váltás, akkor összeadom a minták számát. Ami ha kevesebb mint 6 akkor 1-es bit, ha több akkor meg 0. Namost ez szimulátorban működik, de a valóságban nem tudom hogy menne-e. Mert ha pl áramkimaradás van, akkor ez nyilván megzavarja a dekódert. Csak elméletben le tudnád írni hogy te hogyan döntöd el hogy most épp 0 vagy 1 -es bit jött-e be ?

Szia!
Nekem külső megszakítás lábra érkezik a dcc jel és magas prioritású rutinban kezelődik le a bit idő mérés. Igazából én teljes periódus idejét mérem, timer1 segítségével aminek alsó bájtja 1us-onként növekszik. Amikor jön egy fel (vagy lefutó) él a megszakítás lábra, akkor a kiszolgáló rutin gyorsan elmenti Timer1 értékét és törli, előkészítve ezzel a következő bitre. Ezután már csak az elmentett értéket kell vizsgálni és eldönteni milyen bit jött. Itt dől el az is, hogy a fel- vagy lefutó élt kell figyelni. Például ha a mért érték 128-180us között van akkor valószínű, hogy éppen két külömböző bit, két felénél léptél rá a sínre (pl. 1-es bit poz. félhullám és a következő 0 bit neg. félhullám). Az eremény a "dcc_ujbit" és jelzés a dcc_dekodoló rutinnak pedig a "dcc_ujbitjott" és a "dcc_bithiba" bitek. ASM-ben írtam igy néz ki:

;================== MAGAS MEGSZAKITASOK ============================
; magas megszakitasok kezelese.
; INT0IF: a DCC jel fel vagy le futo elenel jon, megmeri T1 meddig szamolt es ennek megfeleloen
; allitja be a dccujbitet, vagy a hibabitet
; ------------------------------------------------------------------

org 0x0100
MagasInt:

movwf wmenth
movff STATUS,statusmenth
; movff BSR,bsrmenth

;....................................................................
int0:
btfss INT0IF
bra kih

movff TMR1L,dcc_periodusido ; elozo INT ota eltelt ido us-ban
clrf TMR1L ; ido ujraindit
setf TMR1H

btfsc TMR1IF ; ha ido > 255us akkor hiba
bra bithibavanx

movlw dcc_1_min
cpfsgt dcc_periodusido ; ha ido < 2*52us akkor hiba
bra bithibavan

movlw dcc_1_max
cpfsgt dcc_periodusido ; ha ido < 2*64us akkor a bit '1'
bra egyesjott

movlw dcc_0_min
cpfslt dcc_periodusido ; ha ido < 2*90us akkor hiba, elvaltas kell
bra nullajott

btg INTEDG0
bra bithibavan

nullajott:
bcf dcc_ujbit
bsf dcc_ujbitjott
bra kih

egyesjott:
bsf dcc_ujbit
bsf dcc_ujbitjott
bra kih

bithibavanx:
bcf TMR1IF
bithibavan:
bsf dcc_bithiba

;....................................................................
kih:
; movff bsrmenth,BSR
bcf INT0IF
movf wmenth,w
movff statusmenth,STATUS
retfie

>>

Hmm, és ez hogyan reagál arra, ha néha 1 pillanatra kontakthiba van ?Tehát mondjuk a bit felénél van egy kis kimaradás. Akkor az a bit/packet már oda is veszett ? Azon gondolkodom, hogy lenne e értelme egy olyan megoldásnak, hogy a bemenetet 2.5V ra húzni ellenállásokkal, amit egy smidth trigger követne. Így ha kimaradás van 1 pillanatra akkor az nem tudja átváltani a bemenetet, csak ha le, vagy fel van húzva a dcc jel által.

Kontakt hibánál timer1, vagy túlcsordul, vagy 2*64us alatt van, akkor a "dcc_bithiba" 1 lesz. Ilyenkor bizony oda az egész packet. A dcc_kommunikacio rutin ezután kezdheti előről, keresni kezdi a preamble biteket. Én nem raknék több hardver elemet emiatt a dekóderbe, had legyen minél kisebb.

Érdekelne egyébként egy program, ami DCC packeteket kódol le MPLAB stimulus file-ba ?

Te írtad? nem semmi. Annyira nem használom az MPLAB szimulátor részét, hogy még elképzelésem sincs arról, hogyan néz ki egy ilyen fájl, hogy használható stb. Azért kösz Zsolt.

Én egy Naked ISR-ben írtam meg C-ben AVR alá a dekódoló rutint.
De én teljesen státusz vezérelte írtam, tehát nem az itt előbb vázolt egymás utáni folyamatok módszert. Bármikor bármelyik státuszra át tudok ugrani esetleges hibánál.

1. Preamble várás,
2. Indító nulla várás
3. Bájt kezdet várás
4. Bájt várás.

Az összes csomagot egy átmeneti pufferben tárolom, és nem dobom el XOR hibánál, hanem kettő csomagot is bevárok. Ezekből keresem az egyezést és próbálom helyrehozni a hibás adatot. Kiválóan működik nagyon zavart és terhelt hálózaton is, és sokkal gyorsabban reagál is, például Railcom esetén így az eszköz.
ISR-ben meg végig mindenhol ahol globális változó kellene, inkább feláldoztam pár GPIO regisztert hogy ne legyen egy halom push-pop. Emiatt az egész és csomagfeldolgozó rutin össz mérete nem haladja meg a 150 bájtot.

Mozdony dekóderben több kódhelyet foglal el a terhelés és PI szabályzás

Na várjál, mi még csak bit érzékelésnél tartottunk . A bitek elpakolása nálam is segédbitek meg számlálók segítségével történik (már ha ezt érted státusz vezérlés alatt). Fennt van már egy ideje az oldalamon 2006 óta nem változott ez a rész, csak szeretném kipróbálni a kód beszúrást is.

Viszont szivesen látnánk a Te dekódered. Érdekelne a railcomm hardver környezete is ha nem titok.

Há-há megy a beszúrás. Ez se több 60 szónál. mondjuk ehhez még hozzájönek a megszakítás rutinban lévő utasítások.
Más.
Pár hete próbálkozom már a sebesség alapjel képzés átírásával, finomításával.
Feladat a követbező:
Amikor a CV3-4 (gyorsulás lassulás) értéke a minimumra van állítva, például PC-s vezés miatt, a sebesség fokozat váltása elég "keményen" történik. Ugye a PID szabályzónak ez a feladata (nem lő túl, nem is lassú), eddig rendben is van, a LENZ dekódereinél is ugyanez tapasztalható. De talán éppen ezért olyan kedvelt az ESU dekóder, mert csak ennél a gyártónál van valami trükk ami ezt az átmenetet nagyon finoman kezeli. Olyan mintha figyelmen kívül hagyná CV3-4 értékét és a sebesség fokozat változásának arányában beiktatna valami fel- vagy lefuttatást, minél nagyobb a seb. változás annál gyorsaban követi a belső alapjelével. Szóval ti ezt hogyan oldanátok meg?

ESU dekódernél én azt vettem észre, hogy egyszerű aktuális sebesség és célsebesség közötti differenciával szabályoznak.
Tehát konkrétan a lassulás-gyorsulás olyasfajta beállítás, hogy mennyivel ossza a szabályzandó különbséget.
Én is így csináltam meg, és nekem 0-ról teljes sebességre szépen nem ugrásszerűen indul, és két sebesség fokozat között is lassabban vált.

Ez abból ered ugye, hogy két sebesség fokozat között (én mindenhol 128-as fokozat rendszert használok. Akkor is, ha 14-27-28 stb a beállított. Egyszerűen egyszer számolok csak) szóval hogy a régi és az új érték között kisebb a távolság, így annak az osztott értéke is kisebb. Így látszólagos exponenciális szabályzást valósítottam meg.
Kódnyelven leírva:
aktualis_sebesseg += (uj_sebesseg-aktualis_sebesseg) / CV értéke.

Nagyon kis CV értéknél szinte ugrásszerű, nagy CV értéknél igen "óvatos". Nekem minden váltás ez alapján a rutin alapján történik.

Oké emésztem, majd írok az eredményről. Köszönöm a tippet üdv Zsolt.

Ma kipróbáltam a mintavevős megoldásomat. Működik, központról tudok kapcsolni már 1 funkciót. Egyelőre még csak ez van megírva. Még a dekóder címe is fixen van lekódolva. Viszont jobban tetszik dzsolt megoldása, tehát ki fogom próbálni hogy a portbemenet változását irq val detektálom. Ha jól nézem, akkor mintha Schmitt Trigger lenne a bemenete a kulső órajeles számlálóknak. Jó lenne ezt valahogy felhasználni. ( 12F683 adatlap ) Tehát nem a portváltozás irq-t figyelni, hanem valahogy valamelyik timer bemenetet felhaszálni. Erre valami ötletetek esetleg ?

SzerK: nézem az adatlapot, de nagyon úgytűnik, hogy a GP2 IO, az ST, úgyhogy jó lesz ez.

Végülis használhatod a ccp modult mondjuk capture módban. A timer1 pörög magába és amikor jön az élváltás az aktuális timer1 értéket elteszi neked. Neked annyi a dolgod, hogy az előző mintából kivond a mostani capture értéket és megvan a dcc periódusidő. Ez lehet megszakítás nélkül is pl. a CCP1IF-et figyelgetve (legalább 100us-onként rá kell nézned). A dolog hátránya, hogy elhasználtad a hardveres pwm-et. Mondjuk azt nem írtad, hogy mozdony vagy eszköz dekóder készül.
Más.
Topi!!
Jól értelmezem? Az aktuális sebességhez adod kozzá az újseb. - akt seb. / cv eredményét?

Hát igen, azt nem néztem, hogy az a PWM kimenet is. Viszont megcsináltam a portváltós irq -sat. Tetszett volna a dolog, de nem jött be, alig van packet amit dekódolni tud, folyton hiba van, pedig szimulátorban jól ment. Valamit biztos nem jól csinálok. Én a sima portváltozás irq val csináltam, nem az élfigyelőssel. (mert az élfigyelős irq az másik lábon van, és igy új nyák kéne a próbadekóderhez.)
Mozdony dekóder lesz egyébként. De ha fel kell használnom az élfigyelős lábat, akkor már csak 2 kimenet marad, ezért lehet hogy váltani kell 16F684 -re. Az még elég pici (14 pin), és van benne valami 4 kimenetes pwm. Ez ha jól látom nem 4 független kitöltési tényezőjű pwm, hanem csak kiválaszthatom hogy a 4 kimenet közül melyik legyen ugye ? Mellékelem a C forrását az irq-s bemenőjel figyelősnek, hátha észreveszitek hogy mi benne a hiba. Egyelőre maradok a mintavevős módszernél, az működni látszik úgy hogy rá van csiptetve a sínre. Majd kérdés lesz hogy milyen lesz egy igazi mozdony áramszedőin keresztül menet közben.

Igen. Hozzáadom, de signed int! Tehát ha a differencia (-) annak a CV-vel osztott eredménye is negatív, így a hozzáadás kivonás lesz.

Azt kitaláltam, hogy előjeles, hiszen valahogy meg is kell állni.
Szóval begépeltem, kipróbáltam. Ahogy kell, exponenciálisan alakul a seb. alapjelem (viszonylag "hirtelen" indul és ahogy egyre közeledik a tényleges az új seb. parancshoz úgy egyre kisebb a gyorsulás (vagy lassulás). De sajnos ez így nem tetszik. Hiába nagy a cv érték, ha álló mozdonynál pl. max-ra tekerem a vezérlőt, látványosan nem egyforma a gyorsulás ami engem egy kicsit zavar.
Viszont lehet, hogy megvan a megoldás. Eddig nekem a CV3 CV4 azt határozta meg, hogy milyen időközönként lépjen 1 fokozatot a seb. alapjelem (CV3*1ms, a szabvány szerint CV3*0.896ms kéne de így egyszerűbb volt.). Ez így van most is csak most a legkisebb értéke 2 lehet. Aztán képződik még két új érték. Az egyik egy 15-ről lefelé számláló időzítő érték (első körben 15ms, következőben 14ms aztán 13ms és így 0-ig. Így látszólagos hiperbola? alapján indul a gyorsulás vagy lassulás). A másik érték pedig a seb. parancs és a tényl. seb. külömbségének negáltja szerint alakul (ha a külömbség nagyobb mint 32 akkor 0 lesz, ha pedig 0 akkor 32). Tehát CV3 vagy CV4 -hez hozzáadom e két érték közül a nagyobbat akkor szépen lekerekedik az alapjel eleje vége valahogy így:

A híd vezérlő pwm kimenetek bekötését megnézheted a lap tetején lévő fényképező ikonra kattintva, a fórum képei között. Igy megoldott a motor szabadonfutása és csöndesebb lesz mint az ESU. Ugyanúgy a CCPR1L-be írod a kitöltési tényezőt, a P1M1 bittel tudsz irányt váltani.
Az port változás int. ugye 1 perióduson belül kétszer fog jönni. Nem ismerem a C-t de lehet, hogy ez időben már nem fér bele az int. rutinba.

Hát igen, ha külön tudjuk vezérelni a H híd ki-be kapcsolását, úgy könyebb megvalósítani a PWM et. Mint pl az L293 -ban, az "enable". A mostani teszt áramkörömben sajnos ez nincs kihasználva, valamelyik tápra midig húzva van a motor mindkét fele.
Így iránytváltani csak úgy tudok, hogy a motor egyik kivezetését megfordítom, és így emiatt a pwm kitöltését is invertálni kell. Viszont így elég csak 2 portláb a motor felé. (a pwm mindig ugyanazt a motor kivezetést szaggatja)

Az interruptba bele kell férnie, mert itt ugye max 58us -enként jöhet irq. Most meg ennél sűrűbben veszek mintát. Sikerült beszuszakolni a megszakításokat 8Mhz es belső osc biztosította időkeretbe. Még soft pwm is belefért. Igaz csak alacsony frekin, de kisérletezni most jó lesz ez. Majd még próbálkozom megérteni jobban a te módszeredet is, csak PIC18 asm -ben nem vagyok otthon, a 16 osat jobban megértem. Köszi az eddigi segítséget. Bár már én is ott tartanék, hogy hogyan finomítsam a sebesség átmeneteket Egyelőre a szerviz móddal folytatom.

Haladgattam a dekóderrel, már tudok CV-ket is írni olvasni. Viszont bit detektálásra lett egy újabb ötletem. Mivel a mintavevős nem tetszik annyira, ezért visszatértem a portváltós irq-sra. (illetve nem vagyok biztos benne hogy új ötlet, lehet hogy csak most értettem meg tudat alatt dzsolt leirását)

Szóval a portbemeneten csak az alacsony szintet veszem figyelembe a 0 vagy 1 bit kitalálásában. Mégpedig azért, mivel ha mérés közben kontakthiba adódik, akkor az alacsony szintnél nem okoz hibát, hiszen 0V nem esik lejebb, az 0 marad.

A dekódolást úgy kezdem el, hogy induláskor megvárok egy szoros loopban egy 0-1-0 váltást. És az 1-0 váltásnál indítom a számlálást.

Ha pedig túl rövid ideig lenne a dcc bemenet alacsonyan, akkor sem dobom el az eredményt, hanem megvárom a következő eseményt, addig számolok tovább.

A timer számlálót meg csak akkor nullázom, ha legalább 20us óta magas volt a portláb, és utána esett le 0 ra. Igy a magas félbit idejében bekövetkező kontakt hibák is szűrve vannak.

Remélem nem túl zavaros a leirásom, és megértitek.

Most láttam a parancs központod videóját. A látottak alapján inkább nekünk kellene kérdeznünk téged tényleg jó lett gratula.
Csak, hogy megzavarjalak , mi van akkor ha fordítva teszed fel a mozdonyt vagy egyszerűen fordítva kötöd be a síntápot? ugye akkor fordul a "fázis".

Köszi a dícséretet! Dekódert csinálni azért nagyobb kihívás.

Igen, fordul a fázis, de akkor is az alacsony szintet méri. Tehát nem zavarja hogy a bit melyik fele jött előbb. Most próbálgatom, de akárhogy csiptetem a sínre, működik ez.

Bár az egyik irányba feltéve mintha egy egész picit be-be villanna néha a hibás packetet jelző led mikor ki-be kapcsolom a lámpát. Ez még nem tudom mi lehet.

Jaa! Leesett, ötletes egyszerű, vedd úgy nem szóltam.

Fárasztanálak még egy picit a marhaságaimmal

Irányváltás nálad hogy van megoldva ? Mert most beüzemeltem a hardveres pwm-et. A 12F683 -nál be lehet állítani a pwm generátort, hogy a kimenete active high / vagy low legyen. Így már csak a motor másik lábát kell átkapcsolnom, és már meg is van az irányváltás. Nem kell a kitöltést kiszámolnom visszafelé úgy mintha szoftveres pwm lenne. Csak egy apró probléma akadt: az egyik irányban az 1. fokozat 0.16V, a másikban pedig csak 0.02V. Minimum sebességnek 4 van beállítva, maxnak pedig 247. Utána ha lépkedek feljebb, akkor szépen növekszik egyenletesen már. De az egyik irányban 12.16, a másikban pedig csak 12.11V a legnagyobb fokozatban. Ezt lehet hogy a H híd vezérlő okozza ? L293 jelen esetben.

Nem... PID vezérlő, de minimum PI hiánya.
Motor sebessége abszolút nem arányos a kitöltési tényezővel... a feszültséggel viszont igen.

Őő, itt nincs PID, csak simán egy kitöltési tényezőt állítok be. Még motor sincs, csak egy 12V 5W izzó van rákötve terhelésnek a motormeghajtóra. Mellékelem a kapcs rajzot, a "motor" az M1 - M2 közé van kötve. L1, L2 -re pedig a ledek.