Un petit wobulateur: le NanoWobu

[Arthur_Elec]

Bonsoir,
Je vous présente le projet du moment, un cousin du zébulateur de @Blaireau, j’ai dénommé le NanoWobu !

Le principe est le même: un microcontrôleur permet de gérer les diverses options du kit AD9851. Dans mon cas, c’est un Arduino Nano au lieu d’un PIC, d’où le petit nom NanoWobu. Il y a aussi une roue codeuse, un clavier et un écran pour suivre les options. Il sera monté dans un tiroir double pour Tektronix TM500.
Ce petit projet est avant tout numérique, je peux donc travailler dessus quand je n’ai pas mon matos (c’est à dire 90% du temps).

Il y a les 3 modes classiques d’un générateur wobulé:
Start-stop: balayage en fréquence entre une fréquence de début et de fin.
Center-span: balayage en fréquence autour d’une fréquence centrale.
Single: générateur de fréquence simple sans balayage.

Et détails options supplémentaires:
-Balayages montant, descendant ou aller-retours.
-Balayage logarithmique/linéaire
-Le clavier permet de rentrer directement les fréquences ou les temps, avec des multiplicateurs Hz, kHz et MHz (touches A, B et C), une touche suppression (D - delete -) et une virgule (*).
-Roue codeuse avec accélération (c’est à dire que plus la roue est tournée rapidement, plus le pas d’incrémentation est élevé)
-Durée de balayage de 1ms à 10s à la milliseconde près.
-De 2 à 20000 pas.
-Fréquences de début et fin 0 à >50MHz, réglable au Hertz près (à 0.4Hz sur le kit mais 1Hz en logiciel)
-Atténuateur contrôlé (PE4302) par pas de 0.5dB de 0 à -31.5dB.
-Mis en mémoire des paramètres pour les retrouver au prochain démarrage.

Concrètement, le projet est globalement fonctionnel malgré quelques bugs, par exemple des petits problèmes de compatibilité entre clavier et roue codeuse, l’affichage lorsque l’on rentre l’information via le clavier, le recalcul trop long des fréquences durant un balayage faussant la durée totale (je prévois de précalculer et stocker dans un tableau). Il y a aussi des soudures à finir le filtre passe bas pour filtrer la sortie du CAN à refaire, le convertisseur différentiel/single (à priori par AOP), l’alimentation 12V->5V, et tout monter dans le boitier TM500 imprimé en 3D, il faudra pour ça un nouvel écran plus compact.

Voici une petite vidéo pour montrer quelques possibilités de ce wobulateur:

Nanowobu: Wobulateur arduino et AD9850 Part. 1

La suite à venir prochainement
Arthur

[Blaireau]

Joli, le zébulateur bis.
Pour les bugs, le problème, c’est de ne pas interférer sur un autre paramètre en corrigeant.
C’est précisément à ce point qu’il faut avoir toutes les inter-actions du soft en tête, pour ne faire aucun dégât sur l’existant.

En ce qui concerne les calculs de fréquence, (F X 2^32)/Fclock, on peut l’accélérer fortement, sans passer par le calcul en flottant, et tout faire avec des nombres entiers.
Si ça vous tente, la méthode est simple, très rapide, et d’une remarquable précision.

Continuez, on attend la suite!

[Arthur_Elec]

Merci !
Et oui, mais il faut parfois savoir reprendre de zéro certaines parties assemblées au fur et à mesure.
Les calculs se font en effet en flottant, pour le cas linéaire ça va encore:

startFreq + (endFreq - startFreq) * stepEffective / (wobulationSteps - 1);

En log, c’est là que je voulais mettre des tableaux pour calculer par avance les facteur log et 10^x, il n’y a dans tous les cas pas assez de place pour stocker 20000 entiers sur 32bits dans un Arduino !

float ratio = log10((float)endFreq / startFreq);
(unsigned long)(startFreq * pow(10, ratio * ((float)stepEffective / (wobulationSteps - 1))));

Après un test rapide, je gagne un facteur 5 sur 10 pas, et presque un facteur 10 sur 100 pas!

[Blaireau]

J’utilise une méthode différente.
La fréquence est stockée directement en Hz dans un entier de 32 bits, ce qui permet de mémoriser jusqu’à plus de 3 GHZ.
On calcule la valeur de 1Hz, pour le DDS, qui deviendra une constante…
0.000001 X 2^32 / 180. (pour un AD9851 à 180 MHZ)
On a donc la valeur flottante de 1 HZ pour le DDS.
On multiplie ce résultat par 2^16, pour en faire un entier 16 bits, dont la partie fractionnaire sera tronquée.
Ce nombre n’est calculé qu’à l’initialisation, puis gardé en ram, pour servir ensuite dans tous les calculs.

Il suffit ensuite d’appliquer simplement F, (en HZ sur 32 bits) multiplié par cette constante de 1 HZ, pour obtenir la valeur directe du DDS sur 48 bits.
La valeur définitive est obtenue en ne gardant que les quatre octets de poids fort, pour l’arrondi de calcul et le tour est joué.
On a donc bien la valeur 32 bits définitive à envoyer au DDS.

C’est très simple, très rapide pour le µP, mais moins facile à expliquer.

[Arthur_Elec]

Donc si je comprends bien vous calculez tout en avance, stockez sous formes d’entiers dans un tableau que vous lisez avec le pas voulu, puis appliquez un facteur pour revenir sur la plage effective du DDS?
La conversion temporaire sur 48 bits risque de ralentir un peu le calcul de mon côté de ce que j’ai vu.

[Blaireau]

Pas exactement, en simplifiant, je multiplie simplement la fréquence en Hz (entier 32 bits), par la constante 1Hz, (entier 16 bits), pour obtenir un résultat 48 bits.
En ne gardant que les 32 bits de poids fort du résultat, on divise bien le total par 2^16, pour compenser multiplication initiale par 2^16 de la valeur de 1 Hz, ce qui permet d’effectuer tous les calculs sans passer par une routine flottante, affreusement consommatrice en cycles d’horloge.
En résumé, on multiplie par 2^16, on calcule, et on divise par 2^16.
Cette multiplication/division en entier, par décalages arithmétiques successif est très économe en cycles d’horloge, et permet d’accélérer fortement la vitesse de calcul.

[Blaireau]

Vérification faite, le résultat de la constante tient su 24 bits, et non 16.
Avec une horloge à 180 MHz, Hex 17DC66.
Il suffit donc de supprimer les 3 octets de poids faible du calcul final pour obtenir la valeur définitive à expédier au DDS.

Petite remarque concernant la vitesse de wobbulation variable.
Le temps de montée des circuits mesurés n’est pas instantané, et il est important de garder une vitesse de wobbulation raisonnable.
Ce problème est bien connu en analyse spectrale, et les analyseurs préviennent d’une mesure fausse quand le temps de balayage est trop faible par rapport à la bande passante de la mesure.

Les symptômes sont flagrants:
L’amplitude de mesure se réduit
Le centre de la courbe se décale vers la droite de l’écran.

Même problème avec les wobbus.
Il vaut mieux utiliser une fréquence passe partout de 50 HZ, qui combine la persistance rétinienne, et un temps de montée correcte pour la quasi totalité des mesures.

Sauf cas particuliers, une fréquence d’excursion trop rapide fausse complètement les résultats des mesures.

[Arthur_Elec]

Oui bien sûr, il y a même une formule dédiée à ce soucis temps=excursion/résolution. Mais pour des fréquences faibles que je souhaite conserver dans la mesure du possible, 50Hz est juste. Je me suis basé sur les même limites que le Tektro 5L4N, qui se limite néanmoins à 110kHz.
De toutes façons ça n’est que logiciel donc « gratuit ». Avec la lecture des logarithmes et puissances par tableau je peux descendre facilement à mon objectif de 1ms.

[Osgood]

Le calcul en flottant est très gourmand et pas forcément nécessaire. Tant que possible, rester en virgule fixe, c’est beaucoup plus rapide, puisque ce sont des entiers, on choisit juste de représenter des nombres décimaux en positionnant une virgule imaginaire où on veut. Cela nécessite cependant d’avoir les idées claires sur les nombres que l’on manipule et sur l’effet des calculs (une multiplication de deux nombres 15.1 donne un nombre 30.2 par exemple). Donc attention aux débordements. Ce n’est pas la simplicité du flottant, mais c’est le prix de l’efficacité. Si on fait du traitement de signal, par exemple (filtres FIR), c’est préférable, et simplifie aussi l’implémentation par exemple en FPGA.
Ensuite, bien réfléchir aux algorithmes et simplifications possibles. Par exemple, ne pas oublier que log(10x) = 1 + log(x). Et log(100x) = 2 + log(x).
Donc, si on s’y prend bien, on peut réduire fortement le nombre de calculs longs, et limiter drastiquement la taille d’une éventuelle table.
Apollo a volé avec des puissances de calcul très faibles. Même sur un PC, si on fait n’importe quoi, on peut mettre à genoux le système.

[Arthur_Elec]

Bonjour,
Quelques avancées mécaniques sur ce montage:

ça m’a pris une bonne aprèm à faire tout ces trous. Il restera 3 trous pour deux BNC (sortie et trigger) et le bouton encodeur.
J’ai du changer l’écran par un plus large et moins haut pour que ça tienne dans mes modules Tektro.

Dedans toujours pareil. Les câbles sont trop courts.

Après tout ce travail je me suis dit que j’aurais juste pu me faire en 3D…

ça ne m’a pris qu’à peine une heure et c’est quand même plus pro. Il faut faire pareil pour la deuxième plaque avant en alu maintenant, ça devrait être rapide.

[Blaireau]

Et quand le wobbu sera terminé, il ne restera plus qu’à en faire bon usage!

[stecha]

Très différent du nôtre?

[Bruno]

@Arthur_Elec

ça m’a pris une bonne aprèm à faire tout ces trous

[Arthur_Elec]

Non ! Exactement le même usage ( à la différence près que je voudrais descendre un peu plus bas en fréquence)