Etat d’avancement du projet NFC au 19 Septembre 2013

Après avoir travaillé de manière intense sur ma fraiseuse numérique pour pouvoir la présenter au salon des Associations de ma ville, j’ai repris du temps pour faire avancer mon projet NFC. Voici ce qui a été réalisé.

J’ai implémenté les codes nécessaires pour piloter le bus SPI depuis le chip ARM de commande. Ce n’était pas très complexe. J’ai pu vérifier avec un analyseur logique que les signaux étaient corrects. Le Tiva a plein de registres qu’il faut configurer correctement, mais il met à disposition une doc assez complète qui décrit les séquences d’initialisation. Quand on les suit sans se tromper, ça marche!

Les choses sont plus compliquées du côté du front end NFC. Pour commencer, j’ai réussi à obtenir de nouveaux samples de Texas, que j’ai soudé correctement cette fois: Pas d’apport supplémentaire de pâte à braser, mais utilisation de flux et chauffage rapide. Le soudage est très nettement amélioré, l’étain déjà présent sur la carte suffit à assurer la soudure sans débordements.

Il me manque encore tous les composants de la partie analogique et les condensateurs de découplage, mais j’avais envie d’essayer quand même. Effectivement, le chip réagit, puisque le passage de sa ligne “Enable” dans le bon état produit le démarrage de toutes les alimentations secondaires produites par le chip. Au moins, j’ai la preuve que certaines pattes sont correctement soudées et que le chip n’est pas totalement grillé 😀

Par contre, il m’a été pour l’instant impossible de lire par SPI la moindre valeur de registre depuis le chip. Et c’est là que j’ai commencé à découvrir pas mal de défauts du circuit.

Pour commencer, sa documentation n’est absolument pas claire. Elle répète certaines informations dans des paragraphes différents, se contredit, et contient des manques et des erreurs. On ne s’en rend pas compte en première lecture, mais le nombre de messages d’incompréhension sur leur forum “E2E” en dit long.

Le circuit n’est pas non plus exempt de bugs “silicium”. Il réagit de manière non documentée, ou imprévue, quand son pilotage est réalisé comme dans la datasheet. Par exemple, le chip dispose de trois modes de pilotage:

  • un mode parallèle (on pilote 8 fils de données, puis on valide une horloge)
  • un mode SPI sans signal CS : dans ce cas ils ont “inventé” un genre de start condition ressemblant à de l’I2C, mais qui n’est pas de l’I2C, et qui n’est pas supporté par le Tiva, ce qui demanderait un pilotage manuel par bit banging
  • un mode SPI avec signal CS : dans ce cas l’assertion de la ligne CS démarre la transaction SPI, et la désassertion la termine. Sauf que, lors de cette déassertion, il n’y a pas de nouveau signal d’horloge généré,ce qui est normal pour du SPI. Eh bien dans certains cas, ceci empêche le circuit de prendre en compte la commande envoyée. Pour corriger cela, il faut générer une unique pulse d’horloge supplémentaire pour valider la commande. Pas 8, sinon le chip croit qu’une autre commande lui est addressée. Ceci demande de reconfigurer terporairement le bus SPI en GPIO normales, puis d’envoyer la pulse, puis de reconfigurer le bus SPI.

Vous voyez le genre de techniques tordues qu’il faut appliquer… Et qui ne sont pas documentées clairement, malgré leur bizarrerie. Et on n’en est encore qu’à la couche transport, je n’imagine même pas encore tous les bugs fonctionnels que je vais trouver! Je trouve ça assez peu sérieux de la part d’un grand fabricant de circuits intégrés, surtout quand on essaye de concurrencer NXP et Broadcom sur le marché du front end NFC.

Exemple de documentation: dans une version précédente, les données SPI envoyées au chip étaient valides sur le front descendant de SCLK, et les données retournées juste après étaient disponibles sur le front montant de l’horloge… Pas très pratique. Mais bon. Dans la dernière révision du chip, ceci a été corrigé. Toutes les données (MOSI et MISO) sont valides au front descendant de SCLK. Mais la datasheet n’a pas été mise à jour, jusqu’à ce que quelqu’un se plaigne sur le forum!

J’avoue que tous ces problèmes m’ont été signalés par un ami qui avait déja travaillé avec ce circuit, sinon j’en serais encore à savoir pourquoi ça ne marche pas. D’un autre coté, pour DIY qui se voulait électroniquement simple, ces bugs m’agacent, car ils vont complexifier le projet. Je n’attendais pas de me heurter à des problèmes techniques aussi basiques à un stade aussi peu avancé.

Donc pour le moment, je mets ce projet de côté et je repars sur mon autre projet: la fraiseuse.

En attendant, j’ai mis à disposition de tous le code de démarrage que j’utilise pour faire fonctionner le cpu ARM Tiva. J’ai fait un projet github avec tous les codes communs qui évitent de ‘réinventer la roue’. J’ai choisi la licence WTFPL pour son coté humoristique et très proche du domaine public. En effet, je trouve indécent de vouloir mettre des licences restrictives (dites libres ou non) sur un code aussi basique et aussi nécessaire. Ca se passe sur github:

http://www.github.com/f4grx/freestella

 

[algo] Comment calculer une moyenne glissante sur un microcontrôleur à faibles ressources

Pour commencer, je dois dire que l’idée pour cet article m’a été suggérée par Audran (@alf_arobase) lors de discussions à l’Electrolab sur son super projet que je ne dévoilerai pas sans son autorisation! Mais c’est un truc très bien! Bref, cet article est surtout une synthèse des trucs dont on a discuté hier soir, et que j’ai relativement mal expliqué. Avec du recul, ça va mieux.

Le problème

Supposons que l’on ait à mesurer en temps réel un signal analogique à l’aide d’un petit microcontrôleur, pour, par exemple, déterminer quand ce signal passe sous un seuil, et déclencher un signal. Ceci peut être fait de manière triviale, en effectuant une mesure avec l’ADC, en la comparant avec le seuil, puis en décidant l’état du signal de sortie.

Ceci, en réalité, n’est qu’une théorie. Dans la réalité, plusieurs effets vont rendre cette technique impraticable:

  • Le signal à mesurer peut être très bruité;
  • L’ADC peut manquer de précision et sortir des valeurs de mesure différentes alors que le signal reste constant.

En conséquence, quand le signal sera proche de la limite, il va varier rapidement entre les états “signal détecté” et “signal non détecté”. Comme les mesures se feront en général à un rythme rapide, les variations du signal de sortie seront également très rapides, et probablement assez aléatoires.

Que peut on faire? Idéalement, on voudrait se passer de toutes ces petites variations rapides, pour retenir la valeur moyenne du signal à un moment donné. On peut aussi appliquer un filtre passe-bas au signal de l’ADC, car il est équivalent de dire que seules les basses fréquences (les variations lentes) du signal de l’ADC nous intéressent.

Première option: y’a moyen de moyenner (le signal)

La première chose qu’on peut faire, c’est diminuer l’influence des imperfections de l’ADC, c’est le plus facile.
Au lieu de mettre à jour le signal de sortie à chaque fois qu’un échantillon ADC est lu, on peut lire 4 échantillons, ou N, en faire la moyenne, et utiliser cette moyenne pour prendre la décision sur le signal de sortie. Dans ce cas, chaque fois qu’on moyenne 2^n valeurs d’ADC, on gagne n bits de résolution.

Cette méthode s’appelle la décimation. Ça s’invente pas.

Exemple, si je moyenne 4 valeurs, la moyenne pourra prendre, après la virgule, les valeurs x.00, x.25, x.50, ou x.75. Quatre valeurs après la virgule peuvent être codées avec deux bits, c’est deux bits de gagnés sur la résolution, au prix d’une vitesse d’acquisition plus faible. Autre manière de voir: additionner 4 nombres de M bits nécessite M+2 bits pour coder le résultat.

En embarqué, surtout avec des microcontrôleurs 8 bits, on n’aime pas les virgules, c’est donc un bon exemple d’application des calculs en virgule fixe. Faire la moyenne de N valeurs revient à les additionner, et c’est tout. Le résultat aura un dénominateur de N. Si on veut une moyenne du même ordre de grandeur que les résultats de mesure initiaux, on peut alors utiliser une division entière. Si on est malin, on fait une moyenne sur 2^N valeurs, et la chère division se transforme en simple décalage à droite.

Deuxième option : calculer une moyenne mobile

La moyenne c’est bien, mais cela pose un problème. Pour avoir des valeurs bien filtrées, il faut faire une moyenne sur beaucoup de valeurs, par exemple 64 ou 128, ce qui va diviser le “débit virtuel” de l’ADC moyenné par autant, et peut devenir vraiment un gros problème. De plus, chaque échantillon décimé va représenter un groupe d’acquisitions, une “case”, mais sans lien continu entre elles.

La moyenne mobile va nous aider.

La moyenne mobile, on la rencontre très fréquemment sur les graphes boursiers. En effet, les cours de bourse varient très chaotiquement, et un moyennage permet d’y voir plus clairement des tendances. Mais attention: dans ce domaine, faire une moyenne selon la première méthode reviendrait à utiliser un cours journalier pour calculer un cours moyen par semaine. On comprend bien que pour calculer des tendances au jour le jour, on ne peut pas se contenter d’une valeur toute les semaines, même si on tente de l’interpoler.

L’astuce consiste alors à calculer chaque jour une moyenne sur les N jours précédents. Chaque jour, la nouvelle moyenne prend en compte une partie des valeurs qui ont déjà été utilisées la veille, et ajoute l’information du nouveau jour. Ainsi, chaque jour, chaque valeur prend en compte les valeurs précédentes, mais cela atténue les variations rapides, puisque les données de chaque jour interviennent plusieurs fois dans le calcul. Voici à quoi cela ressemble sur le cours de, disons, RedHat pour rester dans l’open source. Ici j’ai demandé à tracer la moyenne mobile sur 50 jours (un classique). J’ai aussi tracé le graphe des valeurs par semaine (donc décimées), je vous l’affiche d’abord:

Cours de RedHat sur 1 an, décimation par semaine
Cours de RedHat sur 1 an, décimation par semaine
Cours de RedHat sur 1 an, décimation par jour, et moyenne mobile sur 50 jours
Cours de RedHat sur 1 an, décimation par jour, et moyenne mobile sur 50 jours

Bon, en bref: la décimation est effectivement moins bruitée que le graphe quotidien (moins de variations rapides). Mais elle contient moins de points (évidemment, 52 semaines par an au lieu de 365 jours). Et si votre seuil de basculement était à 50 dollars, eh bien les basculements seraient toujours aussi nombreux que sans filtrage. La décimation n’aurait eu aucun effet sur ce point.

Par contre la moyenne mobile, en rouge, varie plus “sagement”, tout en reproduisant les “tendances” du signal bruité, et surtout, elle existe pour chaque point de la courbe! Elle ne croise que 2 fois le seuil à $50.

A quoi cela va-t-il ressembler dans le cas de notre ADC? Eh bien c’est strictement la même chose. Chaque fois qu’on fait l’acquisition d’un échantillon, on en calcule la moyenne mobile, et on utilise cette valeur pour prendre la décision sur le signal de sortie.

Moyenne mobile: méthode naïve.

De manière simplifiée, on va avoir besoin d’un tableau pour stocker l’historique des N dernières valeurs. On aura besoin d’un index pour se souvenir de notre position, et d’une routine qui calcule la moyenne.

#define Nbits 4
#define N (1<<Nbits) //Du coup, N est une puissance de 2, ici 16
uchar hist[N];
uchar hist_index;

void init(void) {
    for(hist_index=0;hist_index<N;hist_index++) {
        hist[hist_index]=0;
    }
    hist_index=0;
}

void adc_interrupt(void) {
    uchar sample,i,filtered;
    ushort mm;

    //pseudo fonction pour lire l'ADC
    sample = adc_read();

    //stockage
    hist[hist_index] = sample;
    hist_index++;
    if(hist_index==N) { //gestion buffer circulaire
        hist_index = 0;
    }

    //Calcul brut de la MM
    mm=0;
    for(i=0;i<N;i++) {
        mm += hist[i];
    }

    //maintenant on peut jouer avec la moyenne mobile mm
    //si on veut qu'elle soit du même ordre de grandeur que les samples:
    filtered = mm >> Nbits
}

Cette méthode marche. Mais si N devient grand, le nombre d’additions à réaliser pour le calcul de mm devient énorme, et la routine d’interruption prendra énormément de temps. Il ne faut pas utiliser ce code, il est nul.

Moyenne mobile: Méthode pratique

On va repartir sur quelques bouts de maths : pas bien difficile, des suites. Imaginez des tableaux et des indices, c’est la même chose.

Définissons le signal en sortie de l’ADC comme une suite numérique.

s(n) == valeur lue de l’ADC à l’étape N

Appelons K le nombre de valeurs qu’on veut utiliser dans notre moyenne.

La moyenne mobile est alors définie comme

mm(n) = somme des s(n) pour les K dernières valeurs / K

Oublions tout de suite la division par K (elle est triviale et optionnelle, surtout si K est une puissance de 2)

Donc, on fait la somme des K dernières valeurs :

mm(n) = s(n) + s(n-1) + s(n-2) … + s(n-K+1)

Si cette expression vous perturbe, vous n’avez qu’à imaginer que s(n) est aussi définie pour des valeurs négatives de n, ou alors, qu’elle vaut zéro en ces points. En tout cas, ne vous prenez pas le chou avec ça. Dans le programme ça disparaitra.

C’est en gros le calcul qu’on a fait dans l’algo naïf.

 

Prenons un peu de recul et écrivons le calcul que nous allons faire à l’étape suivante pour calculer mm(n+1) :

mm(n+1) = s(n+1) + s(n-1+1) + s(n-2+1) … + s(n-K+1+1)

soit:

mm(n+1) = s(n+1) + s(n) + … + s(n-K+2)

Allez, ajoutons, pour le fun des maths, s(n-K+1) de chaque coté. Ca ne change rien n’est ce pas? Si A=B, alors A+truc = B+même_truc.

mm(n+1) + s(n-K+1) = s(n+1) + s(n) + … + s(n-K+2)+ s(n-K+1)

Quelle surprise… Mais c’est presque cette vieille mm(n) ! Mais si:

mm(n+1) + s(n-K+1) = s(n+1) + s(n) + … + s(n-K+2)+ s(n-K+1)

Au boulot:

mm(n+1) + s(n-K+1) = s(n+1) + mm(n)

Maintenant, on enlève s(n-K+1) de chaque coté :

mm(n+1) = s(n+1) + mm(n) – s(n-K+1)

C’est gagné. Observons ce qu’on a obtenu:

 

La nouvelle moyenne mobile, c’est  l’ancienne moyenne mobile, plus la valeur la plus récente, moins la plus ancienne.

 

Et ça, c’est vachement cool, parce que ça veut dire que dans mon programme, je n’ai plus que DEUX additions à faire à chaque IRQ, au lieu de calculer toute la somme à chaque fois!

Concrètement on a besoin de quoi? La valeur plus récente, on vient de la lire depuis l’ADC. Il faut se souvenir des anciennes valeurs. Combien d’anciennes valeurs? Exactement K. Après K étapes, ma plus ancienne valeur sera la valeur récente actuelle.

  1. A l’init, ma moyenne vaut zéro, et mes anciennes valeurs valent zéro (ça règle le problème des indices négatifs).
  2. A chaque irq, je lis un sample de l’ADC.
  3. Je mets à jour ma moyenne mobile
  4. Je stocke ce sample dans le tableau des anciennes valeurs
  5. Profit!

Allez, je termine le suspense avec le petit programme d’exemple qui implémente ça:

#define Nbits 4
#define N (1<<Nbits) //Du coup, N est une puissance de 2, ici 16
uchar hist[N];
uchar plus_ancien; //(@skywodd: pas volatile, touchée que dans l'irq après l'init)
volatile ushort mm; //stockage pour la moyenne, doit être une var globale

void init(void) {
    //effacer les valeurs anciennes
    for(plus_ancien=0;plus_ancien<N;plus_ancien++) {
        hist[plus_ancien] = 0;
    }
    //on commencera à stocker à cet offset
    plus_ancien = 0;
    mm = 0;
}

void irq_adc(void) {
    //acquisition
    sample = acd_read();

    //calcul MM
    mm = mm + sample - hist[plus_ancien];

    //cette plus ancienne valeur n'est plus utile, on y stocke la plus récente
    hist[plus_ancien] = sample;
    plus_ancien ++;
    if(plus_ancien==N) { //gestion du buffer circulaire
        plus_ancien=0;
    }
    //La MM est déjà prête à utiliser
}

Au début, avant d’avoir effectivement lu N (ou K) valeurs, la mm va augmenter lentement, il y a donc un petit régime transitoire avant que les choses se stabilisent. C’est inévitable, c’est une caractéristique des filtres.

Certains vont me dire, mais ça marche comme un filtre ! Eh bah oui, on a un genre de filtre passe bas à réponse impulsionnelle infinie (un mot compliqué pour dire que si tous vos samples ADC sont nuls sauf le premier, (et que la précision est infinie), alors tous les samples qui suivent auront une valeur non nulle…).

Les pros du traitement de signal me contrediront sans doute, mais c’est  pas grave. “Avec les mains”, ça marche, le signal est lissé.

Et voila, maintenant vous saurez dire que vous savez utiliser un ATTiny (ou autre :)) comme un DSP !

La combinaison

Bien sûr , si votre source de données a un débit élevé, rien ne vous empêche de calculer une moyenne mobile de valeurs préalablement décimées… Je sais pas trop si il y a quelque chose à y gagner…

 

A+ pour de nouveaux algos!

Interlude: un générateur de bruit / de nombres aléatoires

Entre mes deux projets, qui avancent à leur rythme (je ferai des mises à jour individuelles un peu plus tard, c’est plus complexe) je me détends parfois en faisant de petits montages simples.

Après des discussions sur la liste de diffusion de l’Electrolab, m’est venue l’idée de m’intéresser aux générateurs de nombres aléatoires. En effet, les nombres aléatoires ont un rôle très important pour la sécurité. On en utilise très souvent: dans SSL, dans les signatures numériques, dans PGP…

Il en existe en effet de deux types:

  • les générateurs déterministes ou pseudo aléatoires
  • les générateurs non déterministes ou réellement aléatoires

Générateurs pseudo-aléatoires (PRNG)

Dans un PRNG, on obtient des nombres aléatoires en appliquant (la plupart du temps) une fonction crypto (hash, chiffrement, registre à décalage type CRC, etc) ou une relation de récursivité (nouvelle_valeur = [constante*ancienne_valeur + constante] mod nombre_premier). En fait, ces générateurs produisent une séquence de bits très mélangés, qui dépend d’une graine initiale (seed) qu’il faut initialiser avec une valeur différente à chaque utilisation (par exemple , l’heure système de l’ordinateur en millisecondes: chaque exécution du programme utilisera une graine différente, ce qui produira une séquence aléatoire différente).

Chaque seed génère une séquence différente, mais si on réutilise la même seed, on se retrouve avec la même séquence pseudo aléatoire, c’est pour ça qu’on dit le générateur déterministe.

Les nombres produits ont quand même des caractéristiques des nombres réellement aléatoires, par exemple le nombre de bits à zéro doit être égal au nombre de bits à 1, l’autocorrélation du signal (similarité avec lui même) doit rester très faible, et d’autres propriétés statistiques doivent être vérifiées. Mais tout ceci dépend d’une graine

Générateurs réellement aléatoires (TRNG)

Dans un TRNG, on utilise un phénomène physique pour générer les valeurs aléatoires. Cela peut être:

  • la tension aux bornes d’une résistance de forte valeur: il s’agit de bruit thermique
  • le bruit d’un convertisseur analogique-numérique dans un microcontrôleur (méthode utilisée par le FST-01 et NeuG)
  • le bruit d’avalanche et d’effet tunnel généré par une jonction PN (diode, transistor) en régime d’avalanche
  • le bruit atmosphérique, obtenu par exemple en réglant une radio entre deux stations (c’est la méthode utilisée par random.org, que je n’aime pas car elle est attaquable en émettant des trucs sur la fréquence mesurée, qui doit donc rester secrète)
  • etc.

Ces générateurs sont en général analogiques. Une porte à trigger de Schmidt suffit à numériser le signal, on obtient alors un signal logique qui bascule à des intervalles aléatoires. On peut alors mesurer le signal avec le port GPIO d’un micro-contrôleur et s’en servir logiciellement. Par contre, il est impossible de prédire la sortie du générateur, qui est donc non-déterministe.

Il faut ensuite:

  • Annuler les biais (moyennes, etc) avec un algorithme de nettoyage qui peut être très simple: on acquiert 2 bits, et émet le premier bit d’entre eux s’ils sont différents, sinon jette les 2 bits. On en déduit que le débit d’un tel générateur n’est pas constant.
  • S’assurer des propriétés statistiques du générateur (moyenne=0.5, tous les bits basculent, pas de génération de séquence de bits consécutifs identiques, corrélation, etc)
  • Emettre les données sous un format utilisable

On se rend compte de plusieurs choses:

  • Il faut être sûr d’avoir du “bon” bruit pour générer des nombres suffisamment aléatoires
  • Le débit de bits aléatoires n’est pas extensible “a volonté”!

Un premier montage

Pour mettre ces théories en pratique, j’ai commencé par la base : un générateur de bruit. On en trouve tout plein de schémas, les plus simples se basant sur la jonction B-E d’un transistor NPN, comme celui ci:

Générateur de bruit
Générateur de bruit. Source: David Eather, Silicon Chip Online, 2005 ( http://archive.siliconchip.com.au/cms/A_103659/article.html )

 

 

Oui, oui, le collecteur reste en l’air! Ce n’est pas une erreur! C’est la jonction B-E qui nous intéresse. On pourrait utiliser une diode à la place, mais en général les diodes supportent beaucoup mieux une tension inverse, donc il faudrait une alim de plusieurs dizaines de volts.

En voici la réalisation:

Générateur de bruit numéro 1
Générateur de bruit numéro 1

C’est vraiment un des montages les plus simples.

Pour que le transistor génère du bruit, il faut l’alimenter avec une tension assez élevée (ici 12 volts, le VBE max du 2N2222A utilisé est donné pour 6 volts, il faut donc aller au delà pour entrer en régime d’avalanche). Le bruit généré est d’environ 1Vpp. Après avoir ajouté un condensateur de liaison à la sortie du montage, j’ai pu attaquer directement la carte son de mon PC. A l’oreille, on reconnait bien le “psssssshhh” caractéristique du “bruit blanc”. Voici le spectre mesuré par Audacity:

Bruit généré - Spectre linéaire
Bruit généré – Spectre linéaire

On observe bien que toutes les fréquences sont présentes. Dans les aigus, on voit l’influence des filtres de la carte son (ou du montage? il va falloir le déterminer!) Dans les graves, on voit l’effet des capas de liaison qui empêchent les basses fréquences de passer. Dans l’ensemble, le bruit a l’air bien “blanc”. Maintenant, on voit quand même des petits “pics” à gauche. Une échelle de fréquence “log” permet de zoomer dans les graves:

Bruit généré - Zoom dans les graves
Bruit généré – Zoom dans les graves

Et c’est la cata! Tous ces pics ne sont pas “petits” mais correspondent à quelque chose de précis: le secteur, le 50 Hz! Eh oui on observe bien 50,100,150,200,250,300 Hz qui sont des harmoniques (pairs et impairs) du secteur!

Comment peut-on expliquer ceci? Eh bien, je pense, par l’alimentation! J’ai pourtant utilisé une alim de labo linéaire (et non à découpage) qui n’est pourtant pas si mauvaise. Et la “ronflette” passe quand même! Une autre cause possible est la récup de signaux par la patte non connectée du transistor. Autant dire que c’est très mauvais pour un générateur aléatoire, car bien évidemment, les valeurs du signal ont une corrélation importante, dû aux signaux périodiques sinusoïdaux qui se superposent au bruit ! 50 fois par seconde, une partie des signaux est égale à ce qui se passait 1/50ème de seconde avant! On le voit parfaitement avec l’ “autocorrélation avancée” disponible dans Audacity:

Autocorrélation du signal généré
Autocorrélation du signal généré

Ici, c’est explicite: le signal décalé de 0,2 secondes est partiellement superposable au signal original. Et il est encore superposable au signal décalé de 0,4 secondes. Ce signal n’est pas du tout aléatoire!

Voici comment va se dérouler la suite de l’étude:

  • Blindage du transistor générateur
  • Mesure du signal avec une alimentation sur batterie
  • Optimisation des condensateurs de liaison pour être sûr de la bande passante
  • Mise en place d’un filtrage énergique pour éviter au maximum les bruits! En gros, il faut un filtre passe très-très bas sur l’alim! Donc des capas de découplage, et en amont, une résistance en série dans l’alim. Il y aura aussi des inductances, utilisées pour leur fonction de base “je m’oppose aux variations du courant”.

En conclusion, voici un montage simple, amusant, et qui ne demande qu’à être optimisé. J’ai plein d’idées pour la génération aléatoire proprement dite… Mais on verra plus tard!

Mise à jour du 19 Septembre 2013:

Après mon passage sur Dangerous Prototypes, Jon a commenté sur la version anglaise de l’article pour me faire remarquer que le bruit provenait probablement de ma carte son. J’ai donc fait un enregistrement audacity du signal de mon générateur, mais SANS l’alimenter. Le résultat est sans appel:

Signal résiduel de la carte son
Signal résiduel de la carte son

C’est donc la carte son de mon laptop qui me pourrit le signal, il va donc falloir passer à autre chose sans trop m’inquiéter ! Merci, Jon!

Colis reçus !

Et voila, c’est fait. J’ai reçu ce matin le colis contenant mon eShapeOko, et la seule chose qui m’empêche maintenant de la monter, c’est le taraudage des makerslides, qui sera fait demain soir par mon ami radio-amateur Yves, F1BHY, que je remercie chaudement pour sa disponibilité et sa gentillesse. C’est un bricoleur extra, il manie parfaitement les machines outils et les outils classiques, et nous fait profiter de ses capacités!

Pièces eShapeOko
Pièces eShapeOko

J’ai aussi reçu les nouveaux échantillons de TRF7970 pour mon projet NFC, ce sont des composants en boitier QFN, dont la soudure s’est plutôt mal passée la dernière fois, qui était aussi la première. J’ai mis trop de pâte à souder, ce qui s’est traduit par un composant qui flottait dans l’étain liquide, et en voyant es billes d’étain qui se sont formées de chaque coté après refroidissement, je soupçonne fortement que les contacts soient en court circuit en dessous des boitiers. Seule une inspection par rayons X pourrait m’en informer, mais je n’ai pas ce moyen de mesure en stock :p En plus, si il n’y a pas de court circuit, je crains d’avoir fait un peu trop “bronzer” ces circuits à la station à air chaud.

D’autre part, j’ai fait une erreur de conception sur ces cartes, heureusement rattrapable: j’ai connecté les lignes VCORE au +3V3, ce qui est une erreur : VCore est une sortie, connectée au régulateur interne, et elle ne sert qu’à la connexion de capas de découplage! Du coup, la ligne 1,2 volts s’est retrouvée alimentée en 3V3! Une hérésie! La bonne nouvelle numéro 1, c’est que j’ai réussi à soulever les pattes du TQFP et à y souder des capas CMS “en volant”. La deuxième bonne nouvelle, c’est que le circuit marche encore, ce que je trouve assez extraordinaire sachant que j’ai injecté une “haute tension” sur la sortie d’un LDO interne… Enfin, je vais quand même utiliser un nouveau circuit “propre” sur la carte de test 😀

Les composants sont faits pour être soudés sur une carte SeeedStudio, qui est déja étamée. Je pense qu’avec le flux que j’ai récupéré entre temps, cet étain déja déposé est largement suffisant pour souder les composants. Je vais donc essayer de souder ces QFN avec une bonne quantité de flux, mais sans étain supplémentaire, et on va voir.

A coté des QFN, la soudure des ARM en TQFP est une partie de plaisir 😀

Je vous tiendrai au courant bien plus souvent, maintenant que la machine est arrivée! Pour info, j’ai également démarré un sujet “build log” (en anglais) sur le forum officiel de la ShapeOko, qui contient un max d’informations sur ces machines, avec les modifications que les gens ont réalisées, et les erreurs à ne pas commettre. Une des améliorations décrites là bas que je trouve le plus intéressante est la modification de l’axe Z pour utiliser une “ACME screw”, autrement dit une vis à pas trapézoïdal. Le but est d’accélérer les mouvements sur l’axe Z (le pas de la vis est plus important), ce qui accélère globalement toute la machine. Nous aurons donc bientôt une amélioration à ce niveau dès que j’aurai trouvé un bon fournisseur pour ce matériel, et surtout quand la machine actuelle fonctionnera 😀 En réalité, je peux déja jouer sur le mode de déplacement micro-pas de l’axe Z pour accélérer la cadence. A voir!