Examining a vintage RAM chip, I find a counterfeit with an entirely different die inside


Ken Shirriff writes, “A die photo of a vintage 64-bit TTL RAM chip came up on Twitter recently, but the more I examined the photo the more puzzled I became. The chip didn’t look at all like a RAM chip or even a TTL chip, and in fact appeared partially analog. By studying the chip’s circuitry closely, I discovered that this RAM chip was counterfeit and had an entirely different die inside. In this article, I explain how I analyzed the die photos and figured out what it really was.”

See the full post on his blog.

ESP32 (21) – Mutual authentication

After having published my post about how to implement a webserver on the esp32 chip, some readers correctly warned me that everyone, once connected to the wifi network, could control the relay and asked me how to limit access to the webpage.

A classic solution (that I also used in this previous tutorial) is to ask the user to enter a password. It’s very easy to implement, but has a negative aspect, that is you have to type the password everytime you need to switch the relay.

You can avoid asking the password everytime the user access the page if you implement a login page and keep the user logged in using a session cookie as I’ll explain in a future tutorial!

Today I’ll show you how to protect your website using a feature of the SSL/TLS protocol: the mutual authentication.

Mutual authentication

Everytime you connect to a website using the https protocol, the server which hosts the site sends to your browser the SSL certificate of the site. Thanks to this certificate, you can verify the identity of the server and establish a protected connection to it:


The TLS protocol also offers the possibility for the server to require a certificate from the client: this means a two-way authentication, that is server and client authenticates each other using SSL certificates:


With this authentication method, a user has only to install on his device the client certificate (and the corresponding private key) and choose which certificate to send to the server if more than one is present:


The authentication with SSL certificates is therefore based on the principle of something I own (for example, a key) and not of something I know (for example, a password).


Generally speaking, SSL certificates can be:

  • self-signed
  • signed by a Certification Authority

The first ones are perfect for internal use or for testing, while the second ones, normally signed by trusted CAs, are widely used in production environments or on the Internet. Sometimes you probably received this warning message when surfing on the Internet:


that means that your browser doesn’t trust the certificate sent by the server because it’s self-signed or signed by a non trusted CA.

For this tutorial, I’m going to use OpenSSL as a certification authority to create the certificates we need. If you’re using the toolchain provided by Espressif, you don’t need to install anything else because OpenSSL is included.

First create a folder that will contains all the files required by OpenSSL to operate as a CA in your home directory:

mkdir myCA

Now move into that folder and create some empty files:

cd myCA
mkdir csr certs crl newcerts private
touch index.txt
echo 1000 > serial


Copy the certification authority‘s configuration file (openssl.cnf) from my Github repository into the myCA folder. Open the file and change the main path accordingly to your system:


Now you have to generate the private key and the certificate for the CA. Let’s start with the key (its length will be 2048bit, enough to ensure good security):

winpty openssl genrsa -aes256 -out private/ca.key 2048

(all the commands must start with winpty only if you’re using Windows!)

You’re prompted for a password; it’s very important to remember it because you’ll have to type it everytime you use the CA:


Now generate the CA certificate (with a duration of 3650 days, that is 10 years):

winpty openssl req -config openssl.cnf -key private/ca.key -new -x509 -days 3650 -sha256 -extensions ca_cert -out certs/ca.cer

You have to enter some informations… the only mandatory is the common name which is the name of the CA, that will be included in all the certificates the CA will sign. At the end of the process you can open the file (ca.cer) and verify name and duration:


Let’s now generate the server and client certificates. The steps are the same for both:

  • generate a new private key – openssl genrsa
  • generate the CSR (Certificate Signing Request) file – openssl req
  • sign the CSR file with the CA to obtain the final certificate – openssl ca

Server certificate:

winpty openssl genrsa -out private/esp-server.key 2048
winpty openssl req -config openssl.cnf -key private/esp-server.key -new -sha256 -out csr/esp-server.csr
winpty openssl ca -config openssl.cnf -extensions server_cert -days 365 -notext -md sha256 -in csr/esp-server.csr -out certs/esp-server.cer

Client certificate:

winpty openssl genrsa -out private/esp-user.key 2048
winpty openssl req -config openssl.cnf -key private/esp-user.key -new -sha256 -out csr/esp-user.csr
winpty openssl ca -config openssl.cnf -extensions usr_cert -days 365 -notext -md sha256 -in csr/esp-user.csr -out certs/esp-user.cer

As said before, the client device must own both the certificate and the private key. You can merge certificate and key in a single p12 (or pfx) file with the following command:

winpty openssl pkcs12 -export -out esp-user.pfx -inkey private/esp-user.key -in certs/esp-user.cer

The way you install the P12 file on your device depends on the specific operating system it runs: on Windows you only need to double-click the file and follow the import wizard.

SSL webserver

The source code for the program running on the esp32 devboard is available in my Github repository.

First you have to copy in the prioject folder the certificates (CA and server ones) and the private key for the server certificate and include them – as text data – in the program (I’ve already explained how to include binary files in my previous post):


To implement the SSL protocol I’m using the mbedTLS library, included in the esp framework.

First include all the required header files:

#include "mbedtls/platform.h"
#include "mbedtls/net.h"
#include "mbedtls/ssl.h"
#include "mbedtls/entropy.h"
#include "mbedtls/ctr_drbg.h"
#include "mbedtls/debug.h"
#include "mbedtls/error.h"

Before being able to accept SSL connections, you have to define and initialize all the variables you’re going to use:

// mbed TLS variables
mbedtls_ssl_config conf;
mbedtls_ssl_context ssl;
mbedtls_net_context listen_fd, client_fd;
mbedtls_entropy_context entropy;
mbedtls_ctr_drbg_context ctr_drbg;
mbedtls_x509_crt srvcert;
mbedtls_x509_crt cachain;
mbedtls_pk_context pkey;
// initialize mbedTLS components

Now parse the certificates and the private key and store them in the variables:

mbedtls_x509_crt_parse(&cachain, ca_cer_start, ca_cer_end - ca_cer_start);
mbedtls_x509_crt_parse(&srvcert, espserver_cer_start, espserver_cer_end - espserver_cer_start);
mbedtls_pk_parse_key(&pkey, espserver_key_start, espserver_key_end - espserver_key_start, NULL, 0);

Tell the library which variables to use for CA chain and own certificate and require the mutual authentication (MBEDTLS_SSL_VERIFY_REQUIRED):

mbedtls_ssl_conf_ca_chain(&conf, &cachain, NULL);
mbedtls_ssl_conf_own_cert(&conf, &srvcert, &pkey);
mbedtls_ssl_conf_authmode(&conf, MBEDTLS_SSL_VERIFY_REQUIRED);

After having configured other elements of the library (the random number generator and the debug function) you can bind it to the standard TCP port for the https protocol (443) and accept new incoming connections:

mbedtls_net_bind(&listen_fd, NULL, "443", MBEDTLS_NET_PROTO_TCP);
mbedtls_net_accept(&listen_fd, &client_fd, NULL, 0, NULL);

After having accepted a connection, you only have to call the function:


during the handshake process the library sends to the client its own certificate and require the one from the client, verifying that this is signed by the specified CA: the mutual authentication is implemented!

After the handshake, the program is similar to the previous example, you only have to use mbedTLS specific send/receive functions (mbedtls_ssl_read e mbedtls_ssl_write).


Solid-state joystick


Paul Gardner-Stephen writes:

Early in the year, one of my colleagues, Damian, showed me one of these strain-gauge solid-state joysticks that they were using as part of the undergraduate engineering curriculum.
Their goal was to teach the students how to read strain-gauges. But I immediately saw the applicability for making a no-moving-parts super-robust joystick for the MEGA65 and all other retro computer users.

See the full post on his blog.

FPVising a Eachine H8 mini

The Eachine H8 mini quadcopter (here on Banggood) is without dubt one of the most popular quadcopters, both for its low price (10-15€) and for its good performance in terms of speed and flight time.

This quadcopter does not include a camera and therefore it cannot be used to flight in FPV (First Person View) mode… in this post I’m going to show you how to modify it to add this feature with few euros (or dollars ;) )!

There are other interesting mods for this quadcopter, for example silver13 developed some opensource alternative firmwares (acro and dual-mode) while goebish decoded its communication protocol and it’s now possible to control the miniquad with other transmitters.

Shopping list

To modify your H8 mini you will need:

In addition you can buy a dedicated antenna, but you can also replace it with just some wire.


Smoke test

Before working on the miniquad, let’s perform a smoke test on all the components to verify if they work individually.

Let’s start with the camera and the transmitter: solder the camera’s yellow wire to the VIN (Video IN) pin of the transmitter and the black wire to GND (ground). Now solder a piece of wire to the ANT (antenna) pin of the transmitter and, using a 5v external power supply, power both the camera and the transmitter:

h8fpv-02 h8fpv-03

Using a 5.8GHz receiver you can verify that they work fine:

h8fpv-04 h8fpv-05

Now test the step-up regulator. Connect a 1 cell LiPo to pins  + and – and verify with a multimeter that the output of the regulator is near to 5V (voltage required to power the other components):

h8fpv-06 h8fpv-07


Once verified that all the components are working, you can start modifying the quadcopter.

With a screwdriver remove the 4 screws to open the plastic case and remove the printer circuit board:

h8fpv-08 h8fpv-09

Identify the two pads connected to the battery and solder two wires; you’ll use them to power the new components:

h8fpv-10 h8fpv-11

Connect the outputs of the step-up converter to pins GND and VCC of the transmitter, then solder the two wires to its input pins. I also added a small switch to be able to turn the FPV system on/off independently:

h8fpv-12 h8fpv-13

With some hot glue stick the converter and the transmitter to the bottom of the quadcopter and the camera on the front of it. Connect the camera to the transmitter as already explained during the smoke test and solder the antenna. If you chose to use a wire as antenna, you can add a small plastic tube to keep it in vertical position:

h8fpv-14 h8fpv-15

Your H8 mini is now ready for its first FPV flight!

h8fpv-16 h8fpv-17

Microcontroller action potential generator


Scott Harden writes:

Here I demonstrate how to use a single microcontroller pin to generate action-potential-like waveforms. The output is similar my fully analog action potential generator circuit, but the waveform here is created in an entirely different way. A microcontroller is at the core of this project and determines when to fire action potentials. Taking advantage of the pseudo-random number generator (rand() in AVR-GCC’s stdlib.h), I am able to easily produce unevenly-spaced action potentials which more accurately reflect those observed in nature. This circuit has a potentiometer to adjust the action potential frequency (probability) and another to adjust the amount of overshoot (afterhyperpolarization, AHP). I created this project because I wanted to practice designing various types of action potential measurement circuits, so creating an action potential generating circuit was an obvious perquisite.

See the full post at SWHarden.com.

Check out the video after the break.

App note: How RF transformers work and how they are measured


Application note from Mini-Circuits about transformers, this time the RF transformers. Link here (PDF)

RF transformers are widely used in electronic circuits for
* Impedance matching to achieve maximum power transfer and to suppress undesired signal reflection.
* Voltage, current step-up or step-down.
* DC isolation between circuits while affording efficient AC transmission.
* Interfacing between balanced and unbalanced circuits; example: balanced amplifiers.

App note: Transformers


App note from Mini-Circuits on transformer types and some basics of them. Link here (PDF)

The purpose of this application note is to describe the fundamentals of RF and microwave transformers and to provide guidelines to users in selecting proper transformer to suit their applications. It is limited to core-and-wire and LTCC transformers.


App note: USB hardware design guide


An app note from Silicon Labs with design guidelines for implementing USB host and device applications using USB capable EFM32 microcontrollers. Link here. (PDF!)

This document will explain how to connect the USB pins of an EFM32 microcontroller, and will give general guidelines on PCB design for USB applications. First some quick rules-of-thumb for routing and layout are presented before a more detailed explanation follows.
The information in this document is meant to supplement the information already presented in Energy Micro application notes AN0002 Hardware Design Considerations and AN0016 Oscillator Design Considerations, and it is recommended to follow these guidelines as well.

PRECIsion Power SUpply project


PreciPSU, a high performance power supply project from Mare & Gal Electronics:

PreciPSU is an attempt to build high performance power supply. The idea started few years ago but it was never realised. Some major target performance specs are as follows:

  • three isolated channels
  • around 50W per channel
  • 24V/3A output per channel
  • lowest possible ripple at fastest response
  • small size
  • programmable via USB
  • nice housing with minimalist user interface (2 plugs per channel, knob, button and small display

Read the full post here.