Tonen daadwerkelijke snelheid.

[peterha]

Timo,

Wat Max al suggereerde: ik snap hier dus weinig van. Kiezen uit LOW of HIGH is voor mij duidelijker 

Verder even een start gemaakt met testen, maar meteen wordt gezegd dat er geen Adafruit SSD1306.h file of library is. Terwijl de vorige versie wel werkte.

Ik krijg er nu geen leven in, dus ga morgen maar verder kijken.

Overigens, wat Max zegt van drie streepjes, dat klopt; had ik ook.

Gr. Peter

[Timo]

@Peter, dan ga ik er ACTIVE_LOW en ACTIVE_HIGH van maken ook al kijk ik nooit naar ACTIVE_HIGH 

En als je met testen die error krijgt dan heb je niet het juiste display geselecteerd. Dan staat deze nog op 1 (#define LCD_TYPE 1) terwijl jij 1 nodig hebt. SSD1306 is de driver van mijn OLED display en hiervoor heb jij de library niet uitgepakt (ook niet nodig voor jou). Even op 2 zetten zou het moeten verhelpen.

@Max, goed om te horen! Werkt de "animatie" ook?

Net even snel gespeeld met het goedkope 7-segment schermpje. Morgen er even snel een library voor schrijven Vandaag iig al uitgevonden hoe ik elk segment aan krijg, dat is al heel wat.  De boel er gewoon uit pompen met shift out Als dat dan helemaal werkt heb je best iets leuks voor minder dan €5,- 


Timo

[peterha]

Timo,

Ook bij mij werkt het; de animatie, de meting vooruit en de meting achteruit. 

Dat ik die error kreeg omdat ik het juiste display niet had geselecteerd, wist ik. Alleen ik wilde gisteravond 'nog even snel' kijken of 't werkte. En als je iets 'nog even snel' wilt doen, maak je fouten. Toen ik er daarna even rustig voor ging zitten, wist ik weer wat ik moest doen en daarna werkte het. 

Om dit te voorkomen (voor gebruikers zoals ik), is het wat om via de seriele monitor de gebruiker een aantal vragen te stellen en d.m.v. het ingeven van een cijfer een keuze te maken en die dan stoppen in een variabele?
Bv. 1 voor SSD1306 based OLED display, 2 voor Adafruit_SSD1306 display, 3 voor aaaa, 4 voor bbbbb en x voor zelf aanpassen; 1 voor ACTIE_LOW en 2 voor ACTIVE_HIGH; meetafstanden zelf ingeven etc, of is het makkelijker als de gebruiker zelf de code aanpast?

Gr. Peter

[Max Roodveldt]

@Timo
Ook de animatie werkt...

@Peter
Zo als jij het voorstelt zou inderdaad het eenvoudigst zijn maar er is een probleem: ruimte. Als je wilt kunnen selecteren als de Arduino al loopt moeten alle onderdelen van de software al in het programma zitten.

Door het te doen zoals Timo dat doet, worden alleen de geselecteerde stukken onderdeel van het programma en wordt voorkomen dat er ongebruikte onderdelen in de software zitten - onderdelen die wel veel ruimte innemen. Ruimte die er vaak niet is. Nadeel is inderdaad dat de selectie gemaakt moet worden voor het compileren; dus in de broncode. Maar er is niets wat niet met een duidelijke handleiding kan worden verholpen... 

Gelukkig kunnen we er wel van uitgaan dat niet iedereen elke dag van display en/of melders wisselt, zodat een keer compileren vaak genoeg is.

mvg

[peterha]

Ruimte die er vaak niet is

O.K., snap ik. Als ik in het onderste schermpje van de Arduino kijk, wordt er over bytes en enkele kilobytes gesproken. Dat is inderdaad niet veel: dus woekeren met de ruimte en dan is de code aanpassen de betere oplossing. 

Gr. Peter

[Timo]

Max heeft helemaal gelijk  Dat is de reden dat ik het zo doe. De 7-segment schermpjes nemen niet zo veel ruimte in, die zou ik bijna nog allemaal tegelijk kunnen laten aansturen (ook al is dat niet handig). Maar het schermpje van mij is (iig met deze library) een stuk hongeriger. En om het zo makkelijk mogelijk te doen heb ik zo veel mogelijk aanwijzingen in de code gezet. Zoals Max ook zei, het is iets wat je eenmalig doet. En voor de dingen die je misschien vaker wilt aanpassen (afstand, schaal) wil ik nog een (optioneel) menu inbouwen. Plaats je dan 3 knopjes is het zonder herprogrammeren aan te passen maar je kunt er ook voor kiezen geen knopjes te plaatsen en dit in te stellen met programmeren.


Timo

[peterha]

Het zal inderdaad vaak maar een eenmalige instelling zijn, er van uitgaande dat je dit op een baan gebruikt.
Met wat aanwijzingen in de code moet het inderdaad te doen zijn om (eventueel) de schaal en de afstand in te stellen.

Dan is het zo laten van de code (en het eventueel zelf aanpassen in de broncode) heel legitiem  .

gr. Peter

[peterha]

Max,
Inmiddels is het display ingebouwd en is de snelheidsmeting een actief onderdeel van de baan.
De snelheid gemeten met iTrain en de Speedometer komt tamelijk goed overeen. Dat het niet exact hetzelfde is, zal -denk ik- zitten in interne afrondingsverschillen?

Verschillende treinen gemeten. Resultaten bv.:
iTrain  <> Speedometer
 114,4        115,2
 117,4        118,0
 115,5        116,4
 109,8        110,6

Nogmaals erg bedankt voor de hulp en het delen van de code. Ik vond het een leuk project en voor een paar euro doet ie volgens mij hetzelfde als commerciele apparaten van 200 dollar.

Dat is dan fout - dat zal ik nakijken.

Is dit inderdaad een foutje en is het er al uit gehaald?

Timo,
Is het nog gelukt met het schrijven van een library voor het andere (goedkope) display?

Gr. Peter

[Timo]

Verschillen zijn inderdaad niet zo groot. Zit hem denk ik niet in het afronden maar in latency. Ik denk zelfs dat het display het beter heeft dan iTrain. Dit doordat de signalen die iTrain krijgt eerst uitgelezen moeten worden door de centrale via loconet waarna de centrale ze door moet geven aan iTrain. Hier kan best 1 of 2 ms vertraging in zitten. Nu is vertraging niet zo erg, immers als beide signalen 2ms later zijn is de tijdmeting nog prima. Maar dat is niet zo, de centrale doet gewoon zijn routines en trekt zich niets aan van een melder, die komen wel weer als hij daar tijd voor heeft. Voor eht rijden is het niet zo erg dat een melding niet direct aan komt (paar ms is nog steeds snel) en 1km/h verschil in een meting van schaalsnelheid (echte snelheid verschilt dus maar 1/87!) doet hem ook niet.

De Arduino heeft nu als hoofdtaak snelheid meten dus die zal minder verschillende latency (tijd tussen handeling en actie) hebben. Wel is de interne klok iets onnauwkeuriger maar dat zal echt klein zijn. Waarschijnlijk kleiner dan de latency verschillen.

Library voor het kleine scherm krijgt al vorm. Het scherm geeft al dingen weer. Nu alleen nog ff in de krochten van timer interrupts van AVR duiken. Die heb ik altijd iets verwarrend gevonden met al die verschillende registers... Dan laat ik de timer interrupt de multiplexing en het dimmen doen (display is wel erg fel!) Maar al met al moet het gewoon een algemene library worden waarmee dit display is aan te sturen voor welke toepassing dan ook. Gek genoeg heb ik die voor dit scherm nog niet kunnen vinden. Wel voor losse 7-segment schermen en voor 7-segment met controllers net als die van jullie (Adafruit 7-segement).

Maar goed, altijd leuk, verschillende display's. Kan ik daar eindelijk eens mee spelen. Heb nog wel wat verschillende liggen 


Timo

[gvandersel]

Is er ook een kleuren display?

Groet,

Gerard van der Sel.

PS. Overigens het is niet de latency die hier een rol speelt, daar jullie pollen en geen gebruik maken van interrupts. De snelheid van de Arduino is het meest nauwkeurig, omdat je bij iTrain naast de tijd om het signaal bij de PC tekrijgen ook nog het verschil in verwerking door het OS erbij krijgt. De iTrain tijd zal altijd een indicatie zijn, terwijl de Arduino tijd al redelijk nauwkeurig is. Nog even door naar interrupt verwerking en je krijgt inderdaad latency fouten.

[Max Roodveldt]

Peter,
ik ben blij dat je tevreden bent; uiteindelijk is dat het doel waar we naar streven...

Is dit inderdaad een foutje en is het er al uit gehaald?

Dat weet ik nog niet zeker. Het probleempje is dat ik het hier niet goed kan simuleren - ik test met drukknoppen. Misschien dat je het probleem nog een keer zou kunnen omschrijven? Het duurt bij mij altijd even voor dat het muntje valt...

mvg

[Timo]

Twee kleuren OLED kleuren genoeg? 

Zo ver ik weet zou ik het gewoon latency mogen noemen. Het is het verschil tussen stimulation (trein komt blok binnen) en response (iTrain slaat de tijd op).

De Arduino doet inderdaad aan pollen. Maar het heeft eigenlijk geen zin om naar interrupt over te stappen. De loop() doet 99% van de tijd amper iets (meeste werk is het afsluiten van de meting) en zal dus snel doorlopen worden. Komt bij dat we meten in ms, de afwijking daarin acht ik groter dan de response van de loop dus heeft het weinig zin naar een interrupt over te stappen. Toegegeven, het is niet lastig. Maar op deze manier is het makkelijk om ook analoge uitlezing te kunnen doen (iets dat ook extra latency brengt...)


Timo

[peterha]

Timo en Gerard, bedankt voor de uitleg en de aanvullingen. Geeft me toch een goed gevoel bij die Arduino. 

Max, ik zal hier komende tijd even rustig voor gaan zitten en kijken of ik 't kan reproduceren en zo ja het 'probleem' omschrijven.
Ook als het niet lukt, hoor je 't.

Gr. Peter

[peterha]

Het probleempje is dat ik het hier niet goed kan simuleren - ik test met drukknoppen.

Het is vanavond rustig, dus ik ben er eventjes voor gaan zitten, maar volgens mij moet je het met drukknoppen ook kunnen simuleren.

Wat is de situatie?
Wanneer trein A blok 1 binnenrijdt, wordt melder 1 hoog gezet, knippert het display en start de meting.
Wanneer trein A blok 2 binnenrijdt, wordt melder 2 hoog gezet, stopt het knipperen van het display, stopt de meting en wordt de snelheid getoond.
De snelheid blijft in het display totdat blok 2 verlaten wordt en melder 2 laag gaat.
Tot zover alles correct, toch?

Wanneer een (langzame) trein blok 1 binnenrijdt, wordt melder 1 hoog gezet en start de meting. Na het verlaten van blok 1 wordt melder 2 hoog gezet en wordt de snelheid getoond. Echter, nu kan een andere (snellere) trein blok 1 al binnenrijden, omdat deze door trein 1 al verlaten is. Wanneer trein 1 blok 2 verlaten heeft, toont het display knipperen ten teken dat de meting loopt, omdat melder 1 hoog is. Maar de trein bevindt zich al ergens in het blok. Ergo, de meting vindt niet plaats vanaf het begin = hoog worden van melder 1?

Je kan dit m.i. simuleren door drukknop 1 te activeren, daarna drukknop 2 in te drukken (als zijnde blok 1 verlaten en blok 2 binnengereden) en onderwijl alweer drukknop 1 in te drukken (als zijnde een nieuwe trein in blok 1).
Je geeft dan melder 1 al hoog terwijl melder 2 nog steeds hoog is. Volgens mij is dit de situatie.

Een ander vraagje.
Ik wil mijn Arduino voeden met een externe voeding.
In de omschrijving staat dat ik 'm kan voeden via usb of AC > DC adapter. Het aanbevolen voltage ligt tussen de 7 en 12 volt.
Ik heb diverse gelijkstroom adapters; 7V-300mA, 9V-500mA, 9V-1A of 12V-2A.
Welke raden jullie aan om te gebruiken? Zo'n Arduino is toch niet zo 'hongerig'?

Gr. Peter

[Max Roodveldt]

Peter,
ik snap 'm en ik zal er wat aan doen. Weet nog niet wat - er lijken meerdere oplossingen mogelijk...

En alle vier de voedingen zijn te gebruiken - dus neem de kleinste...

mvg