Archives de catégorie : Technologies

Ces articles ne sont pas rattachés à un projet en particulier, ils décrivent plutot des concepts ou des technologies de manière générale.

Manifeste pour un réseau ouvert des objets connectés

Les objets connectés sont partout. Certains sont plus utiles que d’autres, mais la réalité est la. Le besoin de faire communiquer nos objets de manière globale est là. La connexion doit être permanente, la couverture globale.

Récemment, plusieurs acteurs sont apparus sur ce marché, avec l’ambition de mettre en place un réseau global permettant à des objets connectés de communiquer. L’idée de réseau global pour IoT est très innovante, nous ne pouvons le nier, par contre toutes les tentatives actuelles ont des défauts graves.

Chacun de ces réseaux a en effet développé des technologies propriétaires pour cet usage. Ainsi, pas de risque que les clients aillent voir ailleurs.

Le problème, c’est que ces technologies

  • Requièrent d’acheter exclusivement les modules compatibles
  • Requièrent des modules fournis comme des boites noires
  • N’ont subi aucune évaluation de sécurité
  • N’ont aucune spec publique permettant de comprendre leur fonctionnement

Une fois de plus, nous pensons que cette logique d’enfermement est nuisible au large développement de l’Internet des Objets. En effet, chaque acteur n’a qu’un désir: imposer sa technologie, au détriment des autres, en espérant “conquérir le monde” et tout réussir tout seul.

A l’inverse, nous souhaitons développer un protocole de communication pour l’IoT qui soit totalement ouvert, avec des spécifications accessibles gratuitement à tous, sans NDA, sans donner son adresse email, sans requérir de module boite noire, sans être bloqué avec un fournisseur de module ou de service.

Nous pensons que:

  • Les technologies permettant l’implémentation d’un réseau global pour l’IoT existent déja, n’ont rien de révolutionnaire, et sont accessibles ouvertement.
  • Seul un écosystème ouvert, dans lequel chacun peut contribuer, permettra l’explosion du nombre d’objets connectés.
  • Cet écosystème doit inclure tout le monde: Entreprises, Makers, particuliers
  • Il ne faut pas avoir peur de l’ouverture. Le gateau à partager est suffisamment grand, et sera encore plus grand si tous les objets connectés parlent une même langue documentée et accessible.

Nous souhaitons:

  • Inventer un protocole complètement libre pour connecter tous les objets, dans lequel tout le monde a confiance, parce qu’il n’a rien à cacher.
  • Faire mieux que l’existant. Que celui ci soit une inspiration, mais pas un modèle technique.
  • Garantir la confidentialité et l’authenticité des données transmises.
  • Montrer que le monde du libre vaut mieux que celui de quelques industriels qui bossent dans leur coin.

Voici donc la roadmap que nous proposons:

  • Communiquer sur cette initiative, tout le temps.
  • Définir les fonctionnalités que doit permettre ce protocole
  • Evaluer les composants radio Sub-GHz existants pour déterminer un socle commun de fonctionnalités
  • Ecrire une spécification complète du protocole que tout le monde puisse implémenter avec les solutions techniques qu’il souhaite
  • Mettre en place un réseau aussi large que possible permettant la communication des objets ainsi connectés.

Nous avons besoin de bonnes volontés pour développer ce projet. Les experts de chaque domaine se reconnaitront et sauront participer à ce projet, j’en suis convaincu. J’en connais déja quelques uns qui ont des idées très claires et qui sont prêts à les partager.

Des discussions ont déja eu lieu à l’Electrolab, le plus grand hackerspace de France et presque d’Europe, qui regroupe des spécialistes reconnus du monde de la radio et des communications. Cette association, dont je suis récemment devenu membre administrateur, possède des moyens de prototypage faramineux pour des projets libres et ouverts intéressants. Je n’ai aucun doute que ses membres sauront également reconnaitre l’intéret de ce projet.

C’est vraiment ambitieux. Cela ne fonctionnera que si nous sommes plusieurs à nous y attaquer.

Mais les possibles répercussions sont très larges et très positives. Ceci peut être aussi significatif que l’arduino l’a été pour l’électronique.

Pour manifester votre intéret, ajoutez un commentaire ci-dessous. Si vous souhaitez joindre votre voix au manifeste, dites le, et je vous ajoute a la liste des “signataires” ci-dessous.

Signataires

Sébastien Lorquet, radioamateur F4GRX
Charles Rincheval, @hugokernel

Interlude: ça oscille

Hello

Petite interruption dans le flux de mes projets: des copains radioamateurs et amateurs de micro-ondes sont en train de faire un projet de transverter (translateur de fréquence) pour trafiquer sur la bande des 13 cm (2300-2450 MHz) à partir d’un poste UHF (~432 MHz). Ceci nécessite la réalisation d’un oscillateur à environ 2 GHz. Non, vous pouvez ranger le NE555.

J’avais dit que je me concentrais, mais c’est différent: c’est pas une distraction sans avenir, c’est un vrai projet pour aider un grand nombre de personnes!

Pour y arriver, on prend un VCO commercial (oscillateur à fréquence variable… un peu n’importe comment), et on n’y ajoute (non, pas un potentiomètre), une PLL, qui permet d’asservir la fréquence du VCO à une autre fréquence de référence plus gérable, ici 10 Mhz (parce que c’est une valeur de référence classique).

Pour vous y retrouver, c’est comme un thermostat, mais on règle pas une température, on règle une fréquence d’oscillation.

Je suis donc en train de reprendre un projet existant pour l’améliorer et le tailler à nos besoins.

Le résultat va être un kit, si tout se passe bien il y aura environ 100 commandes. Mais c’est en fait une commande groupée, le but n’est pas commercial. Cette fois, c’est moi qui gère l’orga, avec l’aide de quelques potes. Un sacré boulot en perspective, surtout pour le dispatch!

Je reste volontairement flou sur la page du projet, elle est faite avant tout pour les gens concernés qui sauront y trouver les infos qui les intéressent. Si vous savez vraiment de quoi il s’agit, et que vous voulez participer à la commande, N’hésitez pas à me contacter par ce site pour en discuter.

C’est ici: http://www.f4grx.net/ol13

73,

Sébastien F4GRX.

Les objets du week end

Cette semaine a vu pas mal d’avancement sur plusieurs projets. Je n’ai pas exactement respecté le planning que je m’étais fixé dans le dernier article, mais ce n’est pas grave. J’avance sur mes projets au rythme de mon inspiration et de mes possibilités. Ce qui est plus important est de rester actif et d’avoir en vue l’ensemble des projets, pour être réactif et saisir les occasions d’avancer sur chacun.

Impression 3D

Cette semaine avait lieu le Web2Connect, un salon du blogging et des activités en ligne. Il y avait beaucoup de conférences, je n’en ai suivi que quelques unes (Bitcoin, Sécurité web, etc) et j’ai passé beaucoup de temps avec les gars de Dood Studio, qui exposaient leur imprimante 3D (un mix open source de Reprap, Ultimaker et Makerbot) dans le ‘village de l’innovation’ du W2C.

Dood Studios au W2C13
Dood Studios au W2C13

Nous avons donc sympathisé, et comme ils cherchaient des modèles à imprimer, je leur ai passé le STL de la turbine que j’avais déja tenté d’imprimer auparavant. Résultat moche, comme avant. Nous avons alors tenté de remodéliser une turbine sur solidworks, et miracle, l’impression est de bien meilleure qualité:

Différents STL
Différents STL. A gauche OpenSCAD, à droite Solidworks. PLA, buse 0,5mm.

Mystère… les objets sont quand même bien similaires à l’écran! Nous avons alors décidé de comparer les STL avec meshlab, et la vérité nous a alors sauté aux yeux:

 

Facettes OpenSCAD
Facettes OpenSCAD
Facettes SolidWorks
Facettes SolidWorks

Le STL pondu par OpenSCAD contient des triangles très fins et très allongés, qui partent tous d’un même point, ce qui perturbe slic3r. Le STL produit par Solidworks est formé de triangles bien plus triangulaires, qui “fonctionnent” clairement mieux !

Je n’ai pas trop d’espoir avec OpenSCAD… Il faudrait pouvoir appliquer une re-triangulation “optimale” de Delaunay à ces “mauvais” STL, mais la mise en pratique me dépasse totalement, tant pis! C’est dommage, car l’idée de modéliser grâce à un script me plaisait bien.

eShapeoko

La découpe, gravure et perçage de plaques de MDF, de 3 à 6mm, est maintenant une opération routinière ici: Je maîtrise (à peu près!) ce procédé 🙂 Les plaques sont fixées efficacement au martyr avec du scotch double face, je fais des coupes de 1 à 1.5mm de profondeur à une vitesse de 100 à 150 mm/minute, selon la propreté de la découpe que je souhaite.

Ma perceuse de 60 watts est toujours un peu faible, je compte sur le Père Noël pour me fournir une défonceuse Bosch de plus grande puissance (600 Watts, ce qui me donnera accès à la découpe d’aluminium).

La fraise est une deux dents, d’origine proxxon, en carbure. Diamètre 2mm.

Coté logiciel, j’utilise Inkscape pour importer des DXF ou créer des dessins vectoriels moi même, puis makercam pour calculer les trajets d’outils, et enfin Grbl Controller pour envoyer les ordres à la machine. Ces logiciels sont gratuits.

Carte de puissance

Première chose, après l’avoir modélisé, j’ai découpé et intégré un boitier en MDF pour la carte de puissance qui commande la machine. Celle ci contient en réalité uniquement les modules Pololu et beaucoup de connectique! La machine est maintenant alimentée en 24V, ce qui me permet des déplacements plus rapides (jusqu’à 3000 mm/min sur X et Y au lieu de 2200, et jusqu’à 200mm/min au lieu de 150 sur Z). L’arduino de commande est toujours “en l’air” mais cela ne devrait pas durer 🙂

Modélisation et résultat
Modélisation et résultat
La carte électronique en place
La carte électronique en place

L’assemblage utilise des écrous logés dans des fraisages dans l’épaisseur du MDF.

Adaptateur d’aspirateur

J’ai trouvé un flexible qui me permet d’aspirer la poussière en temps réel. C’est plus propre et plus pratique! Par contre ce flexible est beaucoup plus fin (18mm) que le tube de l’aspi (35mm). Dans un esprit DIY, plutôt que d’utiliser du scotch (ce qui immobilise l’aspirateur) ou d’acheter un truc, j’ai découpé des trous de diamètres progressifs (18-25-30-35), que j’ai assemblé avec 4 grandes vis M3. Les vis qui dépassent servent à maintenir le tube de l’aspirateur sans avoir besoin de scotch! C’est vachement compliqué pour la fonction, mais ça fait le boulot et c’était sympa à fabriquer!

Cône d'adaptation en 6 couches
Cône d’adaptation en 6 couches

Banc d’équilibrage

Les micro-turbines que je prépare vont tourner à très grande vitesse. Et donc, auront besoin d’être très bien équilibrées. Un balourd entraînerait des vibrations, qui auraient des effets néfastes : bruit, usure des roulements (qui seront mis à rude épreuve par les températures). En me promenant sur le web à la recherche de systèmes d’équilibrages, j’ai trouvé un site chinois qui vend plein de ces appareils. Voici deux exemples qui ont été une “révélation” pour moi:

Système d'équilibrage
Système d’équilibrage
Détails du palier
Détails du palier

Ces photos décrivent tout ce que j’avais besoin de savoir. Il y a un entrainement par courroie souple, une mesure de la vitesse de rotation, un palier à roulements de chaque coté, et une mesure de vibration sur le palier, qui peut être faite avec un accéléromètre. L’objet à mesurer peut être déposé très facilement entre les roulements quel que soit son diamètre, et maintenu avec un troisième galet; ce qui m’enlève de la tête le problème du palier à simple roulement que j’imaginais. Bref, j’étais à coté de la plaque, et voilà qu’on m’y remet!

Une telle machine (ou au moins un proto) n’est pas très difficile à imaginer et à concevoir avec ma machine. En quelques heures de modélisation et de réalisation, j’ai une petite machine pour le genre de turbines que je vais utiliser. Voici quelques étapes de la réalisation:

Détails du palier
Détails du palier

 

Autre vue
Autre vue
Fixation de la roulette supérieure
Fixation de la roulette supérieure
Assemblage final
Assemblage presque final (à droite, avec la roue imprimée)

Les roulements 3x4x8mm sont de récupération dans divers ventilateurs de CPU, et les rondelles de 1mm en laiton sont fabriquées maison par découpe dans un tube laiton de 4mm extérieur attaqué au coupe-tube, puis limées à la bonne épaisseur.

Nous voila donc en bon chemin sur la réalisation des turbines, plastique ou métalliques. Les étapes suivantes seront l’entrainement par courroie et la mesure d’accélération/vitesse, mais nous n’en sommes pas encore là!

Ce qui n’a pas avancé

Electronique et radio
J’y reviendrai dans un article pour demain, sinon celui ci va devenir trop long.

Buses reprap
le mini-tour n’était pas disponible. Normalement je pourrai avancer ce soir

arduino
Il est commandé (auprès d’un vendeur ebay français), et a été envoyé rapidement, mais je n’ai pas de nouvelles. Je vais relancer tout ça…

[Tech] Fail en H et gain d’expérience

A l’origine, cet article devait également parler de moteurs brushless, mais j’ai décidé d’en faire deux articles, car cela aurait été trop long. Cet article est déja long, car j’ai volontairement détaillé son contenu pour qu’il soit facile à comprendre.

Vous connaissez tous les ponts en H: ce sont ces réseaux de transistors de puissance qui servent à changer le sens de rotation des moteurs. Plus généralement, ce sont des éléments de commande de puissance permettant le changement du sens du courant dans chaque ligne de puissance. On peut s’en servir pour plein de choses: commander un moteur DC, pas à pas, ou brushless, piloter un élément Peltier, etc. ou tout élément de puissance nécessitant un changement rapide du sens du courant qui le traverse.

Si on a pas besoin de commuter rapidement le sens du courant, un relais 2RT fait l’affaire 🙂

Nous verrons plus tard comment fonctionne un moteur brushless. Pour l’instant, disons seulement qu’il faut donc une carte de commutation pour changer le sens du courant dans les phases du moteur. Pas de secret, il y a plein de docs sur le sujet sur Internet. Cette carte de commutation génère les signaux logiques (0V-5V), mais évidemment, il faut des transistors de commande.

Il y a deux manières de réaliser un pont en H avec des MOSFETs:

Types de ponts
Types de ponts
  • Soit avec des FETs de type N coté “masse”, et des FETs de type P coté “alim”. C’est cette solution que j’ai choisie.
  • Soit avec uniquement des MOSFETs de type N, et un montage “compliqué” qui génère des tensions flottantes pour commander les FETs du coté “alim”. Des chips intégrés existent, mais pour un proto, ça n’est pas du tout amusant.

Pour rappel, le pilotage d’un FET se fait en appliquant une tension entre Grille et Source (VGS = Ug-Us), ce qui autorise le passage d’un courant entre drain et source (Id).

Pour le FET N, cette tension VGS doit être positive. Le FET N est conducteur quand sa grille est à une tension supérieure à sa tension de déclenchement (5-6V environ pour les MOSFETs de puissance), et il est isolant quand sa grille est à la masse. Entre les deux, le FET est dans une zone où il se comporte linéairement, mais la pente de la courbe Id en fonction de Vgs est très raide, il y a beaucoup de variations entre différents composants d’une même série, et les MOSFETs de puissance détestent travailler dans ce mode “résistif” où ils chauffent beaucoup. Mais ça marche, j’ai déja fait une source de courant variable de cette manière, en utilisant un ampli-op pour asservir la tension aux bornes d’un shunt (avec un gros radiateur, et un MOSFET N qui supportait 100A – en commutation, car en linéaire, c’est beaucoup moins).

Pour le FET P, cette tension VGS doit être négative. Et la source est reliée à l’alimentation. Le FET P est conducteur quand sa grille est à une tension inférieure d’environ 5-6V à la tension d’alim du moteur, et il est isolant quand sa grille est à la tension d’alimentation. Attention, je répète je n’ai pas dit que la tension de grille était à 5V, j’ai bien dit 5V en dessous de la source! Pour une tension d’alim de 12V, le FET P connecté à l’alim est donc totalement conducteur quand la tension sur sa grille est en dessous de 7V (=12-5).

On remarque vite que des niveaux logiques ne conviennent pas pour piloter des MOSFETs. Les courants débités par les microcontrôleurs sont déjà un problème, ils sont trop faibles, ce qui va ralentir le temps de commutation des FETs (et donc les faire chauffer). Les tensions surtout posent problème:

  • A zéro volts, on peut bloquer le FET N, et rendre le FET P passant.
  • Mais à 5 volts, le FET N est partiellement passant, et le FET P est toujours passant, car il reste encore 7V (12-5 dans notre cas) entre G et S.

Il faut donc translater ces niveaux de tension à des valeurs qui permettent de faire fonctionner les FETs.

Mon idée initiale a été d’utiliser des transistors bipolaires que j’avais déja, des BC547 et BC557, et des résistances de pull up/down pour réaliser ces translateurs de niveau. Voici en gros le schéma utilisé (les transistors supplémentaires coté N sont censés être des inverseurs pour que toutes les commandes soient positives:

Pont à pilotage Bipolaire
Pont approximativement pifométrique, qui aurait dû marcher. Dessin Kicad.

Grossière erreur, surtout du coté des FET N : les valeurs de composants utilisés ont été calculés de manière totalement “proto-pifométrique-fond-de-tiroir”, je fais passer du courant dans la base mais pas trop, ça saturera à tous les coups, ben… non, ça ne marche pas! Une mesure rapide des niveaux de tension obtenus m’a rapidement montré des tensions bien trop faibles pour commuter les FET N de manière fiable. Après quelques minutes de fonctionnement, un passage de doigt sur les FET m’a révélé une température bien au delà du raisonnable (je me suis pas brûlé, mais ma sueur s’est évaporée avec un petit pshitt), et maintenant, le moteur saute des pas, alors qu’au début de la manip, au moins, toutes les étapes de la commutation étaient observables. J’ai donc explosé au moins un FET N par l’épreuve du feu. Contrairement aux régulateurs de tension et autres, les FETs ne sont donc pas du tout protégés en température…

Mon erreur a été de négliger le pilotage correct des MOSFETs. Ce montage aurait dû marcher, je ne pense pas qu’il soit faux, c’est un problème de choix de composants.

Je dois dire que je suis passé à deux doigts de laisser tomber ce sous-projet (alors que je néglige ma shapeoko), qui était censé être un bricolage rapide du week end. Tout ceci se passait, bien entendu, le dimanche soir à 1h du matin, avec le boulot le lendemain, et pas mal de fatigue accumulée. Un peu désespéré, j’ai googlé “mosfet drive” un peu plus longtemps que d’habitude, et je suis tombé sur cette magnifique page qui expliquait exactement ce que j’avais besoin de savoir: le B-A-BA du pilotage des mosfets avec des composants discrets:

http://modularcircuits.tantosonline.com/blog/articles/h-bridge-secrets/h-bridge_drivers/

Cet article fait en fait partie d’une grande série:

http://modularcircuits.tantosonline.com/blog/articles/h-bridge-secrets/

Voyez vous, ce n’est pas que j’adore réinventer la roue, mais je veux comprendre ce que je fais, alors utiliser un circuit intégré pour piloter un FET dans un prototype, ce n’est pas mon truc. Je sais que ça existe, je sais que ça marche, donc je n’utiliserais ce genre de circuit que si, justement, la compréhension du pilotage des FET n’est pas le point central du projet.

Bref, malgré l’envie de dormir, je lis la page sus-citée, qui mentionne un montage particulièrement intéressant. Je vous la fais en résumé: Puisque le problème des FET est leur pilotage par des niveaux logiques, eh bien on essayons d’utiliser des FETs dont les tension de commutation sont compatibles avec des niveaux logiques. Ces FETs existent, mais ils ne sont pas capables de commuter de grosses charges.

Ce translateur de niveau est un simple MOSFET N dont le niveau logique est compatible avec des signaux logiques. On peut utiliser pour ça le BS170, qui est un FET N de faible puissance, mais dont la tension de déclenchement est de 3V, c’est directement compatible avec un signal logique. Ce MOSFET est câblé en drain ouvert (équivalent du collecteur ouvert) et peut donc “clamper” sa sortie à la masse, qui sera le niveau “0”. Le niveau “1”, lui, est indéfini, il est présent quand le FET est isolant, et sa tension est définie par un pull-up externe, que l’on connecte donc entre le drain et le +12V. On a donc construit un translateur de niveau inverseur.

Le problème est maintenant déplacé: on sait transformer des signaux 0V-5V en signaux 0V-12V, mais le signal haut (+12) n’est pas très franc: A cause de la capacité d’entrée du FET, la résistance du pull-up implique un temps de commutation plus élevé (T=RC), ce qui va certaiment faire chauffer le transistor. On peut régler ce problème en diminuant le pull-up (mais la conso augmentee inutilement) ou en intercalant un inverseur CMOS discret, constitué d’une paire de mos complémentaires (BS170 et BS250): Cet inverseur sera très rapidement déclenché par la tension issue du pull-up, mais il pourra fournir un courant élevé au FET final, car cette paire est directement connectée à l’alimentation, sans résistance. Voici à quoi cela ressemble:

Pilotage CMOS
Pilotage CMOS (R= 4K7) Chaque MOSFET de puissance a droit au même circuit.

J’insiste sur ce point du chargement correct et rapide de la capacité d’entrée des transistors MOSFET, car c’est un sujet très important pour la commutation de (grande) puissance. Pendant le chargement, le FET est demi-passant, et c’est principalement à ce moment qu’il chauffe. Ce n’est pas négligeable, car en PWM, il y a beaucoup de commutations! Regardez un datasheet, la capacité est donnée directement en nano-coulombs, ce qui donne le temps de commutation du FET: Q=IT -> T=Q/I, le temps de commutation est donc d’autant plus court que le courant de commutation est important.

Il peut y avoir un dernier problème, qui ne nous concerne pas vraiment, mais qui devient important si les tensions de pilotage sont plus élevées: la grille d’un FET ne supporte pas toujours la tension d’alimentation du moteur. Il y a en général une limite (destructive) vers 15V. On va alors piloter la grille du FET via un régulateur shunt Résistance Série/Zener à la masse, ce qui évite de le détruire.

Je n’ai pas abordé le sujet des ponts à base de FET N uniquement, il faut savoir qu’ils ont besoin d’une pompe de charge pour produire une tension VGS suffisante pour le FET coté alim. En général, cette pompe implique que le FET supérieur ne peut pas rester enclenché pendant un temps infini, car la pompe de charge a des fuites inévitables et demande un rechargement régulier. Il faut piloter ces ponts en PWM et s’assurer que les FETs supérieurs ne sont jamais pilotés par un PWM à 100%. Pour mon prototype, c’est assez gênant pour faire des essais à basse vitesse, c’est pour ça que je n’ai pas choisi cette conception même si les FET N sont moins chers et plus efficaces que les FET P. Je réserverai les FET N au montage final, si j’en ai besoin.

Voici donc la fin de mon tour d’horizon sur le pilotage des ponts en H, si on veut en savoir plus, je recommande chaudement la lecture des pages que j’ai trouvées, qui décrit avec une infinité de détails tout ce que l’on peut faire avec des ponts. Ces articles sont vraiment très, très complets, je n’ai pas encore eu le temps de tout lire! Je terminerai avec une image de l’état actuel du montage:

Prototype
Le prototype

C’est un pont à 3 branches, pour piloter un moteur brushless. La position des transistors est prévue pour une fixation sur un radiateur de CPU… Ne pas oublier les kits d’isolation, les semelles sont connectées aux drains! J’ai ajouté une résistance de 0R1 pour mesurer le courant consommé.

A+ pour l’application aux brushless!

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!

[Mini Tuto] Travailler en virgule fixe

Suite à discussions avec @skywodd du blog skyduino, qui parlait avec délectation des calculs en virgule fixe, j’ai décidé de faire un petit point sur le sujet pour montrer que c’est pas si difficile que ça.

Ce post va concerner le langage C.

A l’origine: la virgule flottante

En C, quand on veut traiter des nombres à virgule, on va utiliser des variables de type float ou double. Ces types de données gèrent les nombres à virgule avec une notation “signe-mantisse-exposant”, c’est à dire en format “scientifique. En maths on a plutot l’habitude des nombres en base 10, par exemple 1,27 x 10^3. En informatique, on utilise la base 2, c’est aussi le cas dans les float/double.

Quand le compilateur C rencontre des expressions flottantes, il y a 2 possibilités:

  • soit le CPU cible est équipé d’un FPU (floating point unit) matériel, et dans ce cas le compilateur peut générer des instructions assembleur qui font appel à ce fpu.
  • soit le CPU n’en est pas équipé, et les instructions correspondantes sont implémentées par de longues routines écrites en assembleur, pour gcc c’est libm qui s’en occupe. (thx Skywodd, pas libgcc)

Dans la plupart des micro-contrôleurs embarqués de type PIC ou AVR (ou même ARM non cortex M4) il n’y a pas de FPU, du coup les opérations en flottant, si elles sont supportées par le compilateur, sont à éviter pour des raisons de performances.

Problèmes en virgule flottante

Parfois on veut gérer directement des grandeurs physiques, comme quand on écrit le code pour un accéléromètre, un appareil de mesure de tension/courant, etc.

La méthode “triviale” est de passer en float.

Regardons le code suivant:

#define REF_VOLTAGE (float)5.0 //valeur de la tension de référence
#define CONV_MAX 2048 //valeur max de mesure pour un convertisseur 12 bits (exemple)

unsigned short conv = adc_read(); //lire le résultat de la conversion, c'est un entier

float voltage = conv / CONV_MAX * REF_VOLTAGE; //règle de trois!

//maintenant on a une tension

Ce code est mauvais : il commence par faire une division, puis une multiplication. Selon les compilateurs, ça peut être grave, car si CONV_MAX n’est pas converti en flottant, la division produira toujours un résultat zéro: Eh oui, le résultat de cette division sera toujours compris entre zéro et un! Nous pouvons apporter une correction pour éviter cela:

float voltage = conv / (float)CONV_MAX * REF_VOLTAGE;

C’est moins mauvais… Cette fois c’est la précision qui en prend un coup. L’erreur d’arrondi dûe à la précision limitée de la division va être multipliée par REF_VOLTAGE, le résultat sera peu précis. On peut faire mieux de cette manière:

float voltage = (float)(conv * REF_VOLTAGE) / (float)CONV_MAX;

Cette fois, on  va diviser un plus grand nombre, et les erreurs d’arrondis seront minimales.

Maintenant, étudions le problème des performances, en essayant de se passer des nombres flottants.

L’optimisation: la virgule fixe

Dans beaucoup de cas en informatique embarquée, on veut pouvoir gérer des nombres dont les variations sont limitées, c’est à dire qu’on n’a pas besoin de gérer des exposants très différents. C’est le cas par exemple lorsqu’on gère la tension issue d’un convertisseur analogique numérique.

Dans ce cas, le convertisseur va générer un nombre de quelques bits, par exemple 8 à 16 bits. Le résultat de la conversion est un entier, et la plupart du temps cette information suffit.

Remarquons que la plupart des nombres à virgules simples peuvent s’écrire comme une fraction. Évidemment ce n’est pas le cas de tous les nombres, mais dans le cadre de la précision limitée qui nous intéresse, c’est le cas. Exemple: 1,23 = 123/100

On peut décider de fixer ce dénominateur et de le rendre implicite: on ne l’écrit plus. Cela nous permet de travailler avec des entiers “plus grands”.

Si je choisis par exemple 100, tous les nombres ayant deux chiffres après la virgule peuvent s’écrire comme des entiers:

  • 1,23 => 123
  • 4,67 => 467
  • 1,5473 => 155

J’ai choisi une convention de virgule fixe à deux chiffres après la virgule, ce qui en réalité, signifie que je travaille avec des nombres 100 fois plus grands que la réalité.

Si on transpose ceci dans le domaine de l’informatique, il faut faire les choses intelligemment. On ne va plus utiliser des puissances de dix, mais des puissances de deux, car c’est le système naturel de comptage de l’ordinateur. L’avantage, c’est que les multiplications et les divisions se transforment en décalages. Exemples:

* pour multiplier par 16, je décale vers la gauche de 4 bits.
* pour diviser par 32, je décale vers la droite de 5 bits.

Avec cette idée, je ne vais plus utiliser des nombres ayant deux chiffres après la virgule, mais de nombres ayant N bits après la virgule. Pas de panique, ça veut dire qu’au lieu de multiplier mes valeurs par 10,100,1000, je vais les multiplier par 16,32,…1024, etc.

Cela ne change rien au résultat: cela veut juste dire que je travaille avec des valeurs N fois plus grandes que le résultat souhaité.

Dans la plupart des cas en embarqué, on va travailler avec des nombres à virgule fixe de 16 (short) ou 32 (long) bits.

On choisit ensuite le nombre de bits après la virgule. Cela permet de définir une grande quantité de formats:

  • le format 8.8 code les nombres sur 16 bits, avec un dénominateur de (1<<8) = 256, il reste 8 bits pour la partie entière, ce qui permet de coder les nombres de 0 à 255 avec une précision de 1/256, ou de -128 à 127 si on garde le signe
  • le format 12.4 permet de coder de 0 à 4095 (12 bits entiers) avec une précision de 1/16
  • etc… etc…

Donc 5,0 volts flottants, si je le traduis en entier ça fait 5 volts, en format 8.8 ça fait (5<<8)+0 = (5*256) = 1280, et en format 12.4, ça fait (5*16) = 80
Si vous lisez 80 en format 12.4, ça fait en réalité: (80/16) = 5

Calculs en virgule fixe

C’est le même principe que pour les fractions, et dans notre cas elles sont déja réduites au même dénominateur D, celui qu’on a choisi. Un nombre en virgule fixe s’écrit <quelque chose>/D.

L’addition et la soustraction sont triviales, c’est la même chose que pour les entiers:

a/D + b/D = (a+b)/D

Il suffit donc de faire la somme de deux nombres en virgule fixe pour retrouver un nombre en virgule fixe dans le même format, sans autre chose à faire.

Pour la multiplication:

a/D * b/D = (a*b)/(D*D)

mais j’ai besoin de fractions dans lequel le dénominateur est toujours D. Je peux réécrire ce résultat en divisant en haut et en bas par D, ce qui ne change pas le résultat:

(a*b)/(D*D) = (a*b/D)/(D*D/D) = (a*b/D)/D

Le résultat de la multiplication de a et b est donc (a*b/D). En pratique, cela veut dire que chaque fois que vous multipliez deux nombres en virgule fixe dans le même format, il faut diviser ensuite le résultat par D. Comme on a dit que D était une puissance de deux, ça revient à un décalage.

Division: (a/D) / (b/D) = (a/D) * (D/b) = a/b = (a*D/b) /D

Vous me suivez? Pour retrouver un nombre dans le bon format, il faut donc multiplier par D après la division. Normal, c’est le réciproque de la multiplication!

Pour la comparaison, rien à signaler, on peut le faire directement, ce format ne change pas l’ordre des nombres entiers: a/D < b/D si et seulement si a < b .

Pour transposer un nombre flottant (ou entier) en format à virgule fixe, il suffit de le multiplier par D.

Pour transformer un nombre à virgule fixe en format flottant (ou en entier), il suffit de le diviser par D.

Conclusion

J’espère que ce petit aperçu vous aura clarifié les idées. En résumé, il s’agit de :

  • Choisir un dénominateur D assez grand pour la précision que vous souhaitez, celle ci vaudra 1/D. Pour avoir un avantage, il faut que D soit une puissance de 2.
  • Multiplier tous les nombres à manipuler par D, cela se fait par décalage à gauche.
  • L’addition et la soustraction se font avec des opérations normales sur les entiers.
  • La multiplication se fait comme pour les entiers, on divise ensuite par D en décalant à droite.
  • La division a/b se fait en prémultipliant a par D, puis en faisant une simple division entière par b.
  • La comparaison se fait comme pour les entiers

Et c’est tout!

Quelle est la meilleure toolchain pour ARM embarqué?

Sur le web, on trouve plusieurs toolchains ARM, qui peuvent être toutes utilisées pour programmer des cartes embarquées. Voici les principales:

  • YAGARTO (yet another arm toolchain)
  • buildroot
  • CodeSourcery (Sourcery CodeBench)
  • linaro (toolchain “officielle”)
  • GNUARM
  • WinARM

Toutes ces toolchains sont subtilement différentes:

  • CodeSourcery ne supporte pas les FPU (floating point unit) des Cortex-M4, et n’offre aucun support pour les utilisateurs de la version gratuite depuis le rachat de cette société par Mentor Graphics
  • WinARM et GNUARM sont préhistoriques, peu maintenues, etc
  • buildroot est prévue pour être utilisée dans l’environnement du même nom, et n’est pas toujours facile à obtenir séparément
  • C’est très pénible de compiler soi même une toolchain GCC complète

linaro est produite principalement pour les plate formes Android et Linux, et elle supporte les Cortex M4 (STM32, Stellaris etc). Son grand avantage est d’être supportée directement par la société ARM elle même, mais elle met 3 ou 4 fois plus de temps que les autres à compiler un programme. Pour un petit programme, cela peut sembler peu important, mais dès qu’on touche un projet plus volumineux, cela peut devenir pénible. De plus, elle inclut par défaut le support des exceptions C++, ce qui est totalement inutile sur les plate formes embarquées à mémoire réduite.

Pour regrouper le meilleur de ces mondes, Freddie Chopin, un expert en logiciel embarqué ARM très actif dans le monde open source /logiciel libre , a décidé de compiler et de distribuer sa propre toolchain, basée sur les paquets de la toolchain “officielle” linaro, mais en utilisant les options de constructions de CodeSourcery. Le résultat est doté de ces caractéristiques:

  • Plus rapide que Linaro,
  • Elle est compilée avec le compilateur le plus récent pour windows, mingw-w64 (et avec gcc sous linux)
  • Les paquets de base (le compilateur, newlib, gdb et binutils) proviennent directement des projets officiels, et utilisent les révisions les plus récentes,
  • Les autres composants (librairies requises pour la compilation de la toolchain, comme gmp, mpfr, mpc) sont les plus récentes versions stables (sauf si la documentation recommandait une version spécifique),
  • Les exceptions C++ ne sont pas activées (bien qu’une version avec les exceptions soit en préparation),
  • Toutes les librairies cibles sont fournies non strippées, donc avec toutes leurs infos de débogage (ce qui est pratique pour approfondir le débogage de ses propres programmes),
  • la librairie newlib est compilée avec l’option reent-small pour économiser de l’espace de pile.

Ces options sont très intéressantes pour l’efficacité des programmes ARM embarqués.

Cette toolchain est appellée “bleeding edge toolchain”, et elle est téléchargeable pour windows 32 et 64 bits, et pour linux 64 bits, sur le site sourceforge.

Je recommande son utilisation pour tous les projets ARM embarqués.

Des parties de cet article sont basées sur la traduction de cet article original (en anglais).

Construisons ensemble un synthétiseur : La composition des sons

Après un moment d’absence qui m’a permis de réfléchir à l’avenir de ce blog, je reviens vers vous avec un but plus éducatif qu’avant, où je ne faisais que présenter des projets pas faciles à partager.

Je vais décrire petit à petit comment réaliser un synthétiseur musical.

Cette semaine, on commence par quelques généralités sur les sons et les synthétiseurs, c’est indispensable pour savoir de quoi on parle!

C’est quoi un synthé? Vous devez déja le savoir… C’est un appareil qui produit des sons électroniques plus ou moins complexes, ce qui peut servir d’instrument de musique électronique. En général, on utilise des appareils qui fonctionnent selon la norme MIDI. Le MIDI permet de transporter des “évènements” musicaux: Ces évènements sont principalement l’allumage ou extinction d’une note, mais ils peuvent aussi concerner les changements de force des notes (vélocité) ou encore d’autres effets.

On a donc deux classes d’appareils:

  • des “émetteurs” ou “sources” d’évènements MIDI, tels que les claviers maîtres, les surfaces de contrôle ou les séquenceurs
  • des “récepteurs” ou “destinations” d’évènements MIDI, tels que les synthétiseurs ou les expandeurs.

Voyons d’abord quelques définitions:

Prestashop : survivre sans prestataire

NOTE: Je ne développe plus ce module.

Cette semaine, j’ai eu peu de temps libre, j’avais commencé un générateur Cockcroft-Walton pour faire un ioniseur d’air et (tenter d’) enlever des mauvaises odeurs, mais mon fer a souder a lâché dans la foulée. La résistance chauffante s’est dessoudée, et évidemment je ne pourrai pas la ressouder à l’étain… je suis bêtement immobilisé! J’ai donc basculé en mode “soft”.

Prestashop, c’est le WordPress de l’e-commerce, LA référence des softs de boutiques en ligne. C’est LE logiciel à utiliser quand on veut une boutique professionnelle, belle, efficace… C’est bien entendu le soft que j’ai choisi pour mettre en place la boutique en ligne du site de musiques de mon épouse, en me disant que sa notoriété serait un avantage pour le support utilisateur. Sauf que ce n’a pas été aussi simple…

Bunnie Huang: A l’usine, Partie 2 sur 4 : Concevoir pour l’industrialisation

Ce qui suit est donc la traduction de l’article de Bunnie Huang: The Factory Floor, Part 2 of 4: On Design for Manufacturing. C’est donc lui qui s’exprime à travers le “je” utilisé dans l’article suivant. N’étant pas un traducteur professionnel, je suis ouvert à toute proposition d’amélioration que vous me soumettriez dans les commentaires.

N’hésitez pas à consulter les autres parties de cette série:

  1. Le Devis (ou comment faire une nomenclature)
  2. Concevoir pour l’industrialisation
  3. La Conception Industrielle pour les Startups
  4. Choisir (et conserver) un partenaire

Akiba a posté des messages pour présenter les troisième et quatrième jours de mon cours “visite geek” pour les étudiants du MIT Media Lab, qui se déroule à Shenzhen, en Chine. Leur site a eu quelques soucis avec le trafic intense qui en a résulté, ce qui nous fait réfléchir à un changement de serveur. Malheureusement, se trouver à l’intérieur du grand pare-feu de Chine rend difficile l’administration de tout ce qui se trouve dans le cloud.

En attendant, voici le deuxième round de ma série en 4 parties nommée “A l’Usine”.

Optimisation des processus: concevoir pour l’industrialisation et les bancs de test

Il est temps de se pencher sur le sujet des rendements. C’est un sujet ennuyeux pour beaucoup d’ingénieurs, mais pour un entrepreneur, le succès ou l’échec sera partiellement déterminé par l’obtention d’un rendement suffisant. A l’inverse des logiciels, chaque copie d’un bien physique aura quelques petites imperfections. Parfois, ces imperfections vont s’annuler entre elles, alors que das d’autres cas, ces imperfections vont s’accumuler au mauvais endroit, ce qui dégradera les performances. Quand les volumes de production augmentent, ces cas exceptionnels commencent à s’amonceler, et une certaine proportion des produits fabriqués se révèle invendable. Si la conception est robuste, la fraction invendable sera si petite que les tests fonctionnels pourront être simplifiés, ce qui réduira encore les coûts. A l’inverse, des conceptions sensibles aux tolérances des composants nécessiteront des tests bien plus poussés, et le rendement de la production sera plus faible, ce qui donnera plus de pertes. Reprendre manuellement les unités défectueuses entraîne des coûts supplémentaires en main d’œuvre et en composants, ce qui finit par éroder sérieusement les marges commerciales.
Découvrez la suite des conseils de Bunnie Huang sur l’industrialisation