SCX digital

Idea vaikuttaa kiinnostavalta ja tuommoinen kuuden auton skabaaminen 2 kaistaisella radalla kuullostaa pienelläkin mielikuvituksella hauskalta.

Onkos kellään mitään muuta tietoa aiheesta, kuin mitä SCX:n sivuilla on muutamalla lauseella kerrottu?

Järjestelmä olisi tosi helppo rakentaa itsekin vaikkapa microchipin PIC prossuilla. Itsellä kävi mielessä semmoinen, jossa kummallakin radalla on vakio käyttöjännite (vaikka 12V) ja sitten kisaajien ohjaimet olis kytketty yhden picin AD tuloihin, jonka sarjaliikenne pärisee sitten samoilla kiskoilla 12V:n päällä. Joka autossa olisi myös picit, jotka sitten toimivat säätiminä.

Täytyy alkaa vähän paperille rustaamaan. Alkoi tuntumaan siltä, että jos tuota SCX:n järjestelmää saa jonkin adapterihässäkän jälkeen kytkettyä sport rataan, niin silloinkin se saattaa maksaa maltaita...

Silloin tällöin on tullut tilausta kotona neljänkin auton yhteiskisaan, mutta nelikaistainen rata ei tule kysymykseenkään, kun pitää mahtua olohuoneeseen ja useimmiten on vielä purettava samana iltana
Samalla tuo useampi auto samalla radalla voisi tuoda uusia elementtejä kisaamiseen...

Niin ja kotikisoissa autojen virittäminen saisi hieman älyllisempiä muotoja, kun "talli" voisi prommata oman korjauskäyränsä virransäädölle, niin että se vastaisi kuskin mieltymyksiä kiihdytyksissä ja jarrutuksissa...

Tervehdys!

Olen itsekkin pohtinut tuota monen auton yhtäaikaisen ajon mahdollistavaa elektroniikkaa. Päädyin juurikin samanlaiseen alkuratkaisuun kuin tekstissäsi kuvasit. PIC on halpa ja pieni, mahtuu hyvin auton sisään. Samalla olisi mahdollista elektronisesti antaa jokaiselle autolle omat käyttäytymisparametrit. Kontrollerille voisi antaa tehtäväksi myös ajo- ja jarruvalojen ohjauksen.

Mutta nyt meni liian lennokkaaksi. Jonkin verran huolestuttaa kaistanvaihdon mahdollistava mekaniikka. Tietenkin jos SCX tekee valmiita paloja, niin ostaa sitten SCX:n kaistanvaihtopalat. Onko keskustelupalstalla kaistanvaihtomekaniikkaan perehtyneitä? Olisi ratkaistava miten auto kertoo kaistanvaihtopalalle halustaan vaihtaa kaistaa. Onko auton pohjassa esim. LED joka sytytetään haluttaessa kaistanvaihtoa. Rata näkee valon auton pohjassa ja laittaa kaistanvaihdon päälle. Tietenkin voi tehdä niin kuin pienoisrautateissä. Kuski kertoo suoraan ratapalalle milloin haluaa toiselle kaistalle.

Jos meinaat aloittaa systeemin suunnittelemisen olen kiinnostunut osallistumaan projektiin. Suunnittelen työkseni elektroniikkaa ja pystyn tekemään laitteeseen protolevyt ammattimaisilla työkaluilla. Jos näyttää toimivalta niin voidaan tilata teolliset piirilevyt. PICcejä olen käyttänyt työssäni 10 vuotta ja niiden assembler on tullut tutuksi. Kaikille asiaa tuntemattomille: PIC on Microchipin valmistama mikrokontrolleri eli prosessori jossa on sisäinen ohjelma- ja RAM-muisti. Itsenäinen tietokone.

Tämä projekti olisi mielenkiintoista toteuttaa, katsotaan nyt lähtisikö se lentoon.

T: Julius Wilkko julius.wilkko@finscan.fi

Näyttää siltä että aika paljon saisi valmiiksi suunniteltua kamaa ja softaa.

Laittakaa vaikka googleen hakusanoiksi: "dcc probst"

lordjw kirjoitti: Näyttää siltä että aika paljon saisi valmiiksi suunniteltua kamaa ja softaa.

Laittakaa vaikka googleen hakusanoiksi: "dcc probst"

Minä voisin tässä kirjoitella alustavat ohjelmat picceihin ja voitas yhdessä katsella ohjelmia ja elektroniikkaa, sitten kun käyn ne autot hakemassa.

Täytyy käydä myös toi google läpi. Ideahan sinällään on erittäin simppeli ja ajattelin että kannattaisi pitää toteutuskin niin simppelinä kuin mahdollista. Suurin haaste on tosiaan kaistanvaihto, mutta täytyy tutustua eri tapoihin viestiä kaistanvaihtoratapalan kanssa. (tuolla googlessa voi olla jo valmiita ideoita). Itsellä kävi mielessä kuparilenkki, jossa vaihtojännite (siis radan alle sijoitettuna), sit kun auto haluaa vaihtaa kaistaa, niin onko autolla mahdollisuuksia vaikuttaa radassa olevan kuparilenkin virtaan mitenkään niin, että siitä saisi true/false ilmaisimen? (siis vaikka tätä valmista piiriä "väärinkäyttämällä") www.semiconductors.philips.com/pip/NE5521.html

Elektroniikkapuolella pitäisi sitten löytää mahdollisimman simppeli jännite ohjattu virtalähde autoon (FET saturaatiossa ja Vgs:llä ohjaus?)
Ja auroon tietenkin mahd. yksinkertainen erotus 12V käyttikselle ja sen päällä olevalle sarjadatalle. Siinäkin on useita vaihtoehtoja, mutta yksinkertaisin olisi varmaan nerokkain.
Autoon kaavailin PIC16F676:ää ja ohjainpäähän taas 16F870.

Ekaksi voitas ihmetellä ilman kaistanvaihtoa, niin että löytyisi mahdollisimman toimiva konfiguraatio ja sitten on helpompi lisäillä ohjelmalooppien sisään tuo kaistanvaihtotoimintokin. Täältä löytyy kuvia tuosta SCX:n kaistanvaihtosysteemistä. www.slotcarillustrated.com/Featu ... 2003.shtml

T:Sami

Tervehdys!

Olen jälleen samaa mieltä, ensin pitäisi saada autot toimimaan samalla radalla ja sen jälkeen voi ihmetellä kaistanvaihtoa. Toivottavasti rakenteen voi pitää yksinkertaisena. Sähkömoottori on kauhea häiriögeneraattori ja yllätyksiä voi tulla. Täytyy ruveta skoopin kanssa tutkimaan ja testailemaan.

Sinulla oli varmaan hyvä syy juuri noiden PICcien valintaan. Ainoa toiveeni on että autossa olevassa picissä tulisi olla e2 muistia johon voi ohjelmoida auton konfiguraation (lähinnä numeron).

Dataprotokollasta pitää tosiaan tehdä hahmotelma. Yksinkertainen ja tehokas. Päätettävä: kuinka monta autoa (8?), montako nopeutta riittää (8?), ohjauskomennot auton konfigurointiin.

Pistetään mietintämyssy hommiin.

lordjw kirjoitti: Tervehdys!

Olen jälleen samaa mieltä, ensin pitäisi saada autot toimimaan samalla radalla ja sen jälkeen voi ihmetellä kaistanvaihtoa. Toivottavasti rakenteen voi pitää yksinkertaisena. Sähkömoottori on kauhea häiriögeneraattori ja yllätyksiä voi tulla. Täytyy ruveta skoopin kanssa tutkimaan ja testailemaan.

Sinulla oli varmaan hyvä syy juuri noiden PICcien valintaan. Ainoa toiveeni on että autossa olevassa picissä tulisi olla e2 muistia johon voi ohjelmoida auton konfiguraation (lähinnä numeron).

Dataprotokollasta pitää tosiaan tehdä hahmotelma. Yksinkertainen ja tehokas. Päätettävä: kuinka monta autoa (8?), montako nopeutta riittää (8?), ohjauskomennot auton konfigurointiin.

Pistetään mietintämyssy hommiin.

Joo, kyllä autoissa täytyy olla ohjelmoitavaa muistia. (tulevaisuuden haaveita: eräänlainen aikaintegraattori kaasun asennosta, jolloin ns. bensan loppuminen vois olla mahdollista, kun tietty arvo saavutetaan)

Mutta noi pic:it heitin vaan hatusta, ja meinasin illalla mplabissa pyöritellä ohjelmia ja pohtia, että mitkä pic:it olisi sopivimmat.

dataprotokolla:

Ajattelin alustavasti kahta 8 bittistä sanaa per looppi. Toinen sana kuvaisi pelkästään kaasun asentoa ja toisesta 3 bittiä olisi auton tunniste ja loput sitten nappeja tms. Yhdessä loopissa siis aina yhden auton kaasun ja nappien asento. Looppeja ajetaan niin lujaa, että kaikki autot on käyty läpi riittävän nopeasti. Loopit on tietysti sitten isomman loopin sisällä.
Sitten aina pienen loopin päätteeksi nostettaisiin toinen ulostulo ykköseksi, joka olisi radassa taas seuraavasti. Sarjadata kulkee assynkroonisesti kiskoissa ja autojen picit lukee sitä siirtorekisterimeiningillä. Sitten tuo toinen ulostulo picistä kytketään rataan päin vastoin, eli tavallaan nostaa datasignaalin maan ykköseksi aina sanojen välissä. Tämä signaali siis vastaanottavan picin toiseen inputtiin, joka kertoo auton picin ohjelmalle, että sana loppui ja uutta odotettavissa. (täytyy kehittää yksinkertainen kytkentä, jolla saa tuon maan noston näkymään eri inputissa, kuin varsinaisen dataliikenteen.)

Ehdottomasti protokolla olisi parempi, jos sen pystyisi järjestämään täysin synkassa, eli radalla kulkisi myös kellopulssi, mutta tuleeko mieleen systeemiä, jolla tän saisi helposti järkättyä? Kellopulssinhan saisi ehkä vielä ratsastamaan muunneltuna näiden muiden signaalien päällä, mutta onko helppoa (ja pientä) kytkentää mielessä, jolla tän saisi toteutettua?
Tosin jos tuon haastavuuden saisi ratkottua, niin lopullinen työ olisi helpompaa. Itseasiassa jo täytyy tarkistella mahdollisuuksia käyttää jotain digitaalista modulaatiomenetelmää (PCM, GFSK ym). Oikeastaan meidänhän täytyy suoraan ryhtyä käyttämään järkevää menetelmää datan siirtämiseen kiskoja pitkin.

Mutta näin saisi kaasulle 256 arvoa ja vähän ylimääräisiä bittejä mahdollisia tulevaisuuden tarpeita varten (eikös hyvänä tapana ole suunnitellessa jättää vähän väljää tulevaa varten:) )


Eikös tuossa olisi hyvä dataprotokolla?
Elektroniikassa pientä haastetta, muttei mitään mahdotonta.

Eiköhän siirytä nyt puhelin ja e-mail viestintään, niin ei tukita tätä foorumia näillä jutuilla...

Kyllä täällä foorumissa tilaa riittää kaikille autorata-aiheisille jutuille pituudesta riippumatta. Tiedä vaikka saatte muitakin innokkaita mukaan ideoimaan tuota systeemia.

Joku sähköpostilista olisi toinen juttu. Jengi voisi kypsyä. Täällähän kukin voi valita mitä itse tykkää lukea.

terv. mode

Tervehdys!

Niin, kyllähän projektia kannattaa tälläkin foorumilla vetää - jos vaikka saisi hyviä kommentteja ja ehdotuksia.

Ehdotankin että tämän digitaalisen ohjausprojektin nimeksi voisi antaa: CarDCC. Pienoisrautatiemaailma on jo luonut perusteet digitaaliseen ohjaukseen omalla DCC (Digital Command Control) järjestelmällään. Siitä tullaan lainaamaan lähinnä elektroniikkaan liittyviä komponentteja.

Puhuimme Samin kanssa tovin puhelimessa ja esiin nousi huoli autolle lähetettävän datan luotettavuudesta ja synkronoinnista. Seuraava ehdotus kypsyi pääkopassa:

Paketit lähtevät tietenkin radalle peräkkäin
11111Auton1data111111Auton2data111111Auton3data1111111....

Autolle lähetetään uusi paketti ainoastaan jos kaasun asento muuttuu.

Datapakettiin voisi sisällyttää kellon mukaan seuraavasti:
....1111111101DA01DB01DC01DD01DE01DF01DG01DH........11111111...

01=Kello DA-X=Databitit
Eli jokaiselle databitille on oma kellopulssi. Tällä tavalla auton kontrolleri pysyy aina tahdissa ja pystyy paremmin selviämään virhetilanteista. Haittapuolena siirto hidastuu, täytyy testata mihin maksiminopeuteen tehotransistorit pystyvät.

Oikeat ajajat voisivat kommentoida tähän kuinka nopea vasteajan, eli sen ajan kuinka nopeasti auto reagoi kaasuun tulisi olla. Tietenkin välittömästi, mutta tässä systeemissä viivettä tulisi pahimmillaan ehkä olemaan n. 0,1 sekuntia kaasun muutoksen ja auton reagoimisen välillä. Kommentteja?

Itse datassa haluttiin olevan 16bittiä esimerkiksi:
3bittiä auton osoitteelle
1bitti, kaasu maksimissaan (nopeuttaa liikennettä)
8(7?)bittiä nopeus (jos kaasun asento ei ole max)
2bittiä auton valojen ohjaus
2(3?)bittiä auton ohjelmointikomennot tai muuhun käyttöön

Ehdotuksia/kommentteja otetaan vastaan.

T: Julius Wilkko

Mielenkiintoinen aihe ja keskustelu. Tässä olisi yksi bittinikkari käytettävissä projektiin.

Mielestäni sarjaliikennedata autoille kannattaa lähettää peräkkäin (auto1,auto2,....), kuten olitte päätyneet. Tämä on ehkä ohjelmoinnin ja luotettavuuden kannalta paras vaihtoehto, yksinkertaisin.
Bittijaossa kannattaa jättää muutama varalle kaistanvaihto -ohjausta varten. Äkkiseltään luulisi kahden bitin riittävän tarkoitukseen. Se onko kaistavaihto käsky sama kaikilla autoilla, tuottaa ongelman. Kaikki ohjaavat kaistanvaihtoa ja kaveri voi sinut ohjata halutessa "väärälle" kaistalle. Tämän pohtiminen kannattaa jättää myöhemmälle, kypsytellä vain ajatuksia. Kunhan ensin selvittää autojen ohjaukset ja vastaavat kysymykset.

Tervehdys!

Ohjelmointivoimaa arvostetaan aina. Jos nyt Samin kanssa saadaan edes peruskonsepti toimimaan niin silloin löytyy kysyntää lisäohjelmoinnille. Mahdollisuudet ovat uskomattomat esim PC puolella. Digitaalinen ohjausjärjestelmä on sähköisesti erittäin helppo liittää PC:hen.

Komponentit on tilattu, toivottavasti saan ensimmäiset protot kasaan ensi viikon aikana. Teen yksinkertaiset: lähetin, boosteri ja auton dekooderi. Nämä ovat niitä rautatiepuolen termejä.

Vaikkei nyt elektroniikkaa tai ohjelmointia kovin paljon osaisikaan niin kannattaa heittää ideoita siitä minkälainen järjestelmä voisi olla. Esim autossa oleva muistipiiri mahdollistaa vaikka auton tyypin ja moottorin tyypin tallentamisen auton muistiin. Kuljettajakohtaisen koodin kirjoittaminen auton muistiin on myös mahdollista. Antakaa ideoita!

T: Julius

Tuli nyt eilen illalla mietittyä asiaa vähän useammalta kantilta ja tuli seuraavia johtopäätöksiä mieleen.

-Datalinkki ohjainaseman ja auton välillä pitäisi olla erittäin robusti.
-Datalinkin pitää olla kaksisuuntainen. (tekee kierroslaskurin mahdolliseksi)
-Datalinkin täytyy olla erittäin nopea ja protokollan itsessään olla älykäs, niin ettei lähetellä turhia viestejä.

Oma kokemukseni on enemmän RF puolelta, kuin ohjelmistopuolelta, mutta ohjelmathan on periaatteessa simppeleitä ja tuo datalinkki on haastavampi. Vaikuttaa siltä, että hyvä ratkaisu monien joukosta on löytymässä ja meneekin vielä hetki, kun tarkastelen kahta hyvää vaihtoehtoa niin, että toisen voi sulkea pois.

Erillaisista modulaatiomenetelmistä on halpoja ratkaisuja tarjolla (FSK, ASK jne..) ja ne tarjoaa paljon mahdollisuuksia ja nopeutta tiedonsiirtoon.

Tällä hetkellä parhaimmalta näyttää tämä:

www.microchip.com/download/lit/p ... 41159c.pdf

www.microchip.com/download/appno ... 00713a.pdf

Mutta mietin vielä muutamaa muutakin vaihtoehtoa ja kattelen sitten, että mikä on paras tähän tarkoitukseen.

Eli käytettäisiin CAN lähiverkkoa autojen ja ohjainaseman välillä.
Helpoin tapa olisi homma tehdä suoraan langattomasti ja onkin olemassa pic, jossa on integroitu FSK lähetin ja vieläpä tehovahvistin, mutta jätetään se vielä tulevaisuuteen. (ehkä ohjain > ohjainasema linkki voisi myöhemmin olla langaton)

Nyt kun tätä ryhtyy sitten oikeasti suunnittelemaan, niin voisi yrittää pitää komponenttien hinnat kurissa, jos joskus tulisi mieleen tarjota valmiiksi räätälöityä pakettia jollekkin autoratavalmistajalle... kuka tietää..

Niin... kävi mullakin mielessä tuo ratkaisun valmistajille tarjoaminen. Siinä taidetaan vain olla jälkijunassa. SCX/Scalella ja Carreralla on jo tarjolla omansa. No Scalella ei, mutta ne voi varmaankin kopioida SCX:n laitteen. Ainoastaan NINCO ei ole esitellyt mitään mutta pakko niiden on seurata perässä.

Jos SCX ja Carrera Digital hinnat nousevat koviksi niin silloin on tilaus riippumattomalle järjestelmälle ja tähän ehkä ennemminkin kannattaisi tähdätä. Ja jotta laitteelle riittäisi kehittäjiä ja kysyntää kannattaisi rakenne pitää jonkin verran avoimena.

T: Julius

Päädyin tuohon CAN protokollaan:

-Se on erittäin häiriösietoinen (8:n auton sekoilu radalla)
-Siinä on valmiit rutiinit, joissa on ratkaistu meidän tähän astiset ongelmat
-100 muuta hyvää syytä
-Nopea ja mukautuva
-Nerokas

Nyt on edessä muutama viikko luovaa työskentelyä protokollan parissa ja muu ideointi voikin ihan hyvin pyöriä siinä rinnalla.

Ranskalaisilla viivoilla protokollan tarjoamat mahdollisuudet, joille voi alkaa ideoimaan:

-Riittävästi bittejä (8 bittiä kaasulle, ja mitä muuta ikinä tarvitaankin, auton ID:tä ei tarvita, koska viesteillä on aina oma tunniste numero)
-Eikä tarvitse pohtia niinkään framen rakennetta tulevaisuuden kannalta. Järjestelmään voi myöhemmin keksiä uudenlaisia kujeita ja niille kujeille annetaan vain oma uusi viestinumero, eikä tarttee pohtia, että mahtuuko tulevat jutut meidän nykyiseen frameen.
-Kaksi suuntainen liikenne: Autossa anturi, joka havaitsee radan alla olevan ilmiön (oli se nyt sitten vaikka magneetti ja hall anturi). Auto lähettää viestin, että tuli ajettua tämmöisen yli ja ohjausasema merkkaa kyseiselle autolle yhden ajetun kierroksen.
-Kaistan vaihtohomma on vielä avoin, mutta tää protokolla antaa mahdollisuuden tehdä autossa ehtolauseen kaistanvaihtonapille tyyliin: ollaanko kaistanvaihto alueella? (kyllä=lähetä viesti "kaistanvaihto", Ei= älä tee mitään)
Kannattaa myös muistaa, että kaikki mahdolliset laitteet voi huoletta kytkeä protokollaan. Eli rataankin voi sijoitella älykkäitä elementtejä, kuitenkin niin, että tärkeimmät toiminnot on pienimmällä viestin tunnisteosalla. Ehkä ohjainasema olisi pienin ja sitten autojen kierroslaskurin yliajamis/kaistanvaihtoviestit viestit 2-8 tunnisteella. Loppujen prioriteetillä ei varmaan ole suurtakaan merkitystä.

Aloitin jo työstämään tätä ja tarkoituksena on tehdä tää hyvin ja huolella, niin on sitten tukeva alusta, minkä päälle rakentaa muut systeemit. Tän protokollan käyttö helpottaa myös loppukäyttäjien elämää ja omien laitteiden lisäämistä järjestelmään.

Lueskelin myös noi rautatie aiheiset googlet ja siellä moni oli myös haaveillut CAN protokollasta.

Tässä vielä suomenkielellä yleiskuvaus CAN verkosta, niin saatte mielikuvituksen jylläämään:

www.machina.hut.fi/kurssit/41/01 ... Alanen.pdf

Julius ja muut, ketkä sitten on halukkaita ohjelmoimaan, lukekaa microchipin dokumentit aiheesta.

t:Sami

Tervehdys!

Luin läpi nopeasti CAN perusteet ja mielenkiintoiseltahan se näyttää. Olen vain huolestunut tuosta tehonsyötöstä. CAN verkko on viesteille pyhitetty parikaapeli ja siinä on ainostaan normaalit kaapelidriverit. Autoradassa käytössä on kyllä kaksi kaapelia (johdetta), mutta samoilla kaapeleilla pitäisi lähettää myös jopa 10A virtaa. Ajoneuvo CAN verkoissa on neljä piuhaa. 2 sähkölle ja 2 CANille. Yksisuuntainen tiedonsiirto, ohjain->auto ei ole mikään ongelma. Auton vastaaminen luotettavasti johteen kautta keskusasemalle on jo vähän haastavampi homma.

Olen tietysti vaikutuksille altis ja mukana jos CANista todellakin on jotakin lisäarvoa. Ensimmäinen mielikuvani on kuitenkin että CAN on turhan hieno näin yksinkertaiseen tehtävään. Jos esim autolle halutaan kertoa että laita kaasu täysille, voisi sen kertoa viidellä bitillä:
start-osoiteb2-osoiteb1-osoiteb0-kaasutäysibitti
Tämä on käsky joka liikkuu radalla 90% ajasta.

CAN protokollassa standardiprotokollan pituus on vähintään 47bittiä + stuff-bitit.

Ymmärrän hyvin että pienoisrautatiemaailma haikailee CANin perään koska radalla on kaikennäköisiä semaforeja, valoja, vaihteita, opasteita, yms. joita täytyy ohjata keskitetysti. Se onkin siellä periaatteessa helppo toteuttaa - vetää vain CAN johdotuksen ja erilliset sähköt oheislaitteille. Tässä voikin ottaa oppia pienoisrautatiemaailmasta ja kysyä miksi CAN ei ole siellä yleistynyt? Onko se sittenkin turhan monimutkainen harrastajille?

Mutta kuten sanoin, CAN on mielenkiintoinen ja jos näyttää siltä että tekniset ratkaisut löytyvät CANin toteuttamiseen niin olen kiinnostunut. Näin alustavasti mielestäni parempi olisi yksinkertainen sovittu protokolla joka on tavallisen harrastajan helppo toteuttaa.

Katsotaan mihin päin homma etenee, hyviä ideoita!

t: Julius