Projet Reference 10 MHz par GPS

[Électro-Bidouilleur]

Franchement aucune idée. Désolé.

[va2px]

Franchement aucune idée. Désolé.

Merci quand même.

Je n'ai toujours pas réussi à le faire fonctionner de nouveau.  J'ai commandé un nouveau STM32 black pill mais j'ai les même comportement erratiques.  Je ne suis  même plus capable de faire flasher le led sur le board.  Je me demande s'il n'y a pas quelque chose qui rends le microcontroller défectueux dans mon montage.

J'ai contacté le distributeur qui  m'a vendu le dernier black pill et ils m'ont répondu une affaire que je devais mettre un boot loader pour le rendre comme un Arduino.  J'ai l'impression qu'il m'envoient à la pêche ces gens là.

[Électro-Bidouilleur]

Avez-vous essayé de retourner à Arduino IDE 1.8?

Tous les Black Pills que j'ai achetés avaient le bootloader déjà chargé. À mon avis, il parle à travers son chapeau.

[va2px]

Avez-vous essayé de retourner à Arduino IDE 1.8?

Tous les Black Pills que j'ai achetés avaient le bootloader déjà chargé. À mon avis, il parle à travers son chapeau.

Oui, probablement.  Désolé pour le délais.  J'ai laissé le problème de côté durant la période estivale.

J'ai finalement réussi à refaire marcher le micro controller.  Le message d'erreur à la compilation du code source a changé après avoir mis à jour Arduino IDE.  J'ai par la suite essayé de compiler le code source original extrait de l'archive et tout ça a réussi cette fois.

Une chose que je trouve curieux, je dois effacer la plash du STM32 avec STMCube programmer avant de pousser un autre firmware. Il me semble que ce n'étais pas nécessaire quand j'ai fait ce projet initialement.

Bon, je peux maintenant continuer à chercher la bonne valeur pour REPONSE_OCXO_HZ_PAR_V.

Merci pour to aide.

[stephen.tissot@bigsister.]

Un petit message pour l'Electro bidouilleur en chef !
Un grand merci pour ce super projet, j'ai énormement appris en réalisant cet appareil !
J'ai même réussi à apporter quelques petites améliorations :
- J'ai remarqué que la fréquence de l'OCXO n'est vraiment pas stable durant la phase de montée en température, et que mettre en oeuvre la boucle de controle de fréquence alors que la température grimpe est plutôt contre productif. J'ai donc ajouté un capteur de température sur le STM32, posé près de l'OCXO et dans mon cas, le firmware attend que la température atteigne 33°C avant de déclancher la boucle de contrôle. C'est aussi utile d'attendre un peu, le module GPS mettant du temps à trouver ses satellites !
- J'ai aussi ajouté un encodeur rotatif (avec son bouton poussoir) afin de gérer un petit menu (qui permet par exemple d'acquiter les alarmes, d'interrompre la boucle de controle, de rebooter le STM32).

Bref, un super projet, merci encore. J'ai découvert Kicad, produit mes premiers PCB (chez JLCPCB), soudé mes premiers SMD, que du bonheur !

Merci encore et à la prochaine ;-)

[va2px]

Bonjour Stephen,

Le capteur de température est une très bonne idée. Il m'arrive parfois de fermer le FLL le temps que l'OCXO monte en température.  Il faut dire que je ferme rarement ma référence.

[va2px]

Je songe à fabriquer un deuxième GPSDO à des fins expérimentales avec le code source.   Je possède un OCXO Morion MV85 en surplus. Or, en lisant le Datasheet, je constate que la plage de tension externe(Uin) varie de 0 à 4.5V. 

Je sais que d'autres bidouilleurs ont utilisé le même modèle d'OCXO.  J'aimerais avoir vos commentaires sur votre montage.  Est-ce qu'il faut fournir une tension externe de 4,5V?  Dans ce cas, quelles seraient les valeurs de R11 et R12?  Est-ce que de laisser la sortie de Vtune de 0 a 5V peut-être envisageable?

Merci

[stephen.tissot@bigsister.]

Hello va2px !
Moi je laisserai la sortie à 0-5v et je limiterai la valeur max du DAC dans le firmware pour être tranquille.

[va2px]

Salut Stephen,

J'ai parcouru le code source et ça me semble faisable.  Il suffit de changer la validation sur le nombre de bit du DAC par une valeur maximale de DAC à ne pa dépasser.

Merci pour le conseil

Martin

[Électro-Bidouilleur]

Bonjour à tous et à toutes,

On a porté à mon attention une erreur dans le firmware du projet de référence 10 MHz par GPS. L'erreur affecte la communication SPI au DAC80501. Dans le firmware d"origine, j'utilise le SPI en mode 0, ce qui présume que le DAC saisit la donnée DIN sur le front montant de l'horloge SCLK. Mais ce n'est pas le cas! D'après la fiche technique du DAC, la donnée sur la ligne DIN est saisie sur le front descendant de l'horloge. Qui plus est, au repos, la ligne d'horloge devrait être au niveau logique haut, ce qui n'est pas le cas en mode 0. En revanche, le mode 2 rencontre les exigences du DAC. Il faut donc corriger deux lignes dans le code source et recompiler le tout:
Ligne 219:

Code Sélectionner Étendre

SPI.beginTransaction(SPISettings(1000000, MSBFIRST, SPI_MODE2)); // Début d'une écriture d'un des DACs via le port SPI (débit, ordre des bits, mode du bus SPI)
Ligne 459:

Code Sélectionner Étendre

SPI.beginTransaction(SPISettings(1000000, MSBFIRST, SPI_MODE2));// Début d'une écriture du DAC via le port SPI (débit, ordre des bits, mode du bus SPI)

J'ai mis à jour le croquis ".ino" dans le fichier zip du projet, disponible sur mon site web. Vous reconnaîtrez le croquis mis à jour comme ayant la version 2.
https://bidouilleur.ca/Bidouilleur_depot/fichiers_videos/EB_Projet_R%C3%A9f%C3%A9rence_10MHz_Par_GPS.zip

En terminant, vous vous demandez peut-être pourquoi la communication SPI vers le DAC fonctionne quand même en mode 0? C'est que la donnée est maintenue (tout juste) assez longtemps lorsque l'horloge redescend. Mais pour un usager en particulier, sa combinaison STM32-DAC ne marchait pas. C'est dire comment marginale la connexion est en mode 0!

Bertrand.

[philchamp51]

Bonjour Bertrand.

Modification effectuée. Je verrai bien si c'est à cause de ceci que j'avais de temps en temps des pertes de justesse du 10 MHz.

Par contre, une chose bizarre, j'ai une alarme "D" permanente, elle ne passe pas en minuscule, malgré le fait que le 10 MHz soit juste. Cela vous dit quelque chose, à part que le DAC ait atteint sa valeur mini ou maxi ? Comment la faire disparaître ?

[Électro-Bidouilleur]

L'alarme D indique que le changement de DAC requis après un cycle est plus grand que ce qu'il reste avant d'atteindre la limite inférieure ou supérieure du DAC.

Vous dites que le 10 MHz est juste. Comment en êtes-vous si sûr? À mon avis, votre système n'est pas bien configuré et ne peut pas fonctionner correctement. Avez-vous la bonne pente d'ajustement de l'OCXO? Montrez-nous vos paramètres (résultats de la commande PARAM), la valeur REPONSE_OCXO_HZ_PAR_V ainsi que le modèle d'OCXO utilisé.

[philchamp51]

L'alarme D indique que le changement de DAC requis après un cycle est plus grand que ce qu'il reste avant d'atteindre la limite inférieure ou supérieure du DAC.

Vous dites que le 10 MHz est juste. Comment en êtes-vous si sûr? À mon avis, votre système n'est pas bien configuré et ne peut pas fonctionner correctement. Avez-vous la bonne pente d'ajustement de l'OCXO? Montrez-nous vos paramètres (résultats de la commande PARAM), la valeur REPONSE_OCXO_HZ_PAR_V ainsi que le modèle d'OCXO utilisé.

Bonjour Bertrand et merci d'avoir répondu.

Pour le 10 MHz juste, je l'avais mesuré avec mon fréquencemètre HP 5335A qui lui est piloté par un 10 MHz extérieur de référence et la fréquence oscillait entre 9 999 999 99 +6 et 10 000 000 00 +6.

Après une nuit, ce matin, l'alarme D était passée en minuscule. J'ai pu l'effacer mais une heure après, elle est revenue en majuscule persistante. La fréquence mesurée est toujours la même.

L'OCXO est un HP 10811A et les valeurs entrés dans le code sont les suivantes:
      
// Valeurs fixes du système par défaut. Doivent être mesurées et saisies ici:
#define REPONSE_OCXO_HZ_PAR_V -0.3420
#define DAC_TENSION_MIN 0.0000
#define DAC_TENSION_MAX 5.0000
#define DAC_POST_GAIN 1.0

Il se peut que l'OCXO se soit décalé avec le temps, vu qu'il possède un réglage propre. Je vais donc refaire les mesures et réadapter le code en fonction des résultats.

[philchamp51]

Alors.

J'ai refais les mesures conformément à la procédure du manuel de l'utilisateur et les différences avec les valeurs que j'avais il y a deux ans sont infimes mais je les ai tout de même remises dans le code.

Voici les nouvelles valeurs:

#define REPONSE_OCXO_HZ_PAR_V -0.3441
#define DAC_TENSION_MIN 0.0000
#define DAC_TENSION_MAX 4.9987
#define DAC_POST_GAIN 1.0

L'alarme D est toujours présente et voici les paramètres que sort le STM32:

Alarmes: - - D - - - -
Cycle - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - : Long
Échantillon - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -: 283 / 360
Valeur du DAC courante - - - - - - - - - - - - - - - - - - - - - - -: 0
Compteur de l'oscillateur | Compte Nominal - - - - - : 57600 | 57600
Écart vs. compte nominal - - - - - - - - - - - - - - - - - - - - - : 0
Moyenne des écarts du compte - - - - - - - - - - - - - - - -: 0.003534
Moyenne des écarts (ppm) - - - - - - - - - - - - - - - - - - - -: 0.0000
Moyenne des écarts (Hz) - - - - - - - - - - - - - - - - - - - - - : 0.000353
Fréquence moyenne calculée de la référence (Hz): 10000000.000353

[Électro-Bidouilleur]

C'est attendu de voir le D majuscule, car la valeur du DAC est à 0. Le FLL est accoté à la limite inférieure d'ajustement. Demandez-vous pourquoi. Des pistes de vérification:

• Votre OCXO n'est pas centré dans sa fenêtre d'ajustement.
• Vous avez mal configuré les paramètres.
• Une combinaison de 1. et 2.

L'OXCO HP 10811A est un excellent oscillateur, mais sa fenêtre d'ajustement électronique est de seulement +/- 0,5 Hz. Il faut donc que l'ajustement mécanique soit bien fait pour centrer la fenêtre. Qui plus est, la plage d'ajustement électronique est de -5V à +5V. Si vous n'allez pas dans le négatif, vous perdez la moitié de la plage d'ajustement, ce qui rend le centrage et l'opération encore plus difficile.

Pour ce qui est du paramètre REPONSE_OCXO_HZ_PAR_V, la pente de la réponse de l'OCXO est négative, donc le signe moins est justifié. Quant à la valeur, -1 Hz d'ajustement pour 10 Volts de plage (-5 à +5) devrait donner une valeur avoisinant le -0,1. Votre -0.34 est plus de trois fois trop!

Utiliser une référence externe non atomique n'est pas un gage de certitude quant au centrage. Votre système peut produire une performance de plusieurs ordres de grandeur mieux qu'un oscillateur autonome. Stoppez le FLL et faites des ajustements manuels de DAC pour approcher de zéro dans le champ "g: Écart moyen en pulsations du compteur par rapport à la valeur nominale". Vérifiez alors que vous êtes près du mi-chemin de la valeur du DAC. Sinon faites un ajustement mécanique pour mieux centrer.