Messages

Je recherche présentement un remplacement potentiel pour le MV89A.  J'ai trouvé sur ebay un oscillateur au Rubidium FE-5650A.  Est-ce que ça ferait un bon remplacement d'apres vous?

La tension au niveau du régulateur est d'environ 11,4 V. L'OCXO est bien alimenté et tout semble correct de ce côté.
Concernant la température, elle se situe actuellement autour de 40 °C. Elle était à environ 38 °C cet hiver. Elle oscille un peu, mais cela ne me semble pas significatif. Je relève cette valeur grâce à un LM75A placé à côté de l'OCXO.

J'envisage de le remplacer. Cependant, je cherche une alternative plus récente au MV89, car la plupart de ceux que je vois sur eBay ont autour de 20 ans. J'en ai même vu des « neufs » du même âge, ce qui n'est clairement pas un avantage.

Salut,
J'ai construit il y a environ 3 ans le GPSDO proposé par Bertrand dans ses vidéos. Celui-ci est muni d'un OCXO Morion MV89A.
Pendant les deux premières années, la fréquence semblait très stable. Cependant, depuis septembre dernier, la fréquence de l'OCXO augmente progressivement, ce qui oblige le GPSDO à compenser en baissant la valeur du DAC. Par exemple, celle-ci est passée d'environ 30 300 en septembre à 21 659 actuellement. La tendance est clairement à la baisse et s'accélère au fil du temps.

Selon une IA, ce comportement serait dû au vieillissement de l'OCXO, qui a maintenant une vingtaine d'années.

Je me demandais si d'autres bidouilleurs ici avaient déjà rencontré ce phénomène et s'il existe des solutions. J'envisage notamment de remplacer l'OCXO lorsque le GPSDO ne pourra plus compenser correctement.

Bonjour à tous.
Je voulais vous poser une question.
J'ai créé le GPSDO avec le firmware V1 et tout fonctionne correctement, mais après la mise à jour vers la V2, le FLL ne se connecte plus et les erreurs AL ne sont plus minimes.
Quelqu'un aurait-il une idée pour résoudre ce problème ?
Merci beaucoup.

C'est assez intéressant.  Le port série du GPS ne fonctionnait plus avec la version 2 de mon côté.  Il faut préciser que j'ai installé la nouvelle version sur un deuxième micro controller STM 32.  Disons que je n'ose pas mettre à jour celui actuellement à la version 1 puisqu'il fonctionne correctement.

Bonjour,

Je vous avais partagé une capture d'écran d'un dashboard que j'avais réalisé pour le GPSDO avec l'outil Node-Red.  Je l'ai complètement revampé cet été.  Voici la nouvelle version:

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

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

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.

J'ai essayé une antenne similaire à la tienne en haute puissance il y a quelques années.  La mienne avait un peu plus de 20m.  C'étais une antenne commerciale commandé aux EU.

J'avais beaucoup de retour RF dans le shack.  J'ai doc été obligé d'y ajouter un rf choke. Aussi, une radiale par terre est conseillé.  De plus. j'avais de mauvais rapports de signaux sur 80m  mais ce sera peut-être mieux pour toi avec 40m de fil. 

Aussi, les ferrites réagissent mal lors d'opération intensives comme des concours RTTY à haute puissance.

As-tu déjà entendu parler des EFHW half wave?  Ils sont alimentés par un UNUN 49:1.  J'ai jamais essayé ici mais j'ai copié des amateurs munis d'une telle antenne et leurs signaux étaient excellents.

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.

Bonjour,

Je suis à la recherche d'un multimètre un peu plus précis que le mien.  J'ai trouvé le AstroAI TRMS 6000 qui me semble bon. 

Est-ce qu'il y en a parmi vous qui l'ont essayé? 

Des suggestions de multimètres pour le bidouillage en électronique sont aussi appréciés.

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à.

Bonjour,

En voulant changer le paramètre REPONSE_OCXO_HZ_PAR_V dans le code source, j'ai obtenu l'erreur de compilation suivant:

c:/users/beruq/appdata/local/arduino15/packages/stmicroelectronics/tools/xpack-arm-none-eabi-gcc/12.2.1-1.2/bin/../lib/gcc/arm-none-eabi/12.2.1/../../../../arm-none-eabi/bin/ld.exe: C:\Users\beruq\AppData\Local\Temp\arduino\cores\10846859e97402a923050d0c9ee44af1\core.a(HardwareSerial.cpp.o):(.bss.Serial2+0x0): multiple definition of `Serial2'; C:\Users\beruq\AppData\Local\Temp\arduino\sketches\380C3C6D5A705E5372702EC3733DF287\sketch\Controle_Reference_10MHz_STM32_Final_v1.ino.cpp.o:(.bss.Serial2+0x0): first defined here
collect2.exe: error: ld returned 1 exit status

exit status 1

Comme le code source compilait bien avant, je crois que tout ceci est apparu après avoir mis à jour Arduino IDE ainsi que quelques librairies.  En renommant "Serial2" sous un autre nom j'ai réussi à compiler le programme et à installer le firmware sur le STM32. 

Est-ce qu'il y en a qui auraient ne idée de ce qui aurait causé une erreur?

Comme un problème n'arrive jamais seul, mon GPSDO n'a pas bien fonctionné depuis mais je doute que ce soit relié au problème plus haut.  Je soupçonne que le GPS a perdu sa configuration.  Je vais regarder cela ultérieurement.

Merci

Il m'arrive d'avoir eu un tel comportement ici aussi.   La dernière fois, que ça s'est produit, j'ai fait un REACQ et le GPSDO s'est restabilisée à  une valeur de DAC plus basse.  J'attribue cela au filage de mon montage qui doit être refait éventuellement.

Je ne voie pas de découplage HF sur l'alimentation de L'OCXO, tu peu mettre un 100 nF ainsi que sur le Vtune au plus prés de L'OCXO.
A tu pensé à  déconnecter l'antenne intégré du GPS si tu utilise une antenne extérieur (SMA) ? car sans quoi elles rentrent en conflits, il y a une vidéo qui l'explique mais je ne me rappelle plus laquelle.
Si tu a bien configuré la valeur de réponse de L'OCXO et que ton boitier est tout en métal alors il ne devrait pas y avoir de problèmes.

Pascal

Le condensateur découplage HF sur l'alimentation est sous la plaquette de l'OCXO.  J'ai mis un condensateur au tentale de 10 µF.
Pour celui du vtune,  je vais en ajuter un en même temps que le coax.  J'en ai plein en céramique si ça fait l'affaire.
Le boitier est en aluminum.  Le RF peut s'infiltrer de bien des manières, surtout aux alentours de 7Mhz.  En tk, ici c'est la bande qui me cause le plus de problèmes ici.
L'antenne intégré du GPS a bel et bien été déconnectée.

Je suis assez novice en bidouillage électronique.  Alors, c'est fort possible qu'il y ait quelques erreurs dans le montage, surtout au niveau des alimentations.

Merci pour les infos.

Martin