Some news

Since the birth of my first daughter three years ago, I have had no free time so all my personal projects described on this website are for the moment stalled. However, I have recently passed the French amateur radio exam so I have now new project ideas in my mind. I hope to be able to describe them here soon.

Thanks for your patience and stay tuned!

USB HID example for ChibiOS/RT and Olimex STM32-E407 board

I have just made available an example application demonstrating how to communicate using the HID (Human Interface Device) class over USB.

The example uses ChibiOS/RT operating system and targets the Olimex STM32-E407 board. A client application using the HIDRAW driver of the Linux kernel is included to test the two ends of the communication.

The project is available on my GitHub account: guiduc/usb-hid-chibios-example. Feel free to use it as a basis for you own application.

Port of ChibiOS/RT to Olimex STM32-H405 board

The MCP control board of my 737 cockpit project is based around the new Olimex STM32-H405 board.

In order to use it easily, I have ported ChibiOS/RT to this board. You can find the result of this work here. This port is based on the 2.6 stable branch of ChibiOS/RT. You just have to extract the archive in the directory boards of ChibiOS/RT. Feel free to use it for your own projects!

Update (25/12/14): you can also retrieve the port by fetching the branch stable_2.6.x_with_Olimex_H405 from my fork of the ChibiOS repository at GitHub.

Korry from OpenCockpits

Hello everyone,

I will begin this new section of my website about my project to build a Boeing 737 cockpit by testing the korrys I recently received from OpenCockpits. They are to be used in the Collins-style MCP.

The model I ordered is “Switch type Korry MON-OFF (momentary)” (reference 4TS14M) and it costs (at the time of writing) 15 euros each. The legend (text) and the color of the two parts (upper and lower) are to be specified as comments during the checkout.

The service from OpenCockpit is excellent and I received the korrys only a week after the order using normal postal service (OpenCockpit is located in Spain and I live in France). They were properly packed and well protected.



The larger black square seen on the above pictures near the connectors is a ring that can be used to secure the korry when moved to the top of the korry over the toothed area.

The korry is connected using the 6 pins headers at the bottom: pins 1 and 2 = +5 V and GND for the first LED, pins 3 and 4 = push-button, pins 5 and 6 = GND and +5 V for the second LED.

The LED are directly powered with 5 V without need for any external resistor. They consume 19 mA each.

First LED turned on:


First and second LED turned on:


There is almost no light leakage from one part of the korry to the other.

To conclude, this korry is almost perfect and relatively cheap. Thank you OpenCockpits!

Trouble with XBee (Series 2) sleep mode

I am currently playing with Digi XBee Series 2 (ZB) modules (bought from Sparkfun Electronics) to develop a sensor network (temperature in a first step) at home (I will soon write a more detailed article about it).

As some nodes will be powered by batteries, I have to reduce their consumption. So I was investigating the sleep modes of the XBees. I selected the “pin sleep” mode to control the sleep by the external microcontroller (an ATTiny2313). However, as soon as I activated the sleep mode (SM=1), everything stops working.

I found the first problem quickly. I had just inverted the logic of the sleep request pin (pin 9): it is active (go to sleep) high and not low! So I was able to ask the module to go to sleep and to wake up.

However, when the module wakes up, it took about 6 seconds to join the network, which is very long… After some research on the Internet (Google was not my friend this time), I found the answer on a thread on the Digi Support Forum.

When a end device on the ZigBee network is design to sleep, it is important to take care of the SP (Sleep Period) and SN (Number of Sleep Periods) on its parent device (in my case the coordinator). With the default values (SN=1 and SP=0x20), if the end device sleeps for more than 320 ms (SN * SP * 10 ms), its parent device will forget it and, when it wakes up, it will have to perform the long association process (which takes several seconds to complete). If the delay is increased (by increasing SN and SP) to a value longer than the maximum sleep period of the end device, the parent device will keep the information about its son and, when it wakes up, the association is much faster (less than a second).

It now works fine!

Hello world!

Welcome to my new website! I took advantage of my migration to the new Gandi‘s Simple Hosting service (which is working very well for the moment) to merge all the websites I was using (aeronautic blog, electronic projects wiki, main website, etc.) into only one.

Stay tuned!