Nous avons vu que la synchronisation du signal d'horloge par un récepteur GPS permet d'obtenir une horloge dont la précision théorique est de l'ordre de 10E-12 dit-on. Mais lorsqu'on alimente un circuit DDS avec une telle horloge, ledit DDS fournit des fréquences recalculées qui ont la stabilité du GPS (pratiquement pas de dérive à long terme), mais pas la précision, cette dernière étant automatiquement perdue par le fait que le calcul dans la DDS génère une erreur, certes très très minime, certes déterministe, connue (si on se penche de très près sur le calcul...), mais différente pour chaque fréquence et très mal venue s'agissant d'un générateur de fréquence.
La solution ? Se pencher justement sur le calcul pour imaginer la parade. L'erreur de fréquence est tellement faible que l'on devrait plutôt parler de lent et régulier glissement de phase.
Le plus simple pour le mettre en évidence consiste à régler le générateur afin qu'il produise un signal de sortie de 12MHz et de comparer ce signal, à l'oscillo en bi-trace ou en Lissajous avec le signal 12MHz pilotant le DDS. Ce devrait être exactement la même fréquence mais du fait du principe même du DDS ce n'est pas le cas. Il y a glissement d'une période entière après environ 22s soit 1/22x10E6 = 3.8x10E-9 ce qui dégrade la précision d'un facteur dix par rapport à celle obtenue en comparant la fréquence du GPS à celle du rubidium (sachant que je ne sais toujours pas vraiment laquelle est la plus exacte des deux, rubidium ou GPS ??) précision qui je le rappelle était dans le pire des cas 3x10E-10. Dommage non ?
La parade pourrait consister à injecter des périodes à des moments précis (toutes les x périodes...), ce qui consiste à provoquer des sauts de phases bien peu sympathiques, ou alors à provoquer un lent et régulier glissement de phase antagoniste ce qui serait bien plus indolore. Cette seconde façon de faire semble justement bien convenir au circuit DDS puisqu'on peut piloter finement la phase du signal de sortie, comme l'explique son datasheet.
Un autre approche consisterait à ne pas garantir la fréquence des signaux sinus avec une telle précision, et en contrepartie générer des fréquences "rondes" par divisions exactes du 12MHz (avec des diviseurs TTL LS ou une PLL avec diviseur programmable telle le LM7001 déjà expérimenté sur ce site, ICI). Comme quoi, parfois, qui peut le moins peut le plus !!
(Remarque : 1/2³² ~= 2.3x10E-10 pour le mot de 32 bits définissant la fréquence dans le DDS, on devrait donc pouvoir faire mieux en revoyant la programmation du DDS de plus près. C'est bizarre, j'ai pourtant effectué le calcul du mot de commande sur 64 bits avant de l'appliquer au DDS). Toutefois cette précision de 2.3x10E-10 ne serait valable que pour des variations autour de la pleine échelle (240MHz en sortie du multiplieur interne) ? Je vais tirer ça au clair.
23 octobre 2015:
Voici la procédure de test que j'ai appliquée : J'ai donc réglé le générateur afin qu'il produise un signal de sortie de 12MHz et comparé ce signal, à l'oscillo avec le signal 12MHz pilotant ce DDS. Léger glissement d'une période en 22s. J'ai alors bricolé le calcul du mot de commande du DDS (voir le fichier AD9951-628v2.cpp) en ajoutant "1" (une unité) au mot FTW avant de l'envoyer au DDS. Et dés lors le glissement d'une période se fait en 1m30s, soit 90s.
Ce qui correspond cette fois à une imprécision de 1x10E-9, soit environ quatre fois mieux. Si j'ajoute (ou retranche) plus d'une unité alors le glissemment s'accentue au contraire. Preuve que le calcul est exact à... un bit près. Pas de solution exacte donc à attendre de ce côté, je vais juste voir comment se fait l'arrondi dans mon code source, au passage des uint64 vers un entier 32 bits.