It has been quite a long time since my last posts on this blog. Many – hopefully good – reasons explain this prolonged silence. As I am a man of his words and because I am so curious and so fond of finding answers to all sorts of problems, I managed to be a municipal councilor in my town, on completion of a rough campaign which has been complicated by the covid 19 and all the restrictions in social life that this virus involved.

However, I am still active in the field of hi-tech, embedded systems, IoT. I have recently been invited at a round table at the MtoM IoT world in Paris, speaking about edge computing: “Where to process and analyze IoT data? How to distribute the capacities to do so? When should we decide on this? According to which model? Under what constraints?”. On the other hand, I kept working on the leanest possible IoT solution, using basic but rugged, cheap and easy to handle solutions. Which drove me to the concept of “nano-iot” networks, featuring “nano_iot_devices”, nano_iot_gateways” and “nano_iot_servers”. These works result in an effective local IoT network that I use extensively for performing all sorts of experiments inside and outside of my house. So far, I deployed various sensors such as temperature sensors (indoor, outdoor and freezer) , soil moisture sensor, air pressure, humidity and temperature sensor, power meter sensor.

Next is a plot of the latest electrical power consumption in my house:

A closer look at the plot shows the automated activation of the water boiler, the use of various appliances, the power peaks, many interesting information which may help to define the best price contract. I am waiting for colder days to establish a relationship between outdoor temperature and power consumption and then I will be able to get back to my provider as I suspect that my contract is not optimum… although they say that the smart meter will help them to improve their offer…

And now comes the time for a critical decision. 10 years ago now, I started Arduinoos with the intention of sharing my passion for technology, science and well being. As I am pretty broad minded, because I had a chance to meet people from many places around the world, I wrote all my publications in English. The statistics prove that I was right because arduinoos has fans from all around the globe. However, arduinoos fails to meet its closest potential french friends as not so many fellow countryman
and country woman are fluent in english. In addition to that, I feel very unpleased with the isolationism process carried out by the leaders in UK and US. That’s against the spirit of sharing, building bridges over humanity.

So that I am about to suspend, or close, arduinoos and start with a new blog (every thing is ready so far, name, domain, posts), featuring the same spirit and the same subjects. However, this blog will be written in french only. Before making this critical decision, I am looking forward to hearing from you about this decision…

HC-05 Bluetooth module (Part 2)

Part 1, 2

Once the hardware is under control, let’s focus on the software. By default, the HC-05 modules are configured in slave mode and they are discoverable by any master and consequently linkable by any master (eg. A PC, a smartphone or an HC-05 module configured as master). This configuration is obviously the easiest way to start with the HC-05 modules, however this is the less safe.

Configuring the HC-05 module is quite easy as long as you follow one of the procedures

  • Using the “basic platform”: Build the platform, set the jumper in place and power the platform. The module’s LED should blink at a slow rate (see previous post): you are in the AT mode. Once the programming done, power off the platform, remove the jumper and power the platform on again. The module’s LED should blink at a fast rate (see previous post): you are in the search mode.
  • Using the “basic platform” without the jumper: Build the platform without the jumper. Press the push button on the module and then power up the platform. The module’s LED should blink at a slow rate: you are in the AT mode release the push-button (the LED keeps flashing at a slow rate. Once the programming done, power off and power on the platform. The module’s LED should blink at a fast rate : you are in the search mode.
  • Using the “advanced platform”: Write a sketch which will turn PIND4_EN HIGH and PIND6_PWR LOW. Wait for 1 s (I could not find the exact timing, however it proved to be the safe mandatory delay required by the module). The module’s LED should blink at a slow rate: you are in the AT mode. Execute the AT commands, turn PIND4_EN LOW then turn PIND6_PWR HIGH and LOW again. The module’s LED should blink at a fast rate : you are in the search mode.

Nest is an example of code used to drive the “advanced platform”:

	\brief Set or reset at mode
	\param [in] state at mode state
	\return Nothing
	\details    In the at mode, the module's led blinks slowly
    \n          In the normal operation mode, the module's led blinks fast
void atMode(bool state)
    digitalWrite(_powerPin, HIGH); /* power off */
    if (state)
        digitalWrite(_enablePin, HIGH);
        digitalWrite(_enablePin, LOW);
    digitalWrite(_powerPin, LOW); /* power on */
    delay(1000); /* mandatory wait for module readyness */

The HC-05 modules can be given one of the three roles:

  • 0 = slave
  • 1 = master
  • 2 = slave-loop

Set the role using the AT+ROLE command, e.g. AT+ROLE=0. Read the current role from module using the AT+ROLE? command.

The HC-05 master modules can be configured in one of the three communication modes:

  • 0 = connect to fixed address
  • 1 = connect to any address
  • 2 = slave-loop

Set the communication mode using the AT+CMODE command, e.g. AT+CMODE=0. Read the current communication mode from a master module using the AT+CMODE? command.

Now a few words about the AT commands. As seen before, the module must be configured in AT (or command) mode. Under these conditions, it is able to communicate at a 38400 baud rate through its UART (Universal Asynchronous Receiver Transmitter). AT command are originated by any device physically connected to the module and able to send ASCII characters. Each command starts with “AT”, followed by the “+” sign and the command itself. Each command is terminated by a d Carriage Return (ASCII character 13 and a Line Feed (ASCII character 10). On completion of the command, the module simply acknowledges the command by issuing a “OK” or issuing a value followed by “OK”. On case of error, the module answers ERROR(nn) where nn can take the following values described in list below:

  • 00: AT command error
  • 01: Default result
  • 02: PSKEY write error
  • 03: Too long length of device name (more than 32 bytes).
  • 04: No device name
  • 05: Bluetooth address: NAP is too long.
  • 06: Bluetooth address: UAP is too long.
  • 07: Bluetooth address: LAP is too long.
  • 08: No PIO number’s mask
  • 09: No PIO number
  • 0A: No Bluetooth devices.
  • 0B: Too length of devices
  • 0C: No inquire access code
  • 0D: Too long length of inquire access code
  • 0E: Invalid inquire access code
  • 0F: The length of passkey is 0.
  • 10: Too long length of passkey (more than 16 bytes)
  • 11: Invalid module role
  • 12: Invalid baud rate
  • 13: Invalid stop bit
  • 14: Invalid parity bit
  • 15: Authentication device is not at the pair list.
  • 16: SPP lib hasn’t been initialized.
  • 17: SPP lib has been repeated initialization.
  • 18:Invalid inquire mode
  • 19: Too long inquire time
  • 1A: No Bluetooth address
  • 1B: Invalid safe mode
  • 1C: Invalid encryption mode

You might find convenient to issue batches of commands using the following function:

	\brief Send command the the HC-05 module
	\return Nothing
	\details None
void sendCmd(char cmd[])
    /* send AT command */
    Serial.print("command: ");
    /* read answer */
    uint32_t tickMark = millis();
    bool timeoutTriggered = false;
    while (!btSerial.available())
        if((millis() - tickMark) >_atCmdTimeout)
            timeoutTriggered = true;
    Serial.print(" answer: ");
    if (timeoutTriggered)
        Serial.println("<!> timeout");
        while (btSerial.available())

HC-05 Bluetooth module (Part 3)

Part 1, 2, 3

Now that we have the hardware and that we understand the fundamentals of module programming, let’s build a simple network. In this example, we will use a master and a slave module, each of them plugged onto a “basic platform” (see part 1).

The slave module shall be configured using the following set of commands:

  • AT: check if the module is responding
  • AT+STATE: Get the current module state
  • AT+ADDR?: Get the module address
  • AT+NAME=”slave”: Set the module name
  • AT+PSWD=”1234″: Set device’s pswd; master and slave must share the same pswd
  • AT+UART=38400,0,0: Set device’s serial param
  • AT+ROLE=0: Set the module’s role (slave)

The address of each module is expressed in three colon separated values: e.g. 98D3:31:F73314.

The master module shall be configured using the following set of commands:

  • AT: check if the module is responding
  • AT+STATE: Get the current module state
  • AT+NAME=”master”: Set the module name
  • AT+PSWD=”1234″: Set device’s pswd; master and slave must share the same pswd
  • AT+UART=38400,0,0: Set device’s serial param
  • AT+ROLE=1: Set the module’s role (master)
  • AT+RMAAD: Delete all authenticated previous paired devices
  • AT+BIND=98D3,71,F5D7D8: bind slave module to this master

Please note that the address is entered in three coma separated groups of values. Once the programming done, both module are ready to be used. Plug them on their respective platform. For a few seconds, both module’s LED will flash at a fast rate and then burst two flashes at a slow rate on completion of the pairing.
The best way to exercise these instructions is to load the following sketches on both platforms

#include <SoftwareSerial.h>

SoftwareSerial btSerial(2, 3); 

void setup()

void loop()
    /* read and print data from HC-05 module */
    if (btSerial.available())   
        while (btSerial.available())
    /* read data from console and send them wirelessly through the HC-05 module */
    if (Serial.available())    
        while (Serial.available())

Open two separate consoles (eg Putty) and link them to each platform.

Start with the platform holding the slave module: set the module to AT (or command) mode (See part 2), enter the commands as explained above, collect its serial number, reset the module to normal operation. Proceed with the master module set the module to AT mode (See part 2), enter the commands as explained above, collect its serial number, reset the module to normal operation. On completion of the configuration, check if the module managed to pair and start exchanging data through their respective consoles.

Blog of the day

While tumbling through the net, I mean through the jungle of publications, I found the oasis of the maker !

I like very much the look and feel of Last Minute Engineers web site: nice pictures, well explained and documented topics. Pinouts and code samples will help you learning by doing.

One can be fed up with the numerous advertisement. However who could blame someone to finance his works through advertisement ?


Part 123456789101112, 13, 14, 15

First serious failure…
After exactly 4 years of regular use, I experienced the first failure which is due to an aged component.

Although Peek is a very strong material, it did not sustain any longer the thermal strength which it endured for years. This critical part is responsible for guiding the “cold” filament down to the heated nozzle so that a gradient from ambient temperature up to 210 ° and more is observed next to its threads. It is easy to give advises once you know the consequences of some flaws, however, this is a well known principle that parts must be massive around the temperature dissipation points… In this case, the designers did the opposite and this is breakage is surely not a big surprise.

As a result of this breakage, a leak of thawed PLA occurred and finally clogged the extruding stage creating no dramatic further damage. The lesson learned from this unfortunate event that no extra stress should be applied to this part and consequently avoid over-tightening of the nozzle to the insulator.

PS: In the middle of the Covid-19 crisis, I ordered a spare part one month ago which is still “somewhere” at La Poste. I managed to get an other one from Okaphone in the Netherlands which was brought by the the PostNL and everything went well, right in time. The Covid-19 crisis cannot explain the disorganization at La Poste which seems to be endemic since a long time; check this tracking records which is a pure example of non sense:


HC-05 Bluetooth module (Part 1)

Many web pages, posts and topics can be found on the web, however it took me quite some time to gather enough information to have a clear picture about the HC-0x series Bluetooth modules. Although they are outdated by low power BT modules, these modules are still a product of choice for building amazing applications snappy and on the cheap.

Update: Some more work on this type of modules proved that the situation is messier than I thought! In fact the HC-0x modules have been assembled in various manners using various firmware versions which makes the hobbyst’s life a little more complicated.

Anyway, this new series of posts dedicated to these Bluetooth modules, which will explain the way to program them and to use them. This is going to be a progressive approach, so please be patient if you look for the ultimate configuration or code !

Let’s start with some basics. HC-0x modules are easy to use Bluetooth SPP (Serial Port Protocol) modules, designed for transparent wireless serial connection setup. The HC-Ox series consist in a variety of modules as per the description below:

  • Industrial level: HC-03 (Master/Slave), HC-04 (Slave)
  • Civil level: HC-05 (Master/Slave), HC-06 (Slave)

Unless specified, I will deal with the HC-05 module which is the most versatile. Next is an illustration of the module itself, as it can be soldered on a main PCB for its real use (datasheet):

Most of the available assemblies featuring HC-05 and HC-06 modules look like the illustration below. Once again, unless specified, I will deal with the ZS-040 version of these modules fitted with the version 3.0-20170601 for which I found no documentation…

The pinout of the assembly is as follows (and printed at the back of the PCB):

  • State (dir.: out) : module state (3 V digital level). The level of the state goes high when the module is paired. The controller may read this signal is order send data only if the module is paired. You may also wire a LED through a resistor of few hundred ohms. Warning: the pin is inactive on some modules!
  • RXD (dir.: in) : Receive data from the controller (3 V digital level)
  • TXD (dir.: out) : Transmit data to the controller (3 V digital level)
  • GND (dir.: in): Ground
  • VCC (dir.: in): DC voltage (3.6 to 6 V)
  • EN (dir.: in): AT enabling mode (3 V digital level). The enable pin is also known as the key pin. In the case of the ZS-040 module, a high level on this pin has the same effect than pressing the push-button.

The board itself features a push button which enabled the AT mode and a LED which blinks according the module state, as described below:

  • Slow blink (1 Hz): AT mode, or command mode
  • Fast blink (2 Hz): Trying to pair
  • Bursts of two blinks (1Hz): Paired module, ready for communication

Back to the connections: keep in mind that the module can be fed with a DC voltage ranging from 3.6 to 6 V, but the digital pins must comply to a 0-3 V range. This is a pretty well known situation in the world of prototyping as more and more components require less and less power and consequently most often lower supply voltages. Three options can be applied:

The poor man translator using a voltage divider featuring a bridge of two resistors as shown below. This is a cheap solution. However, it draws a significant amount of power and should be use for prototyping only. Note that the TXD signal from the HC-05 is not boosted as a high signal (3.0 V) exceeds the trigger point of the input pin from a 5 V powered micro-controller. The enable pin shall be strapped on purpose to the 3.3 V from the Arduino platform. We will call this reference design the “basic platform” for later use.

The state of the art translator featuring a purpose built chip. Many chips cover the various needs which depend upon the type of communication. In the present case, a general purpose unidirectional translator will do the job, although the proposed TXB104D exceeds the needs as this is a bi-directional translator.

The in-between features popular discrete components. Each channel is fitted with a N-channel general purpose low signal MOSFET biased by two resistors. You may use some cheap of the shelves translator modules.

Next is an illustration of the poor-man’s design featuring a vintage Arduino Diecimila and an early Adafruit shield (Soon both collectors!).

Ultimately, one may want to build a fully versatile platform for programming and using the modules. Next is a suggestion of reference design that will be used in later posts and that we will recall as the “advanced platform”.

This version features a power supply control line which allows a full control of the module by the platform.

100 !

This picture illustrates my production of facial masks frames of the Easter week-end!
I never produced that many parts of the same sort using my brave old Vertex printer. So far, I experienced only 2 failures:
– 1 part was poorly printed showing gaps and lacks of filament. This problem did occur any more after a careful cleaning of the nozzle
– 1 part failed to stick properly to the bed. I readjusted the bed and this problem did not occur any more (although I do not use brim as it is not mandatory and the brim leaves sharp edges which may damage the gloves used my the medics and nurses).

After these 100 hours of printing, I checked the belts and adjusted on pulley, I cleaned the rods and applied clean grease again. That’s it.

HTH (Hope This Helps) has a double meaning this time: I really hope that theses mask help saving medics and nurses health.

By all means

By all means let’s stop the covid-19!

The heroes are those who stay home, in small flats, with nervous kids, noisy neighbors, low stocks of toilet paper and plenty kindness through the networks.

The action men and women keep the ball rolling, feed us, power our phones and care about us. They deserve as much help as we all can, if we can. Some bring them comfort in a noisy manner at 8:00 PM, some are sewing masks (that’s what my sister does!), some others print face shields for medics and professionals. A group of local makers set up an organisation in order to federate the good will of local owners of 3D printers. I volunteered immediately and here I am printing frames!

If you are living in Poitiers’s area France, you may contact this group through their Facebook account or by mail at [m a s q u e 3 d 8 6 @ g m a i l . c o m].

At a rate of 1 frame per hour, I expect to deliver at least a dozen units per day ;-). Next is a picture of one of the earliest product

Breaking news: Production line live !

MicroHTR (Part 9)

Part 1, 2, 3, 4, 5, 6, 7, 8, 9

Here is an update of the MicroHTR (aka micro heater application) topic. Guy is a former marine pilot and his hobby is flying his touring-motor-glider wrote to me a very interesting message:
When flying close to cloudbase, the air becomes cold and the relative humidity becomes very high, this induces formation of ice in the carburetors; the so-called ” carburetor icing”.

In order to prevent carburetor icing and the resulting shut-down of the engine, i have installed electric heaters and a thermistor in each carburetor to heat up the carb’s body and prevent the icing. My intention is to install Brett Beaureguard’s PID control on an Arduino and control the power to the heaters via PWM for the two carburetors seperately ( so a PID loop running for each carburetor ). Interface is a 20×4 LCD with SPi and a rotary encoder KY-040. While reading and learning about the Arduino Atmega2560 programming , the LCD and rotary control I have come across your articles on the subject. ” … The following of the message contains some sort of a detailed description of the requirements.

This is typically the type of message that I like and that moves me forward to helping ;-). As a consequence, I reviewed my code (multiple libraries are involved in this project), and even reworked the PID library in order to take a interesting point into consideration.

The carburators may “start at a lower temperature than the setpoint and the PID kicks in right from the beginning to bring the carbs temp up to the setpoint. Without limiting the PWM they can both pull full Amperage until the setpoint is reached :Bad, this situation is to be avoided since power is limited. “

“The generator delivers 14 Amps at 12 Volts. The heaters are each 40 Watts, so 80 Watts pulls almost 7 Amps. This leaves only 7 Amps to recharge the battery ( 12 V -30 AH) and to power the avionics

Very important notice: This post describes an experimental setup, to be used at own risk and by no way approved for installation in Certified Aircraft

Starting with my earliest version of PlainPID , I tweaked this library so that the current version is now able to report the status of the controller: is it ramping to get to the set point or is it running under normal conditions ? In an application code, this feature translates as shown below:

 /* manage temperature */
float actualTemperature = TMP.getTemperature();
int16_t computedPwm = (int16_t)PID.getOutput(actualTemperature);
/* get stats from the PID */
stats_t stats;
/* manage output */
_pwm = computedPwm;
int16_t _currentMaxPwm = DEF_MAX_PWM;
if ((!stats.firstRampCompleted && (_maxPwmOnRamp == YES)) || (_maxPwmAlways == YES))
    _currentMaxPwm = _maxPwm;
if (_pwm > _currentMaxPwm)
    _pwm = _currentMaxPwm;
/* set duty cycle to the driver */

From the next plot (blue trace = set-point, red trace = actual temperature, green trace = PWM), we can clearly see the original ramp up using a limited power (half the full range in this case), then the PID controller uses as much power it needs. Then we have an illustration of how the PID controller behaves when the set-point is lowered and setback to the original set point. Once again, the power is limited during the ramp up. You may also recognize the efficient management of the overshoot.

Next is an illustration of the information displayed on a 16×2 LCD: the first line contains the actual temperature and the bracketed temperature set-points; the second line contains the actual PWM and the bracketed maximum allowed PWM which depends upon the choosen mode (Limited on ramps or limited always)

If necessary, the power may be limited always to the cost of broader temperature control as shown below .

Blog of the day

Thank you Guy for your very informative mail, the kind of request I love and pushes me hard to help. Part of the description of Guy’s project (Controlled heaters for deicing the carburetors from his touring-motor-glider) was a reference to Brett Beauregard’s blog.

Although I understand that nowadays Brett’s main preoccupation leads him to a lesser commitment to his blog, his great publications are still available and pleasured by those who play serious games. I had a quick glance at the PID subject that I incidentally covered at about (+/- 5 years!) the same time through the MicroHTR project.