Un petit article pour illustrer le programmateur évoqué précédemment. C'est un Arduino Nano qui sert de programmateur, la connexion avec la puce se fait soit pour une puce seule via le socket (malheureusement je n'ai pas trouvé de socket au format SOIC14 de l'ATTiny841 mais uniquement au format SOIC16, il faut donc veillez à plaquer la puce en haut en laissant libre les deux connexions inférieures du socket
Dans le cas d'une programmation in-circuit, un port au format 2x3 (pas de 2.54) permet de se connecter au circuit.
Les deux configurations ont été testées et il ne reste plus qu'à usiner le capot pour encapsuler le tout (j'ai accès à une petite fraiseuse). Le boitier d'origine vient de chez Farnell, une belle trouvaille pour les petits bricolages, environ 2€50 pour le circuit le boitier et le capot (le tout visible sur la première photo).
Après quelques mois d'absence me revoilà sur le pont. Le projet n'est pas au point mort et voici les principaux fait:
Coté micro contrôleur tout est ok et validé, gestion des deux boutons plus et moins pour changer de mode, monitoring de la tension batterie et de la température avec des modes de repli prévus en cas de dépassement des seuils, clignotement lors des franchissement des seuils de tension batterie à la baisse pour informer de l'état des batteries, ... Tout est encore à peaufiner, notamment l'ajustement des seuils de tension et de température ainsi que les puissances d'éclairage mais on entre là dans le détail.
Je me suis en parallèle lancé dans la fabrication d'un petit programmateur pour mes micro- contrôleurs ATTiny841. Il s'agit en fait juste d'empaqueter mon montage existant sur une breadboard dans un boitier bien ficelé mais cela sera nécessaire lorsque je voudrais reprogrammer une puce déjà soudée sur le PCB via le connecteur de programmation.
Le principal problème vient actuellement du circuit de puissance et du driver A6211. Le fonctionnement sur un PCB fabriqué sur mesure a été un échec, peut-être attribuable à de la bidouille pour rattraper quelques erreurs de conception. J'ai remonté un circuit complet non-cms sur une plaque de prototypage à bande et le résultat est fonctionnel mais avec du scintillement. Je pense donc refaire faire un pcb cms débuggé pour statuer sur ce point.
La loi reliant la tension à l'énergie disponible dans un accu lithium n'est pas linéaire, aussi il est nécessaire d'étudier la loi de décharge pour régler les seuils finement. L'objectif étant de découper la plage d'utilisation par tranche de 25% d'autonomie, plus une dernière tranche "sécurité" sur les dix derniers pourcents de la batterie.
Je suis donc parti d'une courbe de décharge énergie-tension, trouvé sur un forum :
Elle présente plusieurs allures suivant le courant de décharge. A pleine puissance la lampe consomme environ 20W, soit 5W par accu (je vise un montage a quatre accus en 2S2P). En considérant la tension la plus basse utilisée de 3A cela représente un courant d'environ 1.7A, sans tenir compte des rendements. Disons 2A pour être large. Sauf que la majeure partie de l'utilisation se fera à puissance bien moindre, j'ai donc retenu la loi de décharge à 1A pour la suite (et je suis probablement au dessus de la réalité).
En repartant de la décharge totale (à 3V pour ne pas endommager les accus) j'ai donc reconstitué le tableau suivant, avec les seuils qui m'intéressent.
Deux seuils sont définis, le premier bride la lampe aux modes classiques 1 à 3, tandis que le second - réglé plus haut - la bride au mode de sécurité 1.
Niveau de batterie
Protection de l'accu
De la même maniere deux seuil sont définis pour surveiller la batterie. Un premier seuil bride la lampe au mode de sécurité 1 afin de privilégié l'autonomie sur le restant de batterie, tandis de que second, réglé à 3V par élément, interdit l'allumage pour protéger les accus.
Remarque : la lecture de la tension batterie m'a donné du fil à retordre, portant un simple analogRead() doit normalement retourner un entier compris entre 0 et 1023, proportionel à la tension mesurée (sur une échelle de 0 à la tension de référence, par défaut la tension d'alimentation du µC). Le fonctionnement était totalement ératique et après de nombreux essais j'ai découvert que pour une entrée analogique il fallait utiliser le numéro d'entrée analogique et pas le numéro d'entrée général. Pour être clair j'utilise la pin 10 pour mesurer la tension, celle-ci est repéré "7/A3" sur le pinout ATTinyCore et il faut exécuter un analogRead(A3) pour faire la mesure, un analogRead(7) lira l'entrée A7, qui pour moi était une sortie PWM pour le spot, d'où le fonctionnement foireux !
Information de l'utilisateur
Plusieurs seuils intermédiaires sont également définis, à chaque franchissement d'un seuil à la décharge la lampe émet plusieurs clignottement alternés sur les deux optiques suivant le niveau de décharge. Ces cligottements sont également émis au démarrage de la lampe pour informer sur l'état de charge initial, mais comme ils suivent les clignottements de mise sous tension c'est encore assez peu intuitif, je vais probablement modifier ceci.
EEPROM
Pour rappel, l'EEPROM est une mémoire non volatile qui va permettre de stocker les valeurs des intensité sur chaque mode. Celle-ci sont conservées à la mise hors tension du µC, c'est un point indispensable pour avoir des modes réglables en live.
.La librairie dédiée a fonctionnée dès le premier essai, j'ai rédigé un cours programme qui écrit juste les valeurs dans l'EEPROM à l'aide d'une boucle for sur le nombre de modes, puis j'ai remplacé l'affectation "en dur" des valeurs de mode dans mon programme principal par une boucle de lecture dans l'EEPROM.
Le mode "programmation" reste à écrire mais désormais toute "l'infrastructure" est prête.
Je vais probablement lancer une pré-série de circuit pour faire un vrai test en puissance nominale, pour l'instant mon montage sur breadboard ne permet pas le passage de l'intensité nominale et de plus j'ai quelques faux contacts. Je travaille sous EAGLE pour dessiner le PCB qui est quasiment prêt et devrait partir en fab prochainement.
Passé toutes ces étapes de validation, j'ai décidé de me lancer à l'écriture du premier "vrai" code implanté sur le µC définitif.
Afin de ne pas m'encombrer de deux drivers et de tous les composants qui vont avec, j'ai juste implanté une led blanche (5mm classique, drivée en 20mA par une résistance ad-hoc) sur chaque sortie PWM. L’œil lissant naturellement la haute fréquence de clignotement cela permet un développement facilité. On se rend toutefois moins compte des variations de puissance qu'avec une led de puissance.
Je n'ai pas encore eu le temps de faire un joli schéma mais voila les grandes lignes:
Mise sous tension
Comme précisé précédemment le µC fonctionne dès sa mise sous tension. Afin de détecter le bon démarrage de celui-ci la lampe émet un rapide clignotement alterné sur les deux optiques.
Démarrage
Le démarrage se fait par un appui prolongé sur le bouton +, la lampe démarre ainsi en mode 1, appelé mode de sécurité avec 10% sur le wide et spot éteint. Cela permet d'éviter d'éblouir tout le dortoir à la mise sous tension quand on cherche un truc au réveil.
Gestion des modes classiques 1 à 3
La navigation se fait à l'aide d'appuis bref sur les boutons + et -
Mode spéciaux 4 & 5
Le passage en mode 4 se fait par double clic sur le bouton - depuis un mode classique, tandis que le passage en mode 5 se fait par double clic sur le bouton +. Au passage en mode spécial 4 ou 5, le mode classique précédent est mémorisé, de manière à retomber ensuite dessus, la sortie d'un mode spécial se fait par appui bref sur le bouton + ou le -.
Mode spécial 6
Le mode spécial 6 se comporte de manière similaire, il s'atteint depuis un mode normal par appui prolongé sur le bouton + et se quitte par un appui bref sur + ou - pour retourner au précédent mode.
Extinction
L'extinction se fait par un appui prolongé sur le bouton -, à partir de n'importe quel mode, spécial ou normal, et même en mode programmation (qui n'existe par encore, mais la structure du programme privilégie toujours l'extinction. Un moyen sûr de se retrouvé si on est perdu).
Perspectives
L'ensemble du fonctionnement décrit ci-dessus est désormais codé et fonctionnel, les points suivant doivent encore faire l'objet d'un développement pour répondre au cahier des charges initial:
Gestion de la sécurité
Le programme actuel a été prédisposé pour gérer facilement les deux critères de sécurité, à savoir la tension de batterie et la température au niveau du PCB, cependant ni la mesure de tension ni la lecture de tension n'ont actuellement été implanté. J'avais rencontré quelques soucis pour la mesure de tension sur l'Arduino Nano, principalement lié à mon inexpérience de ce langage mais je disposais de la liaison par port USB pour déboguer facilement (en transmettant la tension ou la température par l'USB via des commandes série et le moniteur série de l'IDE Arduino). Dans le cas de l'ATTiny841 je pase par un programmateur et je n'ai donc pas de liaison USB directe avec le PC, le débogage va donc se faire en quasi aveugle, avec uniquement des leds sur les sorties inutilisées.
La mesure de tension via le bus 1-wire doit également être testée sur cet ATTiny841 (Uniquement validé sur Arduino Nano).
Mode programmation
J'envisage un mode de programmation permettant de régler les niveaux en utilisation. Pour cela j'envisage la stratégie suivante:
Passage en mode programmation par appui prolongé long (supérieur à 3 secondes) sur le bouton +
Choix de l'optique à régler : double-clic sur + pour le wide, - pour le spot
Réglage par palier de 5% à l'aide d'appuis brefs sur + ou -
Sortie du mode programmation par appui long prolongé sur bouton -
Un point essentiel reste à lever, la lecture et écriture des niveaux dans l'EEPROM du µC afin de conserver ces réglages à la mise hors tension.
Initialement une mesure de température était prévue sur ce projet, en effet les leds ainsi que le driver A6211 sont susceptible de dissiper pas mal de puissance et ainsi de générer pas mal d'échauffement.
Nombre de frontales du commerce sont d'ailleurs d'une telle sécurité qui limite la durée d'utilisation à pleine puissance (est ce juste une temporisation ou une vraie mesure de température ?).
Je prévoyais initialement de réaliser la mesure au moyen d'un capteur DS18B20 fonctionnant sur bus 1-wire. Le bus 1-wire est un bus numérique permettant de brancher plusieurs capteurs sur la même entrée numérique du µC ce qui est très utile (pas dans mon cas car je n'en ai qu'un !).
Par ailleurs certains µC ATMEL comportent une sonde de température interne, c'est notamment le cas de l'ATMega328 qui équipe les Arduino Nano et aussi du ATTiny841. Cette mesure est franchement imprécise, dépendante de la charge du processeur mais je m'étais fait à l'idée que pour une simple sécurité par détection de seuil cela suffirait.
Suite à la remarque d'un lecteur je me suis re-penché sur le DS18B20. Ayant le capteur à disposition je l'ai interfacé sur mon Arduino Nano de développement.
Deux bibliothèques sont à installer, "1-wire" et "DallasTemperature"; Dallas est le fabriquant du capteur.
Le codage est ainsi très simple, trois instructions suffisent à réaliser la mesure:
La transmission est faite via le port série au PC et la température monte avec le doigt sur le capteur, tout va bien je ne suis pas en hypothermie !
Le capteur est donc facile à mettre en oeuvre et permet une vrais mesure, j'y réfléchirais lors de l'implantation sur le PCB si l'encombrement est raisonnable.
Quoiqu'il en soit le température sera suivie pour éviter tout endommagement consécutif à une surchauffe.
Comme précisé en introduction, l'objectif à terme est de remplacer l'encombrant Arduino Nano par une puce du même fabriquant de référence ATTiny841. Cette puce présente toutes les caractéristiques nécessaires pour un encombrement minimal.
Programmation du ATTiny841
Sur la photo ci-dessus on voit bien la différence d'encombrement; à gauche un Arduino Nano et à droite le µC ATTiny841 soudé sur un petit bout de circuit imprimé.
Le montage ci-dessus doit servir à programmer le ATTiny841. En effet, après avoir déporté tout le superflu (prise USB, régulateur de tension, contrôleur série, ...), il faut néanmoins assurer les fonctions !
Le Arduino Nano est donc utilisé comme programmateur et permet d'assurer l'interface entre le PC et l'ATTiny841.
Programmation du Nano en programmateur
Il est nécessaire de charger le programme "programmateur" dans l'Arduino Nano, celui-ci est fourni dans l'IDE (environnement de développement Arduino, en téléchargement sur le site officiel) standard (Fichier -> Exemples -> ArduinoISP). Ouvrir l'exemple et téléverser le programme.
A ce stade le Nano est programmé pour assurer l'interface.
Prérequis logiciel
Coté logiciel il est nécessaire d'installer un noyau permettant la gestion de l'ATTiny841 à l'IDE standard. Pour cela deux étapes:
Ajouter cette adresse " http://drazzy.com/package_drazzy.com_index.json " dans Fichier -> Préférences -> "Additional oards Manager URLs"
Ajouter le noyau "ATTinyCore" à l'aide du Board Manager (Outils->Type de carte->Boards Manager)
Note : Il est recommandé d'utiliser l'IDE 1.6.5
Câblage
En plus de l'alimentation (masse et 5v), quatre liaisons sont à câbler, tout est détaillé dans les commentaires du programme ArduinoISP que l'on complète avec le pinout du ATTiny841:
Reset : D10 du nano sur pin 4 du ATTiny841;
MOSI : D11 du Nano sur pin 7 du ATTiny841;
MISO : D12 du Nano sur pin 8 du ATTiny841;
SCK : D13 du Nano sur pin 9 du ATTiny841.
Le programme génère également trois signaux qu'il peut être intéressant de visualiser à l'aide de trois leds + résistances pour aider au diagnostic en cas d'erreur.
A ce stade il est possible d'écrire le "système d'exploitation" Arduino sur l'ATTiny841 qui est pour l'instant vierge de tout bit.
Cela se fait en passant par Outils -> Graver la séquence d'initialisation après avoir réglé la bonne carte et sa fréquence.
A ce stade je rencontrait une erreur retournée par l'IDE : "avrdude: stk500_getsync(): not in sync: resp=0x15".
Une rapide recherche plus tard, le problème vient du fait que le Nano est sujet à un auto-reset dans ces conditions, un petit condensateur entre la masse et l'entrée reset permet de régler le problème. On le voit sur la photo du dessus (la petite boule jaune en bas à droite du Nano). Tout les Nano n'y seront pas sujet, mais c'est le cas de ma copie chinoise. Problème en tout cas vite résolu avec ce condo.
Si cette étape réussie on peut désormais passer à la programmation de l'ATTiny841 à proprement parler.
Programmation du ATTiny841
Je ne suis pas allé bien loin, j'ai juste branché une led sur la sortie 0 (pin 2) avec une résistance pour faire un blink test. Attention, il est nécessaire d'utiliser "Téléverser avec un programmateur" et non "Téléverser" pour écrire le programme sur l'ATTiny841.
J'ai encore eu un petit soucis à ce stade, mon installation de ATTinycore était peut être incomplète. Quoi qu'il en soit j'ai du rajouter au fichier avrdude.conf (qui définit toute les cartes programmables par l'IDE, situé quelque part dans le répertoire d'installation de l'IDE) les infos trouvables ici (à copier/coller en fin de fichier). Lien alternatif
Et après téléversement ... tada, ça clignote (la led verte au premier plan, l'autre étant le diagnostic du Nano)
Prochaine étape, connecter le driver A6211 et les boutons à l'ATTiny841 pour reproduire l'exemple précédent.
Le fonctionnement du Arduino est principalement monotâche et séquentiel, on ne peut donc par exemple pas imaginer une tâche de fond qui surveille le niveau de batterie (ou alors au moyen d'une interruption mais il faudrait un comparateur externe et une référence de tension car l’interruption fonctionne sur entrée numérique, en général sur des fronts montants ou descendants).
Le fonctionnement est donc basé sur une boucle permanente qui s'exécute après une fonction setup() qui s'exécute une seule fois à la mise sous tension. En générale on initialise les variables et on déclare les entrées/sorties dans cette phase.
Dans notre cas on lira également les niveaux de puissance stockés dans la mémoire EEPROM (une mémoire non volatile) du µC. En effet, si l'on veux pouvoir modifier les niveau de puissance en direct ils ne peuvent pas être stockés dans le programme sinon ils seraient réinitialisés à chaque coupure d'alimentation.
Deux variables de types int (integer : nombre entier) seront principalement utilisées.
Variable mode
La première définira le mode d'éclairage en cours. Deux tableaux lui seront associés pour les leds spot et wide. Ils contiennent les puissances pour chaque mode et c'est eux que l'on sauvegardera dans l'EEPROM. Le mode 0 correspondra à l'extinction totale, c'est dans ce mode que l'on démarrera à la mise sous tension. Il faut bien comprendre que le µC fonctionne dès la mise sous-tension pour scruter les actions sur les boutons + et -. La lampe branchée et éteinte consomme donc légèrement mais cette consommation reste epsilonesque.
On aura donc deux tableaux de type:
spotPower = [0 n n ... n] et widePower = [0 n n ... n]
avec un nombre d'éléments égal au nombre de mode (y compris l'arrêt total donc). Cette variable mode sera mise à jour à chaque tour de la boucle principale en fonction des appuis sur les boutons + et -, et de la mesure batterie. Voila les modes envisagés dans un premier temps:
Mode
widePower
spotPower
Commentaire
0
0%
0%
Lampe éteinte
1
10%
0%
Éclairage de secours
2
25%
15%
Mode progression 1
3
40%
25%
Mode progression 2
4
80%
80%
Mode grand volume
5
30%
100%
Mode longue portée
6
100%
100%
Mode "qui a la plus longue"
Les modes classiques sont les 1 à 4. 5 et 6 seront uniquement accessibles sur des combinaisons "exotiques" type double-click. Je n'ai pas trop d'expérience de l'utilisation de double faisceau donc j'ajusterais au besoin. Il est à noter que si les intensités seront programmables en live sur la lampe, l'ajustement du nombre de mode et de la façon de naviguer entre eux nécessite le branchement au PC et la modification de quelques lignes de code.
Variable niveau de batterie
La seconde variable définie le niveau de batterie, elle aussi codée sur un int avec à priori les valeurs suivantes:
Valeur inférieure
Valeur supérieure
Niveau
<3v
0
3v
10%
1
10%
25%
2
25%
50%
3
50%
75%
4
75%
100%
5
Elle sera également mise à jour à chaque tour de boucle, au début de la boucle puisqu'en cas de niveau batterie 0 la suite de la boucle n'a pas lieu de s'exécuter.
Le niveau 0 interdit l'allumage, le niveau 1 le limite au mode 1.
Variable mode programmation
Une troisième variable d'état est l'état du mode programmation des niveaux. Il s'agit ici d'un booléen (vrai ou faux) initialisé à faux au début du programme. Je verrais par la suite si la possibilité de potarder les niveaux en live présente un intérêt vis-à-vis de la complexité de programmation.
Une petite vidéo avant de partir en weekend, j'ai utilisé un bout de script trouvé sur internet ici (merci à la communauté Arduino !) qui permet la gestion de 4 actions par bouton (click, double click, appui long & appui très long).
Après modification pour qu'il fonctionne avec deux boutons j'obtient le résultat suivant:
La vidéo ne rend pas très bien les variations de lumière car le capteur s'adapte automatiquement mais il y a bien variation ! Pour l'instant je ne gère que les fonctions click plus et click moins sur 4 niveaux d'intensité (0, 10%, 30% et full) mais la programmation est assez aisée et toute les combinaisons devraient permettre une utilisation agréable.
Premier bout de code sous Arduino, pas bien compliqué juste une boucle qui fait varier le PWM de 0 à 100% (toujours bridé à 1A) mais ça fait plaisir de le voir fonctionner !
Après avoir reçu les quelques composants nécessaires au fonctionnement du driver j'ai pu procéder à un premier essai.
Le montage est alimenté par une source continue en 7.2V, soit la tension nominale de deux éléments lithium en série.
Une diode protège l'inversion de polarité et deux condensateurs (un gros électrolytique et un plus petit céramique) lissent cette alimentation. Ce filtrage sera conservé sur la lampe finale bien que l'alimentation soit beaucoup plus propre que mon alim chinoise à 2€75 ! néanmoins le driver est a découpage et peut de ce fait pourrir pas mal l'environnement soit par réjection dans son alim soit par rayonnement sur les pistes environnantes.
Un petit régulateur pour créer du 3.3V est également implanté, ce n'est pas nécessaire à ce stade mais cela me permet de vérifier que cette tension qui sera la tension de commande du µC est suffisante pour valider l'entrée PWM du driver.
Schéma de l'alimentation
Le montage autour du driver est quasiment le même que celui proposé dans la datasheet. J'ai cependant modifié la résistance de mesure afin de limiter le courant à 1A au lieu de 3A, en effet j'utilise une breadboard et de petits fils de routage et je n'ai pas envie de tester leur tenue sous 3A !
Régulateur A6211
La LED utilisé est une XM-L T6 4C. Les micros contrôleurs visible sur la platine de câblage sont actuellement inutilisés. Il y a a gauche un Arduino Nano qui servira au développement et a droite du driver un ATTiny841 qui prendra place dans la version finale.
Photo du montage
Et la photo qui fait plaisir :
Lumière !
Prochaines étapes:
Pilotage par le Arduino Nano
La prochaine étape consistera à piloter l'entrée PWM du driver actuellement fixé à 100% pour moduler l'éclairage. L'objectif est de me faire la main avec le code Arduino que je ne connais pas du tout et je me bornerais surement à faire une gradation par palier de 10% toute les secondes en boucle.
Gestion des boutons poussoir
Toujours à propos de la programmation, la suite consistera à gérer les deux boutons poussoir du rototo, click simple, doucle click et appui prolongé au programme
Démarrage du ATTiny841
Ce µC doit tout d'abord recevoir un bootloader Arduino pour être utilisable, cela se fait en utilisant l'Arduino Nano à ma disposition comme programmateur ISP avant d'écrire le programme final qu'il faudra d'ici là développer.
Clairement, l'intérêt pour le bricolage est aussi grand que celui pour le produit fini, cela se ressentira surement dans la suite !
La lampe en question sera constituée de deux optiques, cela semble le bon compromis dans les différentes lectures que j'ai pu avoir:
Un éclairage large ("wide") utile en progression;
Un éclairage focalisé ("spot") appréciable dans les grandes salles.
Pour avoir eu quelques frontales, j'apprécie les couleurs chaudes et je privilégierais ceci dans le choix. Une XM-L T6 en variante 4C (blanc chaud) semble sympathique pour le spot, l'optique est à définir; tandis qu'une triple XP-G2 est ciblée pour le wide. La formule wide sans aucune optique semble non satisfaisante pour certains, aussi une optique extra-plate type Ledil C11624_GT3-WW est prévu dans les volumes. Suivant les essais on pourra la supprimer.
L'objectif est d'avoir un bon rendement, aussi la plupart des projets basés sur des drivers linéaires me chagrinent. En effet, dans le cas d'un driver linéaire, la différence de tension entre l'alimentation (le pack d'accu) et la charge (la ou les led) part en chaleur. Pas très utile pour s'éclairer et pas bon non plus pour la durée de vie de l'électronique.
Un driver à découpage ("buck" en anglais) présente de ce point de vue un très bon intérêt (au moins théorique !). Pour les plus intéressés l'article wikipedia est bien gaulé.
Le driver identifié est un Allegro A6211. C'est donc un driver à découpage qui permet de fournir jusqu'à 3A (courant classique d'une LED cree XM-L T6 à pleine puissance) . Il permet de moduler le courant via une entrée en modulation de largeur d'impulsion ou PWM.
Le corollaire de cette entrée est qu'il faut générer ce signal pour les deux drivers. Ayant récemment bricolé avec un petit micro-contrôleur (portant par la suite le sobriquet de µC) Arduino j'ai décidé d'en utiliser dans ce projet. Le plus compact des Arduino est le Nano mais il est malgré tout assez encombrant pour notre usage. Surtout quand on regarde ce qui prend de la place sur la carte et qui n'est pas indispensable:
La prise USB permettant la programmation du µC
Le contrôleur USB/ISP, idem
Le µC ATMega328 en lui même, totalement démesuré par rapport à notre application
L'idée est donc d'utiliser un autre µC du même fabriquant (ATMEL) plus adapté à notre besoin. Le ATTiny841 répond parfaitement à ce cahier des charges. La prise USB et le contrôleur de programmation seront eux déportés en dehors de la carte, inutile de les balader sous terre !
La commande des différents modes d'éclairage (encore à définir mais intégralement paramétrables par software, c'est l'intérêt du µC) se fera par deux boutons + et - implantés sur la carte et actionnés par un palonnier, suivant le principe du fameux rototo.
On gérera sur ces boutons le click, le double click et l'appui prolongé. Tout cela permettra un nombre de modes assez conséquent et je l'espère assez intuitif.
Ce blog a pour objet de présenter la conception et la réalisation d'une lampe frontale dédiée à de la spéléologie. La spéléo c'est ma nouvelle marotte et un bon éclairage sous terre est bien entendu indispensable.
De nombreux projets individuels ou collaboratifs sont disponibles sur le web et l'idée de développer le mien suivant un cahier des charges adapté a germé. Ces différents projets sont bien sur une source d'inspiration pour moi. On pourra relever: http://souterweb.free.fr/boitaoutils/themeeclairage.htm http://speleled.over-blog.com/
ou encore http://morgan-speleo.over-blog.com/ qui présente un projet assez similaire à l'idée que j'ai en tête, idée que je détaillerais dans le prochain article.
