BML HDMI video for FPGAs over PMOD

BML HDMIvideoforFPGAs over PMOD

Here are two open-source-hardware HDMI  video boards for adding digital video to FPGA platforms with standard PMOD connectors from Black Mesa Labs:

The BML 3bit HDMI over single-PMOD uses 7 of 8 available LVCMOS 3.3 pins on a single PMOD to provide 3bit color ( R,G,B 100% On or Off ). Example Verilog design drives 800×600 using a 40 MHz dot clock. The TI TFP410 is very versatile in the resolutions it can generate and is really just limited by the clock that the FPGA can provide and the data rates the PMOD connectors are capable of.

More details at Black Mesa Labs homepage.

Teardown of an Extech 380460 milliohm meter


Kerry Wong did a teardown of an Extech 380460  miliohm meter:

This is a highly specialized instrument, all it does is measuring low ohm range resistance (from 200mΩ to 2000Ω in five ranges) and nothing else. The meter came with a rugged case which is handy for field use, although its portability is hampered by the requirement of a wall outlet.
Since this meter is designed for low resistance measurement, it came with a set of 4 wire Kelvin clips. The stock leads are not my favorite though, as the design uses rubber rings to hold the two clip pieces together. One issue of this (instead of proper spring tensioned clips) is that the tension is quite weak and it is difficult to make secure contact with small dimension leads. Also, the rubber ring is likely to lose tension and fail over repeated use.

See the full post on his blog.

Check out the video after the break.

Hands-on with the PocketBeagle: a $25 Linux computer with lots of I/O pins


Ken Shirriff shares his experience with a low-cost, compact Linux computer PocketBeagle:

The PocketBeagle is a tiny but powerful inexpensive key-fob-sized open source Linux computer. It has 44 digital I/O pins, 8 analog inputs, and supports multiple serial I/O protocols, making it very useful as a controller. In addition, its processor includes two 200-MHz microcontrollers that allow you to implement low-latency, real-time functions while still having the capabilities of a Linux system This article discusses my experience trying out different features of the PocketBeagle, along with some technical details.

More details at Ken Shirriff’s blog.

App note: Choose the right power supply for your FPGA


Designing a power supply for FPGA includes multiple voltage, ripple management and power sequencing, here’s an app note from Maxim Integrated. Link here (PDF)

Field-programmable gate arrays (FPGAs) and complex programmable logic devices (CPLDs) require 3 to 15, or even more, voltage rails. The logic fabric is usually at the latest process technology node that determines the core supply voltage. Configuration, housekeeping circuitry, various I/Os, serializer/deserializer (SerDes) transceivers, clock managers, and other functions all have differing requirements for voltage rails, sequencing/tracking, and voltage ripple limits. An engineer must consider all of these issues when designing a power supply for an FPGA.

App note: Current-sense amplifier doubles as a high common mode instrumentation amplifier


Application note from Maxim intergrated on utilizing a boost converter and a current-sense amplifier to form a regulator that derives +5V from -48V without isolation. Link here (PDF)

Instrumentation amplifiers (IAs) are used where gain accuracy and dc precision are important, such as in measurement and test equipment. The downside of IAs is the cost. However, inexpensive current-sense amplifiers handle high common-mode voltages and share some traits with IAs. As a result, in some applications, such as a ground-referenced -48V to +5V power converter, current-sense amplifiers can replace IAs, thereby reducing cost.

Bus timer project


Limpkin published a new build:

For once, this project was not for me… it was for my wife !
Every morning she takes the bus then train to go to work. If she misses her train, she has to wait for more than 30 minutes for the next one. Not missing her bus is therefore quite important.
Where we live every bus station has a display letting you know in real time when the next bus will be there. My first thought was to reverse engineer its RF signal but something easier then came to mind.
In the very same bus stations, a small QR code brings you to a web page displaying the very same “minutes before bus arrival”… HTML parsing therefore made more sense given that I was fairly busy with other projects.

See the full post on his blog.

ESP32 (28) – MQTT and SSL

Security is a very important aspect for MQTT brokers. In a previous article you’ve already learned how to implement authentication and authorization. The weakness in that configuration was that credentials were transmitted in cleartext; it was therefore possible, for an attacker who can sniff the network traffic, to read and use them to impersonate a legitimate client.

Today I’ll show you how to encrypt the communication channel between client and broker using SSL certificates. I’ll also explain how to write a program for the esp32 chip to send data to the broker using the secure channel…

SSL certificate

To be able to encrypt the communication, mosquitto requires a server certificate.

First generate the private key (RSA with a length at least 2048 bits):

openssl genrsa -out mosquitto.key 2048

Then create the CSR file:

openssl req -new -out mosquitto.csr -key mosquitto.key

type the required information; the most important of which is the common name that will identify the server:


Now sign the CSR file with your Certificate Authority (or send it to a public / corporate CA) to generate the certificate:

openssl ca -config openssl.cnf -extensions server_cert 
 -notext -in mosquitto.csr -out mosquitto.cer


Create the ssl subfolder in the folder where you installed mosquitto and copy into that folder the certificate, its private key and the certificate of the CA:



Open the mosquitto.conf file and add the following lines:


The first line changes the TCP port mosquitto is normally listening to (1883) to the default port for SSL connection, 8883.

The following 3 lines set the path for server and CA certificates and for the private key that corresponds to the server certificate. The last one, which is not compulsory, forces the use of the TLS v1.2 protocol, the most secure one at the moment of writing.

Once the server has been configured, you can start it (-v is to enable the verbose output):

mosquitto.exe -c mosquitto.conf -v

To be able to use the mosquitto_pub and mosquitto_sub tools, you now have to add new parameters:

mosquitto_sub.exe -p 8883 -t test --cafile .\ssl\ca.cer --insecure
mosquitto_pub.exe -p 8883 -m 20 -t test --cafile .\ssl\ca.cer --insecure

With -p you specify the TCP port of the server, with –cafile the path of the CA certificate which signed the server certificate mosquitto uses and finally with –insecure you configure the two clients not to verify that the certificate’s common name (in my example mymosquitto.local) corresponds to the server name.

You can avoid using the –insecure switch if you generate a certificate with a common name the exact name of the server/PC which runs mosquitto or – alternatively – if you add a DNS alias which resolves the common name of your certificate with the IP address of the server and run the clients with -h commonName


Tuan PM developed a library (espmqtt) for the esp-idf framework that implements a complete MQTT client. Moreover, the library does support secure connections, you can therefore use it to connect to an MQTT broker with TLS enabled.


Copy the content of the Github repository in the components folder of your project and include the library’s header file in your source code:

#include "mqtt.h"

The MQTT client is configured using the mqtt_settings struct:


The most important parameters are:

  • the server (host) that runs the MQTT broker (you can use the IP address or the DNS name)
  • the TCP port (port) the server is listening to (default is 1883 or 8883 if SSL is enabled)
  • username and password if the server requires authentication
  • one or more callback functions the espmqtt library will call when the corresponding event occurs
the espmqtt library does not copy the parameters in an internal struct. It’s therefore very important that the mqtt_settings variable has a global scope and it’s defined outside a specific function.

Your program can interact with the MQTT client implementing its callback functions.

For example the connection or disconnection from the MQTT server occurs as follows:


The connect_cb and disconnect_cb functions perform the “real” connection and disconnection, while connected_cb and disconnected_cb functions are executed after the corresponding activity is completed (= the client successfully connected to the server). Your program usually doesn’t need to re-implement the main functions, but will implement the ones related to events, to execute actions (for example subscribe a topic) when a specific event occurs.

After having configured the client, you can run it with:


Once connected to the server (connected_cb callback function) you can subscribe or unsubscribe a topic with:

void mqtt_subscribe(mqtt_client *client, const char *topic, uint8_t qos);
void mqtt_unsubscribe(mqtt_client *client, const char *topic);

and publish data to a topic with:

void mqtt_publish(mqtt_client* client, const char *topic, 
  const char *data, int len, int qos, int retain);


I prepared an example to show my esp32 devboard sending data to a mosquitto server, with SSL enabled.

I connected to the devboard an HTU21D sensor as explained in a previous article and my program reads, every 5 seconds, the temperature and humidity values and sends them to the broker. I used a very handy opensource program, HelloIoT, to create a dashboard and display the received data.

The source code of the program and the configuration of the HelloIoT dashboard are available in my Github repository; here’s a short video of the demo: