HI,
Ik zat al een tijdje op iets te broeden en heb er dan maar werk van gemaakt. Ik wou m'n wagons uitrusten met een functie decoder zodat ik de verlichting kon schakelen wanneer ik dat wil en ook wanneer er geen loc met de wagon verbonden is. Maar aangezien ik een 20-tal wagons heb voor personenvervoer, zou dat met de standaard decoders (ESU, Tams, Tran, ...) een redelijk dure grap worden. Dus waarom eens niet zelf proberen? Ik heb al decoders zelf gemaakt voor m'n servo-wissels en de m'n baan verlichting, dus zal dat voor een wagon ook wel lukken.
Op dit ogenblik is het de bedoeling is dat elke wagon afzonderlijk aangestuurd kan worden; dus elke wagon krijgt een sleper en een decoder.
De schakeling is gebouwd rond een PIC12F683, deze is met z'n interne klok van 4MHz meer dan krachtig genoeg om het DCC signaal te decoder (of een ander protocol). Om geen problemen te krijgen met de stroom over de I/O pinnetjes van de µC, worden 2 uitgangen versterkt via MOSFETs tot max. 350mA per kanaal. 2 uitgangen zou voldoende moeten zijn voor één wagon, maar dit kan worden uitgebreid tot 5 indien nodig.
De voeding is gebouwd rond een zener diode om de schakeling zo compact mogelijk te houden. Zonder ingeschakelde verbruikers zou deze schakeling maximaal 5mA verbruiken.
Hieronder het schema:
(http://i1236.photobucket.com/albums/ff460/Sattrickske/ModelRailroad/functie-decoder_zps3a1e886d.png)
Als ik werk met SMD componenten zou het dubbelzijdig printje 20mm x 12mm moeten worden, en dit past zonder problemen in de meeste wagons:
(http://i1236.photobucket.com/albums/ff460/Sattrickske/ModelRailroad/functie-decoder-pcb_zps8ccf4b5a.png)
Met m'n SMD rework station zou ik dit printje zonder al te veel problemen moeten kunnen solderen. De print zelf wordt op een CNC uitgefreesd, etsen zal niet lukken vrees ik.
De software kan rechtstreeks op de print via een programmer worden opgeladen (ICSP functie van de PIC). Een deel van de software heb ik al, dat is nagenoeg dezelfde als voor m'n wissel decoders, zie hier (http://forum.modelspoormagazine.be/index.php/topic,14127.msg206525.html#msg206525).
Op dit ogenblik bedragen de kosten voor deze decoder net geen 1.40€. Het duurste onderdeel is de µC, 0.60€; maar het allerduurste deel zullen wel de werkuren zijn ;)
Graag jullie mening...
Ik mis nog iets op het schema, hoe leest de PIC het digitaal signaal? Het kan zijn dat ik er over heb gekeken?
Geert
Citaat van: Geert op 04 mei 2013, 11:14:11 AM
Ik mis nog iets op het schema, hoe leest de PIC het digitaal signaal? Het kan zijn dat ik er over heb gekeken?
Verdikke ja zeg, rats vergeten... net op tijd, want was de G-code voor de prints aan 't genereren.
Djeezes, duidelijk nog niet goed wakker. Merci hé!
Geen dank,
op dit forum zijn we er om te helpen...
Geert
Zo ik heb het aangepast in de originele post, nogmaals merci hé!
Ik heb het digitaal signaal rechtstreeks via een weerstandje (33K) aan de I/O pin gehangen. Door de interne clipping diodes en de pull-up van de I/O poort denk ik niet dat ik een voltage divider nodig heb. Normaal werk ik met een optocoupler voor het digitaal signaal, maar deze zou hier teveel plaats in beslag nemen.
33k , zelfs 100k of meer is voldoende voor een µC om het digitale signaal te lezen.
Geert
Zo de eerste printjes zijn gefreesd.
De µC zijde:
(http://i1236.photobucket.com/albums/ff460/Sattrickske/ModelRailroad/EOS5DMarkIII-101-0172_zps41766573.jpg)
En de onderkant (voeding):
(http://i1236.photobucket.com/albums/ff460/Sattrickske/ModelRailroad/EOS5DMarkIII-101-0173_zps7f932148.jpg)
Maar nu is het jammer genoeg een 3-tal weken wachten :'(. 2 componenten heb ik in China moeten bestellen omdat ze hier veel te duur waren: de PIC12F683 en de 2N7002PS dual MOSFETs.
Dat ziet er fraai uit Patrick!
Ik ga toch nog even zagen over de koppeling tussen de wagons en de stroom voorziening.
Als je alle wagons van een sleper voorziet, zou je dan niet te veel rolweerstand introduceren?
Ik heb ook een tijdje met het idee rond gelopen, maar dan met de volgende logica/techniek aan boord van iedere wagon:
Alle wagons hebben een met minimaal 3 contacten uitgevoerde stroomvoerende koppelingen
Een gemeenschappelijke 0, een voeding en een sluitlantaarnsensor
Als er geen wagon aan de "achterste" koppeling wordt gehangen zal op de laatste het sensorcontact van de koppeling open zijn.
Dat moet dan voor de decoder het signaal zijn, bij ingeschakelde verlichting, de sluitverlichting aan de kant van de open koppeling te ontsteken.
Wordt er een wagon achteraangesloten dan gaat het sensorcontact naar 0 en dooft de sluitlantaarn op de voorlaatste
Doordat de laatste wagon gevoed wordt en een open sensor contact heeft gaat de sluitlantaarn aan op de laatste aan.
De binnen verlichting kan gewoon via een functieuitgang worden geschakeld.
Het is erg luxe maar ook erg wel mooi denk ik.
grt Piet.
Heb ik ook al zitten bedenken, en gedeeltelijk afgevoerd...
Mijn baan is niet zo groot, dus zijn m'n slepen beperkt; voor personenwagons zal dit beperkt zijn tot maximum 4. Ik heb al een test gedaan met 3 wagons met een originele Marklin sleper -niet echt de beste qua rolweerstand- en m'n BR50 met hoogvermogen aandrijving merkte er niks van. Wat er wel is -en het heeft enigzins met de rolweerstand te maken- is dat er bij hoge snelheid redelijk wat extra geluid van de slepers komt; dus daar heb je een zeker een punt. Aangezien ik met vooral stomers rijd, ligt de snelheid niet zo hoog, dus dat vervelend geluid is redelijk beperkt, maar het is er...
Jouw idee is bijlange na zo slecht nog niet. Het is inderdaad luxe, maar als je kijkt naar de prijs van de decoder, is het luxe die niet al te veel zal kosten. Maar wel luxe die, zoals je al zegt, supermooi zal ogen. Probleem zal bij de prijs van de stroomvoerende koppelingen liggen; een 3-polige ken ik niet, maar wel 4-polige. Maar die dingen zijn toch niet zo goedkoop: 14€ per paar. Voordeel van de vierpolige is wel dat je dan geen richting meer zal hebben aan een wagon, met een 3-polige zal je steeds een achterkant en een voorkant hebben.
Dus samengevat, jij gebruikt de stroom van de locomotief; ofwel één wagon met een sleper. De stroom wordt doorgegeven met meer-polige stroomvoerende koppelingen aan elke wagon, de decoder op elke wagon heeft dan één (of twee, als we richtingonafhankelijk gaan werken) pinnetje op dat als input gaat fungeren. Dat extra pinnetje gebruiken we dan om te kijken of er nog een wagon achter hangt, en zo sturen we de sluitlichten.
Op m'n huidige prints worden de sluitlichten rechtstreeks door een functieuitgang gestuurd, in jouw geval vol automatisch. Maar ik heb meteen een bijkomend vraagje, vanaf welk jaar ongeveer werden die sluitlichten gebruikt? Ik rij in het tijdperk I-III, en na wat opzoekwerk vind ik niks terug over sluitlichten voor 1970. Klopt dat?
Citaat van: Sattrickske op 04 mei 2013, 19:44:20 PM
Op m'n huidige prints worden de sluitlichten rechtstreeks door een functieuitgang gestuurd, in jouw geval vol automatisch.
Is niets mis mee, maar om nou met een stam van 4-5 wagons te gaan rijden en dan op alle wagons brandende sluitlichten vind ik weer "overkill" vandaar mijn idee.
Citaat van: Sattrickske op 04 mei 2013, 19:44:20 PM
Maar ik heb meteen een bijkomend vraagje, vanaf welk jaar ongeveer werden die sluitlichten gebruikt? Ik rij in het tijdperk I-III, en na wat opzoekwerk vind ik niks terug over sluitlichten voor 1970. Klopt dat?
Ik rijd tijdperk III t/m V Nederlands en NS reed voor de tweede wereldoorlog al met petroleumlampen als sluitlantaarn.
Hoe dat bij de NMBS is weet ik niet.
grt Piet.
Okidoki, ik zal een variantje maken dat voor beiden bruikbaar is...
'k Zal effe m'n schema aanpassen
Joh Patrick!
Dat is werkelijk meesterlijk, hoewel ik nog met mijn baan aan het bouwen ben, er is dus wat mij betreft absoluut geen haast bij, vind ik jouw flexibiliteit grandioos.
Schiet me nog wat te binnen, voor de mensen die onder iedere wagon een sleper hangen, die kunnen dan de sluitlichten aan/uit ook regelen met een reedswitch of hallsensor en een magneetje op de volgende wagon.
Wat vind je daar van?
grt Piet.
Citaat van: bossie op 04 mei 2013, 21:30:41 PM
Schiet me nog wat te binnen, voor de mensen die onder iedere wagon een sleper hangen, die kunnen dan de sluitlichten aan/uit ook regelen met een reedswitch of hallsensor en een magneetje op de volgende wagon.
Zou inderdaad kunnen en dat maakt mijn schakeling eenvoudiger, maar je hebt er wel meer plaats in de wagon voor nodig en je moet manueel een switch of magneetje verzetten. Dus hier verkies ik dan toch de 4-polige koppeling met de licht aangepaste versie van m'n schakeling.
Maar ik kom effe terug op je stam van 4 à 5 wagons. M'n printje is zo goedkoop (<2€), dat je er beter eentje in elke wagon stopt. Je geeft dan enkel het commando voor de sluitlichten aan de laatste wagon. Zo had ik m'n eerste versie voorzien, elke wagon krijgt een digitaal adres; waar de stroom vandaan komt, maakt niet uit (sleper of koppeling).
Maar ok, ieder z'n keuze, voor mij is de eerste versie meer dan goed genoeg. Maar voor diegenen die liever Bossie's (Piet) verbeterde versie hebben, hier volgt het schema daarvoor:
(http://i1236.photobucket.com/albums/ff460/Sattrickske/ModelRailroad/functie-decoder-v2_zps660c81f8.png)
Ten opzichte van de eerste versie is de massa (GND) beschikbaar gemaakt en is er een input (Coach Det) via een pull-up weerstand aangebracht. De pull-up kan eventueel weggelaten worden en vervangen door de interne pull-up van de PIC (let wel, deze is zeer zwak). Als er interesse komt voor deze versie, zal ik oor een PCB'tje voor voorzien (zal een 2-tal mm breder worden dan versie 1). De GND is naar buiten gebracht omdat nu elke wagon de input pin (Coach Det) van z'n voorganger aan de GND moet zetten; de wagon waarvan de input pin niet aan GND hangt wordt als sluit wagon beschouwd.
Als je nou de 'Coach Det' dmv een reedswitch of hall sensor die op de koppeling ligt laat schakelen door een magneetje dat op de koppeling van de volgende wagon zit, dan moet het toch ook werken?
En mijn wagons De NS ICK hebben voldoende ruimte om deze subminiatuur decoder te plaatsen.
Ik zie het al helemaal voor me:
Op mijn station staat een E-lok met daar achter twee wagons, keurig verlicht en even verderop komt een rangeerlok met een soortgelijke wagon aan tuffen.
Op het moment dat de achterste wagon gekoppeld wordt gaat de sluitlantaarn van de tweede wagon uit en springt de wagonverlichting aan en het sluitlicht is ook ineens functioneel.
Lijkt me het summum van functionaliteit.
grt Piet.
Inderdaad, hoe die 'Coach Det' aan de GND geraakt doet er niet toe, maar van zodra ie aan de GND hangt, zal de software decoder de sluitlichten uitschakelen.
Alle manieren zijn goed:
- reedswitch
- hall sensor
- GND lus over koppeling
- ...
Citaat van: Sattrickske op 04 mei 2013, 11:02:06 AM
HI,
Ik zat al een tijdje op iets te broeden en heb er dan maar werk van gemaakt. Ik wou m'n wagons uitrusten met een functie decoder zodat ik de verlichting kon schakelen wanneer ik dat wil en ook wanneer er geen loc met de wagon verbonden is.
Fantastisch dat je aan zo'n projekt wil beginnen!Ik heb respect voor u omdat je dit zelf wil verwezelijken.
Maar ik moet toch de vraag stellen waarom zelf een decoder willen bouwen als er binnenverlichting bestaat met al een decoder ingebouwd(KUEHN)
Dat het goedkoper zou zijn staat als een paal boven water maar de tijd die je erin steekt om ze te bouwen die is niet echt meetbaar en in niet in geld te omschrijven.
Maar toch "hoedje af" omdat je aan zoiets wil beginnen. Succes!
Voor sommige onder ons is elektronica gewoon een deel van onze hobby, en in onze hobby steken we allemaal veel tijd in ;)
Bij dit ontwerp is de elektronica mee op de print geplaatst waar de SMD LED's op staan. Het is wel voor MM protocol.
http://www.elektor.nl/artikelen-als-pdf/2009/februari/modelrijtuig-verlichtingsdecoder.811018.lynkx?tab=1
Geert
Citaat van: janieburton op 05 mei 2013, 02:18:58 AM
Maar ik moet toch de vraag stellen waarom zelf een decoder willen bouwen als er binnenverlichting bestaat met al een decoder ingebouwd(KUEHN)
Deze decoder (Kuehn LH10) had ik inderdaad ook gezien; hij is iets moeilijker te verkrijgen wegens te onbekend bij het grote publiek. Kostprijs ong. 17€. Hij heeft jammer genoeg één groot nadeel: de leds staan te ver uit mekaar. Ik heb een serie wagons van de Compagnie Internationale des Wagon-Lits waarvan het interieur in compartimenten is afgewerkt; het gevolg met zulk een led strip is dat sommige compartimenten slecht of helemaal niet verlicht worden.
Dus ben ik begonnen met zelf m'n led strips te maken (gebaseerd op die 5m strips met 300 of 600 leds) en een vaste voeding:
(http://i1236.photobucket.com/albums/ff460/Sattrickske/ModelRailroad/EOS5DMarkIII-101-0079_zpsa05f62f4.jpg)
(http://i1236.photobucket.com/albums/ff460/Sattrickske/ModelRailroad/EOS5DMarkIII-101-0079_zpsa05f62f4.jpg)
Deze schakeling heeft een groot nadeel: de verlichting van de wagon gaat aan van zodra er spanning op de baan staat. Dus heb ik effe andere oplossingen gezocht, en zo is deze decoder ontstaan. En als anderen er iets aan hebben of 'm willen verbeteren -zoals Piet-, nog beter.
Hij is ontstaan onder het moto: wat je zelf doet, doe je (meestal) beter. Bovendien het is en blijft een hobby; bij mij hoeft niet alles op korte tijd klaar te zijn.
Citaat van: Geert op 05 mei 2013, 09:53:44 AM
Voor sommige onder ons is elektronica gewoon een deel van onze hobby, en in onze hobby steken we allemaal veel tijd in ;)
Jouw reactie kwam er toen ik de mijne aan het typen was, maar je slaat de nagel op de kop...
Citaat van: Geert op 05 mei 2013, 09:53:44 AM
Bij dit ontwerp is de elektronica mee op de print geplaatst waar de SMD LED's op staan. Het is wel voor MM protocol.
http://www.elektor.nl/artikelen-als-pdf/2009/februari/modelrijtuig-verlichtingsdecoder.811018.lynkx?tab=1
De mijne is nagenoeg dezelfde, maar bewust niet mee op de leds strip gezet (dak is soms te smal voor de buffer condensator, tantaal of elco). En weerom, leds staan te ver uit mekaar. Ook de 7805 lust ik niet zo, dat ding wordt heet (20V - 5V) * verbruikte stroom = warmte. Bij mij kan je zelf je protocol kiezen, als je maar zelf de software ervoor schrijft ;D. Ik gebruik DCC omdat m'n andere zelfgemaakte decoders ook DCC zijn, dat scheelt wat software ontwikkeling.
Om een digitaal signaal gelijk te richten heb je geen zware buffer condensator nodig. Een lage (en snelle) waarde C is wel nodig om de overgang van + naar - (en andersom) de ontstoren. Je moet ook rekening houden met de totale capaciteit van de 'buffer' condensators op heel je baan als deze onder spanning komt! Het zal niet de eerste keer zijn dat de digitale voeding het dan begeeft onder de grote oplaadstroom...
Als je de schakeling goed ontwerpt, dan zal de 7805 niet te veel warmte ontwikkelen. Deze dient enkel om de µC te voeden. En deze verbruikt 'o' zo weinig stroom ;)
Geert
Citaat van: Geert op 05 mei 2013, 12:34:30 PM
Om een digitaal signaal gelijk te richten heb je geen zware buffer condensator nodig.
Niet helemaal correct. Klopt als je baan proper is en de spanning nooit effe onderbroken wordt door vuiligheid. Mijn reiniging wagons zien er altijd lief uit na een ritje 'proper maken'; zelfs in het schaduw station dat zo goed als hermetisch afgesloten is. De buffer is wel nodig om te vermijden dat je decoder opnieuw opstart wanneer de spanning effe zou wegvallen. Maar een tantaal condesator van 10uF is niet zo groot en overbrugt de meeste storingen.
Citaat van: Geert op 05 mei 2013, 12:34:30 PM
Als je de schakeling goed ontwerpt, dan zal de 7805 niet te veel warmte ontwikkelen. Deze dient enkel om de µC te voeden. En deze verbruikt 'o' zo weinig stroom ;)
Geef mij maar een zener + feed weerstand, veel kleiner en ik bepaal zelf hoeveel stroom er mag verbruikt worden. Ik vermijd 7805 zoveel ik kan want voor grote spanningsveschillen is dat ding heel inefficiënt. Ik ben ze systematisch aan het vervangen door LM2596 (tot 92% efficiency) voor grote stroomverbruikers (µC + servos) en zeners (constante stroom) voor schakelingen met enkel µC. De efficiency van een 7805 bedraagt voor 20V amper 25%. Boosters zijn duur, dus kan je beter besparen op je stroomverbruik (voor wagon verlichting kan je bijna niet anders dan de stroom van je rails te halen).
Maar ik volg je redenering: voor 1 decoder maakt het niet uit. Maar bereken eens opnieuw wanneer je er zo'n 30 gaat installeren... ;)
Daar heb je ook weer gelijk in, de decoders die ik tot hier toe gemaakt heb takten het digitale signaal niet af via de sporen, maar rechtstreeks van de booster. Je ziet maar we blijven bijleren ...
Geert
Citaat van: Geert op 05 mei 2013, 13:34:43 PM
Je ziet maar we blijven bijleren ...
En ik ben op dit ogenblik van jouw projecten aan 't bijleren. Da's pure klasse, zo'n mooie documentatie!
Ik ben effe je s88 met µC aan 't doornemen; stevig projectje! Ik heb er een 10-tal gebouwd met gewone shift registers, jouw versie met µC steekt een beetje mijn ogen uit; knap werk!
Eerste onderdelen zijn vandaag binnengekomen met de post. Op de rest wordt het jammer genoeg nog een tweetal weken wachten. 80% van de versie 1 decoder (zonder input voor wagon detectie) is nu reeds gesoldeerd.
De komende dagen ga ik mij bezighouden met m'n software eens op orde te stellen, da's dringend nodig en 't zal helpen om de software voor dit gedrocht in mekaar te boksen.
topics als deze zijn een feest voor mijn ogen en mijn (wat er van over is ) brein... Dat jullie dit allemaal voor mekaar krijgen, echt respect en "chapeau". Ik ben al blij als ik iets simpels met een mosfetje, een torretje of een paar ledjes in elkaar kan steken op een gaatjesprint.
Die freesmachine van Patrick, daar ben ik dus mega jaloers op ! Ooit...... en dan nog een 3D printer ook, dan is 't helemaal kompleet :-)
De freesmachine helpt gewoon bij het miniaturiseren. Het belangrijkste is het ontwerp, als dat goed is kan er niet veel meer misgaan. Je hebt natuurlijk wel de beperking van de technologie en de beschikbare ruimte; dus ja, de freesmachine was voor mij een enorme stap vooruit. Want vroeger was het bij mij ook gaatjesprint en iets later etsen, maar zo leer je al enorm veel.
Maar gelukkig zijn er hier op het forum heel alerte mensen (thx Geert ;-), want ik was bijna zwaar in de mist gegaan en zelfs dan helpt zelfs de beste frees niet...
Ik maak enorm veel printjes, niet alleen voor de modelbaan; dus de frees was een goede investering. Na een dik jaar was de kostprijs er al uitgehaald. Bovendien kan ik er ook 'gewone' dingen mee frezen, maar daar heb ik er nog niet teveel mee gedaan.
Zoals eerder gezegd, effe wachten op nog wat componentjes (MOSFET chips) uit China en dan is het printje klaar. Maar ondertussen doen we toch verder met hetgeen we al hebben en passen we de software wat aan. M'n oorspronkelijke software voor m'n wissel- en accessory-decoders werkt perfect, maar de code mag eens wat opgekuist worden zodat deze universeel inzetbaar zal worden.
De PIC12F683 zit al vast op de print en daar kan al mee geëxperimenteerd worden. Enkel was de print te klein om een volwaardige connector voor de programmer aan te sluiten. Dus hebben we het opgelost via de voorziene soldeereilandjes en een stukgesneden connector:
(http://i1236.photobucket.com/albums/ff460/Sattrickske/ModelRailroad/EOS5DMarkIII-101-0174_zpse6d5f414.jpg)
De programmer reageert correct en herkent de chip, dus we kunnen verder met de software.
toch fijn als je werk resultaat oplevert, hee Patrick !
Jij bent goed bezig, man. respect !
Citaat van: Sattrickske op 04 mei 2013, 11:02:06 AM
Op dit ogenblik bedragen de kosten voor deze decoder net geen 1.40€. Het duurste onderdeel is de µC, 0.60€; maar het allerduurste deel zullen wel de werkuren zijn ;)
Graag jullie mening...
Toch nog een vraagje, waar bestel je ergens de door jou gebruikte µC aan 0,6€? Voor deze µC is dat niet zo veel. Ik weet ook wel dat je per 100 besteld ;), maar toch...
Geert
Citaat van: Geert op 09 mei 2013, 22:22:18 PM
Toch nog een vraagje, waar bestel je ergens de door jou gebruikte µC aan 0,6€?
AliExpress:
http://www.aliexpress.com/item/PIC12F683-SOP8-8-Pin-Flash-Based-PIC12F683-I-SN-8-Bit-CMOS-Microcontrollers-with-nanoWatt-Technology/846182483.html (http://www.aliexpress.com/item/PIC12F683-SOP8-8-Pin-Flash-Based-PIC12F683-I-SN-8-Bit-CMOS-Microcontrollers-with-nanoWatt-Technology/846182483.html)
Kan wel zijn dat er 10€ taks bijkomt als het pakje door de post onderschept wordt (bedrag is groter dan 22€ en dan riskeer je 10€ taks). Meestal geraakt ie er zonder taks door, maar soms heb ik 't aan mijne rekker. In geval van invoertaks kom ik op 0.56€, zonder 0.46€.
Maar ja, wat is tegenwoordig .60€? De eerste µC waarmee ik 20 jaar geleden werkte waren van Motorola: MC68HC11; die dingen kostten indertijd 20€ :o. 'k Ben nu al een paar jaar met PIC bezig (voornamelijk 12F683, 16F628 en 18F4550), die dingen kosten bijna niets, zijn zeer krachtig en verbruiken weinig stroom.
Bedankt voor de info,
20 jaar geleden nog met Thomsom µC bezig geweest. Die koste toen per stuk 800Bfr, ik heb (had) er veel van liggen maar vorig jaar allemaal weggegooid. Sinds 3 jaar blijf ik bij de PIC's
Geert
Citaat van: Sattrickske op 09 mei 2013, 22:50:43 PM
'k Ben nu al een paar jaar met PIC bezig (voornamelijk 12F683, 16F628 en 18F4550),
Ik zie dat je al eens met PIC's uit de 18 reeks gewerkt heb. Voor mijn huidig project een zelfbouw digitale centrale kom ik wat rekenkracht te kort. Ik denk er aan om de 32 reeks aan te schaffen. Heb jij daar al ervaring mee?
Geert
Citaat van: Geert op 11 mei 2013, 10:46:06 AM
Ik zie dat je al eens met PIC's uit de 18 reeks gewerkt heb. Voor mijn huidig project een zelfbouw digitale centrale kom ik wat rekenkracht te kort. Ik denk er aan om de 32 reeks aan te schaffen. Heb jij daar al ervaring mee?
Toch al wat ja. Ik gebruik een 18F4550 voor de selfmade heated build platform van m'n 3D printer aan te sturen. Enkel m'n PicPro programmer doet 't niet met deze reeks (nog niet uitgezocht waarom). M'n development board kan wel deze reeks zonder problemen programmeren. Ik gebruik niet echt de 'rekenpower' van dat beestje, ik had veel I/O nodig (keyboard, LCD, USB, temp. sensoren, relais aansturing, ...).
Ben helemaal niet stilgevallen, ben gewoon aan 't wachten op nog een paar componentjes uit China (diodes en condensatoren). Ondertussen was ik bezig om m'n wagons van stroom te voorzien, maar ben op een probleempje gebotst: m'n fosfor brons is op. Ik heb een leverancier in Duitsland (duurt altijd een week voor m'n bestelling aan huis geleverd wordt), maar is er niks dichterbij zodat ik snel verder kan? Weet iemand een leverancier ergens in België? Ik zoek platen van 0.1mm.
De laatste componentjes zijn deze week gearriveerd dus decoder kon verder afgewerkt worden. Was niet simpel, dit is de kleinste print die ik ooit gemaakt heb (12x21mm) met een microcontroller, een voeding en een MOSFET versterker.
De voeding zijde (met gelijkrichter, zener-stabilisatie en condensatoren):
(http://i1236.photobucket.com/albums/ff460/Sattrickske/ModelRailroad/EOS5DMarkIII-101-0593_zpsa538e610.jpg)
De controller zijde (met PIC, dual MOSFET):
(http://i1236.photobucket.com/albums/ff460/Sattrickske/ModelRailroad/EOS5DMarkIII-101-0594_zpsa85a5b3a.jpg)
Ik nu 2 van (on-)dingen klaar, er staat een voorlopige test-software op die het DCC protocol verstaat. De software moet nog worden aangepast en geoptimaliseerd, maar da's voor ergens volgende week.
Hoe maak je de verbinding tussen top en bottom layer?
Knap werk. ;)
Ik heb deze week 12F683 PIC's besteld voor een gelijkaardig project. Het is de bedoeling dat deze een mfx lok mee leest als deze zich aanmeld bij de centrale. Het teruggemelde adres zal de PIC opslagen in zijn EEPROM om zo sluitlichten en binnenverlichtingen te schakelen.
De code in ASM heb ik al geprogrammeerd, nu nog wachten op de µC...
Geert
Terwijl ik aan 't wachten was op m'n componentjes was ik aan 't nadenken over een ander probleem. De decodertjes zijn bedoeld voor wagons; maar dan moet je natuurlijk stroom in je wagons krijgen. Stroomvoerende koppelingen gebruik ik liever niet omdat ze bij mij niet zo goed werken als er wagons aangekoppeld moeten worden (er is serieus wat druk nodig voor de koppeling vastklikt). Dus wou ik de wagons uitrusten met massa pickup en slepers (3-rail).
Voor de meeste modellen (Märklin) gaat dat heel eenvoudig, de wagons zijn hierop voorzien, een setje kopen, vastklikken en klaar is kees. Maar ik heb een hele serie wagons van Liliput (Compagnie Internationale des Wagons-Lits) die m'n Orient Express gaan vormen. En dat zijn rot-wagons om er stroom in te krijgen:
(http://i1236.photobucket.com/albums/ff460/Sattrickske/ModelRailroad/EOS5DMarkIII-101-0586_zps4efb7db1.jpg)
Een domme zelftappende schroef houdt het wielstel op z'n plaats en zit lelijk in de weg.
Na testen en prutsen, tot de volgende oplossing gekomen met een adaptertje (met de hulp van de 3D-printer, maar had ook perfect met wat stukjes styreen gekund):
(http://i1236.photobucket.com/albums/ff460/Sattrickske/ModelRailroad/EOS5DMarkIII-101-0587_zpsa90c1395.jpg)
En met fosforbrons een paar wheel-pickups gemaakt:
(http://i1236.photobucket.com/albums/ff460/Sattrickske/ModelRailroad/EOS5DMarkIII-101-0588_zps3688abf6.jpg)
Een standaard sleper van Märklin 7164 aan gepast (2 extra gaatjes geboord voor M1.6) en de wheel-pickup tegen m'n adaptertje gekleefd met secondenlijm:
(http://i1236.photobucket.com/albums/ff460/Sattrickske/ModelRailroad/EOS5DMarkIII-101-0589_zpsf120ad61.jpg)
En tadaaa, stroom in m'n Liliput wagons. Opgelet het heeft wel één nadeel: de wagon wordt een beetje afgeremd door de wheel-pickups. Dit kan bij mij geen kwaad omdat ik geen rangeerheuvel gebruik. Dit nadeel kan snel worden weggewerkt door de massa aan het andere wielstel af te tappen en de pickup dan tegen de wiel assen te laten slepen, geeft minder wrijving. Maar ik had geen zin om draden door gans m'n wagon te gaan trekken, dus heb ik het op mijn manier opgelost.
Later ga ik wel het interieur van deze wagons serieus moeten bijwerken, want Liliput heeft hier iets heel idioots gedaan: het gans interieur is GEEL :o. Geen flauw idee waar dat goed voor is, maar het trekt in ieder geval op niks, laat staan op de Orient Express...
Citaat van: conducteur op 08 juni 2013, 22:37:54 PM
Hoe maak je de verbinding tussen top en bottom layer?
Ik heb maar 3 verbindingen tussen top en bottom, dus gewoon een stukje draad (wire-wrap draad) aan beide kanten solderen.
Citaat van: Geert op 08 juni 2013, 22:48:21 PM
Knap werk. ;)
Ik heb deze week 12F683 PIC's besteld voor een gelijkaardig project. Het is de bedoeling dat deze een mfx lok mee leest als deze zich aanmeld bij de centrale. Het teruggemelde adres zal de PIC opslagen in zijn EEPROM om zo sluitlichten en binnenverlichtingen te schakelen.
De code in ASM heb ik al geprogrammeerd, nu nog wachten op de µC...
Geert
Thanks!
Welke 12F683 heb je nodig? Ik heb er nu genoeg op voorraad (>100) liggen (wel allemaal SMD). Als je wil mag je er een paar komen halen om je te depanneren...
Ziet er mij anders ook wel een leuk projectje uit.
Aan MSD ben ik nog niet aan toe. Ik werk nog steeds met gaatjesprinten. Ik heb ze besteld in DIL, maar zeer prijzig :( , toch bedankt voor je aanbod. Wie weet in de toekomst...
Geert
Wou vandaag proberen om de vernieuwde (C) code in de functie decoder te uploaden. Maar 't gaat mis...
Ik heb een paar optimalisaties in de code ingebouwd, zodat deze herbruikbaar is voor de andere projecten. De DCC decodering werkt perfect. De PWM heb ik uitgeschakeld omdat hiervoor te weinig processor tijd overschiet. Maar bij de aansturing van de uitgangen loopt 't mis.
Ik heb geprobeerd om de gebruikte poorten als initiële pointers te definiëren. Zo hoef je maar op één plaats je configuratie van je schakeling mee te geven en de software trekt verder z'n plan. Maar 't werkt niet, m'n pointers zitten verkeerd na de declaratie:
#define MAX_OUTPUTS 4
typedef struct {
volatile unsigned char * outputPort;
unsigned char outputBit;
} output;
const output outputs[MAX_OUTPUTS] = {
&PORTA, 1<<0,
&PORTA, 1<<1,
&PORTA, 1<<2,
&PORTA, 1<<3
};
PORTA zit op adres 0x005, als ik met de debugger ga kijken na de initialisatie zie ik voor de 4 outputPort constanten 3 verschillende waarden (0x3405, 0x3402, 0x3405, 0x3FFF), de outputBits zijn ook allemaal verkeerd. Als ik de data bekijk, lijkt het erop of alles 1 of meer bytes verschoven is.
Het boeltje is gecompileerd met de HI-TECH C compiler.
Iemand een idee?
Je hebt het blijkbaar in C geschreven, met de C van Chinees...
Hoe en waar is PORTA gedefinieerd?
Je wil dus de waarden 1, 2, 4 en 8 in outputBit krijgen?
Geert
Citaat van: MickeyMouse op 16 juni 2013, 18:40:48 PM
Hoe en waar is PORTA gedefinieerd?
Je wil dus de waarden 1, 2, 4 en 8 in outputBit krijgen?
PORTA zit in de header van de PIC
// Register: PORTA
volatile unsigned char PORTA @ 0x005;
Ik wil vermijden dat er verder in m'n code referenties naar die PORTA zitten. En ja, de waarden voor de outputBit zijn de bitmasks voor de betreffende pinnetjes; 'k ga later trouwens 'outputBit' vervangen door 'bitmask'.
Schrijf je met &PORTA niet het adres van de variabele PORTA in de struct ipv de waarde 5?
Geert
Citaat van: MickeyMouse op 16 juni 2013, 20:07:43 PM
Schrijf je met &PORTA niet het adres van de variabele PORTA in de struct ipv de waarde 5?
Klopt, en da's ook de bedoeling want als ik wat verder m'n outputs aanspreek doe ik het als volgt:
Bitje setten:
*outputs[portOffset].outputPort |= outputs[portOffset].outputBit;Bitje clearen:
*outputs[portOffset].outputPort &= ~outputs[portOffset].outputBit;Waarbij portOffset de aangesproken output is.
Kleine correctie: PORTA is geen variable, maar een definitie die verwijst naar het adres 0x005.
volatile unsigned char PORTA @ 0x005;
--> PORTA is dan toch een char ergens in het geheugen? of betekent die '@ 0x005' dat die op adres 5 gemapt wordt?
Ik ken de C-notatie '@' niet...
Geert
Citaat van: MickeyMouse op 16 juni 2013, 20:16:45 PM
volatile unsigned char PORTA @ 0x005;
--> PORTA is dan toch een char ergens in het geheugen? of betekent die '@ 0x005' dat die op adres 5 gemapt wordt?
Ik ken de C-notatie '@' niet...
Is inderdaad een mapping op adres 0x005. PORTA is een register en zit zo gedefineerd in de header. Het '@' teken is iets specifiek voor HI-TECH C compiler waarmee je rechtstreeks naar een adres verwijst, denk ik. Ik heb het vroeger ook nooit tegengekomen.
Citaat van: Sattrickske op 16 juni 2013, 20:25:54 PM
Citaat van: MickeyMouse op 16 juni 2013, 20:16:45 PM
volatile unsigned char PORTA @ 0x005;
--> PORTA is dan toch een char ergens in het geheugen? of betekent die '@ 0x005' dat die op adres 5 gemapt wordt?
Ik ken de C-notatie '@' niet...
Is inderdaad een mapping op adres 0x005. PORTA is een register en zit zo gedefineerd in de header. Het '@' teken is iets specifiek voor HI-TECH C compiler waarmee je rechtstreeks naar een adres verwijst, denk ik. Ik heb het vroeger ook nooit tegengekomen.
OK, vreesde er al voor... Vroeger deed ik dergelijke dingen altijd met een #define
Ik zie nu ook niet meteen het probleem...
Geert
Toch bedankt voor het mee zoeken.
Op zich is het nog geen ramp, als er geen oplossing uit de bus komt, worden de PORTx rechtstreeks in de software gebruikt en punt uit. Mooie code is altijd leuk, maar als 't echt niet lukt, gaan we er met de grove borstel door. Jammer dan voor diegenen die m'n code willen herbruiken, ze zullen her en der de poorten moeten aanpassen.
Ik zoek nog effe verder, maar als ik 't tegen morgenavond niet gevonden heb, zal het de grove borstel worden ;)
OK, success!!
Mocht er mij nog iets te binnen schieten laat ik het nog weten...
Geert
OK nu mag ik toch effe vloeken tegen de sterren op! Wat een ongelofelijke oen ben ik toch!
Bovenstaande code werkt perfect! Maar deze idioot heeft om te testen de PORTA van de PIC16F877A op de development kit genomen, deze poort is ook gekoppeld aan een A/D converter die default aan staat. Dus elke waarde die ik probeerde te lezen was verkeerd door de ADC. En bovendien was ik met de debugger nog eens de verkeerde waarden aan 't lezen (values ipv adressen). Hoe dom kan je zijn? :-X
Maar soit 't is opgelost geraakt, da's 't voornaamste. 't Waren Geert z'n gerichte vragen die me effe verder deden nadenken en bingo...
Morgen gaan we verder met de EEPROM routines zodat de decoder weet in welke toestand hij was als de stroom (even) wegvalt.
Allee, blij te horen dat alles in de sjakosh is!!
Tja, het C-programmeren is voor mij al een tijd geleden, uit mijn electronica verleden..., maar het had me wat gebeten omdat ik vroeger ook veel gebruik maakte van typedefs, #defines, ....
En...pointers, en het gebruik ervan zijn nu net de kracht van C om met weinig code veel gedaan te krijgen, toch eens je het goed door hebt.
Succes met het verdere programmeerwerk!!
Geert
Citaat van: Sattrickske op 16 juni 2013, 17:53:54 PM
De DCC decodering werkt perfect.
DCC decodering heb ik al eens met succes toegepast, maar nooit eerder op een signaal dat via de wielen-sleep overgebracht is naar de µC. Hoe decodeer je het DCC signaal eigenlijk. Via interrupts bij elke wijziging van het inputsignaal? Houw je rekening met slechte wiel-sleepcontacten? Dit wil ik wel eens graag weten...
Citeer
De PWM heb ik uitgeschakeld omdat hiervoor te weinig processor tijd overschiet.
Dit zit toch hardwarematig ingebakken in de 12F683?
Geert
Citaat van: Geert op 18 juni 2013, 21:39:30 PM
DCC decodering heb ik al eens met succes toegepast, maar nooit eerder op een signaal dat via de wielen-sleep overgebracht is naar de µC. Hoe decodeer je het DCC signaal eigenlijk. Via interrupts bij elke wijziging van het inputsignaal? Houw je rekening met slechte wiel-sleepcontacten? Dit wil ik wel eens graag weten...
DCC signaal decoderen is niet zo moeilijk, ik gebruik hiervoor 2 interrupts: één hardware interrupt op de GP2 pin (rising edge). Deze eerste interrupt start een timer die na exact 80µs een tweede interrupt genereert. Als bij de 2e interrupt de GP2 laag is, heb je een '1' bitje; als ie hoog is, heb je een '0' bitje. De spec van DCC zegt dat een '1' puls precies 58µs mag duren en een '0' puls 116µs. Ik ga dus ergens tussenin gaan 'meten' (bij 80µs) dus. Dan is het gewoon een kwestie van het DCC protocol correct te implementeren.
Wat de fouten door de wiel-sleepcontacten betreft, nog geen problemen mee gehad, om veschillende redenen:
1) Baan is redelijk proper
2) DCC protocol is hierop voorzien.
Voor het tweede zijn er 2 mechanismen. Eerst en vooral is er een checksum aanwezig (EXOR van alle ontvangen bytes moet nul zijn), zodat je steeds elk bericht kan verifiëren op juistheid. En ten tweede, de centrale zend hetzelfde bericht een aantal keren vlak na mekaar uit (m'n CSII toch). Dat laatste is iets lastiger omdat je in geval van geen enkel signaalverlies, de doorgestuurde commandos verschillende malen gaat herhalen. Dat vang ik op door het gecapteerde commando eerst naar een ringbuffer te sturen, waarvan de logica lichtjes aangepast is: je kan geen commando toevoegen aan de buffer als het identiek is aan het vorige element in de buffer.
Citaat van: Geert op 18 juni 2013, 21:39:30 PM
Citeer
De PWM heb ik uitgeschakeld omdat hiervoor te weinig processor tijd overschiet.
Dit zit toch hardwarematig ingebakken in de 12F683?
Verdoeme miljaarde nonde... 'k had de manual niet helemaal doorgelezen en had niet gedacht dat er in zo ne kleine pruts nog een PWM zou zitten. Maar je hebt gelijk! Alleen jammer dat ie maar op één poort zit, de GP2; net de poort waar m'n DCC signaal aanhangt ::). Dus in de volgende versie zou ik één uitgang PWM kunnen sturen en zo de leds dimmen indien nodig.
Zo goed als hetzelfde zoals ik dat doe ;) (zie ISR routine)
ASM code (http://users.telenet.be/RedDeBist/MBAAN/servosturingDCC_v3p1.asm)
Geert
Citaat van: Geert op 19 juni 2013, 07:12:11 AM
Zo goed als hetzelfde zoals ik dat doe ;) (zie ISR routine)
ASM code (http://users.telenet.be/RedDeBist/MBAAN/servosturingDCC_v3p1.asm)
Inderdaad, bijna zo goed als identiek; je houdt -net zoals ik- ook rekening met de 'verloren tijd' in de interrupt routine voor het 'laden' van je timer.
Ik zie dat je nog op zoek bent naar de programmeer modus van DCC... Da's heel simpel: preamble van 20 '1' bitjes ipv. 12, dan is het gegeven commando een programmeer commando.
damn, was al een poosje geleden dat ik nog iets tikte hier... maar het lijkt er op dat je er zo goed als aan uit bent ?
Ik ben benieuwd om het resultaat te zien werken . Lijkt me iets interessant voor andere dingen dan wagonnen ook.. bvb verlichting in huisjes aansturen via de centrale, servo'tjes besturen...
Deze is echt wel voor wagons bedoeld, omdat ie zo piepklein is (pakweg 20x10x5mm) en de uitgangen zijn maximaal 300mA per stuk. Voor huisjes,wissels, verlichting... heb ik een andere die groter is en meer (en krachtigere 2A) uitgangen heeft.
Omdat deze zo klein is, is 't lastiger om 'm te solderen (vooral dat dual MOSFETje is niet om te lachen); daarom raad ik 'm alleen maar aan voor wagons. De grotere (60x40x8mm als ik me niet vergis) is gemakkelijker te solderen en deze kan je wel ergens kwijt in je huisje of ergens onder je baan.
Maar ja, als je geduldig bent (en niet bang bent om je fikken te verbranden tijdens het solderen) kan je 'm voor eender wat gebruiken.
Was effekens stillekes hier, maar was met van alle andere zaken bezig en jammer genoeg niet veel tijd gehad om met modelbouw bezig te zijn... Maar heb nu toch de boel hier zo goed als mogelijk afgewerkt.
De decoders zijn bedoeld om eerst in m'n Orient Express wagons te stoppen (oude Liliput wagons). Telkens ik de voorbije week wat tijd had, was ik aan het schilderen, want dat lelijke interieur stak echt m'n ogen uit. 2 wagons zijn nu bijgekleurd:
(http://i1236.photobucket.com/albums/ff460/Sattrickske/ModelRailroad/EOS5DMarkIII-101-0709_zpsb00bdb1a.jpg)
En daar mochten dan meteen 2 uitvoerig geteste decoders en ledstrips in:
(http://i1236.photobucket.com/albums/ff460/Sattrickske/ModelRailroad/EOS5DMarkIII-101-0713_zpseb93266a.jpg)
En het uiteindelijke resultaat:
(http://i1236.photobucket.com/albums/ff460/Sattrickske/ModelRailroad/EOS5DMarkIII-101-0715_zps6489934e.jpg)
Beide wagons hebben proefrondjes gereden achter m'n Type 231, en dat blijkt allemaal perfect te werken. De buffercondensator voor de verlichting mocht misschien ietsje groter, deze is nu 2.2uF. Het is mogelijk om de tantaal van de print af te halen en met draadjes een klepperke van een elco aan te sluiten. Maar eens de sporen gereinigd waren, bleek het niet meer nodig te zijn, maar 't zou perfect kunnen; de enige beperking is de ruimte in de wagon.
Deze decoder draait nu met versie 1.5 van m'n software. Deze is iets verbeterd tegenover m'n vorige software dankzij m'n logic sniffer. Het inlezen van het DCC signaal vergt nu maar 1 interrupt meer ipv 2. Dit maakt de code veel efficiënter.
Er is wel nog een versie 2 van de software in de maak, waarbij het mogelijk wordt om via de centrale (CSII, Ecos, ...) de CV waarden van de decoder in te stellen (PWM dimmer voor de leds).
MOOI!!!!!!!
Ik zou het graag ook zelf kunnen maar mijn
Heb toch een vraagje: was in die tijd, toen de origineele OE reed niet het gebruikte kunstlicht meer naar de warme kant?
Citaat van: janieburton op 08 juli 2013, 01:00:18 AM
Heb toch een vraagje: was in die tijd, toen de origineele OE reed niet het gebruikte kunstlicht meer naar de warme kant?
Klopt inderdaad, goed gezien! Mijn doel jaar zou rond 1910 moeten liggen en dan was gebruikte licht veel warmer (lees meer geel of zelfs oranje).
De gebruikte leds zijn warm witte power leds van een 5-meter strip met 600 leds. Deze branden op dit ogenblik veel te krachtig. De PWM dimmer die ertussen moet komen werkt nog niet ('k moet de software ervoor nog schrijven), dus de leds branden op voorlopig 'volle' kracht. Volle kracht = gelijkgerichte baanspanning (levert ongeveer 20V), met een 470 ohm voorschakel weerstand voor de hele strip.
Uiteindelijk zou ik via de PWM meer naar 50% van dit vermogen gaan en dan wordt de lichttemperatuur ook veel warmer. Als het dan nog niet genoeg is, gaat er transparant geel/oranje verf over de individuele ledjes om de kleur nog warmer te maken.
Citaat van: Sattrickske op 08 juli 2013, 12:47:02 PM
Citaat van: janieburton op 08 juli 2013, 01:00:18 AM
Heb toch een vraagje: was in die tijd, toen de origineele OE reed niet het gebruikte kunstlicht meer naar de warme kant?
Klopt inderdaad, goed gezien! Mijn doel jaar zou rond 1910 moeten liggen en dan was gebruikte licht veel warmer (lees meer geel of zelfs oranje).
De gebruikte leds zijn warm witte power leds van een 5-meter strip met 600 leds. Deze branden op dit ogenblik veel te krachtig. De PWM dimmer die ertussen moet komen werkt nog niet ('k moet de software ervoor nog schrijven), dus de leds branden op voorlopig 'volle' kracht. Volle kracht = gelijkgerichte baanspanning (levert ongeveer 20V), met een 470 ohm voorschakel weerstand voor de hele strip.
Uiteindelijk zou ik via de PWM meer naar 50% van dit vermogen gaan en dan wordt de lichttemperatuur ook veel warmer. Als het dan nog niet genoeg is, gaat er transparant geel/oranje verf over de individuele ledjes om de kleur nog warmer te maken.
Zou het dan niet beter zijn om gele of oranje led's te gebruiken?
Gele of oranje leds om gloeilampen na te bootsen is niet goed. Te monotoon.
Warmwitte wel, of een oranje transparant over de leds.
In dit geval zou een transparant vel (bedrukt met de printer) een handige oplossing kunnen zijn.
Ik gebruik de Humbrol 1322 om helder witte led's te behandelen.
Dat is een clear orange verf die mist spaarzaam opgebracht van een helder witte een warm witte led maakt.
grt Piet.
Citaat van: bossie op 09 juli 2013, 11:48:18 AM
Ik gebruik de Humbrol 1322 om helder witte led's te behandelen.
Dat is een clear orange verf die mist spaarzaam opgebracht van een helder witte een warm witte led maakt.
Awel ik doe net hetzelfde zie. Soms gebruik ik transparante airbrush verf, ik heb ooit eens een kit verfjes gekregen om nagels te lakken. Maar zie je mij al met gelakte nagels rondlopen :o? Deze verf gaat goed om de kleuren van leds te veranderen.
Citaat van: Gerolf op 09 juli 2013, 10:56:43 AM
Gele of oranje leds om gloeilampen na te bootsen is niet goed. Te monotoon.
Warmwitte wel, of een oranje transparant over de leds.
In dit geval zou een transparant vel (bedrukt met de printer) een handige oplossing kunnen zijn.
Dat werkt inderdaad ook, heb het al een paar mensen zien doen, maar ik vind het meer gepruts. Een potteke transparente verf, een penseeltje en 't is gebakken... (allez geverfd ;))
Ik heb daar indertijd capton-tape voor gebruikt ( oranje en doorzichtig )
Zit daar nu reeds enkele jaren op en geen nevenwerking
te bezichtigen in mijn album in het bordeau tweetje ;)