It’s been a year

JeeLabs - Mon, 06/10/2014 - 12:10

It’s been a year since the last post on this weblog. A year is a long time. The world has changed in many ways, and technology has advanced in just as many, but completely different ways. I have also progressed, in the sense that I’ve been exploring and learning about lots of new things in the world of electronics, software, and physical computing.

Some things have solidified, such as my main laptop, which is still the same as three years ago (an 11″ MBA), because the shiny big fast one went to my daughter Myra, who has a far bigger need for that sort of hardware – for her photography and video work. Another solidifying trend has been my touch typing, which is now at the point where I do so 95% of the time (editing code still makes me go for the hunt-and-peck mode, occasionally).

Other things have stagnated, such as most notably the work on writing The Jee Book. There are pages and pages with words and images on my laptop, but I don’t like them one bit, and will not publish these as it is today. There is not enough direction, passion, focus, and fun in those draft pages. It would diminish the excitement and joy this deserves.

I’ve given a few presentations and workshops in the past year, but nothing of substance has come out of it all with respect to the JeeLabs site(s). My goal for this month is to get back into higher gear in public. Writing has always been very fulfilling and its own reward for me – I’m looking forward to finding my voice on the web again, in some form or other.

Now the hard part… I could use your help.

A year in solitary confinement (just kidding!) has made it harder for me to understand what you’d like most from JeeLabs. Just to get this clear: I don’t think I can restart the daily schedule of the weblog, as it was up to a year ago. This isn’t only about the effort and energy involved, or the lack of material, but the fact that the resulting stream-of-conscience website that it leads to is a bit hard to navigate through. Also, the resulting collection of articles is really not very practical as a resource – there are too many bits and pieces of information in there which are outdated and at times even misleading by now.

What sort of topics would you wish to see covered? My own interests still tend to gravitate towards long-lasting autonomous wireless sensor nodes. What frequency and size of posts / articles do you like? Should the topics be spread out broadly, or rather focus on some very specific problems? How simple or deep-diving should the information be? Do you want more science and maths, or rather some detailed construction plans? Do you prefer a personal and conversational style (such as this), or more a factual information source?

As always, I will make my own independent choices, but I promise to listen carefully and respectfully to each and every comment you send my way (email to

Categories: Community Blog posts

Exposing Raspberry Pi’s network setting files to /boot so that they are visible on a PC

mharizanov - Wed, 24/09/2014 - 21:25

I needed to clone my current Raspberry Pi SD card image to use for another headless project (on another network), but then realized the network settings were my home ones. I had access to a PC only, so could not (easily) modify the settings for that other Pi to connect to the other network. To avoid that for the future, I’ll just move the network setting files to /boot (which is accessible on a PC) and make a Symbolic Link to these in the original location:

cd /etc/network sudo cp interfaces /boot/interfaces sudo mv interfaces interfaces.bak sudo ln -s /boot/interfaces interfaces cd /etc/wpa_supplicant/ sudo cp wpa_supplicant.conf /boot/wpa_supplicant.conf sudo mv wpa_supplicant.conf wpa_supplicant.conf.bak sudo ln -s /boot/wpa_supplicant.conf wpa_supplicant.conf

With this change applied, I’ll be able to plug in the SD card into a PC, modify the network settings and get the Pi connected in no time. Security-wise this is probably not a good idea, but I am taking the risk anyway. (656)

Categories: Community Blog posts

MQTT topic tree structure improvements

mharizanov - Fri, 19/09/2014 - 07:03

I’ve been unhappy with my old MQTT topic tree structure for quite some time now and did some thinking/research on how to improve it. Google pointed me to Tinkerman’s article on similar subject, and I started planning on improvements.

I will repeat a quote I used in my last post “If you can’t measure it, you can’t improve it”, only this time re-phrase it s “If you can’t visualise it, you can’t improve it”. Yes, my first effort would be to visualise my MQTT topic tree and the rest should be fairly easy.

Ben Hardill  had done some excellent work on the subject and his D3 MQTT topic tree visualizer is exactly what I needed. It was quite tricky to get it to work. I wanted to use the new Mosquitto MQTT support for websockets, so I had to upgrade to that new version. Websocket support must be explicitly enabled when building Mosquitto, thankfully Jeremy Gooch has created *excellent* instructions for doing that, I could not have done it without these.

Finally, I had to modify Ben’s mqttws31.js file to work with Mosquitto 1.4, my fixed version is on Github.

With the visualization working, I did about 1003 iterations to get to the following structure, still lots of nodes to add and in rough shape:


The root contains three folders to group my connected things into the categories “places”, “cloud” and “people”. I plan to add more categories there, for example “objects” to track vehicles.

The “places” will contain places and properties that are part of my IoT home automation system, starting with “our place”:


“Our place” is a house with garden, so I broke this in two: the “house” and “outside”. The “house” is branched into three sub-categories: “common”,”first floor” and “second floor”. The “common” section will contain common components that can’t be grouped otherwise. The “outside” will obviously group anything in the garden like outside conditions,greenhouse, front door etc (all WIP)

The “Common” category currently has these leaf nodes:



The “raspberry pi” branch expanded:


The “rfm2pi” leaf represents the the rfm2pi board that handles the wireless transmissions, it has incoming and outgoing leafs. The “out” topic is used to transmit, I use it to send time packets every 5 minutes for example and also to send control packets to remote nodes. Node-RED subscribes to the different NodeID leafs in the “in” topic to handle the raw packets of data and further process it, feeding the other branches with processed data.

The other leafs in this branch are:


The “power monitor” node data is provided by my sensing shield project, still working nicely.

The “solar” node data is provided by the hot water tank controller I described here, the firmware has changed notably from then, but the hardware is same. Note that it is a bi-directional node with “in” and “out” leafs because it can control the heater element in the water tank as well should the sunshine be less than needed to heat up the water.

The “doorbell” node is fed by my IoT doorbell project.

The “security system” node is fed by my home security system interface project.

The “heat pump” node is still work in progress, I plan to have both “in” and “out” sub-topics as it can both control and provide information about the heat pump state. Using my Daikin controller project there.


The “first floor” branch has the following structure:



My friend Glyn Hudson of OpenEnergyMonitor has sent me an EmonGLCD unit as a gift, this is the data provider for temperature in the “kitchen” node.

I have a fire sensor alarm project that is feeding the “fire alarm” node in the “kitchen” branch.

The house’s door, window and PIR states are fed by my security system interface project. That data helps the central heating system, I plan to stop the room thermostats if a window is open.

Living room temperature is provided by a Funky+DS18b20 project.

TV status is provided by the device tracking project. I also can control its state using the LG TV controller project.



“Second floor” branch has lots of to-dos, but in its current shape looks like this:


Room temperature data providers are  Funky+DS18b20 project.

PS3 game console status is fed by the device tracking project.


“Outside” branch looks like this, again I do have still more branches to add:



I have two software bots to feed WeatherUnderground’s forecast and current weather data, quite practical since I do not have rain/pressure/wind sensors available. I use the forecast data to send myself frost alerts and prepare the garden for such events. Still need to blog about these, as I am doing all this in Node-RED now.

The Funky+DHT22 project is the data provider for outside temperature/humidity. That data is being enriched by adding calculated  dew point as well.


The “cloud” branch is naturally grouping all cloud connected “things” like EmonCMS, Pushbullet, Twitter, email, Twilio etc. Still WIP.


Node-RED flows watch over the emoncms/out topic and send that data to EmonCMS.

The twitter/out topic is what gets published to my house’s Twitter account. Follow it



..and finally the “people” branch:


Presence detection project feeds my and wifey’s presence at home topics.

Weight is being tracked with my keypad project.

My location is being tracked with OwnTracks, still need to blog about that project.


That’s roughly where I stand now on my MQTT topic tree restructuring project. I enjoy looking at the D3 visualizer, it is animated and data flies in as it arrives, very beautiful indeed. I like to think of it as my house’s central nervous system visualised.





Categories: Community Blog posts

Monitoring my home automation system uptime

mharizanov - Fri, 12/09/2014 - 22:03

I’ve set up a uptime monitor for my home automation system so that I’m notified when it is down. Such event could mean two things: either Internet connectivity issue, or system is down due to power failure, crash etc. The service is provided by UptimeRobot and is free. It can watch over your system by pinging it or issuing a HTTP GET request every now and then. I chose to go for the second option, as by having that request served by Node-RED flow I’ll be able to both verify that Node-RED is up and my system is connected to the Internet to send me notifications should that be necessary.

The Node-RED flow to serve the HTTP request issued by UptimeRobot is extremely simple:


It spits out a message “Raspberry Pi is Up!” then you access pi’ ip address:port/watchdog. I use duckdns for dynamic DNS, so with a bit of port-forwarding on my router the above mentioned page is exposed to the web. I have enabled basic HTTP authentication on Node-RED as a simple security measure against accidental lands on my control page.

My UptimeRobot configuration is as follows:


So it checks my home automation system every 5 minutes and will immediately send me email notification upon detecting it is down.

I have it running of over a week now and my uptime isn’t exactly perfect, but as they say “if you can’t measure it, you can’t improve it”



Categories: Community Blog posts

Duck DNS updater in Node-RED

mharizanov - Sat, 06/09/2014 - 07:54

Dyn and No-IP have been for long time my choice for dynamic DNS, but both have recently made steps towards commercializing their services and implementing monthly confirmation process. I think it is time for me to move away and look for alternative. DuckDNS seems to be exactly what I was looking for, easy to use, reliable and most important – free. They support a number of devices already, but I wanted to implement my updater in Node-RED. The reason for this is so that I can keep all of my setup in one packaged environment for ease of management/transfer.

Here is my Node-RED flow to update DuckDNS, the flow was heavily influenced from Paul’s No-Ip updater:


[ { "id": "a34035d4.5cbfc8", "type": "inject", "name": "Every 30 minutes", "topic": "", "payload": "", "payloadType": "none", "repeat": "1800", "crontab": "", "once": true, "x": 149, "y": 55, "z": "f810b109.07ef5", "wires": [ [ "83464437.7cb9b8" ] ] }, { "id": "e06ab7d2.1f9548", "type": "http request", "name": "Update DuckDNS", "method": "GET", "url": "****YOUR-DOMAIN****&token=***YOUR-TOKEN****&ip=", "x": 335, "y": 273, "z": "f810b109.07ef5", "wires": [ [ "38e88442.c7177c" ] ] }, { "id": "38e88442.c7177c", "type": "switch", "name": "Was update sucessful?", "property": "payload", "rules": [ { "t": "eq", "v": "OK" }, { "t": "neq", "v": "OK" } ], "checkall": "true", "outputs": 2, "x": 316, "y": 325, "z": "f810b109.07ef5", "wires": [ [ "78932790.876cd8" ], [ "efc4308c.103bd", "b78d5573.4872a8" ] ] }, { "id": "ae6e141.f5191e8", "type": "delay", "name": "One notification/day", "pauseType": "rate", "timeout": "5", "timeoutUnits": "seconds", "rate": "1", "rateUnits": "day", "randomFirst": "1", "randomLast": "5", "randomUnits": "seconds", "drop": true, "x": 322, "y": 448, "z": "f810b109.07ef5", "wires": [ [ "fb043e44.04fbc" ] ] }, { "id": "fb043e44.04fbc", "type": "pushbullet", "title": "DuckDNS update failed", "name": "DuckDNS update failed", "x": 315, "y": 502, "z": "f810b109.07ef5", "wires": [] }, { "id": "3b8d48f5.c472b8", "type": "comment", "name": "No", "info": "", "x": 70, "y": 398, "z": "f810b109.07ef5", "wires": [] }, { "id": "f16adf9d.0e952", "type": "comment", "name": "Yes?", "info": "", "x": 530, "y": 320, "z": "f810b109.07ef5", "wires": [] }, { "id": "efc4308c.103bd", "type": "debug", "name": "", "active": false, "console": false, "complete": false, "x": 99, "y": 444, "z": "f810b109.07ef5", "wires": [] }, { "id": "78932790.876cd8", "type": "function", "name": "Reset fail counter", "func": "context.duckdnsfails=0;\nreturn msg;\n", "outputs": "0", "x": 716, "y": 320, "z": "f810b109.07ef5", "wires": [] }, { "id": "b78d5573.4872a8", "type": "function", "name": "Increment fail counter, check if >5", "func": "duckdnsfails = context.duckdnsfails || 0;\nduckdnsfails++;\ncontext.duckdnsfails = duckdnsfails;\n\n//Fsiled to update 5+ times?\nif(duckdnsfails <=6) {\n\treturn [msg,null];\n}\nelse {\n //shout out last known IP\n msg.payload=context.lastip;\n\treturn [null,msg];\n}", "outputs": "2", "x": 283, "y": 400, "z": "f810b109.07ef5", "wires": [ [], [ "ae6e141.f5191e8" ] ] }, { "id": "dd239510.22dc68", "type": "function", "name": "Has IP Changed?", "func": "context.lastip = context.lastip || 'initial';\nvar currentip = msg.payload;\n\nif (context.lastip == 'initial') {\ncontext.lastip = currentip;\n}\nelse if (context.lastip != currentip) {\nmsg.payload = currentip;\ncontext.lastip = currentip;\nreturn msg;\n}\n\n", "outputs": "1", "x": 327, "y": 224.5, "z": "f810b109.07ef5", "wires": [ [ "e06ab7d2.1f9548" ] ] }, { "id": "83464437.7cb9b8", "type": "exec", "command": "wget -qO- ; echo", "append": "", "useSpawn": "", "name": "Check my IP -", "x": 266, "y": 119.5, "z": "f810b109.07ef5", "wires": [ [ "652e3ea5.9ad1c" ], [], [] ] }, { "id": "652e3ea5.9ad1c", "type": "switch", "name": "Integrity check", "property": "payload", "rules": [ { "t": "regex", "v": "\\b(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\\b" }, { "t": "else" } ], "checkall": "true", "outputs": 2, "x": 340, "y": 173.5, "z": "f810b109.07ef5", "wires": [ [ "dd239510.22dc68" ], [] ] } ]



Categories: Community Blog posts

Improving my home automation system’s Data Quality

mharizanov - Tue, 02/09/2014 - 13:45

Data Quality is one of the areas I have been neglecting in my home automation system so far. As a result, I seem to be capturing some ‘garbage’ data along with the good quality data.  Bad data can affect downstream logic, resulting in hard to predict behavior of the system. It is of course hard/costly to maintain very high quality of data, there is an balance point that I am aiming for:

Cost of data quality



While I am running a small scale home automation system, bad data can (and is) still cause troubles; after all I rely on this data to interact with “things” from the physical and virtual worlds and some of the tasks they perform are of critical importance (hot water boiler controller, alarm system controller, fire alarm system, irrigation system, etc)


My plan is to transition from reacting to data quality failures to proactively controlling and limiting introduction of data flaws in the environment.

To achieve this,  I plan to

  • Profile the data
  • Establish metrics
  • Design and implement DQ rules
  • Monitor DQ exceptions
Profile the data

This is step number one, I need to learn more about the data I am collecting, understanding the content and structure of the data will help me with the next steps. I have a number of

Physical sensors:

  • Room/outdoor/heating system temperature sensors
  • Humidity Sensors
  • Battery Readings of sensor nodes
  • Soil moisture sensor
  • Power readings
  • Security alarm state sensor
  • Fire sensor
  • Flood sensor
  • Shock movement sensor
  • Magnetic contact door sensors
  • Bathroom scale sensor

Software data delivery bots:

  • Outside freezing conditions detectors
  • Presence detectors
  • GPS location loggers
  • Wind speed readings from remote weather stations
  • Air pressure readings from remote weather stations
  • Heat flux calculations
  • TV/game console usage trackers

..and few more of less importance.


The assumption is that anything that can go wrong will go wrong. Given that, I need to understand what are the possible values, payload structures, frequency of sending that each data delivery system can pass on to the home automation system for processing.


For example room temperature reading cannot be less than -5 degrees C indoors and should not be more than 40 degrees C unless something is very, very wrong (house on fire). Hot water boiler’s temperature should vary in the range 5-99 degrees C, anything outside that range is potential error. The DS18B20 temperature sensor I use will give a reading of 85 degrees C or 127 if it encounters error, so I must ensure these two particular values (although possible valid reading) are not considered valid.


This sort of analysis and study of historical data provides good knowledge of the data and helps plan the next steps. It must be done for all systems that introduce data into the home automation system.


Establish metrics

The next step is to establish metrics. What Data Quality aspects do I want to monitor? What are my tolerance thresholds? The most commonly monitored DQ dimensions that are applicable to my DQ improvement efforts are:

  • Completeness
  • Domain Integrity
  • Redundancy
  • Accuracy
  • Validity
  • Timeliness
  • Availability

Wikipedia’s entry for Data Quality says that there are over 200 such measures. The range of possible measures is only limited by the ability to provide a method for measurement.

I try to find the earliest point where bad data is generated and handle it there, before it reaches other business logic.


Completeness refers to making sure that the complete set of data makes it across data handoff points. Easy way to check if we got the complete data is to verify that the payload is of expected, pre-defined size. We know the expected payload sizes from out Data Profiling stage, so the task here is to compare the actual received payload structure/length against that expectation. The reasons for having incomplete data could be many, ranging from hardware error to human error. I observe this when by accident I use duplicate node id and send payload of different size.

Domain Integrity

Next check that I plan to implement is to make sure that the data provided is of the correct type and fits the established in the data profiling stage allowable ranges/valid values/matches predefined pattern. This sort of DQ checks is easily performed by validating with code.


My next effort is to reduce the redundant data; I get redundancy mainly due to remote wireless node re-sending its payload after failing to receive ACK or as a side effect of MQTT’s qos level 0 that can deliver one message more than once.


Accuracy is notoriously hard to measure, your best bet is to validate sensor’s input against another credible source. I performed a series of accuracy checks of the DHT22 temperature/air humidity sensor to check on its accuracy. Alternatively, you can check against readings from similar sensor, for example the outside temperature at your location cannot be +/-5 degrees from a nearby weather station.

Some sensors, like GPS, provide accuracy as part of the measurement, making the task easier. I discard inaccurate location readings, where accuracy is > 100m in my location tracking system.


Data validity is where you make sense of the data in terms of business rules. After data has passed the domain integrity checks, it makes sense to pass it against business rule validation; Can indoor room temperature be < than -10 or > than 40 degrees C? Can hot water boiler temperature be <5 degrees C or > 99 degrees C? Can atmospheric pressure be < 900 or > 1200 where I live?


Timeliness is important data quality dimension when you make decisions based on data provided by other sensors. Would it make sense for the home automation system to turn on heating, if outside temperature reading is 3 days old? We need a mechanism to track the timeliness of the data and expire it based on business rules.


I have ran into a situation where a remote node has stopped sending for some reason (battery low for example), and I only find out about this days later. The availability of the data is important for decision making, so tracking that dimension and notifying me of disruptions is important.


Design and implement DQ rules

Now that I have established what aspects of Data Quality I want to measure, it is time to implement these. I have completely switched all of my business logic to Node-Red for my home automation system, so these checks will be performed there. Below is an example of my implementation of these rules for my solar hot water tank:


Completeness will be ensured by simple check of payload length; should that fail, the flow does not continue:

Domain Integrity & Validity checks

I combine Domain Integrity and Validity checks in one block, probably not ideal from re-usability point of view:


Redundancy is handled by limiting to max of 2 messages per minute. Excessive messages are dropped:


This particular node does not perform accuracy validation, I use that sort of validation in GPS location tracking node.


Timeliness is ensured by providing a MQTT time stamp topic, so that the consuming process’ business logic can decide if the data is good or bad:


Availability is tracked by a ‘heartbeat monitor’ mechanism; Failing to receive a heartbeat (valid data) within a pre-set time interval results in a notification being sent to me:

The above workflow is available to try out:


Monitor DQ exceptions

In an ideal world, you’d log data quality exceptions and analyze that information to adjust the processes, however this is a small home automation system and I will limit this task to providing debug information only.



As a conclusion from this my effort, the quality of the data I collect for my home automation purposes has improved materially and my trust in it has increased. Well worth the effort.



Categories: Community Blog posts


FairTradeElectronics - Thu, 01/05/2014 - 23:19

Photo Ewaste / kai loeffelbein / Kids of Sodom

  Projet résumé - dossier complet à télécharger  

En 2017, selon un rapport de l’ONU, 65 millions de tonnes de déchets électroniques (ordinateurs, téléphones…) seront produits chaque année.
A l’échelle mondiale, moins de 20% des déchets sont recyclés.


  • Organiser un concert dans une des grandes décharges d’électronique avec des instruments fabriqués à partir des déchets collectés sur place.
  • En Afrique ou en Asie : Ghana, Mali, Pakistan, Chine…
  • Des musiciens joueront avec des instruments électroniques fabriqués à partir de déchets collectés sur place.
  • Les instruments seront développés en collaboration avec des Makers spécialistes de l’électronique pendant un atelier d’une semaine.
  • Le concert sera organisé en collaboration avec des partenaires locaux, institutionnels et ONG.
  • Le concert et sa préparation seront filmés afin de réaliser un film documentaire, trace de l’expérience.
  • Parler des déchets électroniques via un dispositif à contre pied des documentaires alarmistes.
  • Favoriser l’émergence d’objets électroniques recyclés, témoins manifestes du rythme effréné de notre consommation.



Des instruments de type “Toys made in décharge” ou “théremine on the go” (projets présentés ici même) pourraient être des bonnes pistes d’instruments à développer et produire pour le concert.

Dossier complet : ELECTRO-WASTE


Categories: Community Blog posts


FairTradeElectronics - Thu, 01/05/2014 - 23:16

Bouts de ficelles et Peer to Peer. Communication old school ou apaisée

Dans l’idée de proposer un smartphone apaisé, capable de se connecter à des réseaux alternatifs, capable également de faciliter le partage de fichiers volumineux ou d’objets réels, il semble important de dresser un état des lieux documenté des moyens de communication “à la marge”, alternatifs, de secours ou simplement “à l’ancienne”.

  • Dans les prisons du monde entier les détenus parviennent à échanger informations et objets autant entre les murs de la prisons qu’avec l’extérieur via des système de relais humains, de transmission par bout de ficelles (le yoyo) de cellule en cellule.
  • Espions et brigands communiquent vie des cachettes, des “boites à lettre morte”.
  • En 1941, radio Londres organisa l’opération”V” et demanda aux français de tracer sur les murs de France des “V” de la victoire. L’opération fut un succès, en une nuit la France fut recouverte du signe de la victoire : la résistance avait enfin un “visage” public.
  • Alors que des systèmes de télécommunication modernes étaient largement disponibles durant la seconde guerre mondiale des pigeons voyageurs furent utilisés car plus difficiles à intercepter (la nuit) que des ondes radio. Aujourd’hui encore, en Syrie, les opposants au régime de Bachar el Assad utilisent ce dispositif quand les réseaux classiques (Web et téléphones) sont coupés.

* Croiser moyens de communication alternatifs avec le téléphone portable peut permettre d’imaginer des dispositifs puissants et inventifs de communication

* Alors que les opérateurs téléphoniques préparent l’arrivée de la 5G (mille fois plus rapide que la 4G) il est bon de se souvenir que les messages les plus importants ne passe pas forcement par les réseaux classiques et tiennent parfois en quelques mots ou objets précieux.


Categories: Community Blog posts


FairTradeElectronics - Thu, 01/05/2014 - 23:10

Une interface sans contact pour téléphone portable

Le thérémine est un instrument de musique, inventé en URSS, par Lev Termen, en 1919. Il se joue sans contact.

Le principe est simple. Un son de base est produit par un dispositif électronique. Le joueur de Thérémine module ce son en hauteur et en volume en variant la distance de ses mains vis a vis de deux antennes. Le phénomène de “capacitance” permettant ces variations est connu de toutes personnes se déplaçant à proximité d’une radio FM en faisant des “interférences”

Sur ce principe de capacitance, nous pourrions imaginer un dispositif simple, robuste et original permettant d’interagir avec nos téléphones, tablettes, ordinateurs? Qu’ils soient apaisés ou de dernière génération.

Objetcifs :
  • Proposer une interface alternative au tactile pour interagir avec nos machines.
  • Imaginer des applications ne nécessitant pas l’usage de l’écran
  • Proposer une nouvelle interface, c’est proposer au créateur d’application de nouveaux scénario d’usages pour nos équipements et ouvrir une voie pour de nouveaux projets.
  • Si un ensemble de 2 antennes peut convertir n’importe quel smartphone/tablette en thérémine, il est évident que l’interaction sans contact devrait permettre d’imaginer des usages totalement en rupture avec ce qui est proposé actuellement pour l’ensemble de nos équipement.
  • Redonner une place aux corps et aux mouvements amples dans la manipulation d’applications sur téléphone
  • Permettre des applications ne faisant pas appel au tactile et à l’écran.
  • Sortir de la standardisation des usages de l’électronique grand public, (ici du tout tactil sur écran minuscule) pour repenser les usages, les besoins, c’est ouvrir une porte à la réflexion sur ces objets monolithiques omniprésents que sont nos smartphones.

Categories: Community Blog posts


FairTradeElectronics - Thu, 01/05/2014 - 21:38

En étudiant les objets souvenirs proposés aux touristes des pays du Sud, en Afrique, en Asie et en Amérique du Sud, nous retrouvons beaucoup d’objets réalisés à partir d’une matière première récupérée dans les décharges. Pneus, fer blanc, semelles de tong, capsules, fils électriques … mais aucun n’est produit à partir des millions de tonnes de déchets électroniques.

Il semble donc intéressant de dessiner des “jouets” ou objets souvenirs électroniques basiques utilisant des composants électroniques fonctionnels. Pour la fabrication, il serait possible d’organiser des temps de formation aux rudiments de l’électronique destinés aux personnes vivant déjà de la récupération.

Nous pourrions voir apparaître une nouvelle catégorie d’objets recyclés sur les marchés touristiques du monde entier et observer le développement  d’un savoir mi savant, mi populaire sur la mise en oeuvre d’objets électroniques.

Goûte d’eau dans l’océan, le projet, en affichant la provenance des matériaux via une étiquette intégrée à l’objet permet d’aborder le problème des DEEE, les Déchets d’équipements électriques et électroniques. D’une manière concrète.

Ainsi l’étiquette pourrait mentionner

1/ la localisation de la décharge où ont été collecté les composants

2/ le type et la marque des appareils démantelés pour récupérer les composants (TV, ordi, imprimantes…)

3/ la provenance, si cela est possible, des appareils


“Made from Waste” model #1

Le premier objet pourrait être un petit jouet musicale de type sampler-séquenceur.

Cahier de charges

* Produire un rythme

* Jouer le rythme en boucle

* Enregistrer des sons via un micro

* Jouer en boucle les sons enregistrés

* Jouer en direct des sons via le micro



FONCTION M – microphone

* Permet d’enregistrer voix et sons sur piste R1 ou R2 en pressant le bouton R

* Permet de jouer en direct un son ou la voix

A-Z – bouton

* Presser une premiere fois permet de jouer en boucle les sons enregistrés par M sur RA et RZ

* Presser une seconde fois stop la lecture de A ou de Z

R- rec button

* Presser R pour enregistrer sur A ou Z

* Lacher R pour cesser d’enregistrer

RA-RZ – Pistes d’enregistrement

* Permet de choisir la piste RA ou RZ pour enregistrer le son via le micro M

U – AC mini USB

* Permet de recharger la batterie intégrée

O – sortie audio

* Permet de connecter l’instrument à des enceintes



* M : Micro de téléphone portable

* A-Z-R : Touche de clavier d’ordinateur

* O : Sortie audio pour minijack 3,5.

Ordinateur, téléphone portable, chaine hifi, radio

* U : Mini USB femelle. Téléphone, disque dur, chargeur



Du plus simple au plus complexe, le fabricant pourra proposer des modèles selon sa créativité.

Les savoir-faires “classiques” de récupérateur (pneu, fer blanc, capsule…) seront également mis en pratique sur ce projet, tant pour réaliser le support, la structure, la boite de ces objets que pour produire des sons, des effets, des commandes manuelles…

Categories: Community Blog posts


FairTradeElectronics - Thu, 01/05/2014 - 21:24

A l’image de l’herbier botanique, permettant de conserver, connaître et ranger, une collection de végétaux, l’herbier électronique permet à tout un chacun de prendre contact avec les composants électroniques.

En démontant un vieux jouet, une télécommande, un lecteur de CD, la collection permet une approche simple de cette science complexe qu’est l’électronique. Nombreuses sont les voix aujourd’hui à dire l’importance de connaître le fonctionnement des machines qui nous entoure. L’herbier propose de connaître et reconnaître les grandes familles de composants.


Un fiche type devra contenir les informations suivantes


  1. Dessin du composant et éclaté si possible
  2. Nom du composant
  3. Famille
  4. sous famille
  5. Usage
  6. Provenance appareil
  7. Provenance entreprise qui le fabrique
  8. Matériaux qui le compose
  9. Provenance des matériaux


C’est un premier pas qui peux permettre d’aborder, par la suite, la réparation de certains objets et de réaliser des montages à partir d’éléments récupérés.


Categories: Community Blog posts


FairTradeElectronics - Thu, 01/05/2014 - 19:38
Projet d’art vidéo

Les téléphones portables des années 90 à 2000 étaient fournis avec des sonneries “monophoniques” d’une grande simplicité, mais qui ont défini un environnement sonore caractéristique de cette époque.


Chargées de souvenirs, ces mélodies basiques révèlent un étrange paradoxe :

Le numérique à ses débuts, au lieux d’apporter une qualité accru, a favorisé la diffusion de sons et de musiques compressés, de mauvaise qualité. Sur les téléphones de seconde génération, la perte de qualité est poussée à son paroxysme: Les sonneries sont des mélodies MIDI monophoniques diffusées sur de minuscules “haut-parleurs”. C’est cette technologie, et ce phénomène que je souhaite souligner ici.

Le numérique altère d’une certaine façon les images et les sons. Avec la puissance grandissante des capteurs et des processeurs la qualité s’améliore tout de même, mais l’âme manque. Etrangement l’écoute de vieux vinyles de qualité, résultat d’une chaine de production entièrement analogique, fait ressentir les dimensions spatiales de la captation, indécelables sur du matériel numérique.

Ainsi, alors que les formats ne cessent de proposer une qualité toujours plus grande, imitant mal habilement le réel, les sonneries minimalistes des débuts semblent, quand on les écoute aujourd’hui, être habitées d’une chaleureuse simplicité presque honnête, presque analogique. L’électronique mise en oeuvre et le résultat produit sur ces antiques appareils étant très éloignés de l’électronique d’aujourd’hui et de sa tentation de singer le réel.

L’idée pour ce projet est de s’emparer de cette thématique et de proposer une série d’actions filmées sur fond de sonnerie. Chaque sonnerie devant inspirer une vidéo, une performance.

Des téléphones “anciens” seront collectés et des sonneries seront sélectionnées. La première série de film pourra être le résultat d’un atelier de création organisé sur un temps court. Un Week end ou une semaine.

Categories: Community Blog posts


FairTradeElectronics - Thu, 01/05/2014 - 19:35

Fiction sociale présentant en plusieurs tableaux (T) une industrie de l’électronique équitable, son usage, sa conception, sa fin de vie. Cette utopie socio-industrielle prend place au Kazakhstan qui a réellement tous les moyens miniers, financiers et scientifiques de devenir pionnier de ce domaine.


T1: Historique d’une utopie : les bases réelles

Bien que fictionnelle et utopique, l’idée d’une industrie de grande complexité, entièrement équitable, prenant place au Kazakhstan trouve de nombreux échos dans la réalité de la région comme dans l’intérêt grandissant au niveau mondial pour les marchandises issues de filières plus respectueuses de l’Homme et de l’environnement.

Fier de son passé turco-mongol, conquérant, guerrier, commerçant et poète, le Kazakhstan est aussi une patrie de scientifiques et d’industries.

Le kazakhstan compte de grands chercheurs comme le géologue Kanysh Satbayev qui fut un acteur incontournable de la géologie et de la métallurgie soviétique. Terre de sciences et d’aventures industrielles, le Kazakhstan accueil le cosmodrome de Baïkonour.

Enfin, le pays connaissant de très graves problèmes de pollution nucléaire suite aux essais soviétiques dans le polygone nucléaire de Semipalatinsk, et ayant vu la mer d’Aral quasiment disparaître sous ses yeux, nous pourrions imaginer que le pays souhaiterai promouvoir à présent des technologies apaisées.

Organisation sociale basée sur une structure clanique donnant priorité au clan, à la famille. La culture Kazakhe, ses rites, ses chants, sa cuisine imprègnent le quotidien de chacun.

La fiction pourrait ainsi présenter toutes ces caractéristiques réelles et dévier sur l’aspect fictif du film:

Face à ses atouts scientifiques, ses richesses minières et industriels et pour ne pas laisser sa jeunesse délaisser la vie du clan et les activités traditionnelles au profit de gadgets chronophages sera instauré une cause nationale : “l’électronique apaisée”

Adieu jeunesse aux yeux et aux cerveaux usés par des vidéos de moutons faisant du skate et de chevaux “trop mignon” (l’équivalent Kazakh fictif de nos LOL cats).

La fiction repose également sur un point réel supplémentaire montrant qu’un sursaut est possible. Le kazakhstan est un pays où des décisions peuvent être prisent sans formalités, par un clan au pouvoir depuis 1990. C’est le plus grand pays du monde où Mc Donalds n’est pas implanté et ne s’implantera jamais. On raconte (ce n’est pas la fiction ici) que cette décision fût prise par le président pour faire plaisir à sa fille et donner une leçon à la firme dont le représentant se serait mal comporté durant son séjour.

Ainsi, on pourrait imaginer le patriarche devenu sage, lancer son pays dans la grande aventure de l’électronique équitable.

T2 : Dans les mines

Le film présenterait des mines artisanales. Les quantités de minerais prélevés sont faibles. La main d’oeuvre est outillée, protégée, massée. Les technologies mécaniques sont motorisées par traction animale et Eolienne

Des moutons très bien traités transportent le minerais en tirant des chariots, des chevaux choyés actionnent des tapis roulant.

Quand les ouvriers ont atteints les quotas de production décidés, ils cultivent les terres alentour faisant du traitement des terres extraites une priorité.

On voit également des gisement de silicates destinés à la production de silicium

T3 : La métalurgie

L’ambiance est au workshop de forgeron.

Flamme et tablier de cuir.

Production de cuivre.

Production d’étain.

Plus technique dans un pan technique, la transformation des silices ou silicate en silicium

T4 : La fonderie electronique

Le tableau s’ouvre sur un laboratoire très technique pour la production de semi-conducteurs.

Production de Wafer de silicium dans l’ambiance d’un laboratoire d’alchimiste.

Production de composants, processeurs..

T5 : Production d’un téléphone mobile apaisé

Un Smartphone apaisé.

Ecran Noir et blanc à encre électronique E-Ink, pas de vidéo.

Du texte, de la géo-localisation, de l’image vectorielle

Un design inspiré du graphisme traditionnel, des matériaux feutres, bois, argent, robustes et dessinés. N’oublions pas que les kazakhs sont bien placé pour dessiner des objets nomades !

La chaîne de production tient plus de l’atelier d’assemblage de montres haut de gamme que de l’usine géante. On suit de postes de travail en postes de travail le montage d’un téléphone.

T6 : Usages

L’usage est centré sur la facilitation lowtech d’une vie apaisée entre technologies et mode de vie traditionnel.  Les contenus intéressants que l’on souhaite partager sont notés pour être partagés plus tard via des réunions dédiés, par exemple dans une yourte commune aux pieds des grands immeubles modernes. C’est facebook en live. Des informations en temps réel pour certaines activités très sélectionnées à trouver.

Les enfants (et les adultes) ne jouent pas a candy crush ou angry bird mais jouent de la musique sans avoir les yeux sur l’écran (Théremine en option, voir le projet Théremine ). Ils complètent leurs “herbiers” en dessinant faunes et flores, participant ainsi à des projets de cartographie du vivant et des choses qu’ils aiment.

Le téléphone apaisé peut être vu comme un “plug” numérique permettant de faciliter le quotidien de manière créative et non aliénante. Sans écran couleur, sans vidéo, il ne peut exercer sa déloyale et faussée concurrence avec les doux contrastes de la réalité. (Avez vous déjà posé, par une fraîche nuit d’été, votre dos sur un rocher encore chaud du soleil de la journée?)

Categories: Community Blog posts


FairTradeElectronics - Thu, 01/05/2014 - 15:31


The road

Voir en plein écran

The electronics road

A research on the electronics industry, its science, its technics, its men and its geography.

How electronic work ?
  • where do the raw material come from ?
  • How is produce the tin of  the weldings, the copper for the printed circuit card, silicon for processor ?
  • What are transistors, diodes? How do they work ?
  • Who are the women, men and children working on this industry?


En français, tout le projet


Categories: Community Blog posts

Workshop: Solder and hack the Nanode

Amin - Mon, 04/06/2012 - 12:07
The first nanode workshop was a great success, we got to introduce many people to soldering and arduino. But we didn’t get to really hacking the nanodes and we couldn’t ...
Categories: Community Blog posts

betapitch: what it meant to us

Amin - Tue, 29/05/2012 - 01:11
We applied, we were shortlisted, we pitched and we didn’t win… But boy it was great! I personally never presented anything in front of such a crowd in my life. It ...
Categories: Community Blog posts

Raspberry Pi Finally Arrives

Nathan - Wed, 09/05/2012 - 17:17

After a long wait the Raspberry Pi I ordered from Farnell on 29th February finally arrived yesterday.

I expect that most people reading this blog knows all about the Raspberry Pi and the charity behind it by now, designed with the aim to bring programming back into the school curriculum and spawn a new generation of coders, it’s had some fantastic news coverage and even people with no idea about computers have mentioned it to me over the last few months. It has been a rocky road, originally it was expected to have been released in late 2011 but finally the much anticipated single board computer has started to be delivered into the eager hands of geeks around the world. Initially only a caseless version of the “Model B” is available, intended for early adopters and developers with a fully cased version being launched for education later in the year. The idea being that by the time it reaches the hands of school children there will already be a healthy eco system built up around it and those preparing educational material will have been able to do so.

At the moment I am just familiarising myself with it and getting a grasp of what it is capable of. I’m running Debian Squeeze on it as that’s my distro of choice for servers and the like anyway and is also what the Raspberry Pi team are currently recommending. As a desktop it’s usable but pretty sluggish, perhaps not as much as expected but it’s potential for me lies more in the home automation and IoT field, £30 for a tiny networked Linux box is unbeatable and with up to 17 GPIO pins, built in UART and support for I2C and SPI it also opens up a lot of possibilities for interfacing to other hardware, a number of expansion boards are already available or in the pipeline. Here is a good primer on Getting Started with Raspberry Pi GPIO and Python.

Categories: Community Blog posts

The Magic of the Boost Converter

Nathan - Mon, 30/04/2012 - 23:49

Or how to get 5V From a single AA Battery.

It might seem like magic but a boost converter or step-up converter is a handy little device that can output a voltage greater than its input voltage. This makes it very useful for getting a consistent voltage in battery powered devices or running a circuit from fewer cells than would otherwise be required. If you don’t need much capacity it can also be a good way of using the last remaining power from batteries that other devices have deemed too flat, connect a few up to a boost converter and you can still get some useful power out of them for a while longer. For more capacity you can add more cells (as long as you keep the input voltage under the output voltage) or use higher capacity batteries such as C or D cells.
The Maxim chip I am using here has an adjustable output (2.7-5.5V) and will work with an input voltage as low as 0.7V.

Obviously it isn’t really magic and this extra power can’t be generated from nowhere, P=IV and all that. What this means in practice is that by increasing the output voltage the available output current must be lower than the source current and will decrease as the input voltage decreases (as the batteries deplete), as seen in the graph on the left below. Efficiency is also dependent on the input voltage and the output current, peaking at around 87% with a 3.3V input and a 5V 200mA load as seen on the right hand graph.


Wikipedia has a better explanation of how a boost converter works than I could give so have a read of that if you’re curious about the details.  The Maxim MAX757 I’m using here is an 8 pin DIP chip and requires minimal external components which makes it ideal for a stripboard build, it has an adjustable output voltage in the range 2.7V to 5.5V and can operate down to a 0.7V input voltage, the data sheet seems to imply that it needs at least 1.1V initially to start up but this doesn’t seem to be the case, at least it wasn’t in my testing. This output range combined with the low voltage capability means it is easy to get the two common voltages used with microcontrollers and other digital electronics of 3.3V and 5V from even a single AA or AAA cell although the extra capacity probably makes two (or more) more practical for most uses.

The output voltage on the MAX757 is set by a voltage divider between ground and the output which is connected to the feedback input (pin 2), the formula to calculate the required resistors is:

VOUT = (1.25) [(R2 + R1) / R2]

To get 5V I have used 30K for R1 and 10K for R2, for 3.3V you could use 18K for R1 and 11K for R2.

If you can find it an alternative part is the MAX756 which is a bit easier if you only need an output of 5V or 3.3V as the voltage can be set by connecting pin 2 low for 5V or high for 3.3V which negates the need for the voltage divider arrangement.

These chips also have a low battery output that can be used to light an LED to notify of a low battery, it brings pin 4 (LBO) low when the voltage at pin 5 (LBI) drops below the converters internal reference voltage of 1.25V. This means the lowest voltage you can trigger the warning is 1.25V so you would probably want to leave this off if using a single cell. For a warning at 1.25V you just need to connect pin 5 (LBI) to VIN and an LED with a suitable resistor to pin 4 (LBO). For a warning at a higher voltage you would need to use a voltage divider to output the desired voltage to the LBI pin.

Here is my stripboard layout for the MAX757, the MAX756 would be the same except R1 and R2 would be omitted and pin 2 would instead be connected to ground to select 5V output or to VIN to select 3.3V output.

Parts list:

1 x MAX757 Adjustable-Output Step-Up DC-DC Converter
1 x 8 pin DIL socket
1 x Piece of stripboard, minimum 8 rows by 21 holes
1 x 22 uH Inductor (0.03 Ohm or less, 1.2A or more)
1 x 150 uF electrolytic capacitor
1 x 100 uF electrolytic capacitor
1 x 100 nF ceramic capacitor
1 x 1N5817 Schottky Diode
1 x AA Battery holder of desired capacity
1 x LED (optional)
1 x 100 Ohm resistor (optional)
For 5V output: 
1 x 30K resistor
1 x 10K resistor
For 3.3V output:
1 x 18K resistor
1 x 11K resistor

For other output voltages calculate suitable resistors using the formula VOUT = (1.25) [(R2 + R1) / R2]

Categories: Community Blog posts

We’re pitching at betapitch this thursday

Amin - Sun, 29/04/2012 - 16:31
Betahaus is one of my favorite places in Berlin. I work and have meetings in the cafe, I hack around in the makerspace Open Design City at the back, and ...
Categories: Community Blog posts

New logo and website revamp

Amin - Thu, 12/04/2012 - 19:17
Hello everyone, we are back ! With lots of fresh and refreshing news. First of all, I am very glad and proud to announce that we could charm a seed ...
Categories: Community Blog posts
Syndicate content