Capteur CCD linéaire

International Français
1

Bonjour !

J'aurai besoin de quelques éclaircissement à propos de ma tentative d'interfacer un capteur CCD linéaire avec un arduino. L'arduino n'étant pas assez rapide pour mon utilisation finale (D'après mes recherches), tout se finira certainement avec un FPGA, c'est juste une solution temporaire pour comprendre le fonctionnement de l'ensemble.

Mon capteur CCD a une résolution de 5000px, et dispose de deux sorties, chacune pouvant être cadencée jusqu'à 20 Mhz (Donc en tout 5000px cadencée à 40Mhz). On peut les cadencer au minimum à 0.5 Mhz, cela pourrait convenir à l'arduino (Du moins, je l'espère).

Je n'ai pas besoin d'avoir les images entière (De toute manière la RAM de l'arduino ne le permettrait pas), je veux juste avoir les quelques pixels " éclairés " (Dépassant un certain seuil) du capteur (Le but étant de tracker une LED ir). Est-ce que je pourrai me passer d'une acquisition analogique, et passer simplement par une entrée digitale ?

Par exemple admettons que le capteur CCD renvoit des infos entre 0 et5v, si la tension est supérieure à 3v, alors l'entrée sera 1, et si en dessous elle sera 0. Est-ce faisable avec un simple potentiomètre (Entre la sortie du capteur CCD et l'entrée digitale) pour régler la sensibilité ?

Merci d'avance !

2

Est-ce faisable avec un simple potentiomètre (Entre la sortie du capteur CCD et l'entrée digitale) pour régler la sensibilité ?

c'est peut être faisable comme ça mais il parait dommage "d'abrutir" la sortie analogique d'un CCD (sans doute côuteux) au moyen d'une reduction d'amplitude par potentiometre. Tout ça pour utiliser le seuil d'environ Vcc/2 d'une entrée numérique. (c'est à dire utiliser une entrée numérique comme un comparateur grossier à seuil 'fixe')

Entre l'acquisition analogique qui parait effectivement difficile à première vue içi et la détection de seuil 'numérique' il y en a une troisième voie qui parait plus appropriée : mettre en oeuvre un vrai comparateur => exploiter les entrées AN0 et AN1 en mode Comparateur ( sortie CCD direct en AN0 par exemple et seuil reglable fixé par potentiometre en AN1).

Nouveau venu sur le terrain de jeu Arduino je propose ça 'par habitude' sans avoir été vérifier l'existence d'une librairie pour gérer le comparateur. :blush: Vu la taille et la productivité de la communauté Arduino il parait impensable que cela n'ait pas été fait !!

Si la mise en oeuvre du comparateur interne demande trop de temps d'apprentissage et de mise au point il faut investir qq € dans un comparateur externe (LM311, LM393, LM339....il y a l'embarras du choix !)

Cerise sur le gâteau : seuil programmable par soft, produit par 'AnalogWrite(), filtré et injecté sur l'une des entrées du comparateur interne ou externe..... ça ouvrirait les portes pour un seuillage dynamique, progressif....etc ....et non réglé manuellement.

comparateur.jpg

3

Bonjour GJ_95600,

Il faudrait aussi voir ce que c'est comme capteur CCD (référence) : Il y a certainement moyen de le cadencer moins vite, aussi il faudrait voir son rendement quantique, spectral en fréquence et son niveau de bruit de lecture, etc. pour une question de S/B et de détectivité de la LED IR à travers une interface de l'Arduino (pas du 16bits).
Et aussi de parles de capteur 'linéaire', c'est à dire ? C'est une barrette CCD mono-ligne ou un capteur multi-ligne piloté en rolling shutter ligne par ligne ?

4

On peut les cadencer au minimum à 0.5 Mhz, cela pourrait convenir à l'arduino (Du moins, je l'espère).

500kHz c'est élevé pour un processeur qui tourne à 16MHz. Cela fait une trentaine d'instruction tout au plus.
Si je comprends bien tu veux lire un pixel, tester sa valeur et mémoriser sa position s'il est éclairé.
Cela implique générer un signal d'horloge, gérer un compteur sur 16 bits et faire un test sur une valeur.
Si ta barrette CCD ne demande qu'une horloge (ce qui est rarement le cas puisque les CCD utilisent le plus souvent 2 horloges déphasées pour assurer le transfert des charges) tu vas peut être y arriver mais il faudra optimiser le code à la main car avec les librairies standards rien que la génération de l'horloge va consommer la trentaine d'instructions.

C'est très très limite à mon sens.

Concernant le seuillage sur le signal je pense que la solution proposée par al1fch est meilleur. Et encore j'ai un doute, par expérience les CCD sortent des signaux d'amplitude relativement faible et qui nécessite en plus un échantillonnage précis. Il faut généralement utiliser un échantillonneur-bloqueur pour prendre la valeur du signal au bon moment sinon c'est du bruit d'horloge que l'on échantillonne. Comme le suggère ekaki il faudrait peut être en dire plus sur ton CCD.

5

Un grand merci pour vos réponses !

al1fch -> C'est parfait, le comparateur de tension fera tout à fait l'affaire ! Dans sa version externe, car le faire sur l'arduino prendrait beaucoup de ressources pour mon application. Petite question, ce genre de comparateur fonctionnera toujours à 20Mhz ?

ekaki -> C'est une barrette CCD mono-ligne, il s'agit de l'UPD3739.

fdufnews -> J'ai conscience que c'est très très limite, de toute manière le but est d'arriver à 20 Mhz, et ça ne se passera pas sur un arduino. Je veux juste arriver à faire fonctionner la barrette le plus lentement possible sur l'arduino (Ou autre pic plus musclé si il reste peu couteux, mais à ce moment là je ne suis plus sur le bon forum :p), pour m'assurer que tout fonctionne (Le capteur, la mise en place de l'objectif, etc), pour après me frotter au FPGA qui est un monde tout nouveau pour moi. En gros, générer la clock, lire l'entrée digitale, et la sauvegarder si 1.

Merci d'apporter vos doutes, c'est exactement ça qu'il me manque, l'expérience autour de ces capteurs.

Je me trompe peut-être complètement sur la façon d'interfacer ce capteur avec l'arduino ? Je suis également curieux de tout ce qui peut toucher au pourquoi du comment de la communication entre l'arduino et le CCD (Il existe des posts sur le net, mais bien trop peu :/)

6

En parcourant la doc les contraintes de timing des horloges (chevauchements) provoquent les réflexions suivantes :
-s'il est prévu de passer au FPGA ... autant commencer tout de suite sans perdre du temps et des cheveux en tentatives de mise au point d'horloges par Arduino ... tout juste potables à 500kHz!!
-si l'étape Arduino est décidée (sans retour !!), je ne vois qu'une production d'horloges en routines assembleur..soigneusement ajustées, cycle machine par cycle machine ou mieux : un 'petit' hard externe de production des horloges et un Arduino qui 'compte le points', gére la fenetre de comptage jusqu'à l'arrivée du pixel lumineux attendu... (si le FPGA n'est pas abordable au premier abord, cette génération d'horloge peut etre faite avec un CPLD voire même qq GAL 22V10)

Les comparateurs (basiques) que j'ai indiqué ont des temps de réponse excessifs pour travailler à 20 MHz.
Il faut des modèles rapides.

7

D'accord, et bien tant pis pour la partie Arduino, je passerai tout de suite au FPGA. A moins que la partie en assembleur soit relativement simple à coder/appliquer (Je dispose de plusieurs arduinos), par exemple un arduino " version assembleur " en générateur de timing et un autre " normal " pour l'analyse. (Allez savoir pourquoi, je doute que ce soit simple :stuck_out_tongue: )

al1fch:
Les comparateurs (basiques) que j'ai indiqué ont des temps de réponse excessifs pour travailler à 20 MHz.
Il faut des modèles rapides.

Je m'en doutais, mais j'espérais avoir tord. Aurais-tu un autre composant à me conseiller ? (Y'a pas de soucis si c'est pas le cas, je cherche déjà en parralèle, je suis juste un peu perdu)

(Edit : le LM311 fonctionne au max à 500 khz. Le LM360 a un temps max de réponse de 20 ns, ce qui semble plus convenir !)

Ce que je cherche à tout prix éviter, ce sont les solutions onéreuse. J'ai trouvé des ADC 16 bits pouvant fonctionner à 20Mhz (Et jusqu'à 70), s'interfaçant très bien avec des FPGA, mais les versions " toute faite " (Juste l'ADC + quelques autres composants) sont à 50 dollars pour une voie. Sachant qu'il me faut 4 voies par dispositif (Un dispositif est constitué de deux capteurs CCD, et les capteurs CCD ayant deux sorties, ça fait 4), que le FPGA chiffre à 50 dollars, on arrive à 250 dollars par dispositif (Et j'ai besoin d'une vingtaine de dispositif, la facture s'allonge très très vite).

D'où ma préoccupation d'avoir une méthode par seuil.

8

Je n'ai pas de référence de comparateur rapide à l'esprit.
Par contre en voyant le schéma proposé page 18 pour les buffers de sortie je me demande s'il n'est pas possible de compléter un peu ce schéma pour en faire un comparateur simpliste et rapide à composants discrets :
Second transistor 2SC945 ou équivalent :
-Collecteur relié à +12V par une résistance,
-potentiel de base constant par pont diviseur (potentiometre et butées) entre +12V et masse,
-émetteur relié à l'émetteur du premier 2SC945.
On doit arriver par ce couplage entre émetteurs à faire un comparateur grossier mais rapide avec sortie sur le collecteur du transistor ajouté.

La production des horloges en assembleur se ramenerait à une enfilade de sbi de cbi et de nop !!

buffer.jpg

9

C'est bien ce que je craignais. Oublies la lecture avec un processeur. Il faut générer trop de signaux pour piloter la barrette. Si les horloges ne se croisent pas parfaitement tu ne récupèreras que du bruit.
Je pense que tu risques de perdre beaucoup de temps pour lire ta barrette avec le processeur.

J'ai trouvé des ADC 16 bits pouvant fonctionner à 20Mhz (Et jusqu'à 70), s'interfaçant très bien avec des FPGA, mais les versions " toute faite "

Attention comme je le disait plus haut et c'est confirmé dans la doc de ta barrette, le signal doit être échantillonné à un moment très précis (la partie grisée dans les timing charts 2 et 5). Si tu ne prends pas cette précaution le rapport signal/bruit se dégrade. Il faut impérativement utiliser des ADC avec un échantillonneur bloqueur.

D'où ma préoccupation d'avoir une méthode par seuil

Si tu veux fonctionner uniquement par seuil il faut alors valider la sortie du comparateur uniquement pendant la période représentative du signal valide (partie grisée de la doc comme expliqué ci-dessus).
Tu n'en as pas beaucoup dit sur ton application mais il faut faire attention au fait que le fonctionnement avec un seuil fixe ne permet pas de s'adapter si les conditions d'environnement évoluent

10

Et bien on oublie toute la partie arduino alors, tant pis, ça aurait été trop beau de ne traiter qu'un problème à la fois :slight_smile:

Merci pour vos recommendations !

fdufnews -> C'est pour de la motion capture optique, ce sera en studio, lumière constante, etc, normalement pas de soucis pour le seuil.

al1fch -> Malheuresement je n'ai pas compris la moitié de ce que tu préconises, si déjà j'arrive à reproduire le schéma du datasheet et qu'il fonctionne, ce sera fantastique ! (Je n'ai reproduit qu'un schéma de Ne555 dans ma vie ^^) Ayant trouvé un comparateur rapide (plusieurs en fait, on verra en application), j'espère que ça ira.

Si des gens sont interessé, je posterai mes avancées (Parce que mine de rien, tout est un peu éclaté sur le net, en ce qui concerne les CCD).

11

je proposais de tenter de transformer les buffers (B1 et B2) de sortie préconisé par NEC en comparateur 'grossier'. Ajout d'un transistor, de 3 résistances et d'un potentiometre au schéma du bas de la page 18. (partie surlignée en jaune) Sortie au niveau de la fleche rouge.
Pas les mêmes performances qu'un LM360 mais parfois ça suffit.

C'est pas 2 horloges qu'il faut générer mais 5 avec des contraintes importantes (@ -GJ- du forum électronique de futura sciences ;))

buff comp.jpg

12

al1fch:
C'est pas 2 horloges qu'il faut générer mais 5 avec des contraintes importantes (@ -GJ- du forum électronique de futura sciences ;))

Haha ! (En plus je me suis dit que ça devait probablement être le même public :p) 5, autant pour moi :frowning:

Dommage qu'on ne puisse pas plus continuer ici :confused:

Merci en tout cas de ton investissement pour le schéma :slight_smile:

(Le truc embêtant quand on est en voyage, ne pas pouvoir bidouiller et devoir attendre de revenir à l'atelier, de réfléchir que sur du théorique -_-)

13

Après quelques jours d'expérimentation, pleine de découverte à propos des FPGA, VHDL et cie, j'ai enfin obtenu un résultat, d'après l'oscilloscope le capteur CCD a l'air de bien réagir à mes 5 horloges.

1280×853 504 KB

1280×853 404 KB

Avant de commander les LM360, j'ai bien envie de tester la méthode de al1fch (Ajout d'un transistor+résistances), je la comprends mais je n'ai tout simplement aucune idée des valeurs des résistances, pourrai-t-on m'aiguiller ? Merci d'avance :slight_smile:

Pour rappel, le circuit original, et le but étant de " seuiller " la tension de sortie.

J'ai mesuré la tension de sortie, quand il fait noir, j'ai du 2.08v, et en pleine lumière, 1.97v. Ça ne vous parait pas trop petit comme écart de tension à comparer à l'aide de transistor ?

14

Qu'as tu pris comme fpga ?

15

Bonsoir

Avec une dynamique aussi faible je retire ma proposition de transformation du buffer de sortie en comparateur !! Elle est hors sujet si l'écart entre niveaux n'est pas de l'odre du volt.
Quelques questions : (je n'ai pas étudié la notice du CCD).
Est-il normal d'avoir une si faible dynamique ?
Les mesures de niveaux ont-elles été faites sur les broches de sorties ou en sortie des buffers B1 et B2 conseillés ?
Le timing des horloges est-il respecté, les points de croisement des horloges vérifiés , voire ajustés ?
A défaut le signal perdrait beaucoup d'amplitude et il ne resterait pas grand chose en sortie.
C'est peut être ce qui se passe. Pas facile d'évacuer les charges vers la sortie sans en perdre au passage !!
Imagines un seau d'eau rempli passant ensuite de main en mains sans précautions et 3 gouttes à l'arrivée !!

16

J'ai mesuré la tension de sortie, quand il fait noir, j'ai du 2.08v, et en pleine lumière, 1.97v.

D'après la doc de la barrette, tu devrais avoir une dynamique bien plus importante.
Niveau de noir 3mV max
Reponse min 7,2V/Lxs
Niveau de saturation 0,17Lxs
Donc niveau min lorsque l'on sature 7.2*0.17=1.22V
Toi tu ne trouves que 11mV
3 explications possibles:

  • tu n'échantillonnes pas le signal au bon moment
  • tes horloges ne se croisent pas correctement
  • tu travailles avec un niveau d'éclairement trop faible et ton information va être perdue dans le bruit

Les 2 premiers points sont très importants pour récupérer un signal correcte
Le premier point permet de bien séparer le signal du bruit d'horloge
Le second point influe très fortement sur l'amplitude du signal, en effet les horloges commandent le transfert des charges dans le registre à décalage jusqu'à la sortie. Ce registre est constitué de capacités connectées les unes aux autres par des transistors. Si les horloges ne se croisent pas parfaitement deux transistors voisins conduisent ensembles et il y a des fuites entre des capa voisines et le signal se perds (effet de moyenne entre deux pixels voisins à chaque décalage).

Il ne faut pas perdre de vue qu'une matrice CCD est un composant 100% analogique.

17

Reglage analogique fin des points de croisement !!

points de croisements.jpg
points de croisements.jpg812×369 43.2 KB

18

Merci pour vos réponses,

Pour le FPGA, il s'agit du XuLA-50 (Spartan 3A, http://www.xess.com/prods/prod047.php ), moins de 30 euros avec le taux actuel !

Je vais donc revérifier toutes mes horloges. J'ai fait les mesures à la sortie des buffers, j'ai tenté de reproduire les schémas d'exemple du datasheet. J'ai juste enlevé les inverseurs d'horloge entre les sorties FPGA et le CCD (D'ailleurs je n'ai pas compris pourquoi ils sont là, sur le schéma il est demandé d'y brancher les entrées horloge inversés pour les désinverser après) :

921×798 47 KB

Au début, je les avais laissé tel quel, mais cela ne fonctionnait pas alors j'ai branché directement les sorties du FPGA aux entrées horloges du CCD. Puisqu'on les as mis là je dois certainement me tromper, peut-être pourrai-vous m'éclairer.

Avant de chercher plus loin, je me demande si je réalise pas mal l’échantillonnage, j'ai vérifié sur l'oscilloscope ce que j'avais en sortie, en occultant différentes partie du capteur pour voir les parties affectés, et ça avait l'air de bien réagir. Ensuite, pour relever la valeur, j'ai tout simplement utilisé un voltmètre à la sortie des buffers. Je comptais relever cette tension sur l'oscilloscope, mais je n'arrive pas bien à voir, mon utilisation des oscilloscope au lycée remonte un peu...

Voilà ce que j'obtiens en utilisant en plaçant une source de lumière sur le côté du capteur (On devrait obtenir un dégradé, ce qui est le cas) :

1280×853 309 KB

20 mV/div - 0.2ms/div, en haut le signal du channel 1 à la sortie du capteur CCD, en bas le signal du channel 2 à la sortie du buffer.

En mesurant la tension d'alimentation du capteur CCD, je viens de me rendre compte qu'elle était à 11.3v, ça commence à être limite pour un capteur qui demande du 12v ?

EDIT : Je suis tout simplement idiot, les pins du FPGA sortent du 3.3v, ça ne correspond pas du tout aux 5v... J'étais habitué aux arduinos qui étant alimenté par de l'usb sortent aussi du 5v. Je vais régler ce " petit " soucis de ce pas !

19

Il m'échape peut être quelque chose mais je dirai que les 'inverseurs' attaquant les entrées horloges pas là pour la fonction logique 'NON' mais pour leurs caractéristiques de sortie en courant (I source et sink égaux = 24mA, 'symétrique') en 5V. Cela est nécessaire vu les capacités plutôt élevées des entrées d'horlogs.(typ 350pF)

Placés entre FPGA et CCD on peut plutôt voir les 74AC04 comme des 'buffers' ou des 'drivers d'horloge' économiques.
Comme le soulignait fdufnews on a içi une forte influence de l'aspect 'analogique' des choses (courants, charge de condensateurs, temps de montée...)
La notice évoque un ajustement des croisements grâce à des résistances de qq Ohms ou dizaines d'Ohms...ça fait penser à un travail en finesse sur les transitions des signaux d'horloge, une maitrise pointue des temps de montée et de descente.

Déjà en envoyant des signaux 5V là ou le CCD les attend ça devrait avoir plus de pêche en sortie !!

20

Pour le moment je ne comprends pas, quand je met un pin en sortie du FPGA à 1, tout le temps, le voltmétre relève 3.3v. Ce qui est normal. Mais dès que je fais osciller le signal, ma tension s'effondre sur l'oscillo, à 0.5v... Je pense que tout le soucis vient de là à la base !

Merci en tout cas de votre aide, je vais continuer à chercher !