App note: Automotive reverse battery protection diode


Super Barrier Rectifier™ (SBR) from Diodes Incorporated offers good power efficiency compared to normal PN junction diode and design simplicity compared to MOSFETs reverse protection. Link here (PDF)

This application note compares the performance of Diodes Inc. Super Barrier Rectifier™ (SBR) as an automotive reverse battery protection diode with other solutions. An overview of the reverse battery protection requirement and the qualification standards are also presented.

App note: A closer look at LVDS technology


A general overview of Low Voltage Differential Signaling (LVDS) from Diodes incorporated. Link here (PDF)

With the increase in demand for high throughputs, current technologies are becoming less efficient. Data transmission devices like RS-422, RS-485, SCSI and other devices are limited in data rate and power dissipation. With LVDS, data rate has increased tremendously to meet the demand in the high bandwidth market and yet still consumes less power than many current devices. LVDS offers low-power. low-noise coupling, low EMI emissions, and switching capability beyond many current standards. LVDS applications can be used anywhere where high data rate is required and needed to be transfer over a distance. LVDS technology can be found in printers, flat panels, switches, routers, audio/video digital signal processing and many more other applications.

ESP32 (15) – mDNS

When you surf on the Internet, the DNS (Domain Name System) service has the job of “translating” (resolve) the hostnames to the corresponding IP addresses.

If, for example, you type in your favorite browser, your computer queries the DNS server – usually the one managed by your provider – and gets from it the IP address of (one of) the servers that host Google website:


A home network usually doesn’t include a DNS server, so if you need to communicate with a device you must know its IP address. It may be easy to find the address of a device if such address is statically assigned or if the device itself has a display that can show it:


On the contrary, if the IP address is dynamically assigned (for example by the DHCP server running on your router) and the device can’t display it, it may be hard to find which is the address of the device. It may help the Multicast DNS (mDNS) protocol; let’s learn how to use it with our esp32 chip.


mDNS is a network protocol, defined in RFC6762, which allows to resolve hostnames without the need of a DNS server in the network.

mDNS is the protocol we use also when connecting to a Raspberry through the hostname raspberrypi.local as explained for example in my tutorial about the connection to a Raspberry Pi Zero.

Its behavior is very simple. When a device needs to know the IP address of another device on the network, it sends a multicast UDP packet with the request. Since it is a multicast packet, it reaches all the devices connected to the network. The response is again sent out using a multicast packet, so all the devices can receive it and update their resolving table:


By default, mDNS resolves only hostnames with the .local suffix.


The esp-idf framework esp-idf includes a component that implements the mDNS protocol; in this tutorial I’ll explain how to use it to answer mDNS queries. The complete source code is available in my Github repository; let’s analyse the most important part.

First of all, using the menuconfig you can configure two parameters:


MDNS_HOSTNAME is the hostname that will be resolved by the esp32 chip (for example “esp32“) while MDNS_INSTANCE is a description of the device (es. “ESP32 Demo Board“).

It’s very easy to setup the mDNS server that answers incoming queries. After having established the connection to the wifi network (this part of the program is based on a previous example) you have only to create a new instance of the server and configure it with the parameters defined above:

// mDNS server instance
mdns_server_t* mDNS = NULL;
// create and configure the mDNS server

Do not forget to include the component’s header at the top of your code:

#include "mdns.h"

That’s all! When you run the program, the mDNS server waits for incoming requests and, if those requests are for the name MDNS_HOSTNAME.local, it answers with the IP address of your board.

mDNS for Windows and Linux

To be able to test the program, your computer has to “speak” the mDNS protocol.

If you’re running Windows, you can install the Bonjour Print Services tool from Apple. Even if it was designed to discovery and configure network printers (hence its name), this service does support the full mDNS protocol and it’s therefore the best solution with Microsoft OSes.


Under Linux, you can use the Avahi daemon, that is usually already installed on the most common distributions.

After having configured your PC, you can test the program with the command ping esp32.local (change the name with the one you configured):



Using the mDNS component, you can design devices, based on the esp32 chip, that can be easily identified on the network, without the need to add external components like a display or a serial connection. Moreover it’s simpler, specially for non-expert users, to use a standard name (“esp32.local”) then looking for a “strange number” (the IP address) that can also change over time.

In this tutorial I’ve only explained how to write a program that answers mDNS queries: this is the most common use of the protocol but it’s not the only one: the component included in the framework also allows to send queries or to broadcast different services… Espressif published a sample program that leverages also some of these features.

Beacon Keyer


Lukas Fässler from Soldernerd published a project writeup showing how he built a PIC-based beacon keyer:

This is likely the first ham radio related project that I document here on this blog
But my very first PIC project was a beacon keyer that I made for my father, HB9BBD. That was in 2013. A beacon keyer is a great project to get started with microcontrollers since it’s not much more than a fancy way of blinking an LED.

Project info at Soldernerd homepage and the GitHub repository here.

Raspberry Pi Zero, audio output via I2S

Pi Zero is a small board – part of the Raspberry family – designed for embedded applications where space is a constraint. The low cost (about 10€ for version W, with wifi connectivity) and the ability to run different operating systems makes it the ideal choice for different applications (media centers, data loggers…).

It may be sometimes difficult to buy a Raspberry Pi Zero… it’s indeed often out of stock on the different webstores. A help may come from the ThePiLocator website, which displays in realtime the availability of the different Pi Zero boards on the official stores.

Raspberry Pi Zero unfortunately doesn’t offer a dedicated audio connector: audio output is indeed normally performed via HDMI:


Although this is perfect for applications like media centers (where audio and video are reproduced by the monitor/television connected via HDMI), it’s not handy in embedded applications where you only need to play some audio files (for example to add audio warnings). Even if you can find on the market some devices that extract audio flows from the HDMI stream, those devices are often expansive and bigger than the Raspberry Pi Zero itself!

A very simple solution, well explained in a tutorial by Adafruit, is to generate the audio signal using two PWM (Pulse Width Modulation) pins and a low-pass filter made with some passive components. This solution has the advantage of being very cheap and easy to make; by contrast the sound quality is not very high.

In today’s tutorial I’ll show you how to generate high quality audio using the I2S bus.


I2S is a serial bus designed to connect different audio devices and to transfer audio signals in digital form.

The bus specification has been published by Philips in 1986. The I2S bus requires at least 3 signals:

  • clock (labelled as SCK – serial clock o also as BCLK – bit clock)
  • word select (WS, sometimes defined also LRCLK – left/right clock)
  • serial data (SD, or also SDATA…)


We can use this bus to communicate audio data between our Pi Zero and an amplifier that accepts audio input via I2S bus:


What you need

I chose an I2S amplifier based on the MAX98357 chip by Maxim. This chip offers 3.2W in output and you can connect directly a small 4 ohm speaker. Both the breakout board with the Maxim chip and the speaker are from Adafruit:

I brought the components from an italian reseller, melopero:

pizero-i2s11 pizero-i2s12

The breakout board is shipped with a terminal block (for the speaker connection) and with a pin strip header for the power supply and the I2S bus; both of them have to be soldered to the board:

pizero-i2s13 pizero-i2s14

The speaker comes with a JST connector that I removed to be able to screw the wires in the terminal block:

pizero-i2s15 pizero-i2s16

Connections and configuration

You need 5 wires to connect the MAX98357 amplifier to the Raspberry Pi Zero:

  • 5V Raspberry -> Vin
  • GND Raspberry -> GND
  • PIN18 Raspberry -> BCLK
  • PIN19 Raspberry -> LRC
  • PIN21 Raspberry -> DIN

Hare are a couple of photos that show the connections listed above:

pizero-i2s17 pizero-i2s18

Let’s now move to the software configuration, starting from an updated version of the Raspbian distribution.

Open with a text editor (for example nano) the file /boot/config.txt

sudo nano /boot/config.txt

comment (add a # at the beginning of the line) the line dtparam=audio=on and add two new lines – dtoverlay=hifiberry-dac dtoverlay=i2s-mmap:


create a new file, /etc/asound.conf

sudo nano /etc/asound.conf

and add to the file the content in the screenshot below:


The last step is to reboot the Raspberry.

Test and mps-youtube

Let’s try to play a sample audio file with the command:

speaker-test -c2 --test=wav -w /usr/share/sounds/alsa/Front_Center.wav

If connections and configuration are ok, you should hear a voice saying “front – center” in loop; stop playing with CTRL-C.

To be able to play mp3 files, you need a player. I chose mpv:

sudo apt-get install mpv

Let’s hear again the historical sentence by Neil Armstrong – One small step for men, one giant leap for mainking – directly from the Nasa website:



In the end of this post, I’d like to show you how to use a program, mps-youtube, to play audio tracks from Youtube using only a command-line interface. Because of it’s written in Python3, you have to install version 3 of the language interpreter and one if its package managerspip:

sudo apt-get install python3 python3-pip

Now you can install mps-youtube and its requirements with:

sudo pip3 install youtube-dl mps-youtube

Run the program with the command mpsyt. First you have to configure the player you want to use (mpv):


Then you can search for a video, typing the search string preceded with /. Alternatively, if you already know the video URL, you can play it with the command playurl <url>:


Noise when changing track

It may happen that when changing the track or at the beginning of a new reproduction, you hear some noise coming from the speaker. The reason is well explained in this thread on the Adafruit customer forum (thread I also contributed to): the cause is the frequency change of the I2S clock signal.

The easiest way to solve the problem is to continuously play a silence signal of a fixed frequency (for example 48KHz):

aplay -t raw -r 48000 -c 2 -f S16_LE /dev/zero &

Run the above program before starting mpv or any other player and you’ll find that all the noise is gone!


Here’s a video showing mps-youtube in execution:

App note: iCoupler® Isolation in CAN bus applications


Application note from Analog Devices on CAN bus system isolation. Link here (PDF)

The intention of this application note is to give the user a brief overview of the CAN bus protocol, focusing on the system physical layer, as well as an understanding of why isolation is so important to the system. This application note also details how to implement isolation in a CAN bus system using Analog Devices’ iCoupler products.

App note: Safety considerations and layout recommendations for digital isolators


Application note from Silicon Labs about end user safety against high voltage shock that are designed together with digital isolators. Link here (PDF)

This application note details the creepage and clearance requirements of an isolator type component, such as a digital isolator, used to provide protection from electric shock. It also details layout recommendations to enhance a design’s robustness and ensure compliance with end safety standards.