Motion Sensor Fusion

 

Source: Meggar at English Wikipedia

Satellite-based geolocation has become a commonplace, thanks to the manufacturers that managed to integrate high-sensitivity RF receivers and complex mathematical computation required by the GPS technology into small and cheap devices that fit into the palm of your hand hidden in a smartphone, or behind a car’s dashboard.

Beside position, another important characteristic to get is the orientation in space, known as the “attitude”. But in this case, no RF communication with an external system is required as it is for GPS, this information can be obtained by using local physical value sensors.

The difficulty is that there is no single sensor that is able to provide an absolute attitude by eliminating all 6 mechanical Degrees of Freedom at once (3 DoF along each axis, 3 DoF around each axis). Thus, a “mix” of several types of sensor is required, and with the democratization of motion sensors based on MEMS (for “MicroElectroMechanical Systems”) at low cost  ($3.02 for a 9-axis sensor on AliExpress), their usage raises today a lot of momentum, especially because of the development of drones and Virtual Reality Helmets.

Compared to the flight instruments depicted above (airspeed indicator, attitude indicator, altimeter, turn coordinator, heading indicator and vertical speed indicator), they basically serve the same goal: get an attitude (or an orientation in space), but at a fraction of the size and cost.

When these sensors are considered as a group, the term IMU (“Inertial Measurement Unit”) is used to reference the sensors delivering only raw values.

But these MEMs motion sensors have an important issue in that the different sensors do not deliver independently a ready-to-process information, and thus a “sensor fusion” operation is required in order to obtain an absolute orientation in space. The term used in this case is AHRS (“Attitude and Heading Reference System”).

Among all existing motion sensor types, the gyroscope is generally considered as the most important one, as it provides an angular velocity and that a simple integration will enable to retrieve relative angles, a very good start for getting the overall orientation in space. One drawback of this method is that by integrating, a constant is introduced, that will accumulate into an error that will result into a drift over time. This is exactly the purpose of the “PUSH” knob near the heading indicator (bottom center in the picture above), used to realign it to the true magnetic North every ten to fifteen minutes.

These relative angles can be constrained further by using an accelerometer sensor that provides linear acceleration values and thus allowing us to determine the Earth gravitational force in form of a “1g” down vector when idle, adding 2 constraints to the angles but also significant disturbance when moving.

There remains a last degree of freedom: the yaw. It can be given by a magnetometer, which provides the magnetic North direction. However, it is far less dynamic than the gyroscope when during rotations.

The problem of data fusion from values given by all these sensors can be definitely solved by using the tactical nuke that applies to this kind of kind of disturbance generated by sensor noise: the Kalman predicitive filter or more precisely its extended version (EKF for “Extended Kalman Filter” for its non-linear version), at the cost of relatively complex (for an embedded system) matrix computations. Nevertheless, an Arduino library implementing this method is available.

Another approach consists in exploiting complementary filters (low-pass + high-pass) to filter the noise inherent to each sensor, as experimented by Robert Mahony in 2008, using a simple PI (for Proportional–Integral) feedback loop.

The complementary filter idea has been pushed further by Sebastian Madgwick in 2010, by using a spherical gradient (a kind of “mean” value between 2 points on a sphere), who was the first to provide an Open Source implementation of Mahony and Masgwick filters. Something worth noticing is the use of the Fast Inverse Square Root algorithm.

The Madgwick algorithm has been improved by Kris Winer in 2014 to remove undefined cases when computing norms with null vectors from the accelerometer and magnetometer to create a library for the integrated Invensense MPU-9250 9-axis sensor.

Eventually, Kris Winer’s sources have been cleaned up by Sparkfun in 2016 to create a clean Arduino library.

Another more basic implementation of Madgwick algorithm has been done by Philippe Lucidarme in 2015, with a bonus graphical visualization tool written in Qt.

If you reach this point, you may have noticed that all the above algorithms were based on “quaternions” instead of more classical Euler angles or matrices. This is because a quaternion represents an object rotation in space under the form of a 3D vector and a scalar value to provide the orientation around this axis. This enables computing rotation compositions in a simpler way compared to the Euler angles or even full-fledged  matrix transforms, and to avoid the dreadful Gimbal Lock.

Advertisements

Generic STM32F103C8T6 Board with SSD1306 OLED Display

Keeping moving forward with these cheap STM32F103C8T6 little boards…

Today, the challenge is to hook up a tiny 0.91″ 128×32 OLED displays featuring an SSD1306 controller that you can find on AliExpress for $3.

With the IL9341, the SSD1306 is a very common controller for OLED displays (datasheet here). Hopefully, we don’t have to write everything from scratch, as Adafruit wrote an Arduino SSD1306 driver library available in their Github repository. Along with their higher level graphic library also available on Github, we have all the tools to draw nice graphics on these tiny OLED screens.

For standard AVR-based Arduino boards, these libraries work out of the box, they are even directly available in the Arduino IDE (search in the Library Manager for “SSD1306” and “GFX”):

For the Generic STM32F103C8T6 boards, making these work is a little bit more involved, though (we are sitting on the bleeding edge, are we?).

Because the SSD1306 library is relying on the standard “Wire” Arduino library to abstract out the underlying I2C bus complexity, using this OLED library directly on the STM32 that features 2x real hardware I2C bus results in a massive waste of efficiency (read: power consumption and processing power).

In order to get the most efficiency out of this board, a much better choice is to use the “Hardwire” library that implements the I2C interface using the dedicated hardware instead of software bit-banging..

Hopefully, this job has already been done in the Arduino STM32 package, even if there are a few bugs lurking around…

Locate the corresponding “ssd1306_128x64_i2c_STM32” project in the “Examples for Generic STM32F103C Series” menu:

As you noticed it from the project title, this example is aimed at the 128×64 version of the display, so we will have to change that to match our screen resolution of 128×32 pixels. This involves removing the stupid test located at lines 58-62 of this sketch:

#if (SSD1306_LCDHEIGHT != 64)
#error("Height incorrect, please fix Adafruit_SSD1306.h!");
#endif

The effective choice of the screen resolution is located into the library header file “~/Arduino/hardware/Arduino_STM32/STM32F1/libraries/Adafruit_SSD1306/AdaFruit_SSD1306_STM32.h” that you need to edit using an external text editor around line 64.

The last problem is to correct a missing declaration for the “swap” macro in the main library file “~/Arduino/hardware/Arduino_STM32/STM32F1/libraries/Adafruit_SSD1306/AdaFruit_SSD1306_STM32.c” that you again need to edit using an external text editor. The change is located near line 105:

#define swap(a, b) { int16_t t = a; a = b; b = t; }

Back to the Arduino IDE, you should now be able to compile (“Verify” in awkward Arduino terminology) the sketch without other problem.

The Adafruit_SSD1306_STM32 library is set to use the second I2C interface on the STM32. According to the board pinout diagram, the wiring is as depicted below:

Here is a short demonstration video:

STM32F103C8T6 Blue Pill Board with Arduino IDE on Linux

Update: it looks like it was working because I had support for the Arduino Due (ARM Cortex M3) already installed, so I added a step to install this below.

As we have seen in a previous post, the ST32F103C8T6 “Blue Pill” or “Red Pill” boards are dirty cheap but extremely powerful MCU hardware boards. Compared to a marginally cheaper (- $0.30) Arduino Pro Mini board featuring an ATMega328 MCU, you get:

• 72 MHz 32-bit ARM CPU vs. 16 MHz 8-bit AVR CPU
• 64 kB / 128 kB Flash memory vs. 32 kB
• 20 kB SRAM memory vs. 2 kB
• unfortunately, no EEPROM memory vs. 1 kB
• In the package used in this board, up to 35 GPIOs, most of these are 5 V tolerant, vs. 23 GPIOs
• 7x timers vs. 3, 2 ADCs vs. 1, 6x PWM channels, 2x SPI,, 3x USART vs. 1, 2x I2C vs. 1,
• additional USB device and CAN interfaces

However, having a nice hardware platform is useless if it is not backed by a good software environment. And despite the sophisticated IDEs and tools available for the STM32, the ATMega328 is still very attractive because of its free and easy to grasp Arduino IDE and numerous libraries, that seriously lowers the required knowledge to be able to tackle with the MCU low-level programming for non-specialists.

Thus, using the same Arduino tools used on the Atmel AVR platform on the STM32 may seem like a good idea… Doing this on a Linux computer provides some additional challenges, but nothing really overwhelming, though.

The first consideration is that there are several ways to program an STM32F103C8T6 MCU:

1. Just like all modern MCUs today, there is a way to program (and most of the time, debug) the chip at the lowest level using a JTAG probe. For the particular STM32 case, you can use an STLink, a JLink or a Black Magic Probe that all use the standard ARM SWD programming / debugging interface, readily available on  a separate 4-pin header on the Blue/Red Pill board short edge facing the micro USB connector
2. Just like for the ATMega328, we can use an Arduino bootloader stored into Flash memory, here the equivalent is the STM32duino bootloader
3. Serial (UART): unlike the ATMega328, the STM32 features an UART bootloader in ROM, i.e. available in an empty chip straight out of the production line

As we try to lower the prerequisite to program these Blue / Red Pill boards, the third method has the main advantage to not require any additional hardware, except for a standard serial UART to USB cable (as I suppose that your host PC does not provide a native RS232 UART DB9 or DB25 connector for a while…). This is the method that we will use here.

Here is the step-by-step procedure:

Requirements:

• an STM32F103C8T6 “Blue Pill” or “Red Pill”module (ARM32 Cortex-M3, 72 Mhz, 64K flash, 20K SRAM, 33 I/O pins, 3.3V), available here for $1.52 (expect a 1 month delay to EEC with standard shipment method)
• a soldering iron (in order to solder the large 2.54 mm pitch male headers provided with the board)
• a Serial-to-USB cable, I used my old faithful FTDI TTL-232R-3V3 cable (datasheet here), but any know working cable or adapter will do
• 4x Male / Female short “Dupont” wires

Step #1: Wiring

Wire the STM32 module and the Serial-to-USB cable as shown below:

 

If you only have +3.3V power supply available, connect it to the “3.3” pin instead of “5V”.

Connect the cable to one of your free USB port on the PC. In order to find out which Linux device is associated with the cable, run the “dmesg” command in a terminal and search for the assigned device name near the last lines. You should see something like this:

$ dmesg
...
[19086.232386] ftdi_sio 3-4:1.0: FTDI USB Serial Device converter detected
[19086.232488] usb 3-4: Detected FT232RL
[19086.232858] usb 3-4: FTDI USB Serial Device converter now attached to ttyUSB0

Step #2: Setup the Arduino IDE

As the Arduino IDE packaged in the standard Linux distros is generally outdated and/or difficult to match with an official Arduino IDE release, it is better to scratch it if already installed, and download and install the latest Arduino IDE (I did use 1.6.12) directly from the Arduino official download page, either for Linux 32 bits or Linux 64 bits. This should create a folder “arduino-1.6.12” in your home directory.

If you want to add a menu item, icons and mime type for Arduino for the current user, run the “install.sh” script from this directory:

$ cd ~/arduino-1.6.12
$ ./install.sh

While you are at it, I suggest to check that your standard user has access to the Serial-to-USB cable. This can be done by running the command “id” and check for group “dialout”. If not found, you can add your user to the corresponding group:

$ id
uid=1000(your_user_here) gid=1000(your_user_here) groups=1000(your_user_here),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),113(lpadmin),128(sambashare)
$ sudo adduser your_user_here dialout

Restart your session (this is required), and check that you now are part of the “dialout” group:

$ id
uid=1000(your_user_here) gid=1000(your_user_here) groups=1000(your_user_here),4(adm),20(dialout),24(cdrom),27(sudo),30(dip),46(plugdev),113(lpadmin),128(sambashare)

Step #3: Setup the Arduino Due (ARM Cortex M3) package

In order to install the required GNU cross toolchain for the ARM Cortex M3 core (the one used in the STM32F103C8T6), we must install support for the Arduino SAM Boards (Arduino Due) which contains the same core.

In the Arduino IDE “Tools” menu, select the “Board” item, and in the cascaded menu, select the “Boards Manager…” item:

This will display the Boards Manager dialog box, in which we need to select the “Arduino SAM Boards (32-bits ARM Cortex M3) by Arduino” and click on the corresponding “Install” button to install the latest version (mine is 1.6.9):

You can then close the “Boards Manager” Dialog box.

Step #4: Setup the Arduino STM32 package

Despite an active community, the STM32 is not (yet) an officially-supported Arduino platform, thus it is not available from the standard “Board Manager” in the IDE menus. You will have to manually download it from “https://github.com/rogerclarkmelbourne/Arduino_STM32“, extract it and copy the folder ‘Arduino_STM32-master’ to your Arduino/hardware folder (“~/Arduino/hardware”), then rename the folder by removing the “-master” suffix from the folder name in order to obtain a new folder named “~/Arduino/hardware/Arduino_STM32” (this suffix is the repository branch added automatically by Github, we don’t need it).

 

Step #5: Select the Board parameters

Launch the Arduino IDE and in the “Tools” menu, select the correct values for “Board”, “Variant”, “Upload method” and “Port”:

• Board: “Generic STM32F103C series”
• Variant: “STM32F103C8 (20k RAM 64k Flash)” (we will speak about it later, in the “Bonus” section below)
• Upload method: “Serial”
• Port: “/dev/ttyUSB0” or the one found at end of step #1 above

Step #6: Compile a Sketch

Copy & Paste the following code to replace the current sketch code:

#define pinLED PC13

void setup() {
 Serial.begin(9600);
 pinMode(pinLED, OUTPUT);
 Serial.println("START"); 
}

void loop() {
 digitalWrite(pinLED, HIGH);
 delay(1000);
 digitalWrite(pinLED, LOW);
 delay(1000);
 Serial.println("Hello World"); 
}

Nothing fancy, if you already know the Arduino language, we just set up the UART @ 9600 bps, set the PC13 GPIO as an output (this one has a onboard LED attached to it) and send the “START” welcome message on the UART. Then in a loop, we toggle the LED ON/OFF with a 50% duty cycle with a 2 s period, while at the same time sending “Hello World” greetings on the UART.

By clicking on the “Check” icon in the Arduino IDE, you can compile (“Verify”) the sketch, you should not get any error.

Step #7: Upload the Sketch to the Board

On the board, set the yellow jumper for BOOT0 to the “1” position (please refer to the board picture above) and press the RESET button.

In the Arduino IDE, click on the Arrow button to upload the sketch to the board.

If everything goes as expected, you should see the red LED blink @ 2 Hz and get our messages sent on the UART by opening the “Serial Monitor” @ 9600 bps in the Arduino IDE “Tools” menu.

Not working? If you get a message like “Failed to open port: /dev/ttyUSB0”, please check that the cable is indeed associated to the correct Linux device by running the “dmesg” command like above, and make sure that your current user has access to the UART by performing the step #2 above.

For my part, I had a rather unusual message while trying to upload the sketch, I obtained a:

Got NACK from device on command 0x43
 Can't initiate chip erase!

Googling around, I found this thread that helped me to identify the root cause of this problem: the chip is actually locked, which is rather unusual for a development board! However, the provided solution involved using a tool from ST that only works under Windows 😦

I found a purely Linux solution by running one of the tools installed by the Arduino STM32 package above: using the “stm32flash” utility, you can read and write unprotect the chip, using the following commands:

$ cd ~/Arduino/hardware/Arduino_STM32/tools/linux/stm32flash
$ ./stm32flash -k /dev/ttyUSB0
stm32flash Arduino_STM32_0.9

http://github.com/rogerclarkmelbourne/arduino_stm32

Interface serial_posix: 57600 8E1
Version : 0x22
Option 1 : 0x00
Option 2 : 0x00
Device ID : 0x0410 (Medium-density)
- RAM : 20KiB (512b reserved by bootloader)
- Flash : 128KiB (sector size: 4x1024)
- Option RAM : 16b
- System RAM : 2KiB
Read-UnProtecting flash
Done.

$ ./stm32flash -u /dev/ttyUSB0
stm32flash Arduino_STM32_0.9

http://github.com/rogerclarkmelbourne/arduino_stm32

Interface serial_posix: 57600 8E1
Version : 0x22
Option 1 : 0x00
Option 2 : 0x00
Device ID : 0x0410 (Medium-density)
- RAM : 20KiB (512b reserved by bootloader)
- Flash : 128KiB (sector size: 4x1024)
- Option RAM : 16b
- System RAM : 2KiB
Write-unprotecting flash
Done.

Going back to the Arduino IDE, you should now be able to upload your sketch successfully to the board!

Bonus

If you were careful and checked either the “stm32flash” utility output above, or check into the Arduino IDE messages during the sketch upload, you may have notice this:

Using Parser : Raw BINARY
Interface serial_posix: 230400 8E1
Version : 0x22
Option 1 : 0x00
Option 2 : 0x00
Device ID : 0x0410 (Medium-density)
- RAM : 20KiB (512b reserved by bootloader)
- Flash : 128KiB (sector size: 4x1024)
- Option RAM : 16b
- System RAM : 2KiB

The “128 KiB” line above means that we are not on an STM32F103C8 MCU with only 64 kB of Flash, but more likely on an STM32F103CB MCU with 128 kB of Flash! This confirms the last point in my previous message that both variants share the same chip production mask and only differ by memory tests.

STM32F103C8T6 boards: Blue Pill or Red Pill?

The Generic STM32F103 Pinout Diagram

Not exactly related to Wi-Fi, but I am tinkering with the cheap STM32F103C8T6 boards that you can buy on AliExpress @ $1.52/piece here:

https://www.aliexpress.com/item/sku/32498344057.html

I received them exactly 1 month after I ordered them.

As I said: no Wi-Fi, but these boards can be nice as local I/O expansion boards, featuring numerous interfaces, large memory and a fast CPU…

First, I traced back this board to its original manufacturer (http://www.vcc-gnd.com!!!) on TaoBao:

https://world.taobao.com/item/22097803050.htm

I am absolutely not fluent in Chinese, but Google helped me to understand that this board contains a 300 mA Richtek RT9193-33 LDO and a good quality Epson MC-306 crystal that is supposed to be better than cheaper cylinder-type 32 kHz crystals that are more sensitive to vibrations.

Second, my post title is a reference to Matrix of course, because of this seminal thread that I missed completely 1.5 years ago:

http://www.stm32duino.com/viewtopic.php?f=28&t=117

I got the Blue Pill, so it probably means that I am still in the Matrix 😉

It is a very informative thread, nevertheless. As for the ESP boards, it looks like there are many variants of the same board:

http://www.stm32duino.com/viewtopic.php?f=28&t=117&start=90#p14095

The one I got is the “version 3”, here is the corresponding (reversed-engineered) schematic:

https://developer.mbed.org/media/uploads/martin159/stm32_min_system_dev_board.pdf

This schematic has a minor RE bug: the U1 LDO is an RT9193, not an RT8183-B, which does not exist.

Third: another problem which is more serious as it is not because of RE but is a BIG design flaw on this board: the R10 USB pull-up resistor should be 1.5k as per the USB specs, not 10k. It causes this board not to enumerate correctly as an USB device. The solution is either to replace it with a correct 1.5k 0603 resistor, or to solder an 1.8k TH resistor in parallel between A12 and +3.3V:

http://www.stm32duino.com/viewtopic.php?f=28&t=117&start=100#p14206

BTW, here is another schematic from the VCC-GND.com original manufacturer, which features a different (but still wrong) 4.7k pull-up… to +5V!

http://www.stm32duino.com/download/file.php?id=276

Fourth: here is a nice board pinout diagram:

http://reblag.dk/wordpress/wp-content/uploads/2016/07/The-Generic-STM32F103-Pinout-Diagram.pdf

Fifth and last: this board features an STM32F103C8T6 (GP Performance Line LQFP48 with 64KB Flash, Industrial range), which differs from the upper STM32F103CBT6 (GP Performance Line LQFP48 with 128KB Flash, Industrial range) by… memory tests! Yes, the C8 ad CB share the same mask, and it is very likely that you could access the full 128KB and not only 64KB! It is reported to work (but of course, no guarantee) on many devices. Maybe good enough for some kind of logging tasks, though…

Squonk’s DIY ESP-01 WiFi Module Breadboard Adapter

ESP-01 Breadboard Adapter

Espressif ESP8266 WiFi chip received a lot of attention lately, both because of its integrated RF front-end requiring no calibration, and also because of its dirt cheap price: you can find WiFi modules featuring this chip, the required Flash SPI, a crystal and a printed PCB antenna for < $3.

Unfortunately, the most common module (named ESP-01, from a family of 12), is not really breadboard friendly: its dual row connector is such that there is no way you can plug it into a standard breadboard directly.

Of course, makers are not really stopped by this kind of details, and it didn’t take long before some among them came with more or less interesting solutions to this problem.

I HAD to propose mine too! So here it is!

As opposed to all adapters I have found so far, mine doesn’t require to make a PCB, only standard easy to find parts and tools are required. It doesn’t take long to build and does not require any special skills either…

What you need:

• a 10-pin long tail header, such that the ones used for Arduino boards
• a cutter knife, if possible with a special cutting surface to avoid damaging your desk 😉
• plyers (not strictly required, but it makes things easier)
• some heavy duty glue

And here is a mini-instructable:

1. cut the header in 2 parts, you will probably mess up the central pins, this is why I asked for a 10-pin header, even if we only need 2x 4-pin ones in the end, trim the 2x headers with the cutter knife
   
2. bend the tails 90°:
   
3. bend the pins again, in order to get an “S” profile:
   
4. Glue the 2x headers back-to-back!

It is not the most gracious adapter around, but this adapter is high enough to allow connecting Dupont wires into the breadboard below the ESP-01 board.

One final tip: I recommend adding a 10µF or higher capacitor across GND and VCC in order to absorb the module voltage drops when turning on the WiFi RF, as it draws suddenly a large amount of current. This capacitor will act as a small energy reservoir, preventing the module to reset because its power supply dropped too low for a short period of time.

Arduino Yùn: what is under the hood?

Two years after its initial release, the Arduino Yùn board has not been explored in details: featuring a large metal shield on its top PCB side, I am surprised that no hacker already tried to remove this shield and see what is “under the hood”?

Wait no longer, I did it! It is actually rather easy, using a soldering iron and pliers, as it is only soldered at 2 opposite locations.

What would be the reason for doing this? Probably the most obvious is hacker curiosity… To be honest, I am surprised that it took me so long to do it!

Now what, you may ask: what is the point in looking at a bunch of chips on a PCB? Well, as you will soon discover, sometimes technical choices shed some light on more political changes.

Not everybody is a hardware specialist with embedded Linux and WiFi knowledge, so let me detail the parts that have been hidden for so long:

• the big square chip is an AR9331 WiFi SoC from Atheros (datasheet), a chip used in many pocket routers, the most common being the TP-Link TL-WR703N
• the “Winbond” rectangle left is a 512 Mbit (64MB) DDR2 SDRAM chip (datasheet)
• the small square chip with relatively large pins on the right is also a Winbond chip, a 128 Mbit (16MB) 104 MHz SPI Flash chip (datasheet)
• the small shiny rectangle above the AR9331 is a 25 MHz crystal
• the small 6-pin chip near the antenna connector is a power voltage supervisor chip, in charge of cleanly resetting the AR9331 CPU in case of a power voltage drop. BTW, the antenna connector IS NOT a standard U-FL (IPEX) connector, it is an RF switch only used during factory calibration, not good for connecting an external antenna!
• all other parts are uninteresting passive components: all the ones near the DDR2 SDRAM are used to connect the AR9331 and the SDRAM with a matched impedance. The ones between the AR9331 and the antenna make up the RF network

Well, from my knowledge acquired with the TP-Link TL-WR703N pocket router, this is simply an implementation of Atheros’s AP-121 reference design (schematic here, although it is supposed to be under NDA).

Wait, where are these parts in the Arduino Yùn schematics provided on the Arduino Yùn product page? Here is the problem: they can’t be found anywhere… Moreover, there are some noticeable differences between the provided design files (“gerber” files) and the board you actually get: see _pepe_ post in the Arduino forum.

Oops, digging further: this schematic doesn’t contain a meaningful version number (only Rev. 010 in the frame) and is dated “Friday, August 30, 2013”, this appears to be the same as the one provided on the Yùn product page.

However, the PDF containing the layout and the gerber files are consistent: they have the same date “2013-08-30” in their frames, additionally giving a hint on the board revision number with the layout file name “dogStick-01-V03.PCB”.

My guess is that these files are related to Arduino Yùn R3, but my Yùn board (which contains the same changes as yours) has “R4” silkscreened (EDIT: actually in the bottom copper layer) on the bottom side near the bottom right corner of the PCB, so it looks like revisions don’t match.

There is also a ZIP file on the Yùn product page containing what appears to be the Orcad design file “DOGSTICK-V05(20140224).DSN”, but I don’t have Orcad and I can’t import it in either Altium or PADS (f someone has Orcad and can generate a PDF out of it, thanks). So it looks like it is V05?!? Not so easy! The same file (zipped under a different name!) is available on the Linino Arduino Yùn product page with a label “Arduino Yun R4 (ORCAD)” in front of it!

Even better, on the same Linino Arduino Yùn page, there is a PDF file with the label “Arduino Yun R4 Schematic (pdf)”. Its frame contains a date “Friday, February 28, 2014”, so it looks like it is newer indeed and corresponds to the Arduino Yùn R4 design. On the same page, there is an item “Arduino Yun R4 Gerber (pdf)”, but no link to download, of course!

What a mess! And you can’t trust this schematic anyway, as my board has 3 buttons (“32U4 RST”, “YUN RST” and “WLAN RST”), but I only see 2 in the schematic (“32U4 Reset” and “USER BUTTON”)!

It is obvious that the board you get is not the same as the one described in the design files: the ones provided seem to refer to a revision R3 of the board, whereas only revision R4 has been shipped since the beginning Moreover, the design files do not detail all the components that are nevertheless soldered on the same main PCB.

After 2 years of existence, it is unbelievable that the Arduino Team has not found the time to update the design files on the Arduino Yùn product page (or anywhere else BTW), and there is no technical reason why they would not provide the schematics for the whole board. It is also easier to understand why my clarification request on the Arduino forum never got an official answer.

Besides some obvious commercial reasons (the Arduino Yùn is selling like hot cakes…), I strongly suspect that the problem lies in the decision of laying out the Atheros AP-121 reference design straight onto the main PCB: by looking at the design files, it looks like the initial choice was to have a WiFi module containing this AP-121 design soldered onto the main PCB, but this turned out to be replaced by manufacturing a single PCB with all components on the same board for cost reasons.

Unfortunately, the AP-121 reference design being under NDA (Non Disclosure Agreement), it cannot be publicly disclosed (at least without Atheros consent), and is thereby incompatible with the Creative Commons Attribution Share-Alike license used by the Arduino Team.

At the light of these discoveries, can we still consider the Arduino Yùn as an Open Hardware platform? The answer is clearly NO.

Sadly, the promises on the Arduino home page no longer apply, since it is now a lie:

The boards can be built by hand or purchased preassembled; the software can be downloaded for free. The hardware reference designs (CAD files) are available under an open-source license, you are free to adapt them to your needs.

NodeMCU Review

It took 25 days to arrive (I guess I missed the first plane), but it eventually arrived yesterday! However, this is a standard delay for packages coming from China.

For those of you that don’t already know it, NodeMCU is a small board, based on the cheap ESP-12 WiFi module from AI-Thinker, itself containing a single-chip ESP8266 WiFi SoC. With an 80 MHz 32-bit embedded MCU (overclocking up to 160 MHz is possible) and built-in WiFi without required factory calibration for under $3, this chip is already interesting per se.

The ESP-12 is one of the available module containing an ESP8266 chip; it is becoming more and more popular because of its integrated WiFi PCB antenna and shield, supposed to provide FCC compliance, as the engraved FCC logo suggests it. However, without a proper genuine FCC ID, it doesn’t prove this fact, and looks more like a cheap marketing trick to make you buy this thing!

The NodeMCU board itself adds an USB/UART converter chip, an LDO power supply with proper decoupling (at last!), plus 2 miniature push buttons and what is the most important feature probably: it breaks out all ESP8266 pins to breadboard-compatible 2.54 mm pitch headers.

What distinguishes this module further from all the existing breakout boards out there is that it has been developed by user “zeroday” from the ESP8266 forum, who initially provided a Lua-based interpreter of the same name for the ESP8266 chip. As the NodeMCU Lua interpreter was first released as closed source, I feared that it was a hook for something to sell, as usual. It turned out I was wrong, when zeroday published the sources on Github a few days before Christmas last year.

Back to the received package: except my board has a yellow solder mask, it is exactly as the one depicted above.

The PCB design is good, but manufacturing is not as good: I received my board with 3 out of the 4 breakout tabs still attached, which is unusual. But besides this, the component assembly looks OK.

More unusual is the choice of a cheap CH340G USB/UART converter chip instead of the more common (in EU and US) FTDI, Silabs or Cypress chips. At $0.40, they certainly help to keep the BOM cost down, but finding a working driver for your PC platform may be tricky. Not a problem here with my Ubuntu Linux that has the driver built-in.

Using the first micro USB cable at hand, I connected it to my PC: the built-in LED flashes rapidly, but there is no other indication whatsoever that the board is working or not. Looking at the logs with “dmesg” confirms that the device enumerates correctly:

[32634.450508] usb 3-4: new full-speed USB device number 15 using xhci_hcd
[32634.467747] usb 3-4: New USB device found, idVendor=1a86, idProduct=7523
[32634.467754] usb 3-4: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[32634.467758] usb 3-4: Product: USB2.0-Serial
[32634.468531] ch341 3-4:1.0: ch341-uart converter detected
[32634.469380] usb 3-4: ch341-uart converter now attached to ttyUSB0


As I read that the device was working at 9600 bps, I fired “screen” as a serial terminal emulator:

sudo screen /dev/ttyUSB0 9600

No luck, nothing responding, no prompt, nada:(

I had to flash the device following this procedure under Linux in order to get the device working with the latest NodeMCU firmware found here. Basically:

git clone https://github.com/themadinventor/esptool.git
cd esptool
sudo python esptool.py --port /dev/ttyUSB0 write_flash 0x00000 nodemcu_latest.bin

Not being a specialist in Lua, I tried the different examples provided on the NodeMCU landing page. Most of them work out of the box, despite the fact that you have to be extra careful when typing in the commands, as Lua strange syntax is very picky (e.g. “:” vs. “.” when invoking methods). The “blinking LED” example doesn’t work, as the “led” object doesn’t seem to exist by default.

As a conclusion, the NodeMCU is a nice small cheap board for someone willing to discover WiFi for IoT without soldering and/or wiring hassles and without having to install any toolchain: the built-in Lua interpreter makes it trivial to test the main module features without having to compile any code. This comes at a cost though: you will have to learn yet another language with its own peculiar syntax and concepts. It really reminds me of bitlash for Arduino boards, although it is much more sophisticated, of course. NodeMCU now integrates a bytecode compiler, but I still wonder how much memory is available (especially RAM) for the actual user, and if this provides enough room for something more sophisticated than simple demos.