Empty

Total: 0,00 €

h:D

Planet

  • Monday, January 6, 2014 - 18:37
    Décodage d'un cadran à impulsions type S63

     S63gris

    Un téléphone de ce type, ça me fais rêver !
    Je passe encore de longues minutes ( pas des heures, faut pas exagérer..) à tourner le cadran en m’extasiant devant la mécanique du régulateur centrifuge, du codeur à rocher, de la simplicité du principe de numérotation décimale. Et je pense également à une poubelle que j'ai vue dans ma jeunesse; une armoire de central téléphonique électro-mécanique !!!! Imaginez, monté sur des panneaux, des centaines d’aiguilleurs électro-mécaniques à 10 positions, qui avancent à chaque impulsion. Des tonnes de ferraille qui aujourd'hui tiennent dans un seul composant de silicium... Je rêve, je vous dis!
    Bref..... On peux pas jeter un truc pareil ! Je vous propose de nous intéresser à la partie numérotation, pour en faire ce que vous voulez. A partir de Arduino, bien sûr!
    Voilà le schéma d'un poste S63 d'origine, complet. Nous allons nous intéresser uniquement à la partie cadran, le rond en haut et à gauche. Ce que le schéma montre mal, c'est que il y a 2 contacts indépendants. Un premier, avec des câbles bleu et blanc-bleu, n'est ouvert que lorsque le cadran est au repose. Il court-circuite micro et écouteur pour éviter entre autres des générer des bruits désagréables pour l'utilisateur lors de la rotation.

    Schéma Original S63Détail Cadran

    Le second, celui qui nous intéresse, en rouge et blanc-rouge, s'ouvre à chaque impulsion. Il y a 1 impulsion pour le 1 et 10 pour le 0. Chez nous. Dans d'autres pays, ça peux varier. Méfiez-vous des importations.
    "Et que peux-on en faire ? " me diriez-vous ! "Ce que bon vous semble, dans la limite de la décence" vous réponds-je.
    Par contre, je peux vous dire comment le faire; avec une Arduino, comme d'habitude, ou d'un AtTiny (mais il faut supprimer les commentaires bien sûr), car l'énorme avantage de ce truc, c'est de n'exiger qu'un seul pin de libre, contrairement à un clavier matriciel. En plus, c'est bien plus classe.
    Donc le programme;
    ------------------------------------------------------------------------------------------------------------------------------------------------------

    /* Décodage pour cadran à impulsion type S63
    Philippe Martorell
    le 6/01/2014
    */
    const int PinLecture = 2 ; // Entrée lecture impulsions
    const boolean Bavard = 1 ; // Génére les commentaires sur le port série
    const boolean Debug = 1 ; // Génére les mesures de temps
    /*
    Pour compiler avec un AtTiny,
    il suffit de mettre à "0" les deux constantes précédentes
    Pensez bien que l'envoi sur le port série prend du temps.
    C'est importatnt dans les mesures des impulsion.
    */
    boolean PlusDuneFois = 1 ; // pour éviter la répétition de commentaire
    unsigned long TempsImpulsionMin = 50 ;
    unsigned long TempsImpulsionMax = 90 ;
    unsigned long TempsInterImpulsionMin = 25 ;
    unsigned long TempsInterImpulsionMax = 50 ;
    unsigned long TempsInterNumero = 200 ;
    unsigned long rebonds = 2 ;
    unsigned long duree = 0;
    unsigned long temps = 0 ;
    int Numero = 0 ;
    
    void setup()
    {
     if (Debug || Bavard) // Si les deux à 0, on initialise pas
      {
       Serial.begin(115200);
       Serial.println ("Initialisation Serie") ;
      }
     pinMode(PinLecture , INPUT);
     digitalWrite(PinLecture , HIGH);
    }
    void loop()
    {
     Numero = 0 ;
     delay ( rebonds );
     while ( !digitalRead(PinLecture) )
      {
       if ( PlusDuneFois == 1 && Bavard == 1 )
       {
        Serial.println ("Attente") ;
        PlusDuneFois = 0 ;
       }
      }
     temps = millis() ;
     if (Debug == 1 )
     {
      debug();
     }
     PlusDuneFois = 1 ;
     delay ( rebonds );
     int Numero = 0 ;
     numerotation () ;
     delay ( rebonds );
    }
    
    void numerotation()
    {
     while (1) //Boucle infinie, on ne sort qu'avec les "return"
     {
      if ( Bavard == 1 )
      {
       Serial.println ("Entree impulsion") ;
      }
      while ( digitalRead(PinLecture) )
      {
       duree = millis() - temps ;
       if ( duree > TempsImpulsionMax )
       {
        if ( Bavard == 1 )
        {
         Serial.println ("Impulsion trop longue") ;
        }
        debug();
        return ;
       }
      }
      if (millis() - temps < TempsImpulsionMin )
      {
       if ( Bavard == 1 )
       {
        Serial.println ("Impulsion trop courte") ;
       }
       debug();
       return ;
      }
      delay ( rebonds );
      if ( Bavard == 1 )
      {
       Serial.println ("Sortie impulsion") ;
      }
      debug();
      Numero ++ ;
      if ( Bavard == 1 )
      {
       Serial.print ("Increment numero ; ") ;
       Serial.println (Numero) ;
      }
      temps = millis() ;
      delay ( rebonds );
      if ( Bavard == 1 )
      {
       Serial.println ("Entree inter-impulsion") ;
      }
      debug();
      while( !digitalRead(PinLecture) )
      {
       duree = millis() - temps ;
       if ( duree > TempsInterImpulsionMax )
       {
        if ( Bavard == 1 )
        {
         Serial.println ("Inter-impulsions trop longue; action") ;
        }
       debug();
      Action () ;
      return ;
       }
      }
     if ( Bavard == 1 )
     {
      Serial.println ("Sortie inter-impulsion") ;
     }
     if ( duree < TempsInterImpulsionMin )
     {
      if ( Bavard == 1 )
      {
       Serial.println ("Inter-impulsion trop courte") ;
      }
      debug();
      return ;
     }
     debug();
     temps = millis() ;
     delay ( rebonds );
     }
    }
    void debug ()
    {
    if (Debug == 1 )
     {
      Serial.print ("Lecture ; ") ;
      Serial.print (digitalRead(PinLecture)) ;
      Serial.print (" duree = ") ;
      Serial.println (millis() - temps) ;
     }
     delay(2) ; // petite tempo par principe
    }
    
    void Action ()
    {
    if ( Bavard == 1 )
     {
      Serial.print ("Action avec numero ; ") ;
      Serial.println (Numero) ;
     }
    // Placez ici l'action à faire avec la variable "Numéro"
    Numero = 0 ;
    }
    

    -------------------------------------------------------------------------------------------------------------------------------------------------------
    Bon, j'ai un peu honte, il traîne des inélégant "return..", mais je n'ai pas su comment m'en passer.

  • Monday, December 30, 2013 - 10:03
    Une Borne d'Arcade maison, Fin

    Suite de l'étude précédente :

    L'heure des bilans :

    Après quasi deux ans de travaux, je vais maintenant en terminer avec cette série de comptes rendu, en faisant quelques bilans…
    Pour la petite histoire, suite à la fabrication des joysticks, j'ai passé deux mois à mettre au point la partie informatique (Août/Sept 2011), puis à imaginer et dessiner le meuble tout en m'occupant de la partie électronique, pour être prêt à commencer l'usinage du meuble (Janvier 2012).
    Quelques temps plus tard (Mars 2012), je reprenais les travaux dans une suite ininterrompue jusqu'à Mai 2013.
    Malgré le fait que l'espace de mon salon demeura un sacré chantier durant cette période, et que la progression au jour le jour fût très longue, je n'ai pas vu le temps passer et c'est avec satisfaction que je retrouve l'usufruit du salon, avec ce nouveau meuble qui en impose par sa prestance.

    Bilan outillage :

    Voici une liste non exhaustive de l'essentiel des outils ayants servis :

    dsc08900.jpg

    • Pour découper

    Des scies de plusieurs types, (circulaire, sauteuse, égoïne, à onglet et sa boite à coupe, à métaux), mais aussi cutter.

    • Pour maintenir

    Différents types de serres joints.
    Nous avons ici du premier prix en rouge, de la marque distributeur (Dexter = Leroy Merlin), et la marque Wolfcraft.
    dsc08903.jpg
    Les deux premier prix. je les ai depuis un bail. et ces derniers travaux les ont achevés ! Tordus et désaxés, ils présentent un jeu trop important et se desserrent tout seul.
    Les deux Dexter (8€ les 2), je les ai achetés durant la construction de la borne, et je peux vous dire que même si au maniement on les sent plus fiable que les autres, bah c'est de la merde quand même ! En effet, au fil des serrages, un des deux à vu son filetage se désagréger dans un crissement de métal broyé... mais peut-être que je suis un gros bourrin ? hum... nan !
    Quant au Wolfcraft (15€), un très bon matos ! Robuste, très bonne prise et maintient puissant, il ne bouge pas d'un poil et se met en place sans se bouziller les mains.

    dsc08904.jpg

    • Pour mesurer et tracer

    Équerre de menuisier, rapporteur d'angle, réglet et grande règle suffisent à se débrouiller en plus d'un simple crayon de bois.
    Pour écrire sur le plastique, il faudra un feutre fin indélébile.

    dsc08901.jpg

    • Pour percer

    Bah une perceuse…
    Mais surtout des forêts à bois et métal de qualités.

    • Pour limer et poncer

    dsc08902.jpg
    Deux râpes à bois et deux limes à métal (une plate et une arrondie), du papier de verre (silex) de trois grosseurs différentes, du plus gros au plus fin, suffisant pour le bois et du papier à poncer pour carrosserie (métal) de 400, 600 et 800 pour la laque.
    Une ponceuse à bande est un atout très utile pour gagner du temps, mais il faut s'assurer de bien maitriser l'outil car la matière disparaît très vite sous son passage !

    • Pour peindre

    dsc08899.jpg
    Quelques pinceaux bien sûr, mais surtout un pistolet à peinture basse pression et quelques bâches plastique pour protéger un minimum l'environnement de travail.
    La laque restant une technique de peinture très longue, cet outil s'avère bien pratique et permet de faire «rapidement» un travail assez propre.

    • Voila, il n'en faut pas pour cher en outils, et il ne faut pas hésiter à prendre du bon matériel, certes plus onéreux, mais qui durera toute la vie en servant à d'autres bricolages. Sinon il faudra racheter de la merde et au final se rendre compte qu'on aurait finit par payer le produit haut de gamme... sauf qu'on ne l'aura pas entre les mains !

    Ça ne sera jamais l'outil qui fera de vous un bon ouvrier, mais il y contribuera. Par contre, un mauvais outil aura tendance à empirer vos défauts…
    Enfin, un bon outil est un outil avec lequel on est à l'aise et grâce auquel on pourra faire mieux en prenant soins de s'appliquer.

    Bilan de compétences :

    • Sur cet ouvrage, j'aurais vraiment touché pas mal de domaines très différents, et au passage appris un tas de trucs !

    - L'informatique, avec la mise en place l'un système automatique GNU/Linux + AdvanceMame/Menu, entièrement géré aux joystick.
    - L'électronique + l'informatique, en redécouvrant le fonctionnement des écrans à tube cathodique et la manière de les interfacer à un ordinateur.
    - L'électronique, avec la fabrication des joysticks et aussi du circuit de protection de l'écran TV.
    - La soudure et le ferraillage, en fabriquant le système de rotation de l'écran.
    - La menuiserie, pour le meuble…
    - Le dessin vectoriel, pour les plans et les design de décorations.
    - La CAO pour les cartes l'électronique.
    - L'ingénierie… Même si certaines choses ont été faites en allant, sans trop savoir en détail comment m'y prendre, j'aurais tout de même pas mal cogitté le sujet…

    Bilan Logiciel :

    • Excepté l'émulateur AdvanceMame, la borne a été conçue et fonctionne grâce à des logiciels libres !

    À partir de mon PC sous Ubutu 10.04LTS,
    - Inkscape et Gimp, pour les plans et les design de décorations.
    - Kicad pour la CAO électronique.
    Les comptes rendu rédigés et publiés avec :
    - Dotclear, que vous lisez maintenant.
    - Gimp pour la retouche photos.
    - Cinellera et ffmpeg2theora, pour les vidéos.
    - Scribus, pour un document de résumé à usage privé.

    Les Regrets :

    • La partie basse aurait pu être mieux conçue

    En effet, placer des petites roulettes et encadrer la borne d'un socle gris pour compenser en stabilité, c'est finalement une bidouille pas pratique du tout, un défaut de conception influencé par mon idée tenace à vouloir utiliser l'intérieur de la borne comme d'un placard.
    Obnubilé par le gain de place intérieur, j'ai perdu de vue la possibilité de faire reposer la borne sur un simple cadre rigide, muni de grosse roulettes à l'arrière.

    • Le sens de rotation de l'écran est inversé !!

    Bêtement j'avais réglé AdvanceMame pour tourner sur la droite et pas compris qu'on pouvait choisir le sens en changeant le réglage…
    Persuadé donc qu'il faille me conformer à cela, j'ai bien fait attention à fixer l'armature métallique au rond rotatif de manière à tourner à droite, ce qui dans le fond n'est pas un problème me direz-vous puisqu'il suffit d'un réglage logiciel…
    Oui, mais nan ! Car c'est fichu si on veut utiliser un vrai jeu au format Jamma, car la quasi totalité des titres verticaux tournent à gauche !
    Même problème avec le jeu Ikaruga sur GameCube qui dispose du mode de jeu vertical, le réglage ne tourne l'image qu'à gauche !
    Il existe une bidouille pour retourner l'image, mais il faut alors intervenir sur le téléviseur, en cas d'erreur c'est assez dangereux pour l'intégrité du matériel, donc je m'abstiendrais.

    • La borne est plus haute que prévu

    J'ai foiré quelque chose en découpant la structure de base, me souviens pu bien quoi et du coup, la hauteur du panel donne 68 cm… au lieu de 66 cm sur l'Astro City originale, élevant de fait la hauteur totale du meuble de deux centimètres.

    • Le plexis du chapeau est raté

    dsc09204.jpg
    La découpe des trous pour laisser sortir le son des hauts parleur aurait-dû suivre le design de l'artwork que j'ai dessiné et placé derrière.
    Pourtant encore une fois, je ne me souviens plus comment cela a pu se produire, mais au final j'ai fait une découpe droite, on le constate bien en se demandant pourquoi les obliques grises et roses sont coupées dans leur longueur.
    De plus en bas à droite, j'ai dérapé avec le cutter, faisant une profonde rayure.

    Remerciements :

    • Au départ je m'étais lancé seul dans l'aventure, mais on réalise finalement qu'on n'est jamais seul sur internet, que les contributions au projet se font indirectement et finissent parfois par nous rattraper, lorsque des contributeurs ont eux même vent de l'avancée des travaux, pour fermer la boucle.

    Je remercie donc chaleureusement et dans le désordre toutes les contributions plus ou moins directes :
    - Paul Qureshi aka MoJo, programmeur de l'électronique du Joystick USB.
    - Andrea Mazzoleni, développeur d'AdvanceMame, lui même basé su Mame.
    - Calamity et son acolyte par le patch de Linux en 15kHz.
    - La communauté Gamoover, et tout particulièrement Aganyte pour les photo de sa New AstroCity de très bonne qualité et Max pour le tuto AdvanceMame qui fut une bonne base de départ.
    - Bien entendu, le projet Debian dans son ensemble et la communauté du libre !
    - Mon père pour son aide et ses précieux conseils dans la mise en œuvre.
    - Éric pour le prêt du pistolet à peinture !
    - Les différents soutiens et commentaires parlés, écrit, et podcastés, Seb, Pascal, Rain, Samaël, TomTom, Quentin, maethor, Nikos, Nicolas, Babosor, etc.
    - Spécial Thanks à mes gentils béta testeur : Kolocat et Kuri Hana !

    Et désolé à ceux que j'oublie ! ^^;

    Spécification de la borne :

    • Dimension et design inspiré de la célèbre CandyCab SEGA AstroCity

    - Hauteur : 146 cm.
    - Largeur : 75 cm.
    - Profondeur : 91 cm.
    - Meuble démontable.
    - Panel amovible pour passer aux portes et ascenseurs.
    - Structure sur roulette, sécurisée sur un socle.
    - Poids total = 90 kg.

    Structure de base (en pin/sapin) = 26 kg.
    Montage rotatif, écran/armature/rond = 43 kg. (L'écran plat pèse 38 kg)
    Capot = 5,5 kg.
    Control Panel = 3 kg.
    Plaquage extérieur = 9 kg.
    Étagère intérieure = 3 kg.

    • Téléviseur

    Sony Trinitron 29 pouces à dalle plate, KV19FX30 (chassis FE-2).
    Diagonale de l'image visible 68 cm.

    • Ordinateur

    - Processeur Intel P4 2Ghz avec 512 Mio de Ram.
    - Carte graphique ATI 9200.
    - Pas de disque dur, mais une Clé USB de 16 Go, avec dessus :

    GNU/Linux Debian 7 Wheezy et son noyau patché 15kHz.
    AdvanceMenu Version 2.6
    AdvanceMame Version 1.2

    • Consommation électrique

    Totale = 175 Watts.

    Écran = 75 Watts.
    Lumière = 16 Watts.
    Ordinateur = 64 à 85 Watts.

    Prix à titre indicatif :

    • Liste et prix de toute la matière première :

    - 2 x 20 équerres métalliques 40 x 20 mm à 4€70 = 9€40
    - 1 Sachet «vrac» 60 x 80 mm remplis de vis agglo de 40 mm = 1€49
    - 4 Pattes d'assemblages de 80 mm à 0€76 = 3€04
    - 3 Tablettes Pin noueux 200 x 60 x 1,8 cm à 12€50 = 37€50
    - 100 Tourillons de 60 mm = ???
    - 1 Panneaux de contre-plaqué 120 x 60 x 1,8 cm = 23€99 - promo 20% = 19€19
    - 2 Équerres larges à 1€31 = 2€62
    - 4 Équerres d'assemblage en acier galvanisé (70 x 70 x 55 mm ép.2,5 mm) à 2€04 = 8€16
    - 4 patins en Plastique à clouer diamètre 30 mm = 1€79
    - 1 Sachet (80 x 120 mm) de visserie en Vrac = 3€10
    - 8 Écrous 6 pans diamètre 10 mm = 2€25
    - 2 Panneaux de MDF 120 x 60 x 1,5 cm à 11€90 = 23€80
    - 6 Roulettes pivotantes blanches Diamètre 25mm à 2€ = 12€
    - 2 Tasseaux en pin à 4€90 = 9€80
    - 20 Taquets à clouer = 1€90
    - 2 Équerres fenêtre zing 220mm à 2€50 = 5€
    - 2 x 10 Boulons à tête fraisée (4 x 40 mm) à 2€75 = 5€50
    - 1 Sachet (80 x 120 mm) de visserie en Vrac = 3€65
    - 2 Charnières paumelle gauche (40 x 50 mm) = 2€
    - 2 Tasseaux brut (270 x 16 x 47 mm) à 5€90 = 11€80
    - 1 Plaque de Verre Synthétique (2,5 x 750 x 500 mm) = 10€95
    - 2 Équerres (100 x 100 x 90 x 3 mm) à 2€90 = 5€80
    - 2 x2 Charnières pour verre (13 x 40 mm) à 2€55 = 5€10
    - 1 Charnière à piano en laiton 32 x 600 mm = 2€65
    - 1 Tube en PVC de (2000 x diam 125 mm) = 13€20
    - 2 Tasseaux de (2000 x 10 x 15 mm) à 2€90 = 5€80
    - 2 Tasseaux de (2700 x 16 x 50 mm) à 5€90 = 11€80
    - 1 Tasseau de (2000 x 10 x 10 mm) à 2€90
    - 2 Fermoir (60 x 30 mm) à 3€10 = 6€20
    - 2 Charnières dégondables 30x40 = 1€79
    - Enduit de lissage spécial bois 1,25 kg = 15€70
    - Peinture blanc brillant acrylique 2,5 L = 39€90
    - Réglette fluo T8 (26mm) - 18 Watts - Blanc 840 - Culot G 13 - 1350 lumens = 7€45

    Total = 293€23,
    Sans l'écran, l'électronique, l'informatique, les joystick et boutons.
    Certaines pièces de bois sont de récupération, ainsi que la ferraille de l'armature de métal.

  • Saturday, December 28, 2013 - 00:18
    DIY – Générateur de Marx

    C’est pas encore l’heure des bonnes résolutions, mais je renoue ici avec une de mes passion premières, un peu délaissée ces derniers temps : la haute tension.
    Le montage auquel je me suis attaqué aujourd’hui est assez simple dans son fonctionnement, il s’agit d’un générateur de Marx, qui permet de multiplier une tension. L’avantage de ce montage, est qu’outre sa simplicité, la tension de sortie est directement proportionnelle au nombre d’étages mis en jeux (aux pertes près).

    Générateur de Marx

    Générateur de Marx

    Le concept consiste à charger X condensateurs en parallèles, et les décharger en série. Pour arriver à un pareil résultat, on va utiliser des éclateurs. En effet, tant que la tension  aux bornes du condensateur ne dépasse pas une certaine tension, rien ne se passe, les condensateurs se chargent tranquillement, et la tension à leurs bornes augmente peu à peu.

    Charge

    Charge

     

    Mais lorsque cette tension est atteinte, un arc électrique se produit sur l’éclateur, qui deviens ainsi conducteur.

    Décharge. En bleu ciel, les arcs électriques

    Décharge. En bleu ciel, les arcs électriques

    (oui, désolé pour les couleurs un peu flashy, ça pique les yeux, je sais)
    Pour que ça fonctionne (bien), il y a tout de même quelques paramètres importants à respecter. Déjà, il faut que la tension d’alimentation soit suffisamment élevée pour pouvoir produire un arc électrique, sinon les éclateurs ne fonctionneront pas. Ensuite, les résistances de charges. J’ai un peu galéré pour trouver des résistances correctes pour ce montage. Au début, j’étais partis avec des résistances couches carbone (les classiques), mais rapidement les arcs sont passés par le côté de la résistance, détruisant celles-ci. J’ai ensuite voulu utiliser des résistances de puissances en céramique. Mauvaise idée : elles ont été détruites en totalité sur un seul shoot. Je suspecte plus la déflagration d’avoir endommagé l’intérieur que la chauffe proprement dite car elles étaient sensées tenir plus que les couches carbone, ce qui n’aura pas été le cas ici. Finalement, j’ai utilisé des résistances bobinées de puissances, et après quelques dizaines de minutes de fonctionnement, tout à l’air en ordre de marche. Dernier point, la distance entre les éclateurs est relativement importante, c’est d’elle que dépendra la « tension de claquage »

    Mon générateur de Marx

    Mon générateur de Marx

    Comme on peut le voir sur la photo, mon générateur est constitué de 6 étages, ce qui multiplie donc par 6 la tension d’entrée… En théorie. En effet, mes éclateurs étant difficiles à régler, ma tension de claquage est assez loin du maximum débité par mon alimentation. Au final, je dois arriver à une tension de 10Kv par condensateur, soit 60Kv en sortie.
    Les éclateurs sont de simples fils de cuivre recourbés, passés au papier de verre pour enlever l’émail.

    Le générateur en action

    Le générateur en action. Le père Noël fait 12cm

    Petit détail pour ceux qui serais tentés par l’expérience, et qu’il est difficile de rendre sur une photo : C’est extrêmement bruyant !! (genre mitraillette dans le salon)

  • Thursday, December 26, 2013 - 09:03
    G2N, un pistolet pour jeux vidéos -2-

    Suite de l'étude précédente :

    • On continue avec l'intégration de la « Pistol Board » dans le pistolet Virtua Gun de SEGA.

    Les borniers se relieront à la Main board pour fournir l'alimentation et les signaux de la camera, ainsi que pour les boutons start et gâchette de la manette USB.
    dsc09362.jpg
    dsc09363.jpg

    • C'est en place, reste à connecter la caméra IR.

    ATTENTION, Il faut obligatoirement une camera provenant d'une Wiimote officielle Nintendo !
    La caméra d'une copie Chinoise, telle que celle-ci ne sera en rien compatible avec notre montage :
    dsc09240.jpg
    dsc09228.jpg
    dsc09229.jpg
    dsc09233.jpg
    dsc09231.jpg
    dsc09238.jpg
    dsc09234.jpg

    Voici donc la caméra Infra-rouge Pixart dé-soudée depuis une véritable Wiimote, sans Motion Plus intégré, modèle RVL-003.
    dsc09433.jpg
    dsc09436.jpg

    Je l'ai ensuite câblé sur une nappe de fils avec un connecteur HE10 Femelle au bout.
    Afin de faire tenir la caméra dans le pistolet, on va exploiter une des fentes d'1 mm de large disposées dans le canon, là où se trouvait la lentille du Virtua Gun.
    dsc09439.jpg
    dsc09616.jpg

    Dans de la carte plastique d'1 mm d'épaisseur, a donc été découpé un disque percé d'un carré pour y loger la caméra.
    Le filtre UV de la Wiimote a été sculpté pour s'adapter a la forme du canon, et le disque est formé grâce à des rajouts en carte plastique de 2 mm.
    dsc09609.jpg
    dsc09608.jpg

    Voilà les pièces achevées, désolé, le flash a cramé les photos, et on ne voit pas vraiment le cordon de colle tout autour de la caméra, utilisé pour fixer le montage.
    dsc09614.jpg
    dsc09615.jpg

    Reste à mettre en place la caméra connectée à la pistol board dans le pistolet.
    Attention, si la WiiSensorBar est disposée au dessous de l’écran, la caméra IR doit être placée avec les pins vers le haut; Pins vers le bas si la caméra est au dessus de l'écran.
    dsc09621.jpg
    dsc09623.jpg
    dsc09618.jpg

    Mise au point :

    Après avoir effectué les branchements de l'alimentation 5V et relié la Pistol Board à la Main Board, on peut mettre le montage sous tension.

    1. La première chose à faire, est d'agir sur le potentiomètre RV2 pour régler la luminosité de l'écran LCD.
    2. Après un reset du circuit (SW1), le message d'accueil doit apparaître.
    3. Ensuite, il faut mettre JP2 sur ON pour passer le montage en mode View Blob.

    Après un reset, ce mode va afficher des 1023 sur l'écran LCD… Dés qu'on passe une source infra-rouge (flame de briquet, WiiSensorBar) devant la camera, une suite de chiffre va alors varier, témoignant du bon fonctionnement du circuit.

    TroubleShooting :

    • L'écran n'affiche rien -> Régler RV2.
    • Le message « camera I2C Error » s'affiche sur l'écran ->

    - Vérifier que les 3 CI sont bien alimentés.
    - Vérifier le câblage de la camera…
    - Essayer de débrancher la pistol board, à la place des 1023, il devrait s'afficher des 0, ce qui à priori témoigne du bon fonctionnement de la main board.

    CAMERA I2C ERROR (1/2 sec)
    LOADING CONFIG…  (3 sec de pause)
    CONFIG LOADED… (3 sec de pause)
    0000000000000000
    0000000000000000
    

    - Reconnecter les deux cartes, tout semble ok, pourtant si les 1023 restent figés, il y a sans doute un problème de communication entre les deux cartes.
    - Déconnecter le signal SDA entre la main board et la pistol board et mettre sous tension, on va procéder à quelques mesures :

    Quand SDA est en l'air, au démarrage, la Main Board passe en mode view blob.
    Quand SDA est branché, à la Pistol Board (résistance de pull-up 2,2k au 3V), au démarrage, la Main Board bloque sur Camera I2C Error.
    À l'oscilloscope on mesure bien le train sur SCL envoyé par le PIC.
    Dés qu'on connecte la broche SDA, le signal SCL disparait. La mesure de SDA est à zero.
    On peut voir SCL qui vit sa vie, calibre 100µs, puis 10µs :
    hni-0049.jpg
    hni-0048.jpg
    hni-0050.jpg
    Là, on branche la résistance de SDA, et SCL passe à 0.
    Si on déconnecte cette résistance de pull-up, SCL reste à 0.
    Le signal sur SCL revient après un reset du PIC à condition que la pin 15 (SDA) reste en l'air.
    De plus, à l'oscilloscope, les signaux d'alimentation 5V et le 3V apparaissent bruités.
    En débranchant la caméra de la Pistol Board, les signaux redeviennent propres.

    À ce stade, il semblerait que la Pistol Board soit fautive.
    On peut le vérifier en établissant le dialogue entre la Main Board et la caméra, sans passer par la Pistol Board, mais en utilisant les signaux d'horloge, d'alim et de reset provenant de la Wiimote elle même !
    Si la Main Board ne plante pas sur I2C Error et que les 1023 du mode Blob fonctionnent, c'est gagné, rechercher la panne sur la Pistol Board.

    • Justification des modifications par rapport au montage original :

    L'horloge et le reset volé à la Wiimote ayant permis un fonctionnement correct, je me suis tourné vers l'oscillateur à quartz 25Mhz, qui, une fois la caméra IR connectée au circuit provoquait un méchant parasitage du 5V, et donc du 3,3V , induisant alors tous les soucis de communications.
    La caméra fonctionnant en 3,3V, je me suis dit qu'elle pourrait ne pas apprécier de manger une horloge à 5V.
    J'ai donc utilisé un oscillateur à quartz alimenté en 3,3V @25Mhz (le 24MHz, comme la Wiimote étant difficile à trouver), ce qui est beaucoup plus logique quand on sait que la caméra IR Pixart fonctionne en 3,3V !

    Interfacer avec l'ordinateur :

    • Une fois que le système fonctionne en autonome, il reste à le faire passer pour un joystick analogique aux yeux de l'ordinateur.

    Pour ce faire, en attendant le développement d'une carte Add-On spécifique, on va désosser une manette et utiliser le joystick analogique qui pilote la croix de direction (et pas l'autre !).
    Il suffit de dessouder le potentiomètre (sa valeur doit être de 10kΩ pour que le circuit du joystick soit compatible avec le G2N) et de brancher des fils à la place en direction du connecteur K1 de la Main Board (Xa, Xw, Xb et Ya, Yw, Yb).
    dsc09606.jpg
    dsc09624.jpg
    Il faut aussi relier un fil depuis un bouton de la manette, vers K1 sur la position Reload.
    Côté Pistol Board il faut câbler deux autres boutons de la manette vers la gachette SW1 et le bouton Start SW2.

    • On en profite pour repiquer du 5V sur la manette afin d'alimenter la Main Board.
    • Quand on agite le pistolet devant une source infrarouge, le mode test de manette de jeu de l'ordinateur doit permettre de visualiser la croix directionnelle bouger.

    À suivre…

  • Friday, December 20, 2013 - 08:40
    Impressions multi-matériaux avec un seul extrudeur

    Imprimer directement en plusieurs couleurs peut vraiment être intéressant, par exemple, pour intégrer des pictogrammes informatifs sur la face d'un objet ou simplement dans un but purement décoratif.

    Ultimaker propose un kit permettant d'imprimer en 2 couleurs (ou 2 filaments de matériaux différents) mais les retours sur les forums ne m'ont pas convaincus de l'acheter, je pense au final que le ratio coût / intérêt n'est pas vraiment bon lorsque l'on s'en sert uniquement pour du multi couleurs, l'intérêt est bien plus grand pour de l'impression multi-matériaux (support en PVA par exemple).

    Je vais vous expliquer 2 méthodes qui vous permettront de passer à l'impression multi couleur avec un seul extrudeur.

    Notez que cet article tourne autour de l'Ultimaker et de son slicer Cura mais il est tout à fait possible d'adapter cette solution à toute RepRap.

    Avec le plugin Cura : PauseAtZ

    En utilisant le plugin fourni avec Cura PauseAtZ qui permet, comme son nom l'indique, de stopper l'impression à une certaine hauteur, de parker la tête afin de changer le filament et ensuite de relancer l'impression avec le nouveau filament.

    Le principal problème de cette technique est qu'il ne permet pas à une couche d'avoir plusieurs couleurs, rien de vraiment nouveau avec cette méthode...

    Feinter le slicer : PauseAtExtruderChange

    Dans cette méthode, on va utiliser Cura exactement comme si nous avions le kit de double extrusion, et allons dire à Cura de slicer comme tel. C'est par la suite que nous allons lire le GCode et remplacer l'instruction de changement de tête (Tx) par des instructions permettant de parker la tête le temps d'effectuer le changement de filament.

    Voici les étapes exactes :

    1. Parker le Z
    2. Déplacer la tête en X, Y à la position de parkage
    3. Stopper le ventilateur
    4. Attendre une action de l'utilisateur (nécessite un ulticontrolleur TODO)
    5. Restaurer la position X, Y
    6. Redémarrer le ventilateur
    7. Restaurer le Z

    Nous pourrions également utiliser le G-Code M600 mais il s'agit d'une instruction en test qui n'est pas inclut par défaut dans tous les firmware et l'utilisation de nos propres instructions nous permet de faire exactement ce que l'on souhaite...

    En pratique

    1. Installez le plugin Cura PauseAtExtruderChange, (déposez simplement le fichier PauseAtExtruderChange.py dans le dossier ~/.cura/VERSION/plugins)

    2. Créons un nouveau profil d'imprimante : File > Machine setting > Add new machine, dans le panel Extruder 2, on s'assure que Offset X et Offset Y soit égal à 0 comme dans l'image ci-dessous :

    Cura - Machine settings

    3. Importez vos fichiers stl, précisez à Cura que vous souhaitez les fusionner pour faire de la double extrusion (sélectionnez le premier objet d'un clique gauche, puis, bouton droit sur le second objet et cliquez sur Dual extrusion merge)

    4. Ajoutez le plugin, modifiez les paramètres tel que vous le souhaitez et vous voilà avec votre fichier G-Code modifié

    5. Lancez l'impression et l'imprimante vous signalera chaque changement de couleur, il vous restera alors à changer le filament, valider le changement auprès de l'imprimante, l'impression reprendra alors exactement oû elle avait été arrêtée mais avec un autre filament.

    Note: Vous pouvez aussi utiliser le fichier python directement en ligne de commande : python PauseAtExtruderChange.py file.gcode > out.gcode (python PauseAtExtruderChange.py -h pour avoir de l'aide)

    Voilà ce qu'il est possible de faire très simplement :

    Vous voilà maintenant capable d'imprimer en multi couleur d'une manière un peu plus évoluée qu'avec PauseAtZ, néanmoins, l'utilisation de PauseAtExtruderChange ne sera intéressante que pour des impressions ou le nombre de changement de couleur par couche est faible sinon, vous risquez de passer votre temps à changer de filament...

  • Wednesday, December 18, 2013 - 16:13
    Noisebridgers Make Novel Method to Cycle LED’s

    Welcome to our workbench.

    Jameco and Instructables.com donated a buncha weird parts to Noisebridge, including LED’s, crystal oscillators, 555 timers, Russian capacitors…. Thank You, JameCo and Instructables! Thanks Dana Sniezko for suggesting this partnership.

    Our mission: make something that does something. Not as easy as it sounds.

    The result: A 9-volt battery driving an LM317 power-supply outputting 5 volts, driving a tiny sliver of crystallized rock into resonance at one-and-a-half thousand vibrations per second, divided in half, 8 times, by a binary counter, down to a speed of about six vibrations per-second, driving an LED.

    Meaning, we made multiple LED’s blink at varying rates, all without a microcontroller. “i’m happy to say, not one 555 was used”, says Johny Radio, organizer. “This was my design goal, since everybody uses 555′s for everything.”

    John Ellis provided essential insight regarding chip-pinouts, Jonathan brain-hacker suggested using two crystals to derive beat-frequencies (which we decided added unnecessary complexity, and would have delayed pizza-time), Martino Da Video was our handsome public-relations representative (he wore pink sunglasses), and Johny Radio conceived the circuit design. It was a real Noisebridge group achievement.

    “One amazing Instructable” says Carley Jacobson of Instructables.com.

    For more details and hot pix, and to learn how to make your own, go to:
    http://www.instructables.com/id/EH2QS8KHMMF6TQA/
    850 views, 6 faves, and counting…

  • Monday, December 16, 2013 - 12:20
    Chris Lord: Linking CSS properties with scroll position: A proposal

    As I, and many others have written before, on mobile, rendering/processing of JS is done asynchronously to responding to the user scrolling, so that we can maintain touch response and screen update. We basically have no chance of consistently hitting 60fps if we don’t do this (and you can witness what happens if you don’t by running desktop Firefox (for now)). This does mean, however, that you end up with bugs like this, where people respond in JavaScript to the scroll position changing and end up with jerky animation because there are no guarantees about the frequency or timeliness of scroll position updates. It also means that neat parallax sites like this can’t be done in quite the same way on mobile. Although this is currently only a problem on mobile, this will eventually affect desktop too. I believe that Internet Explorer already uses asynchronous composition on the desktop, and I think that’s the way we’re going in Firefox too. It’d be great to have a solution for this problem first.

    It’s obvious that we could do with a way of declaring a link between a CSS property and the scroll position. My immediate thought is to do this via CSS. I had this idea for a syntax:

    scroll-transition-(x|y): <transition-declaration> [, <transition-declaration>]*
    
        where transition-declaration = <property>( <transition-stop> [, <transition-stop>]+ )
          and transition-stop        = <relative-scroll-position> <property-value>

    This would work quite similarly to standard transitions, where a limited number of properties would be supported, and perhaps their interpolation could be defined in the same way too. Relative scroll position is 0px when the scroll position of the particular axis matches the element’s offset position. This would lead to declarations like this:

    scroll-transition-y: opacity( 0px 0%, 100px 100%, 200px 0% ), transform( 0px scale(1%), 100px scale(100%), 200px scale(1%);

    This would define a transition that would grow and fade in an element as the user scrolled it towards 100px down the page, then shrink and fade out as you scrolled beyond that point.

    But then Paul Rouget made me aware that Anthony Ricaud had the same idea, but instead of this slightly arcane syntax, to tie it to CSS animation keyframes. I think this is more easily implemented (at least in Firefox’s case), more flexible and more easily expressed by designers too. Much like transitions and animations, these need not be mutually exclusive though, I suppose (though the interactions between them might mean as a platform developer, it’d be in my best interests to suggest that they should :)).

    I’m not aware of any proposal of this suggestion, so I’ll describe the syntax that I would expect. I think it should inherit from the CSS animation spec, but prefix the animation-* properties with scroll-. Instead of animation-duration, you would have scroll-animation-bounds. scroll-animation-bounds would describe a vector, the distance along which would determine the position of the animation. Imagine that this vector was actually a plane, that extended infinitely, perpendicular to its direction of travel; your distance along the vector is unaffected by your distance to the vector. In other words, if you had a scroll-animation-bounds that described a line going straight down, your horizontal scroll position wouldn’t affect the animation. Animation keyframes would be defined in the exact same way.

    [Edit] Paul Rouget makes the suggestion that rather than having a prefixed copy of animation, that a new property be introduced, animation-controller, of which the default would be time, but a new option could be scroll. We would still need an equivalent to duration, so I would re-purpose my above-suggested property as animation-scroll-bounds.

    What do people think about either of these suggestions? I’d love to hear some conversation/suggestions/criticisms in the comments, after which perhaps I can submit a revised proposal and begin an implementation.

  • Wednesday, December 11, 2013 - 09:40
    RaspberryPi + Grove = RaspiO'Mix

    RaspiO'Mix est une carte fille pour Raspberry Pi développée par mes soins sur une idée de Michel d'Erasme qui va vous permettre
    de connecter facilement et rapidement tout un tas de modules de type
    Grove initialement prévus pour Arduino.

    Caractéristiques

    • Aux dimensions du RaspberryPi
    • 4 entrées / sorties tolérantes 5V (basée sur un TXS0108PWR)
    • 4 entrées analogiques, 0-5V, 18 bits de résolution
    • 2 entrées numériques via DIP switch
    • Horloge temps réel avec batterie de sauvegarde
    • 2 connecteurs pour I2C
    • 1 connecteur pour communication série
    • Alimentation 5V via jack

    Connecteurs

    Bien entendu, cette carte est entièrement libre, toutes les informations nécessaires pour la fabriquer sont disponibles sur GitHub / RaspiO'Mix.

    Fonctionnement

    Voici le schéma de principe :

    schema.png

    La conversion analogique / numérique est assurée par un MCP3424, un CAN I2C de 18 bits de résolution, une horloge temps réel DS1307 est présente sur le même bus.

    Une librairie Python est disponible et vous permet d'accéder simplement aux différentes fonctions d'entrées / sorties, I2C, série et ainsi d'intéragir avec un monde 5V bien au chaud dans l'environnement 3V3 du RaspberryPi...

    La carte en action

    Je veux mon propre RaspiO'Mix

    2 solutions s'offre alors à vous :

    1. DIY : Tout est à votre disposition pour le faire vous même, sur GitHub, vous trouverez la liste des composants, des informations techniques, les fichiers Eagle, les fichier gerber, bref, TOUT est disponible pour le faire vous même !
    2. Je peux vous les fabriquer, pour le moment, je n'ai pas de magasin en ligne donc, contactez moi directement pour un devis (je suis en mesure de produire des séries et de faire des réductions sur quantité)

  • Saturday, December 7, 2013 - 02:32
    Moteur stirling Alpha, deuxième prototype

    Ayant relevé tout un tas de défaut qui empêchaient le fonctionnement de mon premier moteur stirling, j’ai donc décidé de partir sur une seconde version améliorant les problèmes. Au final j’ai complètement changé le design, et suis partis sur un modèle à pistons parallèles (mais toujours alpha), car ils permettent plus de réglages. Je me suis largement inspiré d’un design trouvé sur internet, en apportant des corrections sur les points qui avaient posé problème à ses auteurs. Cette nouvelle version présente également un changement d’échelle par rapport à ma V1, mais finalement plus importante que ce que je m’imaginais à partir de la CAO. Comme pour le modèle précédent, je publierais les plans dès que mon modèle sera fonctionnel (s’il l’est), en y apportant les différentes corrections/modifications faites en cours de route.

    Comme il s’agit d’un projet d’assez longue haleine, je vous met ça sous la forme d’une sorte de journal de bord. Cela vous permettra d’y voir la chronologie des étapes, et à moi de garder une trace des temps passés pour faire un bilan final. Histoire de ne pas polluer le blog avec un post a chaque étape, j’essaierais de grouper ça dans un post mensuel, sauf éventuellement sur des points techniques intéressants.

    Vendredi 8 /11: Ebauche du piston chaud. 5h d’usinage, pour réduite un rond d’inox, diamètre 60 sur 200 de long, à un tube d’inox de diamètre intérieur 45… Reste à l’emmener à 50mm de diamètre interne, et reprendre légèrement le diamètre extérieur (0.2mm). La plupart des matériaux ont été achetés ou commandés, à l’exception du laiton.

    Cylindre chaud

    usinage du cylindre chaud

    Mardi 12/11: Finition du cylindre chaud. 2h d’usinage. Cote interne au début du cylindre 49,635, cote à la fin 49,64 ce qui n’est pas mal sur 160mm de long avec des outils moyennement adaptés. Le piston est terminé, à l’exception des perçages.

    le cylindre chaud : un peu plus gros que la v1 ;)

    le cylindre chaud : un peu plus gros que la v1 ;)

    Mercredi 13/11 : 2h d’usinage. Travail sur la tête de la culasse chaude. J’ai été trop léger sur la longueur du rond d’inox acheté. Résultat des courses, l’usinage est compliqué. J’ai atteint 1/100eme de précision sur la partie rentrant dans la culasse, en revanche, sur l’extérieur, j’ai été obligé de descendre en dessous de la côte (problème de concentricité car pas assez de matière pour la prise). Du coups la tête fait 0,5mm de diamètre en moins que la culasse. Pas super esthétique, mais aucune influence sur le fonctionnel. J’essaierais de faire mieux sur le piston froid.

    Mercredi 20/11 : 1h d’usinage. Réalisation du piston chaud, en graphite. Alors le graphite à usiner, c’est du beurre, mais alors à nettoyer…. Donc, 1h pour réaliser la pièce, 3h pour nettoyer l’atelier ! Et dire qu’il m’en reste un autre a faire :’(

    Lundi 25/11 : Ca y est, j’attaque le socle et les parties d’assemblages. L’usinage se fera au centre, j’ai donc du apprendre pas mal de choses sur la génération de code machine, et notamment la prise en main d’Esprit, qui n’est pas un modèle d’ergonomie ;) Merci encore à Alain pour ses précieux conseils.
    Au total, il m’aura fallu 5 heures pour aboutir à une pièce à moitée usinée : les perçages et le surfaçage sont fait, mais il reste encore le contournage. Pour pouvoir le faire, je dois réaliser un support qui permettra de brider la pièce dans le centre d’usinage. Connaissant un peu mieux le logiciel maintenant, je pense gagner pas mal de temps sur les prochaines pièces !
    Sinon, petite boulette en passant : à l’origine je pensais usiner mes pièces d’assemblage sur une fraiseuse « stratoconception ». Cette machine permet de disposer au mieux les différentes pièces, et de tout découper à partir d’une seule plaque de matière. (très pratique pour faire des meubles). Bien que pouvant théoriquement usiner de l’aluminium, j’avais négligé le problème de la lubrification, ce qui m’oblige à passer sur le centre d’usinage pour toutes les pièces d’assemblage, et pas seulement la base. Là où ça deviens moins drôle, c’est que le centre ne fonctionne pas de la même manière, et on travaille pièce par pièce avec des morceaux de taille adaptée… Me voilà donc avec ma scie sauteuse à redécouper ma plaque d’alu de 10mm…. J’en ai pour quelques heures !

    Mercredi 27/11 : 3h d’usinage. Je viens de recevoir mon laiton. 15Kg de brut pour le cylindre froid (ouch !) J’ai passé deux heures sur le tour pour réaliser l’ébauche. Les ailettes de refroidissement sont terminées, et les diamètres extérieurs sont à +5mm pour pouvoir les reprendre aux mors doux quand j’aurais terminé l’intérieur.
    Il me reste maintenant à creuser ça, quelques heures de travail en perspective.
    Sinon j’ai profité d’un créneau machine ce matin pour usiner le support de bridage de ma base. Avec un peu de chance, je pourrais terminer cette partie vendredi.

    L'ébauche du cylindre froid

    L’ébauche du cylindre froid

    Vendredi 29/11 : 5h d’usinage. Aujourd’hui, travail de finition du  cylindre froid. Objectif être le plus prêt de la cote internet du cylindre chaud. Résultat cylindre froid : 49.625mm, cylindre chaud 49,635. Plutôt pas mal :). Par contre, la fin de l’usinage s’est très mal passée : après avoir fait la passe de finition d’un côté du cylindre, j’ai voulu usiner les mors doux pour ne pas le marquer en usinant l’autre côté. Malheureusement, je n’avais pas assez de prise sur le mors doux, la pièce a été éjectée en cours d’usinage. Heureusement pas de blessure, mais la pièce a sérieusement reçu ! des entailles de 5mm apparaissent de chaque extrémités du cylindre. Après une heure de travail supplémentaire, au mors standard cette fois ci, temps pis pour les marques, j’ai réussi à rattraper le coups (heureusement, le côté le plus marqué était celui qui n’était pas terminé, et j’avais un surplus de matière suffisant). Au final, on voit une légère marque d’un côté, mais aucun impact sur le fonctionnement, et la marque est tout de même assez minime. J’ai eu chaud !!

    Lundi  2/12 : 2h d’usinage. On continue le support du moteur au centre d’usinage. Le programme était fait, le support de bridage aussi, mais il aura fallu près de 2h pour en venir à bout. on a perdu pas mal de temps à trouver une bonne méthode pour brider la pièce. Les trous sur le côté, que je pensais faire à la perceuse à colonne ont finalement été réalisés au centre, taraudage compris : c’est assez impressionnant à voir faire !

  • Monday, December 2, 2013 - 16:05
    RS Components distributing RepRaps

    This blog is for the RepRap Project, and so I do not normally post information here about the activities of our company, RepRapPro Ltd.  See our company blog for that sort of thing.

    No.  The reason for this post is that from today a seriously major international company - RS Components, the world’s largest distributor of electronics and
    maintenance products - will be stocking and selling completely open-source RepRap kits.  And in the future they hope to be selling components for RepRaps.  In particular they want to sell vitamins-only kits so that people can print their own RepRaps.

    For more details see RS's blog post here, and, of course, their catalogue here.

  • Friday, November 29, 2013 - 15:31
    Chris Lord: Efficient animation for games on the (mobile) web

    Drawing on some of my limited HTML5 games experience, and marginally less limited general games and app writing experience, I’d like to write a bit about efficient animation for games on the web. I usually prefer to write about my experiences, rather than just straight advice-giving, so I apologise profusely for how condescending this will likely sound. I’ll try to improve in the future :)

    There are a few things worth knowing that will really help your game (or indeed app) run better and use less battery life, especially on low-end devices. I think it’s worth getting some of these things down, as there’s evidence to suggest (in popular and widely-used UI libraries, for example) that it isn’t necessarily common knowledge. I’d also love to know if I’m just being delightfully/frustratingly naive in my assumptions.

    First off, let’s get the basic stuff out of the way.

    Help the browser help you

    If you’re using DOM for your UI, which I’d certainly recommend, you really ought to use CSS transitions and/or animations, rather than JavaScript-powered animations. Though JS animations can be easier to express at times, unless you have a great need to synchronise UI animation state with game animation state, you’re unlikely to be able to do a better job than the browser. The reason for this is that CSS transitions/animations are much higher level than JavaScript, and express a very specific intent. Because of this, the browser can make some assumptions that it can’t easily make when you’re manually tweaking values in JavaScript. To take a concrete example, if you start a CSS transition to move something from off-screen so that it’s fully visible on-screen, the browser knows that the related content will end up completely visible to the user and can pre-render that content. When you animate position with JavaScript, the browser can’t easily make that same assumption, and so you might end up causing it to draw only the newly-exposed region of content, which may introduce slow-down. There are signals at the beginning and end of animations that allow you to attach JS callbacks and form a rudimentary form of synchronisation (though there are no guarantees on how promptly these callbacks will happen).

    Speaking of assumptions the browser can make, you want to avoid causing it to have to relayout during animations. In this vein, it’s worth trying to stick to animating only transform and opacity properties. Though some browsers make some effort for other properties to be fast, these are pretty much the only ones semi-guaranteed to be fast across all browsers. Something to be careful of is that overflow may end up causing relayouting, or other expensive calculations. If you’re setting a transform on something that would overlap its container’s bounds, you may want to set overflow: hidden on that container for the duration of the animation.

    Use requestAnimationFrame

    When you’re animating canvas content, or when your DOM animations absolutely must synchronise with canvas content animations, do make sure to use requestAnimationFrame. Assuming you’re running in an arbitrary browsing session, you can never really know how long the browser will take to draw a particular frame. requestAnimationFrame causes the browser to redraw and call your function before that frame gets to the screen. The downside of using this vs. setTimeout, is that your animations must be time-based instead of frame-based. i.e. you must keep track of time and set your animation properties based on elapsed time. requestAnimationFrame includes a time-stamp in its callback function prototype, which you most definitely should use (as opposed to using the Date object), as this will be the time the frame began rendering, and ought to make your animations look more fluid. You may have a callback that ends up looking something like this:

    var startTime = -1;
    var animationLength = 2000; // Animation length in milliseconds
    
    function doAnimation(timestamp) {
     // Calculate animation progress
     var progress = 0;
     if (startTime < 0) {
       startTime = timestamp;
     } else {
       progress = Math.min(1.0, animationLength /
                                  (timestamp - startTime));
     }
    
     // Do animation ...
    
     if (progress < 1.0) {
       requestAnimationFrame(doAnimation);
     }
    }
    
    // Start animation
    requestAnimationFrame(doAnimation);

    You’ll note that I set startTime to -1 at the beginning, when I could just as easily set the time using the Date object and avoid the extra code in the animation callback. I do this so that any setup or processes that happen between the start of the animation and the callback being processed don’t affect the start of the animation, and so that all the animations I start before the frame is processed are synchronised.

    To save battery life, it’s best to only draw when there are things going on, so that would mean calling requestAnimationFrame (or your refresh function, which in turn calls that) in response to events happening in your game. Unfortunately, this makes it very easy to end up drawing things multiple times per frame. I would recommend keeping track of when requestAnimationFrame has been called and only having a single handler for it. As far as I know, there aren’t solid guarantees of what order things will be called in with requestAnimationFrame (though in my experience, it’s in the order in which they were requested), so this also helps cut out any ambiguity. An easy way to do this is to declare your own refresh function that sets a flag when it calls requestAnimationFrame. When the callback is executed, you can unset that flag so that calls to that function will request a new frame again, like this:

    function redraw() {
      drawPending = false;
    
      // Do drawing ...
    }
    
    var drawPending = false;
    function requestRedraw() {
      if (!drawPending) {
        drawPending = true;
        requestAnimationFrame(redraw);
      }
    }

    Following this pattern, or something similar, means that no matter how many times you call requestRedraw, your drawing function will only be called once per frame.

    Remember, that when you do drawing in requestAnimationFrame (and in general), you may be blocking the browser from updating other things. Try to keep unnecessary work outside of your animation functions. For example, it may make sense for animation setup to happen in a timeout callback rather than a requestAnimationFrame callback, and likewise if you have a computationally heavy thing that will happen at the end of an animation. Though I think it’s certainly overkill for simple games, you may want to consider using Worker threads. It’s worth trying to batch similar operations, and to schedule them at a time when screen updates are unlikely to occur, or when such updates are of a more subtle nature. Modern console games, for example, tend to prioritise framerate during player movement and combat, but may prioritise image quality or physics detail when compromise to framerate and input response would be less noticeable.

    Measure performance

    One of the reasons I bring this topic up, is that there exist some popular animation-related libraries, or popular UI toolkits with animation functions, that still do things like using setTimeout to drive their animations, drive all their animations completely individually, or other similar things that aren’t conducive to maintaining a high frame-rate. One of the goals for my game Puzzowl is for it to be a solid 60fps on reasonable hardware (for the record, it’s almost there on Galaxy Nexus-class hardware) and playable on low-end (almost there on a Geeksphone Keon). I’d have liked to use as much third party software as possible, but most of what I tried was either too complicated for simple use-cases, or had performance issues on mobile.

    How I came to this conclusion is more important than the conclusion itself, however. To begin with, my priority was to write the code quickly to iterate on gameplay (and I’d certainly recommend doing this). I assumed that my own, naive code was making the game slower than I’d like. To an extent, this was true, I found plenty to optimise in my own code, but it go to the point where I knew what I was doing ought to perform quite well, and I still wasn’t quite there. At this point, I turned to the Firefox JavaScript profiler, and this told me almost exactly what low-hanging-fruit was left to address to improve performance. As it turned out, I suffered from some of the things I’ve mentioned in this post; my animation code had some corner cases where they could cause redraws to happen several times per frame, some of my animations caused Firefox to need to redraw everything (they were fine in other browsers, as it happens – that particular issue is now fixed), and some of the third party code I was using was poorly optimised.

    A take-away

    To help combat poor animation performance, I wrote Animator.js. It’s a simple animation library, and I’d like to think it’s efficient and easy to use. It’s heavily influenced by various parts of Clutter, but I’ve tried to avoid scope-creep. It does one thing, and it does it well (or adequately, at least). Animator.js is a fire-and-forget style animation library, designed to be used with games, or other situations where you need many, synchronised, custom animations. It includes a handful of built-in tweening functions, the facility to add your own, and helper functions for animating object properties. I use it to drive all the drawing updates and transitions in Puzzowl, by overriding its requestAnimationFrame function with a custom version that makes the request, but appends the game’s drawing function onto the end of the callback, like so:

    animator.requestAnimationFrame =
      function(callback) {
        requestAnimationFrame(function(t) {
          callback(t);
          redraw();
        });
     };

    My game’s redraw function does all drawing, and my animation callbacks just update state. When I request a redraw outside of animations, I just check the animator’s activeAnimations property first to stop from mistakenly drawing multiple times in a single animation frame. This gives me nice, synchronised animations at very low cost. Puzzowl isn’t out yet, but there’s a little screencast of it running on a Nexus 5:

    Alternative, low-framerate YouTube link.

  • Saturday, November 2, 2013 - 09:11
    SlyBlog: Introducing OpenPhoenux Neo900

    openphoenux-logoThe latest device in the OpenPhoenux open hardware familiy is the Neo900, the first true successor to the Nokia N900. The Neo900 is a joint project of the Openmoko veteran Jörg Reisenweber and the creators of the GTA04/Letux2804 open hardware smartphone at Golden Delicious Computers. Furthermore, it is supported by the N900 Maemo5/Fremantle community, the Openmoko community and the OpenPhoenux community, who are working together to get closer to their common goal of providing an open hardware smartphone, which is able to run 100% free and open source software, while being independent of any big hardware manufacturer.

    OpenPhoenux Neo900

    OpenPhoenux Neo900

    With the big ecosystem of free and open Maemo5/Fermantle applications, the hacker friendly N900, which provides an excelent hardware keyboard, the variety of free operating systems of the Openmoko community (SHR, QtMoko, Replicant, …) and the experience in designing and producing open hardware devices of the OpenPhoenux community (e.g. GTA04), they want to bring the best of all worlds together in one single device, the Neo900.

    The Neo900 is meant to be an upgraded N900, with a newly designed and more powerfull motherboard, which is based upon the existing and tested OpenPhoenux GTA04 design. Together with the nice housing of the N900 (e.g. slider, hardware keyboard, big screen, …), this is trying to get “the hackers most beloved device”. In the same spirit of the OpenPhoenux community, which created unique cases for their GTA04 devices out of aluminium, wood or 3D printing, there is also an effort to build an aluminium housing for the N900, which might lead to personalized and self-produced cases for the Neo900 in the future and thus the independence of spare parts of N900 smartphones.

    n900-cover1 n900-cover2

    Due to the fact that the Neo900′s new motherboard is very similar to the GTA04, it is possible to reuse most of the low level software stack like development tools, the Bootloader and the Linux Kernel from the GTA04 project, with just minor modifications applied. This will speed up the software development process of this new open hardware platform a lot!

    To fund the development and prototyping of this new open hardware device, which is made in Germany, a crowdfunding campain has been started a few days ago, in order to collect 25.000€ (which is by now already halfway reached!). Depending on the outcome of this fundraising the project might be able to provide better hardware specs than the following minimum keyfeature set:

    • TI DM3730 CPU (OMAP3 ARM Cortex A8) with 1+ GHz
    • 512+ MB RAM, 1+ GB NAND flash, 32+ GB eMMC, Micro-SD-Reader
    • 3.75G module for UMTS/CDMA; 4G (LTE) optional
    • USB 2.0 OTG High Speed
    • GPS, WLAN, Bluetooth
    • Accelerometer, barometric Altimeter, Magnetometer, Gyroscope
    • support of N900 camera module

    DSC01773 DSC01774

    If you want to see the N900 to live on, help the independet open hardware community to succeed, or are looking for a new, hacker friendly smartphone, you should consider to support the fundraising with a donation. If you donate 100€ or more, your donation will also serve as a rebate for a finished device, once they are ready.

    [Update 2013-11-04] The goal of 25.000€ is now reached, less than a week after the fundraiser started! Thanks to everybody who donated and spread the word and thus helped to make that happen. If you want to qualify for the rebate on the finished device, it is still possible to donate.

    Let the OpenPhoenux fly on!

  • Friday, November 1, 2013 - 11:01
    openmoko-fr: Nouveau matériel annoncé : Neo900 / Développment du GTA04

    Bonjour tout le monde!

    Cela fait longtemps que je n'ai plus écrit sur ce blog, mais ce n'est pas pour autant que l'activité autour d'OpenMoko est morte.

    En effet, Radek a décidé que QtMoko était suffisamment stable pour baisser le rythme de développement et il a expliqué à la mailing-list de la communauté que, pour lui, sa distribution est surtout utile en attendant un port d'Android sur le GTA04.

    À propos d'Android justement, le projet Replicant a essayé de porter leur version d'Android sur le GTA04, mais ils ont eu des soucis avec le noyau qui a quelques incompatibilités avec Android. Comme il n'y a que deux développeurs chez Replicant et que le plus actif ne connaît pas assez le développement noyau pour porter Replicant sur le GTA04, il a été décidé d'attendre que le noyau soit utilisable avant de continuer les efforts.

    C'est pourquoi Golden Delicious est en train de suivre le développement noyau Linux à chaque RC (donc leurs développements sont actuellement fait sur la version 3.12), puisque Android essaie de fusionner avec le noyau Linux au fil des versions. Donc avec un peu de temps encore, j'espère que l'on pourra profiter de l'expertise noyau de Golden Delicious et l'expertise Android de Replicant, pour avoir enfin un port d'Android 4.x utilisable sur le GTA04 :)

    Sinon, Golden Delicious a décidé de ne pas baisser les bras pour faire du matériel "le plus libre possible" et propose un nouveau projet avec la communauté du Nokia N900 : le Neo900.

    Le but de ce projet est de profiter du développement du GTA04 pour raviver la communauté du N900 et de leur proposer du matériel un peu plus libre (le N900 a un OS libre Maemo, mais le matériel n'a pas été ouvert par Nokia). Ainsi, l'idée est de reformer la carte du GTA04 pour passer dans le boîtier du N900 et d'en profiter pour mettre un module LTE.

    Ne vous inquiétez pas pour la multiplication des projets du Golden Delicious : le but est d'utiliser le plus possible de chipset en commun pour pouvoir faire des commandes plus grosses que si un seul projet existait.

    Le plus enthousiasment dans ce projet est qu'il permet de réunir les différentes communautés open-source/libre autour du développement d'un même matériel et ainsi proposer un support encore meilleur aux utilisateurs.

    Qui dit nouveau projet, dit également financement : Golden Delicious a lancé sa campagne de don depuis le 30 octobre. N'hésitez pas à contribuer !

    Notez également que le premier pallier de 5'000€ pour débuter le développement à déjà était atteint hier et qu'au moment de l'écriture de cet article la campagne vient de passer au dessus des 10'000€.

    À bientôt!

    Trim

  • Monday, October 28, 2013 - 10:22
    Chris Lord: Sabbatical Over

    Aww, my 8-week sabbatical is now over. I wish I had more time, but I feel I used it well and there are certainly lots of Firefox bugs I want to work on too, so perhaps it’s about that time now (also, it’s not that long till Christmas anyway!)

    So, what did I do on my sabbatical?

    As I mentioned in the previous post, I took the time off primarily to work on a game, and that’s pretty much what I did. Except, I ended up working on two games. After realising the scope for our first game was much larger than we’d reckoned for, we decided to work on a smaller puzzle game too. I had a prototype working in a day, then that same prototype rewritten because DOM is slow in another day, then it rewritten again in another day because it ends up, canvas isn’t particularly fast either. After that, it’s been polish and refinement; it still isn’t done, but it’s fun to play and there’s promise. We’re not sure what the long-term plan is for this, but I’d like to package it with a runtime and distribute it on the major mobile app-stores (it runs in every modern browser, IE included).

    The first project ended up being a first-person, rogue-like, dungeon crawler. None of those genres are known for being particularly brief or trivial games, so I’m not sure what we expected, but yes, it’s a lot of work. In this time, we’ve gotten our idea of the game a bit more solid, designed some interaction, worked on various bits of art (texture-sets, rough monsters) and have an engine that lets you walk around an area, pick things up and features deferred, per-pixel lighting. It doesn’t run very well on your average phone at the moment, and it has layout bugs in WebKit/Blink based browsers. IE11′s WebGL also isn’t complete enough to render it as it is, though I expect I could get a basic version of it working there. I’ve put this on the back-burner slightly to focus on smaller projects that can be demoed and completed in a reasonable time-frame, but I hope to have the time to return to it intermittently and gradually bring it up to the point where it’s recognisable as a game.

    You can read a short paragraph and see a screenshot of both of these games at our team website, or see a few more on our Twitter feed.

    What did I learn on my sabbatical?

    Well, despite what many people are pretty eager to say, the web really isn’t ready as a games platform. Or an app platform, in my humble opinion. You can get around the issues if you have a decent knowledge of how rendering engines are implemented and a reasonable grasp of debugging and profiling tools, but there are too many performance and layout bugs for it to be comfortable right now, considering the alternatives. While it isn’t ready, I can say that it’s going to be amazing when it is. You really can write an app that, with relatively little effort, will run everywhere. Between CSS media queries, viewport units and flexbox, you can finally, easily write a responsive layout that can be markedly different for desktop, tablet and phone, and CSS transitions and a little JavaScript give you great expressive power for UI animations. WebGL is good enough for writing most mobile games you see, if you can avoid jank caused by garbage collection and reflow. Technologies like CocoonJS makes this really easy to deploy too.

    Given how positive that all sounds, why isn’t it ready? These are the top bugs I encountered while working on some games (from a mobile specific viewpoint):

    WebGL cannot be relied upon

    WebGL has finally hit Chrome for Android release version, and has been enabled in Firefox and Opera for Android for ages now. The aforementioned CocoonJS lets you use it on iOS too, even. Availability isn’t the problem. The problem is that it frequently crashes the browser, or you frequently lose context, for no good reason. Changing the orientation of your phone, or resizing the browser on desktop has often caused the browser to crash in my testing. I’ve had lost contexts when my app is the only page running, no DOM manipulation is happening, no textures are being created or destroyed and the phone isn’t visibly busy with anything else. You can handle it, but having to recreate everything when this happens is not a great user experience. This happens frequently enough to be noticeable, and annoying. This seems to vary a lot per phone, but is not something I’ve experienced with native development at this scale.

    An aside, Chrome also has an odd bug that causes a security exception if you load an image (on the same domain), render it scaled into a canvas, then try to upload that canvas. This, unfortunately, means we can’t use WebGL on Chrome in our puzzle game.

    Canvas performance isn’t great

    Canvas ought to be enough for simple 2d games, and there are certainly lots of compelling demos about, but I find it’s near impossible to get 60fps, full-screen, full-resolution performance out of even quite simple cases, across browsers. Chrome has great canvas acceleration and Firefox has an accelerated canvas too (possibly Aurora+ only at the moment), and it does work, but not well enough that you can rely on it. My puzzle game uses canvas as a fallback renderer on mobile, when WebGL isn’t an option, but it has markedly worse performance.

    Porting to Chrome is a pain

    A bit controversial, and perhaps a pot/kettle situation coming from a Firefox developer, but it seems that if Chrome isn’t your primary target, you’re going to have fun porting to it later. I don’t want to get into specifics, but I’ve found that Chrome often lays out differently (and incorrectly, according to specification) when compared to Firefox and IE10+, especially when flexbox becomes involved. Its transform implementation is also quite buggy too, and often ignores set perspective. There’s also the small annoyance that some features that are unprefixed in other browsers are still prefixed in Chrome (animations, 3d transforms). I actually found Chrome to be more of a pain than IE. In modern IE (10+), things tend to either work, or not work. I had fewer situations where something purported to work, but was buggy or incorrectly implemented.

    Another aside, touch input in Chrome for Android has unacceptable latency and there doesn’t seem to be any way of working around it. No such issue in Firefox.

    Appcache is awful

    Uh, seriously. Who thought it was a good idea that appcache should work entirely independently of the browser cache? Because it isn’t a good idea. Took me a while to figure out that I have to change my server settings so that the browser won’t cache images/documents independently of appcache, breaking appcache updates. I tend to think that the most obvious and useful way for something to work should be how it works by default, and this is really not the case here.

    Aside, Firefox has a bug that means that any two pages that have the same appcache manifest will cause a browser crash when accessing the second page. This includes an installed version of an online page using the same manifest.

    CSS transitions/animations leak implementation details

    This is the most annoying one, and I’ll make sure to file bugs about this in Firefox at least. Because setting of style properties gets coalesced, animations often don’t run. Removing display:none from an element and setting a style class to run a transition on it won’t work unless you force a reflow in-between. Similarly, switching to one style class, then back again won’t cause the animation on the first style-class to re-run. This is the case at least in Firefox and Chrome, I’ve not tested in IE. I can’t believe that this behaviour is explicitly specified, and it’s certainly extremely unintuitive. There are plenty of articles that talk about working around this, I’m kind of amazed that we haven’t fixed this yet. I’m equally concerned about the bad habits that this encourages too.

    DOM rendering is slow

    One of the big strengths of HTML5 as an app platform is how expressive HTML/CSS are and how you can easily create user interfaces in it, visually tweak and debugging them. You would naturally want to use this in any app or game that you were developing for the web primarily. Except, at least for games, if you use the DOM for your UI, you are going to spend an awful lot of time profiling, tweaking and making seemingly irrelevant changes to your CSS to try and improve rendering speed. This is no good at all, in my opinion, as this is the big advantage that the web has over native development. If you’re using WebGL only, you may as well just develop a native app and port it to wherever you want it, because using WebGL doesn’t make cross-device testing any easier and it certainly introduces a performance penalty. On the other hand, if you have a simple game, or a UI-heavy game, the web makes that much easier to work on. The one exception to this seems to be IE, which has absolutely stellar rendering performance. Well done IE.

    This has been my experience with making web apps. Although those problems exist, when things come together, the result is quite beautiful. My puzzle game, though there are still browser-specific bugs to work around and performance issues to fix, works across varying size and specification of phone, in every major, modern browser. It even allows you to install it in Firefox as a dedicated app, or add it to your homescreen in iOS and Chrome beta. Being able to point someone to a URL to play a game, with no further requirement, and no limitation of distribution or questionable agreements to adheer to is a real game-changer. I love that the web fosters creativity and empowers the individual, despite the best efforts of various powers that be. We have work to do, but the future’s bright.

  • Wednesday, October 23, 2013 - 19:50
    Talpadk: 3D printing using Ninja Flex filament

    Yesterday I received some of the relatively new “Ninja Flex” filament sold by http://www.fennerdrives.com/ 

    As the internet doesn’t seem to overflow with print reviews / settings for it yet I decided to post some words about it.

    NinjaFlex Sapphire 1.75mm

    NinjaFlex Sapphire 1.75mm

    The Filament

    It is always difficult to measure a soft material but using my caliber I measured the diameter to be 1.75mm as it is supposed to.
    The filament also seems to be nice and round.

    I ordered the “sapphire” version of the filament, and it has a nice (mat) blue color  which turns glossy when printed.
    It is also slightly translucent when printed thinly.

    The filament is very flexible (I can tie a tight knot on it without it breaking)
    The filament is also elastic but not as much a a regular rubber band… perhaps 5-8 times harder if I should make a guess.

    The material is not known to me, but I strongly suspect it to be polyurethane (PUR) with a surface coating/treatment to make it less sticky.
    Fennerdrives already produces PUR belting  which have been used in 3D printing prior to this material appearing and due to the mat to glossy change.
    (Update: it has been confirmed that it is polyurethane)

    The Fennerdrives recommended settings are:

    Recommended extruder temperature: 210 – 225°C
    Recommended platform temperature: 30 – 40°C

    The filament isn’t exactly cheap I would say roughly 3x the cost of PLA/ABS including shipping compared to the cheap PLA/ABS I normally buy.
    Then again soft/specialty filaments doesn’t seem to come cheaply normally.
    (Actually a lot of the cost comes from the somewhat expensive USP shipping)

    Fennerdrives does ship both from the US and the UK, living in Denmark (inside the EU) this is a big plus for me.

    3D model for the rubber feet

    3D model for the rubber feet

    The test prints

    As I’m currently designing and building a tabletop CNC mill I thought that I might as well print some rubber feet for it.

    The print isn’t necessarily the simplest one to print due to the outwards sloping unsupported  walls.
    However the angle is quite close to vertical and wouldn’t normally be causing problems.

    The 3D model was created using FreeCAD which is my preferred open source CAD package.

    I used Slic3r for generating the G-code.

    And my printer is a RepRapPro Huxly which has a bowden extruder which might actually not be ideal for extruding a soft and springy filament.

    Print 1

    Was done using my regular PLA/ABS profile.

    I had to abort the very first attempt as the filament wasn’t printed continually.

    • I increased the extrude temperature from the low temp that felt right while manually extruding the filament
    • Reduced the speed using the M220 command
    • And upped the heat bed temperature to 85 deg C

    Much to my amazement the rubber foot actually printed sort of  okay.
    It was however sticking so hard to the “Kapton” tape that removing it actually pulled the tape off the print bed!

    Prints 1 though 4

    Prints 1 though 4

    Print 2

    I then tried to create a specific profile for printing the rubber filament.

    • Reduced the printing speeds to avoid having to scale them using the M220 command
    • Removed the “Kapton” tape as it had become wrinkled any way
    • Printed without having heat on the bare aluminium print bed.

    It printed with roughly the same quality at the first print but was very very easy to remove.

    Print 3

    I noticed that the hot end seemed quite “laggy” probably caused by the flexible nature of the filament and i therefore made some additional changes.

    • All print speeds were set to 15 mm/s to avoid having the extruder changing speed
    • Retract was disabled, again to keep a constant pressure in the hot end
    • “Skirt loops” was increased to 4, to give the hot end more time to build up a constant pressure.
    • Infill was reduced from 50% to 0% to see if the vibrations caused the surface defects
    • The hot bed was set to 40 deg C

    Just after starting the print I realized that setting infill to 0% would cause some parts to be printed in mid air with nothing supporting them from below.
    Out of curiosity I did however allow the print to continue.

    The printer managed to print the part despite the fact that is was ”unprintable”…
    Also the surface finish was very satisfying.

    Due to the 0% infill the part was slightly softer as was to be expected

    Print 4

    I don’t like printing the impossible as it may or may not succeed I made one small change

    •  I changed the infill back to 50%

    I’m pleased to report that the surface finish seems to be just as good as before.

    Printer settings

    Please keep in mind that  printer settings varies from printer to printer and that the one described here may not be optimal even for my own printer.

    The following list is semi sorted by what “I think is probably the most important settings”

    • No retract
    • Uniform print speed (of 15 mm/s)
    • Multi loop skrit (4 loops)
    • Hot end temperature 240 deg C
    • Print bed temperature 40 deg C
    • Travel speed 100 mm/s
    • Extrusion width 0.5 mm with a 0.5 mm nozzle
    • First layer 50% (might actually be a bad idea)
    • Layer height 0.3 mm

    Again while reading this keep in mind that I haven’t played very much with the temperatures.

    I had some undocumented failures after print 1 where the extruder/hot end seemed to jam and I haven’t dared reducing the temperature again as I needed/wanted some functional prints.
    The problems may however be related to too fast extrusions, filament loading and or the filament being deformed by the retracts.

    My prints was stringing slightly internally lowering the temp may be able to reduce this…

     

    Edits

    • It has been confirmed by the friendly customer support at Fennerdrives that the material is actually polyurethane.
    • Even without any heat on the hotbed it still sticks very very well to “Kapton”

  • Thursday, October 10, 2013 - 10:53
    off

    Pcb

    Nomenclature

    Circuit imprimé Pcb
    microcontrôleur ATTINY85V10PU IC1 Attiny85 2
    support pour CI DIL 8 IC1 8pinsocket 2
    oscillateur 8 MHz X1 X1
    condensateur 220 µF C2 Condo220
    condensateur 0,1 µF C1 Condo2
    2 x résistances 10 kOhm R3, R2 10k
    2 x résistances 1 kOhm R1, R5 R1
    2 x LED infra rouge type 333-A LED2, LED3 Ir 333 A 3
    2 x LED infra rouge type 333C/H0/L10 LED1, LED4 Ir333 C^H0^L10 3
    LED verte 3mmgreenled 2
    Transistor PNP PN2907 Q5 2907 T 2
    Transistors NPN PN2222 Q1, Q2, Q3, Q4 2222 2
    connecteur ISP 6 broches ISP 6pinbox T
    bouton poussoir S1 6mmswitch
    Porte-batterie 2 x AA borne + et - 2aabatterypack

    Principe de fonctionnement

    Pcb2

    Le principe de fonctionnement du OFF est basé sur le TV-B-GONE de Mitch Altman plus d'info ici => http://learn.adafruit.com/tv-b-gone-kit

    Le principe est le suivant : les codes infrarouges de toutes (ou presque...) les télévisions sont stockés dans le microcontrôleur ATTINY85. Quand on appuie sur le bouton poussoir, le montage émet ces codes grâces aux 4 diodes infrarouges. La portée est de 40 m environ et le temps d'émission de tous les codes stockés est de 1m30 environ.

    Ce montage est composé de 3 grands blocs fonctionnels :

    1. Électronique programmable :

    Dès que les montages électroniques doivent accomplir des taches complexes, il est souhaitable de mettre en œuvre un microcontrôleur (un tout peut ordinateur avec un processeur, de la mémoire vive et un minuscule espace de stockage). Dans notre cas, ce microcontrôleur est un ATTINY85. Il est associé à un oscillateur (appelé également quartz) de 8 MHz afin d’obtenir un fonctionnement stable et précis. Enfin le connecteur 6 broches permet de programmer ce microcontrôleur

    2. Amplification :

    Le microcontrôleur n’est pas capable d’alimenter directement les diodes infrarouges. Dans ce cas on utilise en électronique des transistors. Le montage OFF utilise 2 étages de ces composants : Un étage primaire (2N2907) commandé par le microcontrôleur et un étage secondaire (4 x 2N2222) commandé par l'étage primaire

    3. Émission infrarouge

    L'émission des codes infrarouges est assuré par 4 LEDs infrarouges afin d’obtenir une grande portée.

    Guide de montage

    Composant coté OFF :

    Souder les résistances R2, R3 et R5
    Attention ! NE PAS SOUDER R1 AVANT D’AVOIR FAIT LA PROGRAMMATION DE L’ATTINY85 !!!!

    Souder le support de circuit intégré ; il y a une encoche sur ce support qui doit être aligné avec le dessin correspondant sur le circuit imprimé.

    Souder le condensateur C1

    Souder l'oscillateur X1

    Souder le bouton S1

    Souder la LED verte : la patte la plus longue doit être insérée dans le trou marqué d’un “+”

    Souder les LEDs IR (LED 1, LED 2, LED 3 et LED 4)
    Il faut que la patte la plus longue soit soudée à plat sur la pastille marqué +
    La patte la plus courte doit être soudée sur la pastille marquée “LED XX” (de l’autre coté…)

    Souder le transistor Q5 : il faut légèrement écarter les pattes extérieures pour que le composant entre en place.

    Souder les transistors Q1, Q2, Q3, Q4 :
    Il faut légèrement plier les pattes centrales de ces composants pour bien les faire entrer dans leurs emplacements…

    Souder le connecteur 6 broches : il y a une encoche sur le connecteur qui doit être aligné avec celle du dessin correspondant sur le circuit imprimé.

    Souder le condensateur C2 : attention ce composant est polarisé, il faut que la patte qui est repérée par une bande “-” soit dans le trou qui n’est pas marqué d’un “+” :-)

    Programmer le microcontrôleur

    les commandes pour AVRDUDE avec comme programmeur un arduino + ARDUINO as ISP sont : 

    avrdude -P COM10 -b 19200 -c avrisp -p attiny85 -U lfuse:w:0xfe:m -U hfuse:w:0xdf:m -U efuse:w:0xff:m
    avrdude -P COM10 -b 19200 -c avrisp -p attiny85 -U flash:w:tvbgone.hex

    Le fichier hex peut être trouvé ici => http://learn.adafruit.com/system/assets/assets/000/010/188/original/firmwarev12.zip

    Finir de souder

    Souder la résistance R1

    Tester

  • Thursday, October 10, 2013 - 10:52
    booster

    Pcb

    Le montage Booster est basé sur le design du joule thief.

    Nomenclature

    Circuit imprimé                                       Pcb
    Transistor BC337 T1 To92 2
    Résistance 1 kOhm R1 R1
    Bouton poussoir 6mmswitch
    Ferrite Ferrite
    LED blanche LED Led3
    1m de fil orange
    1m de fil gris
    1 support de pile Porte Pile

    Principe

    Le principe est le suivant :

    Schema2

    Pour permettre à la LED de s’allumer avec une bonne intensité, de l’énergie est accumulée dans la bobine (constituée par la ferrite et les fils de couleur). Une fois que la bobine a accumulé assez d’énergie, le couple LED + transistor décharge l’énergie stockée et la LED transforme cette énergie en lumière. Une fois ce cycle terminé, la bobine se recharge en énergie, recommençant ainsi un nouveau cycle. Ce fonctionnement est tellement rapide (plus de 100 fois par seconde) qu’il est invisible pour l’œil humain…

    Du coup la led blanche qui fonctionne avec un tension de 3,6 V classiquement peut être alimenté avec une pile de 1,5 V voir une pile 1,5 décharge (jusqu’à 0,3 V environ)

    Guide de montage

    1. Bobinage de la ferrite :

    Le but est de réaliser un bobinage de 20 spires (ou tours) pour chaque couleur de fil, il faut que le debut d'une bobine soit commun avec la fin de l'autre bibine (comme repéré par les point sur le schéma)

    2. Montage et soudure des composants du coté “Booster”: 

    a. le petit bouton poussoir, Il se situe sous le logo Tetalab
    b. la LED blanche : la patte la plus longue va dans le trou marqué d’un “+”. Ne pas enfoncer complètement la LED avant de la souder, il faut pouvoir tordre ses pattes pour l’orienter dans l’axe du montage

    3. Montage et soudure des composants du coté “Novela 2013”

    a. Le transistor : il faut légèrement plier la patte centrale de ce composant pour bien le faire entrer dans son emplacement.
    b. La résistance : dans le sens qu'il te plaira !
    c. Le support de pile : attention à la polarité

  • Tuesday, September 24, 2013 - 17:13
    Xiangfu Liu: Install Xilinx(ISE 14.6) Platform Cable USB under Ubuntu 13.04 64bit

    Let’s make is simple
    I am using the Xilinx ISE 14.6. it will failed install the cable driver. we just ignore that error and doing those:

    sudo apt-get install fxload gitk git-gui build-essential libc6-dev-i386 ia32-libs
    cd /home/Xilinx #I like install them under /home
    sudo git clone git://git.zerfleddert.de/usb-driver
    cd usb-driver/
    sudo make lib32
    ./setup_pcusb /opt/Xilinx/13.2/ISE_DS/ISE/
    cd /lib/x86_64-linux-gnu/ && sudo ln -s libusb-0.1.so.4 libusb.so

    Links may help:

    1. http://www.george-smart.co.uk/wiki/Xilinx_JTAG_Linux#Download_the_driver_source
    2. http://forums.xilinx.com/t5/Installation-and-Licensing/ISE-11-2-Impact-can-t-find-USB-II-cable-SLED-11-Linux-64-bit/m-p/42064?query.id=386680#M467
  • Monday, September 23, 2013 - 12:27
    Xiangfu Liu: Btctele.com is improving

    我们在不断的提高 Btctelecom 的用户体验。从主页开始。这是一个候选的界面:https://dev.btctele.com/index2.php,如果大家有任何意见和建议。请在这里留言。

    Happy Btc + Telecom

  • Wednesday, September 18, 2013 - 12:02
    Heated Piezo for Jetting Wax (and other stuff)

    I'd just like to draw everyone's attention to this really nice RepRap heated (ink)jet head by Mike Alden, shown here printing wax.

    Details are on the RepRap Wiki here.

Pages