Modelspoorforum.nl

Oke terug wat tijd voor mijn treintjes. Een update uitgevoerd op de YD7001 en de laatste versie van iTrain op een M2 MacBook Pro met een USB connectie tussen computer en controller. Detectie wordt gedaan met een YD6016LN-CS. Alles werkt, dus ikke gelukkig.

Ik heb een test ovaal liggen waarin ik ook een strook heb opgenomen om snelheidsmeting te doen (centrale melder met zijmelders). Wat testjes gedaan en alles blijkt te werken. Nu het echte werk. De eerste loc die ik begin te testen, geeft een heel rare snelheidsgrafiek, met serieuze sprongen op en neer. Mijn eerste idee, ik moet iets doen aan de lastregeling van de loc. Een tweede loc van een andere fabrikant ... je kunt het raden ... net hetzelfde. Wat is er aan de hand? Slechte Locs?

Ik ben uiteindelijk manueel gaan tijd registreren, terwijl de lok rondjes reed en we een snelheidsmeting deden. De loc begint op de hoogste snelheid. Met mijn chronometer, nam ik steeds de lap tijden. De tijden gingen mooi lineair omhoog, maar in iTrain, nog steeds een grimmige grafiek.

Nu begin ik te denken dat het ligt aan het detecteren en het doorgeven aan iTrain. Als er hier soms wat vertraging op zit dan gaat de meeting de mist in.

Enig idee wat er mis gaat? Ligt het aan mij?

[EDIT] Nog wat gelezen hier en op iTrain forum. Er zitten Piko locs tussen, maar de raarste grafieken krijg ik met een Loc van Roco (73227) en eentje van Trix (25595)

[EDIT2] USB vervangen door LAN ... zelfde probleem

Ikke schreef:Oke terug wat tijd voor mijn treintjes. Een update uitgevoerd op de YD7001 en de laatste versie van iTrain op een M2 MacBook Pro met een USB connectie tussen computer en controller. Detectie wordt gedaan met een YD6016LN-CS. Alles werkt, dus ikke gelukkig.

Ik heb een test ovaal liggen waarin ik ook een strook heb opgenomen om snelheidsmeting te doen (centrale melder met zijmelders). Wat testjes gedaan en alles blijkt te werken. Nu het echte werk. De eerste loc die ik begin te testen, geeft een heel rare snelheidsgrafiek, met serieuze sprongen op en neer. Mijn eerste idee, ik moet iets doen aan de lastregeling van de loc. Een tweede loc van een andere fabrikant ... je kunt het raden ... net hetzelfde. Wat is er aan de hand? Slechte Locs?

Ik ben uiteindelijk manueel gaan tijd registreren, terwijl de lok rondjes reed en we een snelheidsmeting deden. De loc begint op de hoogste snelheid. Met mijn chronometer, nam ik steeds de lap tijden. De tijden gingen mooi lineair omhoog, maar in iTrain, nog steeds een grimmige grafiek.

Nu begin ik te denken dat het ligt aan het detecteren en het doorgeven aan iTrain. Als er hier soms wat vertraging op zit dan gaat de meeting de mist in.

Enig idee wat er mis gaat? Ligt het aan mij?

[EDIT] Nog wat gelezen hier en op iTrain forum. Er zitten Piko locs tussen, maar de raarste grafieken krijg ik met een Loc van Roco (73227) en eentje van Trix (25595)

[EDIT2] USB vervangen door LAN ... zelfde probleem

Zijn de lengte van de rails en eventuele wissels correct nauwkeurig ingegeven in iTrain. Nu lijkt me dat een kleine kans hebber maar zou kunnen. Ook zou ik eens een derde LOC er opzetten die digitale al afgeleverd is van fabriek. Wie weet heb je pech en zijn de eerste 2 locs niet lekker.
Wat voor detectie melders gebruikt u?
In iTrain heb je alleen een aantal stukken geïsoleerd rails nodig en exact ingegeven lengte van rail voor het meten van de snelheid met een terug melding, liefst met current- of opto detectie.

De snelheids test grafiek word uitgevoerd middels 3 geïsoleerde blokken, eens ff kijken over welke blokken hij heen en weer gaat en dan buiten die blokken de ovaal op 1 plek onderbreken, zodat de spoel/Coil werking teniet is gedaan.
Afijn, zijn tips, er zullen leden zijn die nog veel slimmere ideeën hebben!
Met vr gr Blauwe Koelkast

Verzonden vanaf mijn iPad met Tapatalk

Bedankt voor jouw antwoord ... ik heb in totaal getest met 8 locs. Om een punt-hoofd van te krijgen. Ik gebruik een Yamorc YD6016LN-CS als stroom detectie.

De foute detectie valt natuurlijk het meest op bij de hogere snelheden. Maar ik krijg geen concequent resultaat. De meetfouten lopen natuurlijk op. In elke stap zal er wel een bepaalde vertraging zijn en die vertraging is.

Stappen:
1. Yamorc YD6016LN-CS detecteert stroom op een poort.
2. Yamorc YD6016LN-CS stuurt een Loconet bericht naar YD7001
3. YD7001 stuurt bericht naar MacBook Pro M2 (via LAN of USB)
4. Mac OS 13.4.1 stuurt bericht naar iTrain
5. iTrain verwerkt gegevens

Ik ga voor hogere snelheid een een langer traject proberen om de procentuele fout te verkleinen.

Ben ik echt de enigste die hier tegenaan loopt?

ja word wel een raadsel, ik zou bijna denken dat de loconet data verstoord is.!


Verzonden vanaf mijn iPad met Tapatalk

Heb je gedetecteerde en ongedetecteerde stukken in je meettraject ??

Zo ja, waarmee voed je de ongedetecteerde ?

Andere optie: Antislipbandjes; Roco monteert die notoir al ruim 25 jaar aan de verkeerde kant van het draaistel: Namelijk als eerste wielstel. Dit omwisselen met het andere wielstel, zodat de metalen wielen altijd (!!) als eerste de detectie veroorzaken.

Groet,
Karst

Ongedetecteerde stuk wordt momenteel rechtstreeks gevoed. Dus we hebben daar een spanningsverschil … dar ga ik aanpassen.

Maar ik vermoed niet dat het de hoofdoorzaak is. Als ik met de hand de tijd opneem, dan heb ik een vlakke grafiek, zelfs rekening houden met de meetfouten. De fouten in iTrain zijn veel groter.

Ik vermoed dat het gewoon vertragingen zijn zoals eerder beschreven en bij hoge snelheid kan je dan beter een veel langer traject gebruiken. Ik ga alleen eens moeten zien hoe stabiel ik de snelheid kan houden, maar dat gaat ook afhangen van de individuele lok.

Bedankt iedereen voor de reacties.

Nee, hoor,

Dat maaktg wel degelijk uit, bij ongedetecteerd -> gedetecteerd krijg je een onbetrouwbaar meldpunt. En dat kan oplopen in het ongustigste geval tot een complete loc-lengte ...

Simpel oplossen: (eventueel tijdelijk) die ongedetecteerde sectie ook aansluiten op een uitgang van de terugmelder.

Suc6,

Karst

Zal testen ... later meer.

Ben zeer benieuwd wat den oorzaak is.
Karst, ook groeten von Herr Dirk te Zevenbergen BlauweKoelkast


Verzonden vanaf mijn iPad met Tapatalk

Nop niets ... allemaal nieuwe draden, alle stukken spoor lopen nu via de detectie en exact dezelfde resultaten. Met stopwatch krijg ik perfect oplopende tijden ... in iTrain een onregelmatige grafiek met metingen die ver van elkaar liggen.

Mijn meetstuk is 23cm en dat is volgens mij veel te kort voor de hogere snelheden, zeker met de ketting van vertragingen die kunnen oplopen en zo het percentuele meetverschil kunnen verklaren. De impact bij lagere snelheden is daarom veel kleiner. Ik ga later eens testen met een veel langer meerstuk voor de hogere snelheden, maar ik moet dringend wat werken .

aha... 23cm is idd veel te kort.

Koploper schreef destijds minimaal 100cm tussen de beide melders voor....

Ligt aan de meetmethode in iTrain

Bij gebruik van 2 melders is inderdaad 50-100 cm gebruikelijk. Bin een centrale melder en zijmelders is een centrale melder van 20 cm lang genoeg.

De vertragingen in de decoder zetten we tijdens het ijken op waarde 0! Tenzij je een functie hebt die de CV3 en CV4 uitschakeld.

De metingen met een centrale melder van 20 cm zijn accuraat genoeg. De Ucon Railspeed doet het zelfs maar met 10 cm en is nauwkeurig.

Een lange meetsectie geeft op hoge stappen meer nauwkeurigheid. Echter geeft dit voor lage stappen meer ruimte voor fouten.

Gaan we kijken naar effectieve metingen dan wil je liever nauwkeurigheid in de lage stappen, de hoge stappen vallen niet op dat een trein iets harder rijd dan gemeten.

ITrain corrigeert daar ook op, de lage stappen.

Als je grafiek stekelig is duidt dat vaak meer op een slecht afgestelde lastregeling dan een foutieve meting. Een foute meting is incidenteel, een foute lastregeling merk je over een bredere band aan stappen.

Maar je kunt jezelf afvragen hoever je hierin een autisme moet voeden. Het visuele resultaat lijkt mij belangrijker als de theorie. Als de trein mooi rustig rijd, en netjes stopt heb je het goed gedaan.

Resumé als vuistregel

Meetsectie kort: betere meting de lage stappen
Meetsectie lang: betere meting op de hoge stappen

Aan jou de keuze wat je belangrijker vind.

Verstuurd vanaf mijn SM-S916B met Tapatalk

Als het aan de last regeling zou liggen, dan zouden de tijden ook variëren bij manuele tijd opname. Ik gebruik de oplossing centrale melder met twee zij melders.

Ik maak me eigenlijk ook geen zorgen om automatisch te rijden. Maar ik test momenteel al de componenten en weet graag wat er gebeurt.


Sent from my iPhone using Tapatalk

Ik denk niet dat manueel qua timing kan winnen van elektronische meting. Dat zou wel heel bijzonder zijn. De menselijke reactievertraging is daar te hoog voor.

Bij manueel denk ik aan een handbediende stopwatch of iets in die geest.
Daarom vraag ik me ook sterk af of deze vergelijking zinvol is.

Het enige wat je volgens mij verkeerd hebt gedaan is ongedetecteerde secties gebruiken terwijl dat tegenwoordig niet meer wenselijk is.

Voor de rest, gewoon lekker genieten, als je melders het doen, dan is het goed. De kans dat ze te traag melden is nihil, dat zal ook pas effect hebben als de melders onderling verschillende vertragingen hebben. Als alle melders dezelfde vertraging hebben heft het zich gewoon op.

Mocht je het anders zien dan kan dat, ik ben hier ook niet heilig in. Alleen praktisch ingesteld.

Groetjes





Verstuurd vanaf mijn SM-S916B met Tapatalk

Die ongedetecteerde secties heb ik weggewerkt. Die hadden geen invloed meer. Ik liet eerst de loc rondjes rijden op maximale snelheid. Ik nam de tijd per ronde op een vast punt. Voorbeeld met een Trix stoomloc was rond de 11,30 seconden op maximale snelheid. Ik ben het ermee eens dat mijn reactie snelheid niet dat is, maar ik zat plus minus 0,2 seconden naast.

Dan start de meeting in iTrain. Ik nam nog steeds de tijd op. Die tijden per ronde gingen mooi omhoog en mijn stopwatch (iPhone app) liet mooi de ronde tijden zien. Maar de snelheden in iTrain waren zoals eerder beschreven.

Maar zoals jullie reeds aangaven, het zijn de lagere snelheden die belangrijk zijn voor het rijden in iTrain.

Ikzelf ga ook voor de praktische kant, maar de ingenieur in mij wil graag begrijpen hoe het allemaal werkt. Dank u allen voor de hulp en ik heb mijn strategie voor het opmeten van snelheden.

Stap 1. Kies methode met centrale melder en twee zij melders
Stap 2. Kies lange centrale melder voor hoge snelheden en laat loc rondjes rijden, niet van richting veranderen. Doe tweede meeting voor andere richting.
Stap 3. Kies korte centrale melding voor lage snelheden en doe de door DTS reeds gedocumenteerde metingen.

Tada nu heb ik een mooie grafiek

Bedankt
Dave

p.s. Dat haar was al lang niet meer aanwezig

Dave en Martin,

Ik rij al jaren met iTrain icm met Dinamo, 15 volt op de baan, mijn ijkspoor centrale melder is 52 cm en is gewoon goed.

Sommige lokdecoders icm merk locomotief geeft ook bij mij in het begin een zaagstand tussen CV20 en CV 27. Tot middelspanning loopt de ijking mooi in lijn en daarna wordt de zaagtand zichtbaar. Ik verlaag hierbij CV5 (gewoon mee spelen totdat je een mooie lijn heb en je gewenste maximaal rijsnelheid). Bij mij op de baan rond 100 km per uur, wat dat nu allemaal is weet ik ook niet met de smd componenten wil ik het ook niet snappen. De locomotief moet gewoon lekker rijden op de baan en iTrain behoort de rest de doen.

23 cm is inderdaad erg klein ik heb hier een meetstuk van 1.5 m (voor h0) en dat gaat precies goed.
Wat mij wel bevreemd is dat de snelheid vooruit - achteruit significant verschild .