Domanda:
Orologio visivo con frequenza di aggiornamento del display in millisecondi
Kozuch
2014-08-13 14:16:07 UTC
view on stackexchange narkive permalink

Devo creare un orologio visivo capace di millisecondi: userò l'orologio per la sincronizzazione dei fotogrammi visivi di più telecamere. Ho trovato questo progetto ma sembra utilizzare un display a LED che ha una risoluzione di un solo 1/100 di secondo. Non sono sicuro che le cifre possano essere spostate per mostrare i millisecondi.

Immagino di dover utilizzare il LED invece del display LCD a causa della frequenza di aggiornamento in ms? Qualcuno può aiutare con il mio progetto per favore? Sono un programmatore SW e non ho esperienza nella programmazione HW. Quindi anch'io sono nuovo su Arduino: non ho ancora realizzato alcun progetto. Non possiedo né Arduino né display LED.

Grazie!

A cosa serve il progetto? Prendi un altro progetto e modificalo. Ha solo bisogno di mostrare i mulini giusti quando lo fermi, quindi non preoccuparti della frequenza di aggiornamento.
Devo misurare visivamente la differenza di sincronizzazione di una telecamera stereo, quindi ho effettivamente bisogno di una frequenza di aggiornamento in ms. Ho modificato la domanda di conseguenza.
Grazie per i chiarimenti. Qual è il tempo massimo necessario per misurare? L'ho visto fare con un anello di LED bianchi che gira in cerchio.
Bene, quello che fondamentalmente faccio finora è provare a bloccare il mio FPS su Xs (ora 2s) in OpenCV e fare solo un controllo visivo di entrambi gli stream della telecamera uno accanto all'altro sul monitor di un PC. Quindi in realtà ho bisogno solo della cifra degli ultimi secondi + millisecondi (esempio: 5.123). Ma in futuro potrei voler testare una sincronizzazione video e magari lasciarla funzionare per ore, tuttavia probabilmente la stessa quantità di cifre sarebbe sufficiente poiché la sincronizzazione non dovrebbe spostarsi di 10 secondi. Preferirei un display a LED con numeri, invece di semplici "lampadine" a led 0/1. Supponiamo che mi aspetti una misurazione nell'intervallo di 100 ms, quindi avrei comunque bisogno di 100 pezzi di LED più semplici.
"Diciamo che mi aspetto misurazioni in un intervallo di 100 ms, quindi avrei comunque bisogno di 100 pezzi di LED più semplici." No, in realtà fai i LED in binario e puoi ottenere 256 ms con 8 LED, 512 ms con 9, 1024 con 10 ecc.
Sebbene possa essere la configurazione più semplice possibile per quanto riguarda la leggibilità dei LED, penso che non voglio un'uscita binaria. Devo essere in grado di leggere il tempo velocemente senza doverlo convertire da binario a decimale.
La maggior parte delle fotocamere funziona a 50 su 60 fotogrammi al secondo. Ciò significa che durante la registrazione di un fotogramma compaiono 2 numeri. Se quei numeri sono ad es. 6 e 7, il fotogramma probabilmente mostrerà qualcosa come un 8. In altri casi appariranno strani pensieri nell'ultimo segmento, rendendolo completamente inutile e dandoti solo 1/10 di secondo di precisione. È possibile utilizzare i 7 segmenti per i primi numeri e un cerchio di LED per i centesimi di secondo. Suggerirei di acquistare un arduino con più pin rispetto ad arduino uno, poiché avresti bisogno di chiudere alcuni pin per tutti quei led.
potresti semplicemente ottenere un IC contatore binario, un IC binario a 7 seg e un timer 555.
@Gerben: Sei un ordine di grandezza troppo grande - 60 Hz produce una risoluzione di 16 ms che è circa. 1/100 di secondo. Ma voglio ottenere una precisione 16 volte maggiore, da 16 ms a 1 ms. L'idea di avere un cerchio di LED è comunque carina: potrei avere un cerchio per 1/100 della cifra e uno per 1/1000 (ms). Potrei almeno misurare il tempo di esposizione in questo modo se più LED brillano in un cerchio.
A meno che tu non abbia telecamere ad alta velocità, non vedo il punto. Anche le fotocamere hanno una "tapparella" che crea letture led imprecise.
quale gamma di velocità dell'otturatore prevedi di utilizzare?
Tre risposte:
#1
+7
Duncan C
2014-08-15 19:34:13 UTC
view on stackexchange narkive permalink

È necessario definire i parametri del problema in modo più chiaro.

In primo luogo, e soprattutto, qual è la velocità dell'otturatore che utilizzerai? Se è più lungo di 1 ms, non è possibile utilizzare un display a 7 segmenti per mostrare il conteggio MS, poiché l'otturatore della fotocamera sarebbe aperto per più valori.

Anche se la velocità dell'otturatore è un singolo MS, l'otturatore non sarà sincronizzato con il timer, quindi a volte l'otturatore sarà aperto quando il display cambia. Ciò può accadere anche con la cifra dei secondi della visualizzazione del tempo.

Se stai usando una videocamera, supponi che la frequenza dei fotogrammi sia di 60 fps, che dà probabilmente una velocità dell'otturatore intorno a 16,6 ms. È troppo lungo per visualizzare i valori di tempo ms utilizzando display a 7 segmenti.

L'anello dell'idea LED è buono, ma lo aggiusterei.

Ecco cosa farei: Costruisci un orologio LED per visualizzare il numero intero di secondi. Non eseguire il multiplexing, usa i fermi e controlla costantemente ogni display a 7 segmenti. (Esistono chip CMOS standard che bloccano i driver a 7 segmenti.) Se ti interessa solo la cifra 1s del secondo valore, usa solo 1 display a 7 segmenti. Ciò renderà le cose più facili da cablare.

Usa 3 anelli o colonne di 10 LED per il display MS: decimi, centesimi e millesimi. Preferirei usare le colonne poiché sarebbe visivamente più facile da leggere.

Il display mostrerà i tuoi secondi come numeri e 3 colonne di 10 LED, mostrando l'intervallo di tempo inferiore ai secondi in decimi, centesimi e millesimi. Se l'apertura dell'otturatore si estende su più MS, come molto probabilmente farà, tutti i LED che rappresentano il secondo tempo saranno accesi nell'immagine, in modo da ottenere un'immagine visiva bella e pulita dell'intervallo di tempo in cui l'otturatore era aperto (Tutti i LED dall'inizio alla fine dell'apertura della tapparella saranno accesi.)

È possibile pilotare le 3 colonne di LED utilizzando 3 contatori 4017 divisione per 10. Questi chip hanno sia un'uscita 1 su 10, che guiderà un LED, sia un'uscita count / 10, che alimenterà la fase successiva.

Scrivi codice Arduino che generi un breve impulso positivo ogni MS. Inseriscilo nell'ingresso dell'orologio del 4017 guidando la cifra dei millesimi. Inserisci l'uscita out / 10 di quel chip nell'ingresso di clock dei centesimi 4017 e l'uscita dei centesimi 4017 nell'ingresso di clock dei decimi 4017.

Puoi guidare l'intero display ms con 2 Linee Arduino: l'orologio ms e una linea di ripristino collegata a tutte le linee di ripristino dei contatori 4017. Per avviare il cronometraggio, prima pulsa la linea di reset per azzerarli tutti, quindi avvia il tuo ms clock.

Il mio ricettario CMOS non dice quanta corrente emetterà il 4017 per 1 su 10 uscite, ma scommetto che è sufficiente pilotare direttamente un LED del display. È possibile collegare tutti e 10 i LED in ciascuna colonna come catodo comune, con un singolo resistore limitatore di corrente tra il catodo comune di ciascuna colonna e la terra.

Probabilmente si potrebbe impostare un pin del timer su Arduino per generare un impulso di millisecondi output, ma non è qualcosa che ho imparato a fare ancora.

Di tanto in tanto otterrai un intero secondo display a 7 segmenti con 2 valori diversi catturati in un frame, ma sarà raro e sarai in grado di capire cosa è successo dai fotogrammi immediatamente prima e dopo. (Il frame precedente mostra un 5. Il frame corrente mostra un 5 e un 6 sovrapposti, quindi è un disastro. Conclusione, questo frame mostra la fine del secondo 5 e l'inizio del secondo 6.)

Grazie per una risposta molto lunga e preziosa! Dato che sono nuovo di HW non so nemmeno cosa sia un "contatore" HW (come il 4017). Quindi per bypassare il contatore immagino di poter collegare tutto direttamente alle uscite GPIO sulla scheda Arduino stessa? Se dovessi fare tutto in LED senza 7 segmenti (40 LED) significa che ho bisogno di 40 pin GPIO + 1 per la tensione di ingresso? Quale scheda può fornire 41 o almeno 31 pin (potrei probabilmente omettere i secondi)?
Voglio dire, essendo un programmatore SW mi sarebbe più facile implementare tutta la logica necessaria solo in SW senza circuiti integrati (contatori HW ecc.)
Sì, avresti bisogno di 40 pin per farlo direttamente da Arduino, più 7 pin per il display a 7 segmenti. Fatevi un favore e acquistate una copia del "CMOS Cookbook". È molto utile per cose come questa.
Anch'io sono un programmatore, ma non credo che sarai in grado di farlo. Avresti bisogno di 47 linee logiche. Il chip che ho citato, il 4017, è molto facile da usare. Gli dai un ingresso sincronizzato e invia un 1 logico a 1 di 10 uscite e commuta le uscite su ogni impulso dell'orologio. Quindi si ripristina di nuovo all'inizio e ricomincia. Ha anche un'uscita che è un conteggio di clock che è 1/10 della frequenza di ingresso. Controllare questo collegamento per una spiegazione sull'utilizzo del 4017: http://www.doctronics.co.uk/4017.htm
Potrebbe essere controintuitivo, ma in realtà è più facile fare questo tipo di progetto con i circuiti integrati. Ti impazzirai cercando di collegare 47 linee di uscita a un Arduino, quindi risolvere tutto. Il Mega 2560 ha abbastanza linee I / O, ma poi non sarai in grado di fare molto altro con la scheda.
Grazie per i preziosi commenti. Ammetto che il design con i circuiti integrati è davvero più semplice. Cosa succede se non voglio perdere la precisione di 1 ms oltre il ms-decade (oltre 1/100 di s)? Potrei eseguire più di 10 LED in un intervallo di 1 ms, diciamo 50 o anche 100 in modo da poter misurare la sincronizzazione anche con tempi di posa più lunghi e senza perdere precisione. Diciamo che avrei bisogno di un "contatore" con 50 o 100 (1 ms) uscite o in qualche modo concatenare più contatori di decine. Potrei eseguire un passo di 2 ms o anche più grande per ridurre il numero di LED, ma ottenere comunque una precisione inferiore a 10 ms per otturatore più lungo.
Penso di aver bisogno di qualcosa in questa direzione: http://www.instructables.com/id/16-Stage-Decade-Counter-Chain-Using-two-4017-Chi/
Capisco, posso concatenare i contatori ma perderò uno stadio poiché devono essere incatenati sul 9 ° pin per non perdere la frequenza ... quindi per 50 LED avrei bisogno di 6 di loro non 5. C'è un contatore che ha più di 10 uscite? Forse 20 o più? O può essere risolto in modo diverso?
Nel caso qualcuno sia interessato, puoi fare più di 10 LED collegando a cascata più 4017 - vedi qui: http://electronics.stackexchange.com/questions/33652/how-to-cascade-4017-decade-counters
#2
+3
gbulmer
2014-08-16 18:25:56 UTC
view on stackexchange narkive permalink

Penso che l '"interfaccia utente" di Duncan C sia eccellente. È pulito, semplice ed elegante.

Usare i singoli LED è molto meglio delle cifre. IMHO è molto più flessibile ed evita l'ambiguità delle cifre. +1 per il concetto.

Tuttavia, lo renderei "più morbido" e utilizzerei molti meno componenti.

Diventando 'più morbido' potresti avere più flessibilità, che ti darebbe la possibilità di espandere la risoluzione utile del 'orologio'.

Duncan C ha fatto un punto molto importante che le cifre sono inutili se una cifra cambia durante la fotografia. Tuttavia, questo è ancora un potenziale problema con le tre linee di LED. Quando il tempo di esposizione è più lungo della durata della linea di LED "cifra inferiore", le informazioni vengono perse.

Certamente il design di Duncan C potrebbe essere accelerato o rallentato per adattarsi a questo, ma ha un limite di risoluzione incorporato perché conta in 10. Imporre l'idea digitale di "10" su un sistema analogico (che è simile all'abaco di un bambino) perde alcune delle tre flessibilità intrinseche nella superiorità fondamentale (in questo caso) di un display analogico. Suggerisco di renderlo "morbido" in modo che il sistema possa essere "ottimizzato" nel software dopo che l'elettronica è stata completata.

Invece di contatori a decadi a funzione fissa, usa i registri a scorrimento. Poi c'è la flessibilità completa per cambiare l '"interfaccia utente" nel software.

Per ridurre il numero di componenti, utilizzare registri a scorrimento progettati per pilotare i LED .

Ad esempio, gli strumenti Texas producono molti driver LED. I più economici, nei pacchetti Dual-In-Line (che possono essere usati in una breadboard, e quindi sarebbe più facile da prototipare) che ho trovato su RS erano TLC5916 / TLC5917. Ogni dispositivo aziona 8 LED, quindi il progetto di Duncan C ne userebbe 4. Questo è più costoso dei contatori decennali. Tuttavia, penso che il costo (circa 5 GBP) potrebbe valerne la pena.

Un vantaggio è che sono driver a "corrente costante" e quindi eliminano i resistori di limitazione della corrente su ciascun LED. Ogni dispositivo utilizza un resistore per programmare la corrente per tutti gli 8 LED. Ciò non farà risparmiare molti soldi, ma farà risparmiare un sacco di cavi.

Questi registri a scorrimento sono alimentati da uno schema di bit di dati, uno alla volta, usando un secondo segnale di "orologio" per dire al registro a scorrimento quando il bit di dati è valido. La commutazione dell'orologio carica il bit di dati. Quindi potresti metterli in cascata, end-to-end, esattamente come i contatori a cascata. Per ridurre il carico della CPU, l'ingresso alla catena di registri a scorrimento potrebbe essere caricato in modo autonomo, 8 bit alla volta utilizzando la periferica SPI in Arduino.

In alternativa, è possibile utilizzare 4 pin per caricare i dati contemporaneamente, con un pin che guida un orologio condiviso. Questi registri a scorrimento possono funzionare molto più velocemente persino dell'assemblatore Arduino (fino a 30 MHz / bit). Quindi non è necessario molto tempo.

Le uscite dei registri a scorrimento non cambiano finché non viene inviato un ulteriore segnale. Quindi cambiano tutti l'uscita contemporaneamente. Così le tue fotocamere non saranno confuse vedendo i dati caricati.

Quindi c'è una maggiore complessità del software rispetto ai contatori a cascata. Tuttavia, non ci sono vincoli sui dati che mostrano. Ad esempio, potresti decidere di volere 20 LED di risoluzione, in modo che le fotocamere abbiano un tempo di esposizione più ampio e i fotogrammi possano ancora essere sincronizzati o "posizionati" l'uno rispetto all'altro nel tempo.

Anther Il vantaggio di questo comportamento "morbido" è che potresti aggiungere molti più LED e ottenere praticamente qualsiasi risoluzione di cui potresti aver bisogno, utilizzando esattamente la stessa tecnologia hardware.

Questo approccio condivide un vantaggio del design di Duncan C. Il tempo è indicato da punti luminosi discreti e non dalla forma. Quindi dovrebbe essere relativamente semplice utilizzare l'elaborazione delle immagini per elaborare le immagini. Questo potrebbe essere molto importante se le fotocamere sono videocamere.

Modifica:
per chiarire alcuni punti.

È puramente software che determina il comportamento dei LED in un approccio basato sul registro a scorrimento. Quindi è pratico e semplice simulare i contatori di decadi. Quindi l '"interfaccia utente" non può essere peggiore.

La complessità di una catena di registri a scorrimento è la stessa dei contatori a decadi, se si desidera utilizzarli in questo modo. Tuttavia, per alcuni pin in più, i registri a scorrimento potrebbero essere caricati indipendentemente, il che potrebbe avere alcuni vantaggi.

L'uso di driver LED a corrente costante riduce il numero di resistori da collegare di un fattore 8. TI e altri vendono dispositivi con 16 e 24 driver LED, quindi il numero di pacchetti potrebbe essere ridotto.

Il contatore delle decine ha una restrizione incorporata. Non sorprende, non fornisce una risoluzione superiore al 10%. Tuttavia, se hai bisogno del 5%, non può farlo.

L'elettronica basata su registro a scorrimento potrebbe emulare un "quadrante di orologio", quindi se è necessario il 5%, usa 20 LED per quella parte. Se è richiesto l'1%, aggiungi altri registri a scorrimento e LED

Riepilogo :
Il concetto di Duncan C di utilizzare un display "abaco analogico" è, IMHO, un'interfaccia utente più robusta rispetto alle cifre arabe LED.

Tuttavia, IMHO un'implementazione cablata che utilizza contatori di decadi è una restrizione non necessaria, che limita la risoluzione. I registri a scorrimento rendono il display "morbido". Il cablaggio dei registri a scorrimento è la stessa complessità dei contatori di decadi. L'utilizzo di driver LED consente di risparmiare molto cablaggio.

Il tuo suggerimento sui registri a turni sarebbe più flessibile, ma penso che sia molto oltre il livello di comfort dell'OP nel lavorare con l'hardware. Ha respinto il mio suggerimento, che avrebbe utilizzato 3 chip e pochissime connessioni. Per quanto riguarda la risoluzione del mio suggerimento, se l'otturatore è aperto per più di 1 MS, si accenderà una serie di LED che mostrano l'ora di inizio e di fine dell'otturatore. Se l'otturatore rimane aperto per 5 ms, nell'immagine si accendono 5 led millesimi. Oltre i 10 MS, perderesti il ​​livello di dettaglio MS perché tutti i LED "millesimi" sarebbero accesi, ma penso che sia ok.
@DuncanC - 1. L'uso dei registri a scorrimento può avere * esattamente * la stessa complessità elettronica dei contatori a decadi. 2. l'utilizzo di driver LED rimuove 26 componenti, il che è un bel po 'di lavoro extra da compilare ed eseguire il debug. 3. Kozuch ha scritto "Sono un programmatore SW ...", quindi spostare la complessità al software sembra essere la cosa più utile da fare. 4. È semplice emulare un contatore di dieci anni nel software, quindi l'interfaccia utente * non * può essere inferiore. Sono d'accordo con la tua analisi. Il mio punto è estremamente semplice e pertinente; l'interfaccia utente è migliorabile per adattarsi all'applicazione * dopo * che l'elettronica è stata completata.
il tuo punto di vista sulla flessibilità è ben accolto. Quali 26 componenti rimuove il tuo approccio, però? Se leggi attentamente la mia descrizione, ti consiglio di pilotare i LED direttamente dal 4017 e di cablare ogni set di 10 LED con un catodo comune e un singolo resistore limitatore di corrente tra ciascun catodo comune e la terra. Solo un LED in ogni "decade" sarà mai acceso, quindi dovrebbe funzionare perfettamente. Il mio progetto richiede 3 chip, 3 resistenze e 30 LED. I driver LED eliminerebbero le 3 resistenze, ma utilizzerebbero molti più circuiti integrati.
In realtà, dopo aver letto il TLC5916 / 17 (e il relativo TLC5925) ho scoperto che era sia un registro a scorrimento che un driver LED in 1 pacchetto. Ogni chip prende un resistore che imposta la corrente di uscita per tutti i LED che pilota, quindi penso che il conteggio dei componenti sarebbe quasi identico. Se hai usato due TLC5925 (ognuno dei quali guiderà 16 LED), allora avresti bisogno di un resistore limitatore di corrente in meno, ma una differenza di 1 o 2 resistori non è importante.
#3
+1
user2973
2014-08-14 01:26:17 UTC
view on stackexchange narkive permalink

Supponendo che l'otturatore della fotocamera sia abbastanza veloce da acquisire un display che si aggiorna ogni millisecondo:
Ottieni display a sette segmenti (LED) con cifre individuali. Quelli con più cifre insieme sono solitamente multiplex e questo potrebbe non funzionare per la tua applicazione (la frequenza di multiplexing dovrebbe essere superiore a 1000 Hz o sarebbero visibili solo una / alcune cifre alla volta). Utilizzando display a una cifra, collegare ogni cifra a un registro a scorrimento come il 74HC595. Quindi hai solo bisogno di due pin Arduino per controllare ogni cifra (dati e orologio, l'orologio di blocco può essere condiviso da tutti i registri a scorrimento). Usa resistenze di protezione per ogni singolo segmento di diodo e fai attenzione al limite di corrente del registro a scorrimento quando accendi tutti i segmenti.

A 16 MHz hai 16000 istruzioni per ms, quindi non dovrebbe essere un problema.

Non so molto sui display LCD, ma con LED e un registro a scorrimento a scatto le transizioni dovrebbero essere aggiornate praticamente istantaneamente (da una prospettiva di millisecondi).

No, hai * 16.000 * istruzioni per ms. (16.000.000 al secondo / 1.000 ms al secondo)
Sì, hai ragione, corretta la risposta (puoi anche modificarla).
Hai scritto "Quelle con più cifre insieme sono generalmente multiplexate e questo non funzionerà per la tua applicazione (sarà visibile solo una cifra alla volta)". Ciò è probabilmente errato e potrebbe essere fuorviante. Ad esempio, se l'applicazione è una videocamera, la "velocità dell'otturatore" è di 16 ms o 20 ms. Anche a 1/1000 di secondo, un millisecondo, c'è tempo sufficiente per disegnare tutte le cifre di un LED multiplex, in modo che appaia bene.
Tranne che l'aggiornamento del display non verrà sincronizzato con l'otturatore, quindi quando il display cambia, una data immagine probabilmente conterrà LED accesi da entrambi i valori. Se la velocità dell'otturatore è di 20 MS e l'orologio cambia lo schermo ogni MS, l'immagine acquisirà 20 valori diversi, il che sarà un pasticcio indecifrabile.
@gbulmer Non ho considerato il tempo di scatto, ma dovrebbe essere veloce per una visualizzazione del timer di 1 ms. Di solito multiplex a 200 Hz (tutto il display) quando viene eseguito sull'MCU, per evitare di bruciare troppi cicli della CPU, ma ovviamente potrebbe essere fatto più velocemente o con un driver IC multiplexing dedicato a 1000 + Hz. Ho aggiornato la risposta per essere più elaborata.
@user2973 - Penso che la mia risposta si aggiunga a quella di Duncan C, che credo sia un ottimo modo per andare. Detto questo, penso che sia completamente fattibile aggiornare tutte le cifre in un display multiplex a 10kHz o più veloce per evitare problemi di velocità dell'otturatore, utilizzando meno del 20%. Tuttavia, l'approccio di Duncan C è molto più robusto delle cifre leggibili dall'uomo, quindi consiglierei comunque di farlo. La mia risposta migliora la flessibilità e la complessità elettronica dell'implementazione di Duncan C.
@DuncanC - il mio commento si riferiva al presupposto che "(sarà visibile solo una cifra alla volta)" user2973 ha aggiornato la risposta per incorporare il mio commento. Sono pienamente d'accordo con te, usare qualcosa di più "analogico" è * molto * meglio delle cifre arabe. La tua proposta è come l'abaco di un bambino ed è dimostrabilmente superiore alle cifre arabe per molti scopi.


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...