Jeg har vært passiv bruker av forumet siden det ble opprettet.  Modeljernbane har jeg drevet med i 40 år.  Digitalforsøkene ble startet for ca 20 år siden.  Etter noe eksperimentering med selvbygde sentraler og to digitale N-Skala lok, endte jeg opp med to Roco H0 Startset med DB BR 80 lokomotiver( http://www.worldrailfans.info/Articles/Europe/GBR80.shtml" rel="nofollow - http://www.worldrailfans.info/Articles/Europe/GBR80.shtml ).  Noen ekstra skinner, og det ble en grei to spors rundbane anlegg med kryss og sidespor.  Noe senere ble også hovedanlegget klargjort for digital kjøring.  Lenz PC interface, og to nye ROCO startsett ble også innkjøpt.  Samtidig startet digitalisering av bl.a. Lima, Heljan og ROCO lok.  Som mange vet, støtter ikke de enkle ROCO sentralene programmeringsspor  -  kun programmering på hovedsporet, og ingen støtte for utlesing av konfigurasjonen (CV).

I 2007 begynte jeg å bygge moduler med FREMO grensesnitt.  Programmeringssporet er plassert på en av disse modulene   Denne modulen er en snumodul som står i den ene enden av anlegget.  Modulen følger ikke FREMO standarden på andre punkter enn grensesnittet.   Hele modulen, bortsett fra FREMO grensesnittet, benytter Trix skinner.

Hittil har programmeringen blitt gjort ved at et rele kopler fra resten av anlegget når jeg har behov for å programmere lokomotiver på programmeringssporet.  I denne bloggen vil jeg skrive om hva som skjer på og ved programmeringssporet, og hvilke tekniske løsninger jeg velger.  Jeg har også tenkt å ta dere med både langs hovedlinjen og inn på noen sidelinjer der også andre interessante løsninger benyttes.  I dette første innlegget kommer her et bilde av programmeringssporet med mitt første H0 digitallok : Roco DB BR 80 fra startsett .  På bildet er det også to midlertid plasserte krettskort : et Vellemann ( http://www.velleman.eu/" rel="nofollow - http://www.velleman.eu/ )  kort for optisk spordeteksjon, og også et Arduino kort  ( http://no.wikipedia.org/wiki/Arduino" rel="nofollow - http://no.wikipedia.org/wiki/Arduino ) som benyttes for blokkdetektering.  Vellemann kortet er koplet til PC serie port via en Optokopler.  Arduino kortet har USB.

Her er også et bilde av ferdig loddede kretskort som jeg skal teste ut på programmeringssporet, ( http://www.merg.org.uk/merg_resources/cbus-dcc.php" rel="nofollow - http://www.merg.org.uk/merg_resources/cbus-dcc.php ), og en Raspberry PI ( http://no.wikipedia.org/wiki/Raspberry_Pi" rel="nofollow - http://no.wikipedia.org/wiki/Raspberry_Pi ).

Neste blogginnlegg vil inneholde mere om disse kretskortene, og hvordan de er tenkt benyttet.

16. Desember 2013

Hyggelige og nyttige kommentarer på bloggen.  Siden det er mest spørsmål rundt Arduino, vil jeg fokusere på dette denne gangen.  Vil først nevne at jeg også har gjort noe eksprementering med Arduino og RFID.  Tanken min rundt dette er å ha lesere ved utkjøring fra stasjoner,  for å automatisk registrere togsammensetning.  For øyeblikket tror jeg ikke jeg går videre med dette, fodi det  trolig er enklere å løse dette i programvare ved at styringen har full oversikt over alle vogner til enhver tid, og å benytte optiske vogn eller akseltellere for å være sikker på hvor mange og derved hvilke vogner som er med i toget.  I fremtiden kan det vel også være aktuelt med DCC dekodere, med tilbakemelding  i alle vogner.

Først en oversikt over bruksområder for Arduino på en modeljernbane: (se også http://www.siliconvalleylines.com/downloads/ModelRailroadingWithArduino.pdf" rel="nofollow - http://www.siliconvalleylines.com/downloads/ModelRailroadingWithArduino.pdf )

Jeg utvikler / benytter Arduino på følgende områder :

·         DCC analysator 2 mikrosekunders oppløsning , kun positive eller negative pulser.  Realtime inn i database for senere analyse.   Jeg Kommer med mere  informasjon i et senere blogginnlegg.

·         Block Detector.  Strømdetektering, Se litt info lenger opp.  Kommer senere med mere info.

·         Ultralyd avstandsmåling – et 1 times prosjekt, se mere nedenfor i dette innlegget.

Planer – som kan implementeres med Arduino kort, Arduino prosessor eller med andre prosessorer (f.eks. Microchip PIC):

·         Amperemeter DCC og andre kilder

·         Spenningsmåler DCC

·         DCC programmerer

·         Relestyring

·         Ledstyring

·         LCD Display styring

·         Pulsmotorstyring ( http://modelrail.otenko.com/arduino/controlling-your-trains-with-an-arduino" rel="nofollow - http://modelrail.otenko.com/arduino/controlling-your-trains-with-an-arduino )

·         DCC decoder.

·         Servostyring.

Andre :

·         OpenLCB/NMRAnet Developer and Early Adopter Kit.  Eksperimentsett for NMRAnet / OpenLCB ( http://nmranet.org/" rel="nofollow - http://nmranet.org/ )

·         DCC Command Station ( http://www.oscale.net/en/simpledcc" rel="nofollow - http://www.oscale.net/en/simpledcc )

·         Rfid http://blog.arduino.cc/category/wireless/rfid/" rel="nofollow -  

Ultralyd avstandsmåling – Et  godt eksempel på hvor effektivt det er å utvikle enkle løsninger med Arduino.

Jeg var en tur hos Kjell og Company( http://www.kjell.com/" rel="nofollow - http://www.kjell.com/ ) i Sverige i helgen. De har i det siste fått et bedre utvalg av Arduino kort og tilbehør ( http://www.kjell.com/Sok?query=arduino" rel="nofollow - http://www.kjell.com/Sok?query=arduino ) .  Jeg kjøpte bl.a. en Ultralyd sender og mottager ( http://www.kjell.com/sortiment/el/elektronik/mikrokontroller/arduino/avstandssensor-p87891" rel="nofollow - http://www.kjell.com/sortiment/el/elektronik/mikrokontroller/arduino/avstandssensor-p87891 ) til SEK  49.90.  I dag brukte jeg en time på å teste denne ut.  Tanken er å sette den i enden av programmeringsporet, for å måle avstand til Lokomotivet, og bruke dette til å beregne hastigheten.  Målet er en helt automatisert beregning av dekoderens hastighetsparametre.  I løpet av en time i dag fikk jeg programmert Arduino kortet, koplet til sensor og gjort noen tester på arbeidsbenken.  Det ser ut til at deteksjon med avstand fra 4 – 20 cm fungerer bra.  Har testet med DB BR 215 Diesellok og DB BR 80 damplok, både forfra og bakfra.  Tror jeg skal få til lengre avstander med en mere nøyaktig/fastmontert plassering av sensoren.

Har også gjort en liten endring i  det medfølgende eksempelet for å få høyere oppløsning.  Her er status etter dagens arbeid.

/*

Tilkopling :

Sensor:                 Arduino:

VCC                        5 V

Trig                         Digital input 4

Echo                      Digital input 2

Gnd                       GND

*/

 int inputPin=2; //ECHO pin

 int outputPin=4; //TRIG pin

 void setup()

 {

   Serial.begin(9600);

   pinMode(inputPin, INPUT);

   pinMode(outputPin, OUTPUT);

 }

 void loop()

 {

   digitalWrite(outputPin, HIGH); //Trigger ultrasonic detection

   delayMicroseconds(10);

   digitalWrite(outputPin, LOW);

   float distance = pulseIn(inputPin, HIGH); //Read ultrasonic reflection

   distance=distance/58;

   Serial.println(distance); //Print distance 

   delay(100);

 }

Har også fullført MERG kortene. Og gjort den første utlesingen av CV’er fra et lokomotiv.  Mere om dette neste gang.

http://programmingtrack.no-ip.org/locodb/DB2151298.pdf" rel="nofollow - http://programmingtrack.no-ip.org/locodb/DB2151298.pdf

Interessant innlegg!

Du spør i starten om "hvorfor leker vi i det hele tatt." Hvis man er interessert i å fordype seg i dette kan jeg anbefale klassikeren på området, nederlenderen Johan Huizingas Homo Ludens fra 1938, som fortsatt gis ut i nye oversettelser og utgaver. En dansk oversettelse (Huizinga, J. (1963). Homo ludens: om kulturens oprindelse i leg.  København: Gyldendal) hvis man ikke vil/kan lese den i engelske eller tyske oversettelser, og kan sikkert fås tak i på et bedre bibliotek.

ses wrote: Interessant innlegg! Du spør i starten om "hvorfor leker vi i det hele tatt." Hvis man er interessert i å fordype seg i dette kan jeg anbefale klassikeren på området, nederlenderen Johan Huizingas Homo Ludens fra 1938, som fortsatt gis ut i nye oversettelser og utgaver. En dansk oversettelse (Huizinga, J. (1963). Homo ludens: om kulturens oprindelse i leg.  København: Gyldendal) hvis man ikke vil/kan lese den i engelske eller tyske oversettelser, og kan sikkert fås tak i på et bedre bibliotek.

1. Summer for Merg Sentralen
2. Merg DCC Sentral
3. to Serieport grensesnitt for MERG Cbus.
4. to Raspberry Pi
5. En Zotac mini PC (X86 basert CPU) som kan benyttes til bl.a. å kjøre Windows programvare.

Kan rapportere om fremgang på to områder :  programvare og maskinvare.

På maskinvaresiden, har jeg valgt å benytte en Arduino Uno for kontroll av programmeringssporet.  Den skal :

1.       Styre rele for kopling mellom kjørestrøm og programmeringsstrøm.

2.       Sporbelegg deteksjon, 4 blokker , med detektering på begge skinnestrenger.

3.       To , eller flere optiske detektorer.

4.       Ultralyd avstands / hastighetsmåling.

Jeg gjør også noen forsøk med lydmåling, for å se om jeg kan måle støyforskjeller  med forskjellige dekoderinstillinger.

En Arduino Uno, har 13 Digitale inn/ut porter og 6 analoge innganger.  To av de digitale portene går til seiekommunikasjon, slik at det kun er 11 ledige.  Jeg trenger flere.  Jeg har derfor valgt å teste ut en I2C basert I/O Expander.  Microchip MCP 230008 ( http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en021393" rel="nofollow - http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en021393 )har jeg liggende, og de kan skaffes fra flere leverandører.  Priser fra ca. USD 1 – NOK 30.  Jeg har aldri brukt disse så en prøveoppstilling ble laget.

Adafruit har et Arduino bibliotek for MCP230008 og et eksempelprogram ( https://github.com/adafruit/Adafruit-MCP23008-library" rel="nofollow - https://github.com/adafruit/Adafruit-MCP23008-library ) .  Det fungerte på første forsøk.  Nå er det bare litt lodding som står igjen for å få blokkdetektoren til å fungere.

Programvare tar ofte litt lengre tid enn planlagt.  Status nå er at jeg benytter JMRI på Raspberry Pi for å lese lokomotivkonfigurasjonen, samtidig som min egen programvare  logger ved siden av.  De første testene på en web applikasjon er oppe å kjører  på

Men her er det fortsatt mye å gjøre, både på feilhåndtering, layout og funksjonalitet.  Første skritt er å lese CV’er for å identifisere hvilket lok som er satt på programmeringssporet.  Neste skritt er å kunne endre adresser fra Nettbrettet.  Deretter skal det lages programvare for å kjøre automatiske målinger av start, stop, og hastighet, og så kommer det første store målet, som er å automatisere innstillingene av Cvene for motorkontroll – basert på de automatiske kjøretestene.

Øverst på hovedkortet, skal jeg lodde inn en sokkel for Arduino Prosessoren,  når prototypingen av programvaren er ferdig.

MCP23008 er plassert omtrent på mitten av kortet, og Nederst er det sokler for 2, 4-doble optokoplere.

I denne testoppkoplingen, har jeg koplet til 5 V via en 3k3 motstand for å drive optokopleren.

Den som jeg var usikker på, var om MCP230008’erns interne Pullup motstander på 100k var tilstrekkelige til å trekke signalet opp (tidligere har jeg brukt en 10k motstand for dette) .  Det ser ut til å fungere bra.

Nå under testingen brukes den gule LED’en på Arduinoen for å se at detektoren fungerer.  Arduinoen er programmert med denne Sketchen.  (Kan kun sjekke en detektor – Pinne 10 på MCP230008)

#include <Wire.h>

#include "Adafruit_MCP23008.h"

// Basic pin reading and pullup test for the MCP23008 I/O expander

// public domain!

// Connect pin #1 of the expander to Analog 5 (i2c clock)

// Connect pin #2 of the expander to Analog 4 (i2c data)

// Connect pins #3, 4 and 5 of the expander to ground (address selection)

// Connect pin #6 and 18 of the expander to 5V (power and reset disable)

// Connect pin #9 of the expander to ground (common ground)

// Input #0 is on pin 10 so connect a button or switch from there to ground

Adafruit_MCP23008 mcp;

 void setup() {

mcp.begin(); // use default address 0

mcp.pinMode(0, INPUT);

 mcp.pullUp(0, HIGH); // turn on a 100K pullup internally

pinMode(13, OUTPUT); // use the p13 LED as debugging

}

void loop() {

 // The LED will 'echo' the button

digitalWrite(13, mcp.digitalRead(0));

}

Jeg har eksperimentert videre med Ultralyd avstandsmåleren.  På gulvet detekterer den et H0 lokomotiv med opp til 3,2 meters avstand.  Installert på programmeringssporet detekterer den opp til 22 centimeter.  Det er egentlig ikke noe stort problem fordi det er de siste centimeterene før stopp, og rett etter start som er viktig, men jeg har en mistanke om at det er hodet på en bolt som reflekterer signalet.  Skal forsøke å se om jeg kan bli kvitt denne.

Kortet for styringen av programmeringssporet er funksjonellt ferdig.  Først ble det en testoppkopling for å teste relestyring, som brukes for å veksle mellom kjørestrøm fra Roco sentralen, og programmering via MERG kontrolleren.

De  siste komponentene er  loddet på  kortet.  Nå gjenstår det bare å legge til sokkel  for Arduino prosessoren og tilkopling av ledninger, men dette vil jeg vente med inntill kortet med programvare er ferdig.  Jeg har derfor fullført testingen av kortet :

Etter dette har jeg montert alt sammen midlertidig ved siden av programmeringssporet, og koplet opp en USB kabel mellom Arduinoen  og Raspberry Pi.  Med denne oppkoplingen kan jeg teste ut kortet sammen med omkringliggende komponenter, og ha et godt miljø for utvikling av programkoden på kortet:  Jeg utviker på Raspberry PI, via en VNC klient, og laster ned v.h.a. USB kabelen, slik at det bare tar noen sekunder å teste nye versjoner av programkoden.

Arduino programkoden har allerede gjennomgått flere revisjoner.  Den første versjonen var for å teste relestyringen, ved at den slo av og på releet hvert 5 sekund.  Neste versjon sjekket alle de 8 spordetektorene ved å sende statusen til en terminalemulator en gang pr. Sekund.  Deretter ble det en versjon for å teste Ultralyd avstandsmålingen.  Nå er jeg igang med den endelige versjonen.  Den fungerer ved at det sendes en kommando til Arduinoen, som returnerer med et svar.  Kommandoer som er implementert i dag er:

• Q01VM
• Query 01 Version Major
• Returnerer versjonsnummeret for programvaren.  Svarer med:   M01P2
• Q01VS
• Query 01 Version Subversions
• Returner releasenummer for programvaren       : M0123
• Q01U1
• Query 01 Ultrasonic 1
• Skal returnere informasjon fra Avstandsmåleren
• Q01TA
• Query 01 Track All
• Returner svaret fra alle spordetektorer.  Det kan også spørres om hver enkelt med meldingen Q01Tn,  hvor N=0 – 7.

Utviklingen av programkoden på Raspberry har også gjort fremskritt.  Et av de første behovene er å finne ut hvilken Decoder type, som er installert i hvert enkelt lokomotiv.  De fleste decoderprodusenter benytter CV 7, software version number på en fornuftig måte.  Utfordringen min er at jeg har ganske mange dekodere fra ESU, som er ganske forskjellige, men hvor ESU har lagt inn samme verdi i CV 7.  Dette gjelder så forskjellige dekodere som,  LokPilot v. 2 3 og 4,  Loksound dekodere,  ROCO 10745 (fabrikkinstallert i mange ROCO startsett) i forskjellige versjon, og mange av dekoderne som selges som Bachmann 3-Function decoder  36-553.  Etter lesing av manualer, fra dekoderleverandørene og JMRI dokumentasjonen, samt egen testing har jeg laget denne tabellen (fortsatt ikke helt komplett)

Hele tabellen ligger her:

http://programmingtrack.no-ip.org/EsuRocoBachmannCVlist20140324.xls" rel="nofollow - http://programmingtrack.no-ip.org/EsuRocoBachmannCVlist20140324.xls

Programkoden er kommet så langt at den klarer ved hjelp av å lese ut forskjellige CV’er, og om nødvendig forsøke å skrive til noen CV’er,  å finne ut om det er en basic decoder (ESU, Roco eller Backmann), og hvem av dem det er,  eller om det er en av de mere avanserte dekoderene.  Det gjenstår  fortsatt funksjonalitet for  å finne forskjeller mellom Lokpilot 2,3,3 og LokSound.  Tilsvarende funksjonalitet for Lenz og Zimo kommer senere.

Etter at jeg har funnet ut hvilken dekoder som er i loket, har jeg også laget funksjonalitet for å identifisere om loket har vært innom programmeringssporet før, og eventuelt programmerer CV’er fra en liste.  Måten jeg benytter er å sjekke dekodertype, hvis denne støtter lange adresser benyttes denne for å identifisere loket.  For NSB lok benytter jeg lokets 3 (med en null foran) eller 4 sifrede nummer,  for tyske lok benytter jeg typenummeret f,eks 218, og legger til kontrollsifferet, slik at jeg får 4 sifre.  Det gjenstår å se hvor mange kolisjoner jeg får.  For de dekoderene som støtter det, vil jeg benytte et løpenummer i CV 106 (User identification) .

Hensikten med alt dette, er å kunne ta vare på historikk på CV’er, for å kunne sammenlikne kjøreegenskapene for de ulike lokene, med ulike dekodere.  Når programmeringssporet, er ferdig med sensorer vil jeg få en automatisert dokumentasjon av dette.

Status i dag :

http://programmingtrack.no-ip.org/dynamic.php?system=ENGINEDB&page=10000&id=0" rel="nofollow - http://programmingtrack.no-ip.org/dynamic.php?system=ENGINEDB&page=10000&id=0

Til slutt har jeg også funnet dokumentasjon på hvordan styre vendeskiver med Arduino:

http://www.rmweb.co.uk/community/index.php?/topic/78578-dcc-controlled-peco-turntable-project/" rel="nofollow - http://www.rmweb.co.uk/community/index.php?/topic/78578-dcc-controlled-peco-turntable-project/

Veldig hyggelig med tilbakemeldinger – er ofte vanskelig å selv vurdere om det man skriver er av interesse for andre.

Det enkle svaret er vel at jeg gjør det fordi det er gøy, men hvis jeg skal forsøke å forsvare det litt, kan jeg utdype :

JMRI er en glimrende CV editor for å lese og skrive CV verdier.  Jeg har koplet opp JMRI i parallell til egenutviklet programvare slik at jeg kan lese ut og skrive, og se hvilke kommandoer som blir generert over serieporten.

Mine viktigste argumenter for å lage en egen programmerer, er :

1.      I JMRI kan man lese ut og lagre CV’er på (XML) filer, slik at man manuelt kan se hvilke endringer man har gjort, eller legge tilbake gamle instillinger.  Jeg vil istedenfor filer, lagre innstillingene i en database (MySQL) slik at jeg kan ta ut rapporter, sammenlike, og gjøre mere komplekse operasjoner  som f.eks. resette dekoder til fabrikkinstillinger og deretter programmere inn gamle verdier for f.eks. CV1, lange adresser, ol, uten å gjøre dette som manuelle steg i JMRI)

2.      Jeg ønsker å autmatisk sette parametre for styringen,  både CV i lokket, men også parametre i styringsprogrammet for å oppnå jevneste og mest mulig forbildetro, hastighet, aksellerasjon og bremsing.  JMRI har en automatisk hastighetsmåler som måler tiden mellom to punkter, og derved beregner konstant hastighet for toget (eller egentlig gjennomsnitlig).  Jeg håper å få til en nøyaktig måling av retardasjon og akselerasjon v.h.a. Ultralyd avstandsmåling.  Denne målingen vil jeg gjøre fra enden av programmeringssporet, og når jeg/eller programmet er fornøyd med profilen, vil jeg lagre den, og benytte den under kjøringen senere.

3.      JMRI DecoderPro er en PC applikasjon, som ikke kan benyttes på nettbrett.  Jeg lager grensesnitt slik at det kan brukes på PC, iPad, iPhone, Android etc.  I tillegg tror jeg at jeg vil kople til en enkel fjernkontroll (type TV) med enkle funksjoner, som f.eks:

·        0 – Identifiser Lok på programmeringsspor.

·        1 – Les og lagre alle CV’er i lokket.

·        2 – Tildel og programmer en midlertidig unik adresse for loket, slik at det kan prøvekjøres.

·        3 -  Kjør testprogram for lokomotiv,  for å grovinstille CV’er

·        4 – Kjør avansert testprogram for fininstiing av CV’er

Andre ting jeg har sett at jeg kan lage bedre enn JMRI er dekodertype identifisering.  JMRI kan f.eks. ikke skille mellom ESU dekodere som f.eks. Lokpilot, Loksound, Basic, Roco 10745 i forskjellige varianter, og Bachmann 3-function.

Mine viktigste argumenter for å lage et eget styringssystem, er:

 (her er jeg litt på tynn is fordi jeg ikke har sett mye på alternative løsninger) :

1.      Da jeg begynte med dette for ca. 30 år siden fantes det ikke noe alternativ.  Den gangen så jeg litt på CMRI, men valgte å lage egne blokkkontrollere med DC styring under MS-DOS.  Dagens versjon av styringen er laget i løpet av de siste 15 årene, men støtter fremdeles scriptene som jeg laget for 30 år siden.

2.      Ambisjonsnivået er relativt høyt. F.eks. lag en tidtabell hvor lokaltoget starter fra utgangstasjonen hver time (mellom 06:00 og 23:00), og returner klar til innsats nesten to timer senere. (slik at det er behov for minimum to togsett).  Det betyr at jeg ikke kan lage script for hvert enkelt tog, men lage generelle script for å kjøre etter tidtabellen, og andre script som finner ut hviket materiell som skal brukes i denne avgangen.  Andre funksjoner, eller separate programmer er f.eks. togekspeditør på en stasjon (må løse komfikter i forhold til sporbruk ved forsinkelser/ekstratog), lokfører som kjører toget etter signalene/rutetabellen, og signalstyring / linjeblokk.  Alle programmene kommuniserer via TCP/IP, slik at de kan kjøres på en eller flere PC’er.  Jeg kan også velge hvilken funksjon jeg selv vil utføre manuelt.  (Neida jeg er ikke ”helt” ferdig med alt enda).

3.      Ønsker å automatisere skiftebevegelser og samenstilling av godstog (Her er jeg avhengig av bedre kontroll med lokegenskapene –  ref. Egen programmerer)  f.eks. er en av de viktigste kundene et aluminiumsverk (samme produksjonsnivå/produkter som Årdal Verk), som har behov for levering av riktig mengde Aluminium oksid og  Kull (for anodeproduksjon), og transportkapasitet for ferdige aluminiumsprodukter. (20000 – 200000 Tonn pr. År avhengig av årstall) og Anoder.  (10 femtitals vogner med last på 10 tonn hver, per dag – eller nyere vogner med 80 tons kapasitet på 2000 tallet)

4.      Ønske om norske signalbilder og stillverk.  Ved å selv lage programvaren, kan jeg få norske signalbilder uten avansert elektronikk, men overlate kompleksiteten til programvaren.

Ultralydavstandsmåleren er installert, og ser ut til å fungere greit i avstandsområdet 4 – 21 cm.  Jeg kan derfor måle hvor langt lokomotivet kjører etter en stop kommando.

Arduino programmet er nå i tredje versjon.  Den første versjonen sjekket spordetektorene og rapporterte status.  Opprinnelig hadde jeg tenkt å installere en optokopler for vekselstrøm, slik at både positive og negative DCC pulser kunne detekteres.  Følsomheten viste seg å være for dårlig på denne, slik at jeg byttet  til to andre  som jeg hadde liggende. TLP521-4, er en 4 dobbel optokopler som fungerte bedre, men den har kun en diode pr. Kanal, slik at den kun detekterer den ene fasen av DCC signalet.  En les vil derfor fungere 50 prosent av gangene.

Neste versjon av programmet gjorde derfor et hundre les for hver av de 8 kanalene, slik at sjansen for at det blir detektert er over 99 prosent.  Problemet som nå oppstod er at en les totalt tar 450 millisekunder for 8 detektorer.

Den tredje versjonen av programmet, har fått 20 konfigurasjonsvariable.  Et av dem sier hvor mange ganger det skal leses, før det konkluderes med at sporet er tomt.  Ved å lese 9 ganger blir sansynligheten: 50 + 25 + 12,5 + 6,25 +3 ,12 + 1,56 +  0,78 + 0,39 + 0,19 = 99,8 prosent.  I praksis ser det ut til at sansynlighetene er over 90 prosent.  Og der er godt nok, hvis jeg detekterer ofte nok,  slik at feildeteksjon kan korrigeres fort nok.

Diagrammet viser litt om dette.  På toppen viser det av en les fra Arduinoen tar mellom 25 og 76 millisekunder.  Dagens versjon gjør tre les : Henter spordeteksjonsstatus for alle 8 spor(Q01TA),  Henter distanse i cm for Ultralydmåleren (Q01U1) , og den tredje henter desimal cm fra Ultralydmåleren (Q01CW).  Dette tar tilsammen 200 millisekunder, slik at jeg burde kunne lese 4 – 5 ganger i sekundet.  Jeg har opså lagt inn debugginginformasjon som forteller meg at hver enkelt les over I2C tar 460 mikrosekunder.  Hvis jeg klarer å redusere denne tiden til under 116 mikrosekunder, kan jeg synkronisere lesen med DCC signalet for å oppnå sikker detektering.  For øyeblikket kjører jeg I2C bussen med 100khz frekvens på kontrollsignalet.  Arduinoen støtter også 400khz, slik at det skal være mulig å å komme ned mot 120 mikrosekunder.  Tror også at det er mulig å optimalisere ytterligere ved å erstatte AdafruitMCP23008 library, med mere effektiv kode.   Dette er foreløpig ikke prioritert fordi det fungerer nogenlunde ok med dagens implementasjon.  Andre alternative løsninger er å sette inn en kondensator etter opptokopler,  eller bruke en mere avansert krets istedenfor MCP23008, enten en Arduino eller en PIC prosessor.  Etter at jeg har optimalisert I2C trafikken (som i dag tar ca. 50 millisekunder) kan jeg gå løs på USB optimasliseringen.  I dag tar en les 25 millisekunder, ved å øke hastigheten fra 9600 Baud til 116000 Baud, vil nok også denne tiden gå ned.

Programvaren på Raspberryen er også forbedret ved at den måler tider og kan brukes til å konfigurere Arduinoen.  Her har jeg oppdaget en eller annen feil som gjør at jeg kun klarer å lese status 1 gang pr sekund, istedenfor 4 – 5 ganger i sekundet.  Så dette må jeg prioritere å finne ut av.

Dette er en enkel test som kjører det testede lokomotivet forover i 20 sekunder, ut av programmeringssporet på hastighetstep 4 med spedstepmode 14.  Stopper lokomotivet, og kjører tilbake inn i programmeringssporet og stopper når den innerste spordetektoren oppdager lokomotivet.  Ved å kjøre testen mange ganger og sjekke avstanden med Ultralydmåleren for jeg ut statistikk over hvor nøyaktig kontrollen er.  Det har etterhvert begynt å fungere, men stopposisjonen er ganske unøyaktig – sansynligvis bl.a. fordi jeg kun leser ut sensorene en gang per sekund.  Her er en liten tabell, over avstanden i centimeter, Ultralydsensoren har målt for de siste testene:

149        Test001StopPosition        13

150        Test001StopPosition        3

151        Test001StopPosition        5

152        Test001StopPosition        18

153        Test001StopPosition        19

154        Test001StopPosition        18

155        Test001StopPosition        3

156        Test001StopPosition        15

157        Test001StopPosition        6

158        Test001StopPosition        12

Ikke impoenerende presisjon her, men et greit utgangpunkt.  For hver kjøring får jeg også ut en rapport om hastigheter og responstider under testen.  Her er et eksempel fra den siste kjøringen :

Forklaringer til tabellen :

TimerSensor002001 – Tidsforbruk fra spordetektor 002 til  001.  Her er en svakhet ved at den kun beregner hele sekunder.

KMHSensor003001 – Hastighetsmåling fra spordetektor 003 til 001.  Unøyaktig fordi den benytter TimerSensor  (Uten desimaler)

Test001StopPosition – Ultralydmålerens avstandsmåling I hele cm.

-         Hastighetsberegninger pr sekund fra  20 cm  til stopp.  I Eksempelet over

o   164854 klokkeslett

o   6.0 – Centimeter, kjørt siste sekund.

o   19.0:13.0 – Hvor lokomotivet kjørte fra og til på dette sekundet.

-        Vi ser derfor at lokomotivet bråstoppet her. Og det stemmer lokomotivet ble kjørt i skiftemodus.

TestrunSec – Hele testen tok 52 sekunder.

TestRunMessages – 441 meldinger gjennom systemet i løpet av testen.

TestrunMessagesSec  -8,48 meldinger pr. Sekund

TestRunUltra – 59  avstandsmålinger i løpet av testen.

TestrunUltraSec – 1,18  avstandsmålinger pr. Sekund – Derfor er unøyaktigheten i alle målinger på nesten et sekund.  -  Så her er det bare å jobbe videre med å få opp frekvensen.

258        Test001StopPosition        22

259        Test001StopPosition        21

260        Test001StopPosition        21

261        Test001StopPosition        22

Har også forbedret analyseprogrammet til å regne med microsekunder, slik at tidene blir mere nøyaktig.

Her er rapporten for kjøring nr 260:

Vi ser av TestrunUltrasonicSec at vi leser ut detektor og avstander nesten 4 ganger i sekundet.  Vi ser også av TestrunMessagesSec at det går nesten 30 meldinger pr. Sekund (mot tidligere 8).  Noen nye måleparametre er kommet til :

TestrunBackendResponseMax     97 millisekunder  – Lengste responstiden fra kortet .

TestrunSocketResponseMax      261 millisekunder – Lengste responstid for TCP/IP pakker – her må det gjøres forbedringer

TestrunDccMessages          7 – Meldinger sendt til Roco sentralen / Lenz interfacet

TestrunDccMessagesError   0 -  Error Status fra Roco sentralen / Lenz interfacet

TestrunDccMessagesOk      7 – OK status fra Roco sentralen / Lenz interfacet

Av en eller annen grunn har jeg ”mistet” et måleparameter :

UltraSpeed001 – må finne ut hva som har hendt med denne.  Andre forbedringspotensiale er hastighetsmålingen mellom blokkene – og hvorfor får jegnegativ hastighet – tror årsaken kan være en feilkopling av blokkene.

KMHSensor002001                          -22.13280922200384

KMHSensor003001                          18.58940065368651

KMHSensor003002                          16.820897225768025

KMHSensor004001                          29.39840015737303

KMHSensor004002                          26.641563788341905

KMHSensor004003                          16.413954481672526

KMHSensor006005                          -682.5388177608281

KMHSensor007005                          16.965907762041148

KMHSensor007006                          16.027296992780073

KMHSensor008005                          17.749610682756636

KMHSensor008006                          16.975522859413246

KMHSensor008007                          21.4086326620066

Test001StopPosition                       21

TestrunBackendResponseMax     97

TestrunDccMessages                      7

TestrunDccMessagesError            0

TestrunDccMessagesOk                 7

TestrunMessages                            928

TestrunMessagesSec                      27.47894588631593

TestrunSec                                        33.77131

TestrunSecOld                                  34

TestrunSocketResponseMax         261

TestrunUltrasonic                            131

TestrunUltrasonicSec                     3.906173358120538

TimerSensor002001                        -0.226415

TimerSensor003001                        4.9871

TimerSensor003002                        5.213515

TimerSensor004001                        4.005769

TimerSensor004002                        4.232184

TimerSensor004003                        1.526506

TimerSensor006005                        -0.007342

TimerSensor007005                        5.464323

TimerSensor007006                        5.471665

TimerSensor008005                        6.634692

TimerSensor008006                        6.642034

TimerSensor008007                        1.170369

Oppstart etter sommerferie, begynte med korrupt SD brikke på en av Raspberry’ene.  Dette er den tredje SD brikken som er ødelagt i løpet av et år hos meg (fordelt på 5 Raspberry Pi).  Backup er ikke så dumt, alternativt, som jeg gjør er å ikke lagre viktig informasjon på SD brikken, og ha automatiserte rutiner for å reinstallere.  Jeg har derfor forbedret den automatiske installasjonsprosedyren for JMRI, og samtidig oppgradert til siste versjon av JMRI, 3.8.  Denne har jeg lagt inn i min automatiske installasjonsprosedyre.  Hvis noen vil prøve er kommandoene :

wget programmingtrack.no-ip.org/setup010308.sh
. ./setup010308.sh

Resten er som før – se blogg 6 Januar 2014

Programmmeringssporet

For å få mere nøyaktige malinger, startet jeg feilsøking I grensesnittet mot Roco sentralen.  Etterhvert fant jeg så mange programmeringsfeil (som jeg selv har laget for 8 år siden), at jeg konkluderte med at det var på tide å programmere dette på nytt.   Har nå ferdig en prototype som fungerer mye bedre, men foreløpig kun støtter 14 Step, lokomotivkontroll.  Rapporten fra den siste testen viser at maksimal responstid for TCP/IP meldinger nå er nede i omtrent 0,1 sekund.  Alle målinger blir derfor mye mere nøyaktig.   Det kan man bl.a se på hastighetsmålingene.  Here er rapporten for kjøring nr 388.  

Jeg kjører Raspian (2014-06-20-wheezy-raspbian.zip) fordi den er den eneste som støtter Hardfloat i Java.  Før denne støtten kom, var ytelsen enda dårligere.

Forrige gang SD kortet ble korrupt startet det med at ”sudo shutdown”  ikke fungerte, slik at jeg måtte ta strømmen, men jeg tror at SD kortet allerede var korrupt, og årsaken til at shutdown, og mange andre kommandoer ikke fungerte.

Generelt er det ikke å anbefale å ta strømmen på en Raspberry uten å stoppe den først.  Dette er nok årsaken til mange korrupte SD kort, men jeg har også opplevd at jeg etter å ha gjenbrukt et tidligere korrupt SD kort, fikk en ny crash etter kort tid -  dette skyldes trolig at kortet var utslitt.  For å unngå å miste data ved crash, benytter jeg en  USB minnepinne for lagring av data. Eksempel :

mkdir /mnt/sda0

mount /dev/sda0 /mnt/sda0

cd /mnt/sda0

For å frigjøre

umount /mnt/sda0

Har enda ikke opplevt korrupt minnepinne,  etter å ha kjørt en applikasjon på Raspberry  i snart to  år som logger en ny fil hvert 15. sekund. (Ikke MJ relatert) – men har brukt opp to SD kort på denne maskinen.

Har også planer om å teste ut med en USB SSD disk for å kjøre mySql.

....

” Tenkte jeg skulle forsøke setup-skriptet ditt, men får ikke til å koble til serveren/DNS du har angitt.”

Hvis du får opp bildene i bloggen skal du også få tak i installasjonsscriptet.  Er det på arbeidsstasjonen din, eller på Raspberry du ikke får tilgang ?

Hvis det kun er på Raspberryen, har du kanske vært inne å endret nettverksoppsettet til statisk IP ? og ikke fått DNS riktig ?  Det jeg har valgt å gjøre, er å kjøre Raspberryen med dynamisk IP (default), og etter installasjon, gå inn i Router boksen, og reservere IP adresse for Raspberryen.  Fordelen med dette er at ved en nyinstallasjon får Raspberryen samme ip adresse.

Vedlagt begge scriptene – hvis du fortsatt ikke får tilgang.

http://programmingtrack.no-ip.org/setup010308.sh" rel="nofollow - exec > >(tee logfile.txt)

sudo apt-get update

sync

sync

sudo apt-get install librxtx-java

sudo apt-get install tightvncserver

sync

sync

wget programmingtrack.no-ip.org/JMRI.3.8-r26527.tgz

wget programmingtrack.no-ip.org/startVNC.sh

sync

sync

tar -zxvvf JMRI.3.8-r26527.tgz

sync

sync

#tightvncserver

sync

sync

vncserver :0 -geometry 1920x1680 -depth 24 -dpi 96

http://programmingtrack.no-ip.org/startVNC.sh" rel="nofollow - http://programmingtrack.no-ip.org/startVNC.sh

# sudo apt-get install tightvncserver

#tightvncserver

vncserver :0 -geometry 1920x1080 -depth 24 -dpi 96

Hvordan gjøre enkle ting vanskelig.

Første forsøket med z21 gikk ikke veldig bra.  Jeg pakket opp startsettet, koplet opp z21 boksen og ruteren som fulgte med.  For å oppgradere firmware til siste versjon lastet jeg også ned siste versjon av z21 Maintenance tool på PC’en.  For å oppgradere måtte jeg også kople den medfølgende ruteren til nettet mitt.  Koplet til strømmen på begge enhetene og forsøkte å få kontakt fra PC’en.  Og det fungerte selvfølgelig ikke.  Adressen til z21 skal være 192.168.0.111, men den svarte ikke engang på ping.  Dagen etter gjorde jeg et nytt forsøk.  Jeg hadde nå en mistanke om at noen hadde pakket opp settet før jeg kjøpte det, og endret adressene, både på router og z21 boksen fordi de kjørte med feil oppsett.  Istedenfor 192.168.0.x nett, var router satt opp med LAN range på 192.168.1.x nett.  Hadde ikke lyst til å forsøke å endre router oppsettet, men etter en stund gikk det et lite lys opp for meg :  192.168.0.x nettet var jo den samme adressa rangen jeg benytter på nettet mitt.  Tok derfor bort den medfølge routeren og koplet z21 boksen rett i den andre routeren,  og da fungerete alt.  Så anbefalt fremgangsmåte for å sette opp z21 boksen, bør derfor være :

1. Kople opp z21 og medfølgende router uten å kople routeren til hjemmenettverket.
2. kople opp PC mot router og forsøke å pinge 192.168.0.11.
3. hvis hjemmenettverk ikke kjører på 192.168.0.x adresser kan den medfølgende router koples til     hjemmenettet.   Hvis hjemmenettet kjører på 192.168.0.x, sjekk om det er noen devicer som har adressen 192.168.0.111,  hvis ikke er det bare å kople z21 rett inn i hjemmerouteren, men pass på at dhcp range ikke overlapper med 192.168.0.111

Mitt router oppsett er :

Router Ip address 192.168.0.1

Ip Subnet mask 255.255.255.0

DHCP 192.168.0.200 – 192.168.0.253

Status på z21 boksen min nå er at den er opp i nettverket – men ikke koplet til anlegget.  Har testet ut å kjøre lok med iPad (uten at noe fysisk lok kjører) og det fungerer.  JMRI har foreløpig ikkeordentlig støtte for z21, men det er på vei i de siste utviklingsversjonene.  Protokollen som benyttes mot z21 er basert på å pakke inn det gamle Lenz serieport grenssnittet inn i http://en.wikipedia.org/wiki/User_Datagram_Protocol" rel="nofollow - UDP pakker.  Jeg har laget et lite testprogram som kopler seg opp, og gjør enkle kommandoer som ”Track Power on/off” etc.

Utfordringen min nå er at jeg har tre potensielle DCC sentraler, og jeg må bestemme med for hvilke jeg vil benytte for kjøring og programmering :  Roco LokMaus II/Multimaus,  z21 eller MERG ?

Her er oppsettet mitt som det er i dag :

Arkitekturvalg

Jeg har nå tre forskjellige Digital Sentraler :

1. Roco Lokmaus II/Multimaus
2. Roco Z21
3. Merg CBUS-DCC ( http://www.merg.org.uk/merg_resources/cbus-dcc.php" rel="nofollow - http://www.merg.org.uk/merg_resources/cbus-dcc.php )

Hvem av dem jeg skal bruke er ikke et strategisk valg, men noe jeg kan endre på når jeg måtte ønske. Det som er viktigere, er  å bestemme meg for om jeg ønsker å benytte DCC som styringssystem, og på hvilke områder jeg vil gjøre det.  Det er helt klart at analog likestrøm (og vekselstrøm) ikke er aktuelt, men det er greit å ha mulighet til prøvekjøring av analoge lok på deler av anlegget.  Det som er mere spennene er å se på alternative måter å styre lokomotivene på.  Det mest interessante er hvis man kan få dem autonome (selvstyrende).  Google har laget autonome biler som er ute å kjører på veiene allerede, og det eksperimenteres med autonome seilbåter som skal seile over atlanteren ( http://www.microtransat.org/tracking.php" rel="nofollow - )

Det å få et tog på en modeljernbane til å være autonomt, er en mye enklere oppgave.  Den eneste utfordringen er plassen inne i et H0 lokomotiv.  Jeg har derfor vurdert å kjøpe et G-Skala startset, og montere en Raspberry Pi inn i lokomotivet.  Andre alternative platformer, er også litt for store for H0:

Arduino og Arduino board-kompatible :

• Arduino UNO - 75 x 53 x 15 mm
• Arduino Yún - 68.6 mm × 53.3 mm
• ChipKit uno32  - 75 x 53 ?
• FRDM-K64F - 75 x 53 ?

Alternativt ikke compatible kort:

• STM32F4  - 97 x 66 mm

Bortsett fra fysisk størrelse er det også forskjellige prosessorer og programvare på de forskjellige kontrollerene.  En standard Arduino er lite aktuell fordi den har liten kapasitet, men det som gjør den interessant er miniversjonene av denne, men da er prosessoren loddet fast. .  Yun, har to prosessorer, en som kjører Arduino og en prosessor som kjører Linux, så den er interessant, men har to ulemper : høy pris og ikke mulig å bytte brikker – fordi de er loddet fast.

De andre kortene har høyere ytelse og er basert på ARM prossessorer (ARM prosessorer sitter i stort sett alt av moderne mobiltelefoner og nettbrett - både Apple iOS og Android. Raspberry Pi har også ARM) Det er kun Chipkit som har ARM prosessoren i en standard 28 Pin DIP utførelse - slik at den kan taes ut og plugges inn i et egenutviklet kort, og de har en miniversjon: Fubarino® Mini 5.1 cm x 1.9 cm, men her er også prosessoren loddet fast.  STM32F4 og Freescale FRDM-K64F, er andre spennende ARM løsninger, men også her er det fastloddede prosessorer og litt for store kort, men prisen er lav, ca kr 200.-.   FRDM-K64F er også veldig spennende fordi den er referanseimplementasjon av ARM’s IoT(Internet of Things) mbed plattform ( https://mbed.org/" rel="nofollow - https://mbed.org/ ).

Jeg tror jeg bestiller en FRDM-K64F for testing.  Det er nok litt for tidlig å plassere styreprosessoren i H0 lok, så foreløpig fortsetter jeg med å bygge det som et autonomt lok, men med styreprosessoren som en ekstern Raspberry PI.  Senere kan jeg vurdere Raspberry Pi Compute Module – når denne kommer ned i en akseptabel pris.

Spørsmålet blir da kommunikasjonen til Loket.  Her er DCC nesten det opplagte valget, men jeg har misstanke om at jeg har utfordringer med responstider / forsinkelser. Om dette skyldes støy p.g.a. dårlig kabling eller kontaktproblemer må jeg finne ut av. 

Det er interessant at Marklin har valgt infrarødt for ”myworld”, men enda mere interessant at ROCO har valgt wifi for Roco Next Generation ( http://www.roco.cc/en/specials/next/index.html" rel="nofollow - http://www.roco.cc/en/specials/next/index.html ) .  Her ser det ut som om systemet er basert på at lesebrettet kommuniserer direkte med lokomotivet via wifi uten å ha noe elektronikk (DCC sentral) imellom, og det blir tilgjengelig til jul i år ? – noen som vet ?.   Det er ganske tydelig at det er en begynnende trend bort fra DCC til mere generelle industristandarder (IoT)  – selv om jeg, og dere andre neppe kommer til å bytte ut alle DCC dekoderene vi har i dag.

Bluetooth

Og her er lenker til info om Bluetooth Smart styring - bl.a. fra Bachmann :

http://bluerailtrains.com/intro.cfm" rel="nofollow - http://bluerailtrains.com/intro.cfm

http://resources.bachmanntrains.com/ihobby2014/html5/index.html?page=1" rel="nofollow - http://resources.bachmanntrains.com/ihobby2014/html5/index.html?page=1

Marklin pensemotor problemer er blitt diskutert både her og andre steder de siste årene.  Min forståelse av problemet er at Marklin har montert en endebryter som er laget for opp til 0.5 Ampere i en veksel som bruker omtrent 1.5 Ampere.  Derfor blir bryteren brent opp.  Den eneste varige løsningen på dette problemet er å kople ut bryteren.  Jeg gjør det på følgende måte :

Åpne motoren ved å bøye opp taggene :

Ta ut innholdet.

Lodde over begge de to sorte bryterene.

Sette den sammen igjen – og bøye over taggene.

Da har vi en motor som fungerer – men uten beskytelse for overbelastning.  Det hadde jeg igrunnen også før modifiseringen.  Den siste gangen jeg brant opp en motor var årsaken at det stod et lokomotiv på vekselen, slik at den ikke la over, og til slutt brant opp.  For å unngå at pulsene blir for lange, har jeg lagt inn et hallelement som måler strømforbruket. 

https://www.sparkfun.com/datasheets/BreakoutBoards/0712.pdf" rel="nofollow - https://www.sparkfun.com/datasheets/BreakoutBoards/0712.pdf

https://www.sparkfun.com/products/8883" rel="nofollow - https://www.sparkfun.com/products/8883

En arduino er koplet til denne.  Arduinoen styrer et relee som må være inne for å gi strøm til sporskiftemotorene og dekoder.  Kontinuerlig innkopling eller mange pulser over en kort periode, kopler ut releet, tenner en rød LED og sender en melding til PC styringen, som forsøker å rette opp feilen, eller stopper alle togene om nødvendig.

http://www.raspberrypi.org/raspberry-pi-2-on-sale/" rel="nofollow -  Viktigste nyhet er mere RAM (1GB) og ny 4 kjerners CPU, med mellom 1.5 og 6 ganger bedre ytelse, avhengig av applikasjon.  Da bør det la seg gjøre å kjøre JMRI med ok ytelse ?  Jeg har bestilt et par stykker for å  se hvordan de fungerer (prisen er den samme som før (USD 35).  Det er allerede produsert 100000 eksemplarer, så ventetiden blir kanskje ganske kort.

Hovedbryter.

Programmeringssporet er på en modul som har ganske kompleks strømopplegg.  I dag er det flere strømforsyninger fra Roco og TRIX, en 8 volts strømforsyning til Ethernet Router og to micousb strømforsyninger for Raspberry Pi.  I hvilemodus er kun Raspberryene og Router tilkoplet strøm.  Kun disse enhetene har et strømforbruk på omtrent 40 Watt.  Mye av dette ligger nok i de tre 200V adapterene.

For å redusere kabelsalaten, og strømforbruket, har jeg satt meg et mål om at det kun skal gå to kabler inn til modulen :  En ethernet kabel og en 220 Volt tilkopling.  Ut av modulen, skal det kun gå DCC signal til neste modul (Fremo).  Jeg ønsker ikke å ha eget WI-FI nett i modulen. 

Ved hjelp av ”Power over Ethernet” (PoE) kan jeg få en ganske god løsning:  På modulen går Ethernet inntaket rett inn i en Linksys PoE Splitter

( http://www.tp-link.com/en/products/details/?model=TL-POE10R" rel="nofollow - http://www.tp-link.com/en/products/details/?model=TL-POE10R )

Denne har en utgang som gir 9 Volt, og forsyner en Arduino med Ethernet kort,  og en Ethernet Switch.  (Brun/Gule ledninger på bildet) Disse enhetene vil derfor alltid være tilkoplet strøm.  Strømforbruket er ca 5 watt.

På Arduinoen har jeg laget en liten WebServer som styrer utgang 4 (Orange ledning) , og er koplet til en transistor, som driver et rele (Blå Ledninger) , som fungerer som hovedbryter (220Volt) for resten av modulen (bl.a. Raspberry, Digitalsentraler, Can Bus,  og andre transformatorer).

Neste skritt er å sette opp 8 releer, som skal styrer via CAN Bussen, for å styre strøm til de forskjellige enhetene (DCC skinnestrøm,  DCC pensestyring, Signaler, LYS, etc).  Når alt dette er klart,  kan jeg fjernstarte anlegget fra en web Browser : Først hovedbryteren, som også starter Raspberryene, hvor jeg kan styre de forskjellige releene (også dette fra en web browser).

Fra programmeringssporkontroller til stasjonskontroller

 Erfaringen med programmeringssporkontrolleren er god.  Den fungerer stort sett som forutsatt.  Jeg planlegger derfor å etse et kretskort til denne.  Før dette vil jeg utvide funksjonaliteten til å bli en total stasjonskontroller.  De viktigste funksjonene blir :

1.     1.  Signalstyring : Lys og semafor.  Viktig funksjon er myk blinking av LED ved hjelp av PWM (Pulse-Width Modulation) og programvarestyrt lysstyrke.

2.     2.  Sporvekselstyring: Kun driver for servo – andre alternativer via ekstern funksjonalitet (DCC Accessory decoder el).

3.     3.  Tilbakemelding på fysisk posisjon for sporveksler.  Det skal være støtte for fysisk bryter og spenningsdetektor av hjertestykke.

4.     4.  Sporfeltdetektor: Basert på diode-drop og optokopler.

5.     5.  Punktdeteksjon basert på Infrarød stråle.

6.     6.  Avstands/hastighetsmåler med Ultralyd.

7.     7.  Mulighet for rele for å kople inn programmeringsspor

8.     8.   Mulighet for å plugge inn en SPROG klone.

9.     9.  Støtte for å legge sporveier.

10.  10. Tilkopling til lokalt stillverk, fysisk eller virtuelt (iPad?), via USB, RS232/485, CAN, ethernet – eller direkte tilkoplet ?

11.  11. Mulighet for fjernstyring fra f.eks. JMRI, via USB, RS, RS232/485, CAN eller ethernet ?

Deretter skrudde jeg sammen kortene og en signalmast i et testoppsett – Dette skal jeg bruke for å teste konseptet og lage programvaren til Arduinoen.  Blir det vellykket, må jeg finne ut hvor mye en Arduino klarer.  Teoretisk kan det koples opp 62 kort – som tilsammen kan styre 992 LED / servoer, men jeg antar at Arduinoen får litt pusteproblemer før dette.  En nyttig funksjon er at kortet støtter både 3,3 volt og 5 volt, slik at alternative Arduinokort eller Raspberry Pi, kan benyttes istedenfor.  Grensesnittet er I2C. Bildet viser testoppsettet uten testledninger.

Svein_A wrote: Litt usikker på hva du skriver her nå. Mener du at man trenger flere Arduinoer for å styre signalene på en enkel stasjon med kun 2 gjennomgående spor? Er kapasiteten så begrenset..?

Veldig godt spørsmål, som det er vanskelig å svare med et Ja eller Nei.  Svaret avhenger av hvordan Signalene drives: 

1. De kan koples til en vanlig digitalutgang, enten med digital driving eller programvaredrevet pulsmodulering (SW PWM).  Da vil en standard Aurduino UNO kunne styre 14 (+6) LED-Lys.  For å få til myk blinking må det da lages ekstern blinkelektronikk (kan være basert på (den samme) Arduino).  Ulempen er at Signalmastene må modifiseres, og at det blir vanskelig å få til myk endring av signalbilde.  SES hadde et innlegg om dette på forumet for en stund siden. (uten Arduino)
2. De kan koples til en PWM utgang (HW PWM) .  Da har Arduino UNO 6 utganger. (Leonardo 7)
3. Arduinoen har en I2C (Inter-Integrated Circuit) som kan koples til en eller flere PWM LED drivere f.eks. PCA9685.  Hver av disse kan koples til 16 LED. Teoretisk maksimum for en Arduino UNO er 992 Utganger med 62 stk. PCA9685.  SM-bussen som sitter internt i  alle PC’er for styring av bl.a. temperatur er basert på I2C – PCA9685 kan derfor også koples rett til PC eller Rapberry Pi – slik at man ikke trenger noen Arduino i det hele tatt for å styre signalene.  En annen fordel med PCA9685 er at den har 1024 step (10-bit) – Arduino har 256 step (8-bit).

Dagens versjon av min programvare støtter alternativ 1 (med hard blinking)  og alt. 2, men jeg bruker kun alternativ 2.  Alternativ 3  skal også implementeres snart.

Jeg jobber med et regneark som viser oversikt over de forskjellige Arduinokortene – og alternativene). Kolonne N: (I/O) viser hvor mange Digitautganger kortet har,  Kolonne N (PWM) viser hvor mange HW PWM utganger kortet har. Kolonne B og C) viser prisestimater hvor B ofte er basert på noe egenlodding av kort.

Hva er da det reelle behovet for en stasjon ? Et godt eksempel er f.eks. Ødsle i denne tråden :

http://forum.mjf.no/forum_posts.asp?TID=9025&KW=&PID=17062266&title=stillverk-med-nsbforbilde#17062266" rel="nofollow - http://forum.mjf.no/forum_posts.asp?TID=9025&KW=&PID=17062266&title=stillverk-med-nsbforbilde#17062266

En rask opptelling gir omtrent disse tallene:

Andre funksjoner som kan være aktuelle på en stasjon å styre med Arduino :

• -        Lyd/Høytaleropprop.
• -        Sporveksler styring / kontroll (Servo?)
• -        Lys i stasjonshus og lokstall
• -        Simulering av TV og sveising.
• -        Lokstall dører.
• -        Vannstender.

Jeg har koblet relativt mye ledinger på MJ anlegg opp gjennom årene.  Det eneste jeg liker mindre, er å feilsøke ledningskaoset noen år senere.  Det viktigste prinsippet mitt er derfor færrest mulig ledninger, og enda viktigere: Færrest mulig ledninger mellom moduler / seksjoner.  Min løsning på dette er kretskort med distribuert logikk og buss komunikasjon (CAN, USB, Ethernet, RS232, I2C)  Oftest er det også rimeligere med en ekstra arduino (fra. Kr 50) hvis man sparer noen ledninger og plugger.  Her er et eksempel på en enkel moduloppbygget stasjon (Skal det være forsignal på utkjørsignalene i spor 1 ? spor 2?) :

Det er klart at denne stasjonen kunne vært styrt av en Arduino med f.eks. to PWM Shields, men jeg tror det er bedre å distribuere det f.eks. med 4 Leonardoer :

Eller en Arduino Leonardo og to  PCA9685 (I2C bussen < 50 cm lang) :

Eller en Arduino Mega og en PCA9685 :

Eller kanskje den måten jeg ville gjort det på (Under, Fra venstre Arduino Trinket (kr 80), Arduino UNO (kr 170), PCA9685 (kr 110), Arduino Leonardo (kr 160), Arduino UNO (kr 170) og Arduino Trinket (kr 80).

Dette blir til sammen ca kr :  770.  Litt for dyrt ? men ved å lodde litt selv (1 – 2 timer ?) :
Kr 15 + 20 + 20 + 160 + 20 + 15 – Jeg velger å behold Leonardoen fordi jeg trenger USB porten, men kan nok også eliminere denne ved å bruke en prosessor fra Chipkit DP32 (kr 25) og en ekstra UNO prosessor (eller PCA9685) (kr 20) .  Så minimumsprisen blir da ca.  Kr 135.- (+ kr 100 i ledninger, kretskort/veroboard, kondensatorer, krystaller og motstander ?) -   Dette alternativet kommer jeg mere tilbake til senere.

Håper det ble litt klarere nå !

1. Må bruke pinnen merket 3V istedenfor power (som er 5 Volt) på prototypingkortet.
   
2. Pin 39 og 40 er ikke tilgjengelig på prototypingkortet - det er derfor nødvendig med et http://www.kjell.com/sortiment/el/elektronik/mikrokontroller/arduino/stackningsbar-stiftlist-p87899" rel="nofollow - ekstra sett lange Arduino pinner for å få avstand til prototypingkortet, slik at pinne 39 og 40 kan koples direkte til UNO32 under prototypingkortet.

Da er utviklingen på programmeringssporet stoppet.  Årsaken til dette er flere, men hovedgrunnen er at hver gang jeg ønsker å teste nye løsninger i programvare eller maskinvare, må jeg stoppe en stor del av trafikken på  anlegget mitt.  Som en oppsummering har jeg laget denne listen

1. På DCC, to-skinneanlegg er det to vanlige metoder for blokkdeteksjon :  ”Current Transformer block detector” eller Diode-drop,  hvor en eller flere dider er koplet i serie med strømforsyningen til blokken.  Spenningsfallet over dioden (normalt 0,7 Volt) benyttes til å detektere strømforbruk.  Jeg har benyttet en Løsning jeg fant i en bok av Rutger Friberg ( http://www.hobby.se/index.php?action=m3&id=1&huvudID=1&temav=links&temac=links_train_rutger&temah=normal&fotID=1&stilmall=stilmall-A.php" rel="nofollow - http://www.hobby.se/index.php?action=m3&id=1&huvudID=1&temav=links&temac=links_train_rutger&temah=normal&fotID=1&stilmall=stilmall-A.php ) for mange år siden.  Noen andre autoriteter på DCC mener at diode-drop metoden fører til et dårlig DCC signal (som delvis kan reduseres med spesielle dioder) , og derfor unøyaktig kontroll på togene.  Dette kan være en utfordring med Automatisk styring.  Jeg har ikke konkludert enda, om dette er et problem hos meg
2. Kabeldragningen av DCC signalet er litt tilfeldig på mudulen min.  Jeg vet ikke om dette påvirker anlegget mitt.
3. Togdeteksjon med diode-drop og Arduino fungerer bra, belegg blir rapportert til PC / JMRI i løpet av 1/10 dels sekund.  Dette bør være ok.
4. Avstandsmåling med Ultralyd ser ut til å være en nyttig funksjon, men jeg må lage bedre rutiner for å fjerne støymålinger.
5. Lesing av alle CV’er fra lyddekodere feiler ofte når det er hundrevis av verdier å lese.  Ofte feiler det fordi lok’et flytter seg i løpet av utlesingen.
6. Programmeringssporet er plassert som et sidespor på en liten stasjon på hovedlinjen fra den største sekkestasjonen på anlegget mitt.  Den konvensjonelle meningen på nettet ser ut til å være at et programmeringsspor bør plaseres sentralt på anlegget, for å raskt kunne kjøre et lok inn på sporet, for å endre CV’er.  Det er nok et  godt utgangspunkt, men utfordringen min er at jeg også benytter programmeringssporet for prøvekjøring – og da har dette blitt en utfordring for meg, fordi jeg ønsker å kunne teste lok og CV verdier uten å forstyrre trafikken på anlegget.
7. Programmeringssporet er plassert på en stasjon som også benyttes til å skifte sammen godsvognslerker som kommer fra en sidebane, og skal videre på hovedbanen i et større tog.  Programmeringssporet benyttes til dette – noe som også begrenser hvor lenge jeg kan ha lok stående der uten å forstyrre trafikken.
8. Nye lok bør innkjøres.  Produsentene anbefaler ofte 15 – 20 minutter, først i en retning, og etterpå i den andre.  Dette forutsetter en rundbane.  Dette har jeg mulighet for ut fra programmeringssporet, men igjen forstyrrer dette trafikken – fordi deler av runnbanen er hovedlinjen.
9. Jeg har ofte ønsket å teste/innkjøre lok før DCC dekoder installeres.  Ved innkobling av likestrømskontroller, blir viktige deler av hovedlinjen utilgjengelig for andre tog, slik at denne muligheten sjelden benyttes.
10. Anlegget er plassert på et loft.  Mye av uviklingen av programvare og elektronikk ønsker jeg å gjøre et annet sted.  Modulen er for stor og tung til at jeg lett kan flytte den (bære den ned en trapp alene), og det er for mye arbeid å fjerne tog fra modulen, og koble fra FREMO grensesnittet.

Programmeringssporet 2.0 skal benyttes til videre utvikling.

Første versjon av kravspesifikasjonen for denne er :

1. Modulen skal være lett, og liten, slik at den kan flyttes enkelt. Mål: vekt under 5 Kilo.
2. Skal ha mulighet for enkel prøvekjøring, uten å benytte hovedspor.
3. Skal ha rundbane på modulen.
4. Skal ha Fremo grensesnitt i en ende, men vil ellers ikke følge normen (bl.a. fordi jeg må ha krappe svinger).  Skal også kunne fungere som en snumodul.
5. Ca. 150 cm lang.
6. Skal ha Minimal bredde, men må kunne ha en sirkel (Roco R2, eller Trix R1 – ca. 36 cm radie). Sidespor kan benytte Roco R1, men alle lok må kunne benytte modulen/programmeringssporet uten å kjøre inn på R!)
7. Skal inneholde en Inglenook  ( https://en.wikipedia.org/wiki/Inglenook_Sidings" rel="nofollow - https://en.wikipedia.org/wiki/Inglenook_Sidings ) – som  skal kunne brukes uten å påvirke trafikk på hovedlinjen.
8. Skal være mulig å kjøre tog automatisk, både Digitale og Analoge lok samtidig, ved hjelp av tradisjonell blokkstyring.
9. Skal være mulighet for stalling av minimum 5 lok på sidespor,  både digitale og analoge.
10. Hele modulen skal være styrt i realtime ved hjelp av Arduinoer hvor responstider er konstante.(ingen PC’er / Raspberry Pi hvor responstider er variable).
11. Kun en strømforsyning til modulen (sansynligvis 12 eller 15 eller 19 volt likestrøm)
12. Ethernet og/eller Can-Bus for kommunikasjon mot andre moduler / PC.
13. DCC kablingen skal optimaliseres – og unngå bruk av diode-drop detektor, kun ”current Transformer block detector” og IR (Infrarød deteksjon)

Her er første skissen av en mulig løsning, hvor sporene går i to høyder.  Togene kommer inn over Fremo grenssnittet.  Etter ”stasjonen” kjører de en etasje ned i modulkassen.

Denne skal testes med Trix skinner.

1. Spor over to etasjer med for stor stigning mellom etasjene.
2. Den er for stor.  
3. Den er for kompleks, og tar for lang tid å lage.

1. Velleman strømforsyningen har RS-232 for tilkopling til PC.  Denne protokollen er relativt godt kjent så det er et reelt alternativ å lage et program for å lese strømforbruket fra  strømforsyningen.
2. Kople opp en strømmåler til en Arduino og logge derifra.

Arduino  - strømmåling

http://www.sparkfun.com/datasheets/BreakoutBoards/0712.pdf" rel="nofollow - Allegro ACS712 kan benyttes til dette.  Dette er en Halleffekt basert strømmåler, slik at Arduinoen kan være elektrisk isolert fra kretsen som måles..  Jeg benytter en 5 Ampere version av ACS712.  Den skal strømforsynes med 5 Volt og sender ut et Analogt signal, 1.5 Volt når det går -5 Ampere gjennom kretsen . 2.5 Volt når det ikke går strøm, og 3.5 Volt når det går 5 A gjennom kretsen.  Ved å kople denne til Arduino Analog 0, kan jeg måle strømforbruket med denne Sketchen :

int sensorValue;void setup(){

 Serial.begin(9600);  // sets the serial port to 9600

}

void loop(){

sensorValue = analogRead(0);       // read analog input pin 0

Serial.println (sensorValue, DEC);  // prints the value read

delay(100);                        // wait 100ms for next reading

}

Her får jeg direkte verdien fra Arduino Analog les.  Denne varierer mellom 0 og 1023 (10  bits oppløsning).  Jeg får derfor verdien 512 for 0 A. (2.5 Volt).  Jeg ser at verdien øker når loket kjører – men det ser ut som om oppløsningen er for liten  til å måle små endringer i strømforbruket, som når loket kjører inn i en skarp kurve.