Tonen daadwerkelijke snelheid.

[Max Roodveldt]

Het komt volgens mij omdat de ingangssignalen af en toe niet duidelijk genoeg gedefinieerd zijn. Waarom weet ik nog niet.
Als ik het goed heb gebruik je weerstanden van 47k - kan je er paar van 10k in solderen? Die maken mogelijk het signaal voor de Arduino wat harder.

Hoe lang doet je trein er over het blok te passeren Als dat langer duurt dan de tijd dat de snelheid wordt weergeven wordt mogelijk de meting opnieuw gestart. De display tijd staat op dit moment op 5 seconden (5000 ms). Na afloop van die tijd dienen alle twee de melders vrij te zijn.

Je vertelde dat de afstand tussen melding 1 en melding 2 ongeveer 3500 mm is. Hoe groot is de afstand tussen melding 2 en melding 1 

mvg

[peterha]

Ik gebruikte inderdaad 47k, ik zal er vanmiddag 10k in solderen.

Bij een snelheid van 100 à 110 km doet de trein er 10 - 12 seconden over om het meetblok (= blok6 = 3660 mm) door te rijden. Bij actief worden van bm2 = inrijden blok 7 dient de meting te stoppen; blok 7 is ook 3660 mm lang. Ergo, na ook zo'n 12 seconden gaat bm2 uit/laag.

Wat bedoel je met "..afstand tussen melding 2 en melding 1.."?
De afstand tussen melding 1 en melding 2 is 3660 mm en aangezien ik maar een richting op rij, is er geen meting c.q. melding van melding 2 naar melding 1.

Of bedoel je daarmee de hele baan rond? Het traject waarin blok 6 zit, bestaat uit 8 blokken [1 t/m 8]. De afstand van begin blok 7 + blok 8 + blok 1 + blok 2 + blok 3 + blok 4 + blok 5 is in totaal 22590 mm.

Gr. Peter

[Max Roodveldt]

Dus er is een moment waarop beide blokken bezet gemeld worden; namelijk als de locomotief van het ene blok in het andere rijdt. Dat is het moment waarop de invoer fladdert. Zijn er wagens met geleidende assen die eventueel voor valse meldingen kunnen zorgen

Op dit moment meten we de opgaande flank van het signaal. Op de blokgrens komen die van twee blokken. Dus of we moeten de tijdsduur van het signaal meten, maar dat heeft als nadeel dat de lengte van de locomotief meetelt of we moeten een blok overslaan.

Probeer het eens als volgt: eerste melding van blok 6, tweede melding van blok 8. Als het tussenliggende blok 7 langer is dan de trein krijgen we gescheiden meldingen die elkaar niet overlappen. Dan zou het goed moeten gaan... 

mvg

[peterha]

Ik heb ondertussen de weerstanden van 10K er tussen gedaan, maar dat biedt ook geen soelaas.
Alleen bij het opstarten en/of resetten van de Arduino blijven de streepjes vast, maar zodra een meting gestart is en de streepjes gaan knipperen, blijven ze knipperen en komt er dus ook geen goede melding.

Juist om te voorkomen dat wagons bij meldingen c.q. blokovergangen roet in het eten gooien, heb ik de vorige (en ook deze) testen uitgevoerd met alleen de loc; dus niets erachter.

En het is juist dat bezetmelders 1 en 2 tegelijk branden/actief zijn wanneer de loc over deze blokscheiding rijdt.

Ga je suggestie even proberen door de tweede melder een positie/blok op te schuiven.
Wordt vervolgd 

[Max Roodveldt]

Het heeft even geduurd maar  ik denk dat 't muntje is gevallen... 

Het eerste signaal duurt 10 seconden (blok 6)
Het tweede signaal duurt ook 10 seconden (blok 7)
Na de opgaande flank van blok 7 laat het display 5 seconden de snelheid zien.
En dan is het tweede signaal nog niet weg en start de meting opnieuw - maar nu vanaf de andere kant.
En eindigt de meting met het opnieuw inrijden van blok 6...

Dus moet je de display tijd verhogen - maak 'm langer dan de rijtijd door blok 7 - dus pakweg zo'n 15 seconden.
Door de variabele showtime van 5000 te veranderen in 15000.

mvg

[peterha]

Ik ga dat straks proberen, maar ondertussen was ik aan het testen met je vorige opmerkingen.

Ik heb de signaaldraad een melder opgeschoven en de meetafstand dienovereenkomstig verlengd, maar ondanks dat na het opstarten of resetten de streepjes vast bleven en daardoor wel een goede meting kon plaatsvinden, gingen ze weer knipperen nadat de meting afgelopen was.

Ik dacht dat het misschien toch aan de weerstanden lag, dus ik heb die van 47k er nu weer tussen; maar het euvel bleef.

Oké, ga weer naar boven om e.e.a. aan te passen en testen.

" I'll be back....." 

[peterha]

Dit is wel 'n oplossing 

Ik heb de connectors weer op de oorspronkelijke posities gezet en het meettraject aangepast naar 3660 mm. Met de instelling van een langere display-tijd blijven de streepjes na het verstrijken weer 'vast'. Dit gaat dus goed, maar met alleen één loc.

Vervolgens heb ik er weer de wagons achter gehangen, zodat het weer een trein is, maar nu gaat het weer fout; de trein is te lang (180 cm) en is het blok nog niet uit voordat de melding weggaat. Dus knipperen de streepjes weer.
Heb vervolgens de wachttijd op 20000 ms gezet en toen ging het weer goed.

Maar met een langere trein (248 cm) gaat het weer fout; ook deze is dan weer te lang. Door nu de wachttijd op 25000 ms te zetten, gaat het weer wel goed.

Ik betwijfel echter of dit dé oplossing is, zeker wanneer de treinbaan in automatisch bedrijf is en er meerdere treinen rijden.
Net nog even gekeken, maar het komt (makkelijk) voor dat twee opvolgende blokken bezet zijn door twee elkaar volgende treinen. Ze zullen niet elkaars blok inrijden, daar zorgt iTrain wel voor, maar wanneer dit in blok 6 en blok 7 (het meettraject) gebeurt, gaat de meting fout.

Is het een oplossing door de code wat 'uit te kleden' zodat alleen gekeken en gereageerd wordt op enkel de bezetmelding van melder 1 en melder 2, zonder dat gewacht moet worden dat de display tijd voorbij is?
Misschien een (te) simpele vraag van een niet-programmeur...

Gr. Peter

p.s. dit houd je wel van de straat, hé? 

[Max Roodveldt]

Nee, dit is niet "de" oplossing, maar maakt wel het probleem duidelijk.

Als eerste ga ik de code aanpassen voor eenrichtingsverkeer, zodat de meting alleen start bij het eerste blok en stopt bij het tweede blok.
Precies datgene wat jij al voorstelt. Dan moet het werken en is de displaytijd niet langer van invloed. Een nieuwe meting kan pas plaats vinden als het tweede blok ook verlaten is. Denk ik...

wordt vervolgd.

ps - er is hier op straat toch niets te beleven... (aan de overkant is een begraafplaats...)

[peterha]

Een nieuwe meting kan pas plaats vinden als het tweede blok ook verlaten is. Denk ik...

Hoewel het in praktijk ook voorkomt dat twee blokken achter elkaar bezet zijn... Wat dan?
Misschien toch handiger om te meten met IR of LDR en over een kortere afstand?
Of wordt dit nu een uitdaging die we toch gaan oplossen? 

(aan de overkant is een begraafplaats...)

Nou ja, dan heb je daar ook weinig last van 

[Max Roodveldt]

Hoewel het in praktijk ook voorkomt dat twee blokken achter elkaar bezet zijn... Wat dan?

Maar je gaat toch geen snelheid meten als het volgende blok bezet is...

Misschien toch handiger om te meten met IR of LDR en over een kortere afstand?

Dat nooit. Je hebt de perfecte melders liggen...

Of wordt dit nu een uitdaging die we toch gaan oplossen? 

Yep...

Wordt vervolgd...

[peterha]

Maar je gaat toch geen snelheid meten als het volgende blok bezet is...

Wat ik bedoel te zeggen is, dat de Arduino staat ingesteld om snelheid te meten wanneer melder 1 getriggerd wordt en meet wanneer melder 2 getriggerd wordt.

In het geval er twee treinen dicht achter elkaar zitten, dus trein 1 zit in het tweede blok en trein 2 rijdt het eerste blok binnen, vindt er geen accurate melding plaats. Maar, aangezien het volgende blok bezet is, zal de trein toch moeten afremmen en geldt die snelheid niet. Dus waar maak ik me druk om?

Peter

[Max Roodveldt]

De meting begint als de trein het eerste blok in rijdt. Dan wordt melder 1 hoog.
De meting stopt als de trein het tweede blok in rijdt. Dan wordt melder 2 hoog.
Dat zijn twee duidelijk gedefinieerde kantelpunten.

Om eenduidig te kunnen meten moeten dus - voor dat de meting begint - beide blokken leeg zijn.
Want bij een bezet blok is de melder al hoog en is er geen opgaande flank.

Dus zit ik nu te bedenken hoe ik dat programmatisch zeker kan stellen - en aan kan geven...

Want er zijn vier mogelijke standen:

• gereed om te meten = "----"
• metende = knipperen
• uitslag = "123.4"
• niet gereed om te meten = ?

en voor die 4de heb ik nog niets...

- of ik moet het resultaat pas laten verdwijnen als beide blokken weer vrij zijn... 

[peterha]

Lastig,

Even kijken....

Niet gereed om te meten, betekent dat melder 2 nog hoog is (blok is bezet), waarbij melder 1 al hoog wordt, terwijl melder 1 al eerder laag is geweest.

Dat kan alleen als een nieuwe trein al blok 1 binnenrijdt, terwijl de oude trein zich nog in blok 2 bevindt.

Want als -als gevolg van een hele lange trein- melder 2 hoog wordt terwijl melder 1 nog hoog is (en niet al laag is geweest) is het een geldige meting.

Volgens mij is dit een situatie waarin geen correcte meting gedaan kan worden?

Je zou dan het display blank kunnen laten, dus niet "----" vast of knipperen, maar leeg.
Als het resultaat blijft staan en pas verdwijnt als beide blokken vrij zijn, zou het verwarring kunnen geven doordat gedacht wordt dat er toch een nieuwe meting gedaan is.

Wat vind je van deze casus?

[Max Roodveldt]

Ik weet 't nog niet - blank laten kan worden verward met defect.
Nog maar even over nadenken - zou je in de tussentijd iets willen proberen?

Code: [Selecteer]

/*****************************************************************************
test versie: Speedometer tbv Peter
*****************************************************************************/

// libraries
#include <Wire.h>
#include "Adafruit_LEDBackpack.h"
#include "Adafruit_GFX.h"

Adafruit_7segment display = Adafruit_7segment();

const int section1      =     A0; // first section
const int section2      =     A1; // second section

const int Overflow      =  10000;
unsigned long curTime   =      0;
unsigned long preTime   =      0;
unsigned long runTime   =      0;

// speedometer
bool  sect1occup        =  false;
bool  sect2occup        =  false;
bool  timerRuns         =  false;
bool  calcReady         =  false;
int   valSect1          =      0;
int   valSect2          =      0;
int   threshold         =    511; // 0 is uit, 1023 is aan
float distance          =   3450; // afstand tussen meetpunten in mm.
float scaleSpeed        =      0; // in schaal km/h.

/****************************************************************************/

void setup() {
 
  // set display
  display.begin(0x70);
  display.setBrightness(7); // 0..15
  display.writeDisplay();

  Serial.begin(9600);
  Serial.println("Check inputs");
 
  display.println(Overflow);                                 // display "----"
 
} // end setup

/****************************************************************************/

void loop() {
   
   speedometer();
   displaySpeed();
 
} // end loop

/****************************************************************************/

void speedometer() {
 
  valSect1 = analogRead(section1);
  valSect2 = analogRead(section2);
 
  if (valSect1 > threshold) sect1occup = true; else sect1occup = false;
  if (valSect2 > threshold) sect2occup = true; else sect2occup = false;

  if (!timerRuns) {                                         // nog geen meting

    if (sect1occup && !sect2occup) {                          // meting begint
      timerRuns = true;                                       
      preTime   = millis();
      runTime   = 0;
     
      Serial.print("sector 1 = "); Serial.println(valSect1);
    }

  } else {                                           // als de meting loopt...
 
    curTime = millis();         
    runTime = curTime - preTime;
   
    if (sect2occup) {                                      // meting ten einde
                                                    // bereken schaal snelheid
      scaleSpeed = ((distance * 3600) / runTime / 1000) * 87;
      calcReady  = true;
      timerRuns  = false;
     
      Serial.print("sector 2 = "); Serial.println(valSect2);
      Serial.print("   speed = "); Serial.println(scaleSpeed, 1);
    }
  }
}

/****************************************************************************/

void displaySpeed() {

  if (timerRuns) {                         // als snelheidsmeting gaande is...
   
    if ((runTime / 100) % 2) {                            // knipperen display
      display.println(Overflow);                             // display "----"
    } else
      display.clear();                                       // display "    "
   
  } else {

    if (calcReady) {                        // als snelheidsmeting klaar is...
        display.print(scaleSpeed, 1);      // display gemeten snelheid in km/h
        if (!sect1occup && !sect2occup) calcReady = false;
      } else {
        display.println(Overflow);                           // display "----"
      }
  }
   
  display.writeDisplay();
}

/****************************************************************************/

Dit is een eenrichting versie... (alleen even de afstand aanpassen)

Wordt vervolgd

[Timo]

Ik zie dat er aardig bezig is geweest hier 

@Peter, zijn al je blokken maar voorzien van één melder? Maar inderdaad, als de trein niet normaal kan doorrijden is de meting toch niet "goed". Het is nog steeds de gemiddelde snelheid 

Zelf had ik met de code doorlopen ook al gezien dat er geen blokkade zat om een nieuwe meting te starten als de melder nog bezet was.

Zelf heb ik ook niet stil gezeten. In eerste instantie ben ik aan de slag gegaan met de code van Max. Alleen zoals gezegd, wilde ik het geschikt maken voor meerdere systemen en display's. De code raakte dus nogal aangepast  Om te proberen heb ik even snel een display wat ik had liggen van stal gehaald. Een 128x64 I2C OLED met SSD1306 controller. Maar in principe is de code nu makkelijk te gebruiken met andere schermen  Zo heb ik het goedkope Banggood scherm ook binnen en daar wil ik hem eigenlijk aan hangen. Maar hiermee heb ik nog niet gespeeld. Omdat beelden meer zeggen, hier een filmpje.

Deze zou ook moeten werken met het Adafruit 7-segment display wat jullie (Peter en Max) hebben. Alleen laat de Arduino IDE me even vallen, Daar zo over meer. Maar toen ik de library van het display door keek schrok ik wel van de functie om getallen te printen op dat scherm. Of eigenlijk, om alles te printen op dat scherm. Ze hebben wel een hele fool-proof code gemaakt maar de methode die ze moeten gebruiken, mm. En dat vooral om de stomme floats te kunnen ondersteunen. Zelf heb ik het dus ook niet op basis van float gedaan maar gewoon met unsigned int. De snelheid berekenen komt dan neer op ((36UL * distance * scale + (time / 2)) / time ) en geeft 10x de snelheid. Later zet ik er nog een komma tussen om 1 getal achter de komma te hebben. Klinkt omslachtig maar is wat ze na veel code (om floats te ondersteunen) ook in de 7segment library doen.

Goed, en toen wilde ik me code hier plaatsen maar heb ik iets gedaan waardoor het compleet niet meer werkt  Dat moet dus even wachten.

Wel zat ik met een gek probleem. Ik probeerde met een #define de juiste delen van de code te laden voor het juiste scherm. Zolang ik #define LCD_TYPE 1 had staan werkte alles prima. maar maakte ik er een 2 dan dan krijg ik opeens function not defined in this scope.  Ik heb het probleem terug kunnen brengen naar:

Code: [Selecteer]

#define TEST 1

#if (TEST == 1)
  byte varname = 1;
  //const byte bla = 2;
#endif
#if (TEST == 2)
  const byte bla = 2;
#endif

void setup() {
  // put your setup code here, to run once:

}

void loop() {
  // put your main code here, to run repeatedly:

}
Zolang TEST i 1, dan is er geen probleem. Maar zodra je er een 2 van maakt is het mis. En het gaat dan ook alleen mis als je ergens daarin een variable probeert te maken. Ik snap even niet meer waarom.


Timo