Vertraging camera - beeldscherm meten

ik denk dat je meer hebt aan een oude analoge scope.
komen hier en op marktplaats regelmatig voorbij voor weinig.

je pakt 2 lichtsensoren (fotodiodes werken het beste denk ik)

die sluit je aan op kanaal A en B van de scope.

je triggert op A

vervolgens plak je sensor A op een lampje en B op het display wat hetzelfde lampje opneemt.

vervolgens laat het het lampje bijv iedere 100 ms pulseren en lees je de tijd af op de scope.

pulseren kun je met een 555 of arduino wel maken.

En dan moet je de vertraging van je scherm zelf nog goed kunnen meten. Hoe wou je dat gaan doen?

Ook nog haha, het hoeft natuurlijk niet op de honderdste voor mij maar wat er met een budget mogelijk is en beter dan met de telefoon stopwatch foto methode.

Die gene met zijn arduino zegt een vertraging the hebben van 170uS tussen led aan en sensor opgepikt. Dat lijkt me acceptabel als ik ik ms wil meten.

In ieder geval alles bekabeld doen, niet draadloos. (want dat geeft al een bak vertragingen)
Zelfs bekabeld is nog lastig; bijv. USB kan een latency tot 12mS hebben...

Ik vermoed dat het hier om drone racen gaat, en dan is een kabel lastig..

Maar het is een goed idee om de test met en zonder kabel uit te voeren, zodat je een schatting maakt tussen het radio en LCD deel

Klopt het gaat om FPV camera's voor drones. Dat is 5.8ghz verbinding en ik gebruik voor alle tests dezelfde zender en ontvanger.

Wat ik wil aantonen is het verschil in camera vertraging.

Deze man gebruikt een arduino
https://oscarliang.com/fpv-camera-latency/

[Bericht gewijzigd door Dutch 79 op zaterdag 22 juli 2017 12:55:11 (25%)

Ha Dutch 79,

Misschien kan je met de Arduino een start/stop teller maken.
Maar je kan toch de camera zich zelf laten zien dan kan je frame op frame het tijdsverschil meten denk ik in ieder geval deed ik het zo in de analoge wereld.
Let er wel op dat indien je lange verbindingskabels gebruikt hier ook vertraging in gaat zitten dit geldt ook voor video verwerkings-apparatuur.

Groet Henk.

Hoi Henk,

Ik zou niet weten hoe een arduino te programmeren, haha.

Ik gebruik nu in totaal zo'n 10cm kabel tussen camera en VTX. Daar zit natuurlijk wel wat vertraging in maar uiteindelijk zal het bij iedere camera evenveel vertraging moeten zijn en is een verschil aantonen dus mogelijk.

Tenminste, in mijn hoofd nu nog in de praktijk.

Jasper

Ha Dutch 79,

Je probleem was duidelijk en je heb op dit moment niets met transmissie vertraging van doen maar let hier wel op in de praktijk is deze wel aanwezig.
De meting met de stopwatch is op zich qua bron goed het enige is je bent niet synchroon met de klok van je camera.
Je kunt je computer een klok laten weergeven 3 a 4 getallen achter de komma net als je stopwatch.
De camera richt je dan op het beeldscherm dit geeft als effect dat de camera zich zelf ziet maar met vertraging.
Je ziet dus het beeld van computer naar monitor en van camera naar monitor wat je wel nodig heb is programma (motion capture software) maar je zult nu ook zo iets gebruiken je lees dan direct de vertraging af op je beeldscherm.

Met de Arduino of liever gezet met een TIC (time interval counter) start je de teller op het moment je de lamp aanzet en via een detector gekoppeld aan de camera stop de teller het verschil in tijd is je vertraging.

Groet Henk.

Op 22 juli 2017 10:06:45 schreef Dutch 79:
Ik kom bij 6 cameras allemaal op zo'n 60ms uit wat mij sterk lijkt en te hoog is vergeleken met andere mensen die tests gedaan hebben.

Dat lijkt me in de moderne wereld een realistisch getal.

Op 22 juli 2017 12:23:29 schreef Dutch 79:
Die gene met zijn arduino zegt een vertraging the hebben van 170uS tussen led aan en sensor opgepikt.

Dat lijkt me onrealistisch. Een scherm wordt rond de 60x per seconde ververst. Dus 16ms per beeldje. Hoe kan je nu in godsnaam 170 us aan vertraging hebben tussen iets in de werkelijke wereld en op een beeldscherm krijgen?

Omdat hij met een arduino gekeken had naar de tijd die een led nodig had om aan te gaan en de sensor om dit op te pikken.

Waarschijnlijk had ik dat wat onduidelijk omschreven.

Dus puur Arduino die aanstuurt en opneemt, zonder tussenkomst van camera en scherm.

Zie hier hoe hij het gedaan heeft.
https://oscarliang.com/fpv-camera-latency/

The LED and LDR are both connected to the Arduino UNO micro controller, so we can measure the time very accurately. The LED and LDR has delay as well: LED takes time to turn on (i.e. increase brightness from 0% to 100%), and LDR takes time to detect light. From my measurement, the delay is only around 170us, compared to the delay of FPV camera this is negligible.

Nu probeer ik in mijn boeren middelbare school Engels wel een beetje mee te doen maar ik heb liever info in het Nederlands

Een goedkope scope zie ik zo snel niet staan en de kit die ik gevonden had is slechts 1 kanaal dus dat komt niet goed dan omdat ik niet 2 opnemers kan zien.

Mooiste zou natuurlijk zijn om puur de camera en weergave te testen, dat natuurlijk wel een meer realistisch beeld dan alleen een camera in een laboratorium.

Ha rew,

Ik heb niet het verhaal van de Arduino gelezen waar TS naar verwijst maar alleen de 30fps geeft niet de vertraging het aantal fps geeft alleen de oplosendvermogen in de tijd.
De vertraging zit in de beeldverwerking bestaande uit processing en encoding mpeg of iets dergelijks.
Ook aan de ontvanger is een procestijd nodig dus een aantal microseconde kan zeker wel.
Dat bij de meting van TS alle waarden ongeveer gelijk zijn heeft te maken met zijn resolutie (registratie methode)de vertraging veroorzaakt door eigenschappen van andere apparatuur is groter dan de camera toevoegt de onderlingen verschillen vallen in het niet.
@TS er is volgens mij software om mijn voorstel uit te voeren.
Als ik morgen tijd heb lees ik het verhaal met de Arduino wel.

Groet Henk.

Hoi Henk,

Perfect verwoord, precies de reden waarom ik dit forum gekozen had. Als ik dit in het Engels had moeten doen was ik waarschijnlijk nooit gekomen waar ik wilde zijn.

Ik hoop zsm van je te horen, voor nu alvast bedankt voor de moeite.

Jasper

Ok. Dan snap ik hem nu.

Een "LDR" is een traag ding. Dat kost tijd om te reageren. Een led is een redelijk snel ding. Ik heb in mijn studentenhuis leds gehad die "wegens omstandigheden" 2x per seconde 1 microseconde aanstonden, terwijl ze eigenlijk uit moesten zijn. Mensen zien dat... Enerzijds bewijst dat dat het menselijk ook heel gevoelig is, maar anderzijds ook dat de leds binnen een microseconde ook echt licht aan het geven zijn.

Die 170 microseconden zit dus voornamelijk in de LDR. De led is verwaarloosbaar.

IK denk dat jou methode met het maken van een foto heel aardig werkt. Er zijn alleen een aantal variabelen die je niet goed onder controle hebt. Zo zal het display van de telefoon een refreshrate hebben. Stel dat is 60Hz, en dat display dat je wilt testen heeft dat ook. Stel ze lopen in sync. Dan zie je zeg .060 op de telefoon terwijl de display-onder-test .000 aangeeft. Maar stel dat de displays nu net NIET tegelijk bovenin beginnen. Dan kan dat op de foto zomaar 1 tikje van 16ms schelen, terwijl de vertraging niet anders is geworden.

Wat fotoopa heeft gemaakt om dit soort dingen te meten is een arduino-achtig ding wat snel met de ledjes knippert en waar je dan een foto van kan maken om te zien welke leds er aanstaan.

Wat /ik/ zou doen is een 16-leds bordje op een STM32 aansluiten (click), en dan de STM32 programmeren om gewoon op 1 kHz binair te tellen met de leds.

Je moet dan diverse fotos nemen en dan steeds het verschil in de binaire waardes uit het beeld halen. Dit moet omdat bij 1 meting je steeds een variatie krijgt in het aantal miliseconden, afhankelijk van hoe je de foto genomen hebt in de refresh van het display. Ik verwacht dat je dan dus bijvoorbeeld waardes tussen 40 en 56ms zult meten, de vertraging is dan dus 40ms en nog eens maximaal 16 ms door de verversing van het scherm.

Mogelijk is het handiger om met 10 ledjes lineair te tellen (dus gewoon ombeurten aan) en dan met de overige 6 ledjes een binaire code aan te geven. Of ook lineair.. Hmm. Dan kan je slechts 60ms meten. Dan meet een 90ms vertraging ding even goed als een 30ms ding Dat lijkt me niet gewenst.

Ha rew,

Dat is het punt door de aperture is de nauwkeurigheid niet groot genoeg let wel dit heeft alleen invloed op de uitkomst als je frame capture toepast.
Als je dus camera's wilt vergelijken moet je hier rekening mee houden of je stelt ze allemaal op het zelfde aantal fps in of je rekent terug.
Maar voor het meetsysteem maakt dit niet uit ook in mijn voorstel om vanuit de camera de overlay klok te starten deze via de computer op de monitor weer te geven en de camera op de monitor te richten dus zijn eigen beeld nog een keer weer te geven.
Hier door zie je op de monitor een klok en nog een keer de monitor met een klok vertraagd je kunt dus direct de vertraging aflezen (het verschil tussen de twee klokken).
Ik denk dat voor een vergelijk dit voldoende is anders is het als je frame op frame meting wil doen.
Als je een standalone meet toestel wil maken kan jou idee zeker werken.
Wel is het opletten met zo,n bounce signaal led/uit led/aan gaat de regelversterker heftig te keer waardoor weer extra vertraging ontstaat en dit verschild nogal per camera.
Dus de iris een klein stukje open (achtergrond verlichting) is gewenst zodat de sprong wel waarneembaar is maar het regelgedrag niet te heftig is.
Dat is de bron het stuur signaal kan naar kanaal A start van de teller.
Uit de camera het video detecteren op de sprong en dit naar kanaal B het verschil tussen A en B is de vertraging van de camera.
Nu heb ik zo geen idee of deze tijd meting met de Arduino goed haalbaar is.

Groet Henk.

Goedemorgen,

Ik heb nog eens naar een scoop gekeken en zag dat iemand een 2 kanaals scope met 1 probe op een schakelaar die 2 leds inschakelt en de andere op het video uit signaal.

Zodra hij dus de schakelaar om zet zie hij kanaal B omhoog gaan en enkele ms later kanaal A veranderen.

Het verschil is dan de vertraging die ik wil testen.

Alleen dan moet ik een 2 kanaals scope hebben en die kit van 45€ heeft er maar 1.

Mijn voorkeur gaat dus nog steeds uit naar een budget setup, waarschijnlijk de arduino oid.

Ik zie wel deze scoop maar weet niet of ik er verder veel aan heb. Geen idee wat ik er allemaal nog meer mee kan zeg maar.
https://www.elecrow.com/ds202-digital-storage-oscilloscope-with-touch-…

De test setup is mooi alleen de klok is niet geschikt voor dit doel.
Hij heeft wel 3 cijfers achter de komma maar door de lage refreshrate doorloopt de telefoon niet alle getallen.
Wat hij weergeeft is bijvoorbeeld:
59,845
59,875
59,905
59,935
etc, etc

En dat is niet genoeg resolutie voor je testopstelling.

Wat je kan gebruiken is een counter (teller) met led display (geen lcd).
Deze stuur je aan met een frequentie generator.
Of zelf bouwen met TTL ic's.

Nog eenvoudiger is een synchroommotor met een wijzer op de as. De motor draait op een vast toerental en door te kijken hoeveel graden de wijzer verschoven is om het tijdsverschil te bepalen.

Hoi Part,

Ik denk inderdaad dat het een combinatie is van de tijd en beeldscherm verversing.

Ik heb een ander gezien die inderdaad ook zei dat zijn tijd met 0.006 per stap omhoog ging en de mijne wellicht met grotere stappen. Als je daar nog de verversingstijd bij telt van beide schermen dan is de gemeten vertraging en grote optelsom en niet betrouwbaar.

Nu heb ik verder gezocht en kwam een kleine redelijk goedkope scope tegen en is mijn volgende vraag.

Kan ik hiermee een schakelaar meten die een LED aanstuurt en vervolgens op een 2e kanaal het video signaal wat uit de camera komt meten?

MINI DS202 Nano ARM Mini Handheld TFT Display Digital Storage Oscilloscope

https://www.banggood.com/MINI-DS202-Nano-ARM-Mini-Handheld-TFT-Display-Digital-Storage-Oscilloscope-p-974692.html?p=ZW051057416242016088

Ding kost iets van €87,50 en wellicht ook nog voor andere doeleinden te gebruiken?

Andere optie zou deze zijn maar geen idee of die beter is

https://www.banggood.com/Nano-DSO203-DS203-Professional-Digital-Oscilloscope-4-Channel-72MSs-p-925667.html?p=ZW051057416242016088

[Bericht gewijzigd door Dutch 79 op donderdag 3 augustus 2017 08:48:55 (14%)

Zo jij schuift makkelijk met je budget, van 50 euro naar 500 euro (jouw discussie op EEVblog)
Denk er wel om dat je ook moet weten hoe je moet meten en hoe je de scoop instelt. Niet alleen tijdbasis en amplitude maar ook trigger type, sample-manier etc. Ik denk dat dit alleen zinvol is als je de delay van elk onderdeel in de keten kunt meten.

Ik zou zelf eerder zoiets doen als electron beschrijft. Nu heb je erg veel onbekende variabelen. Je zegt dat het om de verschillen, dus relatief, gaat. Dan maakt de waarde niets uit. De ene 60ms de ander 50 ofwel de eerste heeft meer vertraging. Maar je wilt blijkbaar toch harde cijfers.

Het huidige proces
1) Schakelaar om. dat kost tijd maar dat geeft niet. Je kijkt vanaf het "aan" moment.

2) de scoop triggert op de schakelaar, meet en verwerkt de data.
Hoe snel is per scoop verschillend.

3) de scoop laat het op het scherm zien.
Daar zijn ook forse verschillen tussen scoops onderling.

4) tegelijk met het trigger moment krijgt de led stroom en begint te geleiden. Het duurt een bepaalde tijd totdat hij fel genoeg brandt om zichtbaar te worden. Sommige leds geven bij een paar uA al zichtbaar licht, andere pas bij een paar mA om detecteerbaar fel te worden. Daar zitten dus ook verschillen

5) De camera neemt het op met een aantal beeldjes per seconde. Ik weet niet hoelang 1 opname van 1 frame duurt en hoelang hij de boel verwerkt tot output. Misschien dat de ene camera in het donker veel meer tijd nodig heeft om met zijn belichting op zo'n led te reageren maar in normaal daglicht veel sneller is dan een die in het donker sneller reageert.

Eigenlijk zoals de scoop. Dus als 1 frame bestaat uit 1 ms meten (het is ook een vorm van meten) en dan 39 ms blind is terwijl hij het beeld opbouwt. Dat betekend dat het mogelijk is dat hij een frame overslaat omdat de led net buiten die 1 ms valt. Je zou de meting moeten kunnen syncen met de camera.

6)de camera zet het om in een of ander digitaal formaat en stuurt het naar zijn uitgang. Je meet op dat punt de frames met je scoop.
Jou meting is klaar.

7)de zender decodeert het signaal en zet het om in een RF signaaltje wat hij uitzend. Hoe snel die data verzonden wordt weet je nu niet. Misschien is de ene veel sneller daarmee dan de ander.

8) de ontvanger registreert het, waarschijnlijk hier ook in vaste stappen, decodeert het, bewerkt het tot een signaal wat het scherm aan kan en stuurt het naar je display welke het mogelijk weer decodeert en het uiteindelijk een pixel aanzet.

Je kunt waarschijnlijk al die stappen wel uitmeten maar dan moet je echt goed weten wat je doet.

Je hebt het over 100km/h (ik wist niet dat die dingen zo hard kunnen). Dat is 2,77 cm/ms. Je zou iets met die snelheid en afstand moeten kunnen doen met de drone zelf.

Hoi,

Aller eerst even uitleg over mijn budget verandering. Ik wilde een nieuwe FPV bril kopen (a 350€) maar die blijkt toch minder goed dan verwacht, dus was er ipv, 100 voor een dso nano ineens meer beschikbaar.

Ik wil in eerste instantie puur de camera bekijken en dan daarna het gehele traject.

Daarvoor moet ik wel eerst meerdere type video zenders, ontvangers en schermen hebben om verschil te kunnen aantonen.

Nu met verschillende 2 van ieder kan ik al wel iets maar niet echt iets aantonen. Wat als beide de zelfde chip gebruiken?

Met tijd en afstand lijkt me erg lastig om iets te doen omdat er waarschijnlijk meer factoren gaan meespelen.

Ik wil waarschijnlijk een licht sensor aan een monitor plakken en dan de led schakelen.

Als ik het goed heb weet je dan wanneer de led aan is en wanneer het scherm licht genoeg is voor de sensor.

De vertraging van de led zou ik dan wellicht ook kunnen meten door de sensor een zelfde afstand van de led te plaatsen als ik de camera doe.
Meet ik dan de led en sensor zou ik moeten kunnen zien wat het verschil tussen de twee tijden is en dat van de gehele meting aftrekken?? Tenminste, zo heb ik het in mijn kop zitten intussen.

Groeten,

Jasper

Dan zou ik de led laten knipperen. bv met een 555 of een knipperledje. Dan wordt het makkelijker om te meten, de scoop in te stellen en schakel je altijd even snel. De snelheid zo laag dat je wel weet welke respons bij welke incident hoort.

Ik denk dat je ivm snelheid en gevoeligheid beter een fototransistor kan gebruiken ipv een LDR.

Die opstelling is qua bruikbaarheid niet verkeerd denk ik.

Dit kan je ook met bril en zender/ontvanger er tussen doen. Door de led direct voor de fototransistor te zetten en te meten kun je de boel corrigeren. Je kunt zelfs 2 leds en fototransistors gebruiken. 1 stel direct tegenover elkaar als referentie. Dan meet je direct het verschil tussen de twee responses en hoef je niks te compenseren

Zo krijg je een vertraging die vergelijkbaar is met wat de gebruiker echt ervaart.

Ik weet niet waar je woont maar ik wil je wel een keer helpen om wat dingen te testen voor je dure scoops gaat kopen.

[Bericht gewijzigd door fred101 op zondag 13 augustus 2017 19:22:41 (11%)

Hoi Fred, ik zie in je profiel dat we niet ver van elkaar wonen.
Ik zal als de vakantie over is zeker even contact opnemen om eens af te spreken.

Groeten,.
Jasper

Op 13 augustus 2017 16:02:54 schreef fred101:
4) tegelijk met het trigger moment krijgt de led stroom en begint te geleiden. Het duurt een bepaalde tijd totdat hij fel genoeg brandt om zichtbaar te worden. Sommige leds geven bij een paar uA al zichtbaar licht, andere pas bij een paar mA om detecteerbaar fel te worden. Daar zitten dus ook verschillen

De "ramp up time" van de led moet echt zonder moeite onder de 1 µS te krijgen zijn (hoef je niets voor te doen). En een led geeft dan ook binnen 1 µs gewoon vol licht.