Échantillonnage 80 MHZ signal TTL

[invite6b26d34c]

Bonjour à tous,

Ma problématique est la suivante :
J'ai un signal TTL 0/5V que j'ai analysé par un algorithme de traitement du signal développé sous LabView avec une carte NI.
Actuellement, j’échantillonne mon signal TTL à 80Mhz, pour déterminer avec une grande précision le temps entre chaque front montant. Ce temps est extrêmement important dans mon algorithme.
Les cartes NI étant particulièrement cher, je cherche à créer ma propre carte électronique pour échantillonner mon signal.

J'ai commencé à réfléchir à la question et l'idée la plus prometteuse me semble être la suivante :
Utiliser une horloge à 80Mhz, branché sur des bascules D (4 pour résolution 16 bits) pour compter le nombre d'impulsions entre deux fronts montant.
Chaque front montant devras donc faire un RESET sur les bascules et le dernier comptage des bascule devras être sauvegardé le temps qu'un microcontrôleur vienne lire la valeur. L'idéale serais que le microcontrôleur lise la valeur sur le minimum de broche ( SPI ou I2C )

Que pensez-vous de cette approche ? Comment faire pour "sauvegarder" la dernière valeur de mes bascules D ( 4 bascules D pour avoir un comptage sur 16 bits ) ?

Merci par avance pour votre aide !

.
-----

[inviteede7e2b6]

t'as des bascules D qui tournent à 100 mégas ?

[invite6b26d34c]

Oui, il me semble que celles ci font l'affaire ?

http://www.conrad.fr/ce/fr/product/1...-PDIP-16-1-pcs

[invitee05a3fcc]

Oui, il me semble que celles ci font l'affaire ?

Si tu te bases sur les infos d'un revendeur ...tu es mal barré !
C'est 90Mhz http://pdf.datasheetcatalog.com/data...MC74F163AN.pdf

[A voir en vidéo sur Futura]

[inviteede7e2b6]

et faudrait au moins le double ( Shannon et toussa)

[invitee05a3fcc]

et faudrait au moins le double ( Shannon et toussa)

fastoche ! Tu en mets deux en parallèle !

[invite6b26d34c]

Merci pour vos réponses.
Je crois comprendre qu'il n'existe pas (ou peu) de bascules D suffisamment performantes.
Mon approche n'est donc probablement pas la bonne...
D'après vous, quelle serait la bonne approche ?

[inviteede7e2b6]

si tu n'a aucune expérience en métrologie HF, le mieux et d'acheter l'équipement ad-hoc.

sinon tu vas perdre temps et argent

[Antoane]

Bonjour,

Il faudrait un échantillonnage à 2*80MHz pour pouvoir s'intéresser à des signaux TTL de fréquence allant jusqu'à 80MHz.
Si j'ai bien compris, tu veux, toi, mesurer la période d'un signal de fréquence << 80 MHz en utilisant une horloge à 80MHz.

Utiliser une horloge à 80Mhz, branché sur des bascules D (4 pour résolution 16 bits)

Avec 4 bascules, tu as 4 bits. Ca donne 16 valeurs possibles différentes.
toute fréquence inférieure à 80 MHz / 16 = 5 MHz sera lue comme du 5MHz.

[jiherve]

Bonjour,
avant de compter il faudra gérer la métastabilité donc 2 bascules supplémentaires, l'erreur globale de mesure commise sera alors au maximum de 3 périodes de l'horloge d'échantillonnage.
Ceci dit un comptage à 80MHz avec de la logique discrète TTL ce n'est facile que sur le papier,car rien que la distribution d'horloge est non triviale, pour ce genre de projet il faut passer par un FPGA (ce qui doit être le cas de la carte NI)ou de la logique ECL.
JR

[bobflux]

Si tu veux de la précision, utilise un "time to digital converter".

Sinon, n'importe quel CPLD un peu rapide fera l'affaire.

Il existe des uC ARM-Cortex tournant à plus de 200 MHz, utilise le timer en mode capture. C'est le même principe que sur un uC de grand-papa qui tourne à 16MHz.

Ce qui arbitrera la question, ce sera la fréquence des impulsions à chronométrer. En effet, si elles sont plus fréquentes que le rythme maximum d'interruption que ton uC peut gérer, alors il faudra utiliser de la logique programmable...

Il y a une différence entre mesurer la durée d'impulsions de 1s, mais précisément, et mesurer la durée d'impulsions répétitives de 100ns. Dans le second cas, on aura beaucoup de mesures, donc on s'intéressera au moyennage des résultats, ou autre traitement. Ce traitement peut déterminer la solution à choisir.

Je reste vague, car tu lâches pas d'infos sur ton problème. C'est... ton problème

[Jack]

Tout le monde est parti sur un signal à mesurer de 80 MHz. Ce n'est pas ce que j'ai compris du problème: le premier message parle d'une fréquence d'échantillonnage de 80 MHz, mais quid de la fréquence du signal à mesurer ou du temps mini entre 2 fronts successifs?

[bobflux]

Oui c'est ce que je disais, en fait le problème est surtout sur la fréquence des impulsions à mesurer, et quoi faire des données mesurées ensuite.

[Jack]

En effet. On attend donc ces fameuses infos.

[jiherve]

bonjour
non tout le monde n'est pas parti de travers et pour avoir une grande précision tout en échantillonnant à 80Mhz on peut penser que le signal incident est << 80MHz ce qui au passage ne change rien quant au sens de mon précédent message.
JR

[Jack]

D'accord, d'accord, je retire mon "tout le monde".
La solution du FPGA est en effet la plus indiquée pour de la logique haute vitesse.

[bobflux]

Personnellemet je mettrais plutôt un CPLD, car c'est plus simple à utiliser qu'un FPGA (moins de tensions d'alim, flash interne, etc). Pour justifier un FPGA pour un problème aussi simple, il faudrait que les impulsions à mesurer soient suffisamment fréquentes pour que le traitement des temps mesurés nécessite l'artillerie lourde...

Pour aller plus haut en fréquence d'échantillonnage, l'utilisation d'un SERDES est envisageable. On peut échantillonne dans les Gbits!

En tout cas, une solution intégrée est préférable (CPLD ou timer de uC rapide) pour éviter les casse-tête de distribution d'horloge etc, comme mentionné par jhervé. Et puis, la logique programmable, c'est flexible, on peut facilement corriger les erreurs et modifier le cahier des charges, tant que le hardware suit...