DC/DC switcher for 5v TO 3v at 750mA in a TO-220 7805 footprint


An open source small DC/DC 3W switcher to drop 5V to 3V in a 7805 TO-220 pinout from Black Mesa Labs:

This post is an open source hardware design from Black Mesa Labs for a simple DC/DC converter for dropping 5V to 3.3V ( or adjustable to lower voltages via resistor selections ). The design is based on the PAM2305 from Diodes Incorporated, a great little 1 Amp step-down DC-DC converter in a small TSOT25 package. The PAM2305 supports a range of input voltages from 2.5V to 5.5V, allowing the use of a single Li+/Li-polymer cell, multiple Alkaline/NiMH cell, USB, and other standard power sources. The output voltage is adjustable from 0.6V to the input voltage.

More details at Black Mesa Labs site.

DIY Arduino PCB Pryamiduino


A how-to on designing a DIY Arduino PCB Pryamiduino from Bald Engineer:

Continuing the DIY Arduino tutorial series, this AddOhms episode shows how to create a PCB in KiCad. I make a joke that the original design was a rectangle, which I found boring and pointless. So instead, I designed a triangle to give the board 3 points. Get it? Puns! I am calling it the Pryamiduino. To be honest, I found not having a constraint to be a problem. By forcing a specific board size and shape, many decisions were more manageable.

More details at Bald Engineer’s blog.

Check out the video after the break.

Arduino controlled Dual Mono AK4490 DAC (part 3)

Arduino controlled Dual Mono AK4490 DAC

Here’s the part 3 of Dimitris’ Arduino controlled Dual Mono AK4490 DAC project we covered previously:

Following up on Part 2, it’s time to talk about the output stage.
This output stage is the brainchild of my friend Kostas, all I did was lay out the PCB.
It is a fully discreet single-ended class-A output stage, outputting ~2.4V RMS.

More details on Dimdim’s blog. If you missed part 1 and part 2, be sure to check it out.

ESP32 (32) – BLE, iBeacon

In my previous article I explained the Bluetooth Low Energy technology and the advertising process.

You learned that a BLE device can leverage the advertising packets to send data; in this case the device is called broadcaster and the devices which receive data are called observers.

The payload of an advertising packet has the following structure:


ADV ADDR is the device MAC address (this is the address displayed by the program developed in the previous article) and ADV DATA is a field, with a max length of 31 bytes, that contains one or more structures, each with 3 elements:

  • AD length is the total length (in bytes) of each data structure
  • AD type is the type of data contained in the structure
  • AD data is the real data

The official website of the Bluetooth Special Interest Group lists all the available AD types.

A device, for example, can transmit its local name using the AD type 0x09:


In scan mode, the Bluetooth driver returns to the program the received data (ADV DATA) in the scan_result->scan_rst.ble_adv array. This array contains uint8_t values and it’s size is scan_result->scan_rst.adv_data_len.

The Bluedroid library contains a method, esp_ble_resolve_adv_data(), which allows to get the value for a specific AD type passing the raw data. The header file esp_gap_ble_api.h contains definitions for the most common AD types:


In my Github repository you can find an updated version of the scan program. Thanks to what explained above, now the program can also display – if available – the name of the device:



A particular family of broadcaster devices are the iBeacons. These devices have been designed by Apple to allow interaction with IOS devices (iPhone …) based on location awareness. Let’s make an example: an iPhone can “notice” that it is close to a particular iBeacon, associated with a room in a museum, and therefore offer the user a brief guide to the exhibited works.


iBeacon specifications are available on Apple’s developer portal. iBeacons work transmitting advertising packets with  specific payload (ADV DATA):


The first structure has AD type = flags (0x01). Each bit has a different meaning, usually iBeacons use 0x0A value for AD data.

The second structure has type = 0xFF, that is Manufacturer Specific Data. The Bluetooth standard allows the different manufacturers to use this ID to transmit custom data. The total data length is 25 bytes (0x1A – 0x01 that is the length of the AD type field).

Apple specifications further subdivide the AD data field in several elements:


The first field is the manufacturer/company; iBeacons normally use the code 0x004C, assigned to Apple Inc. The next two fields define the iBeacon type and have a fixed value (0x02 e 0x15). The UUID field, together with the Major and Minor ones (optional, they can have a value of 0) uniquely identifies each iBeacon.  (insieme con i campi Major e Minor (facoltativi, possono essere impostati a 0) identificano univocamente il singolo iBeacon. Finally, the TX power field contains a measurement, one meter away from the iBeacon, of the received power and is useful for  precisely estimate the distance between the phone and the iBeacon itself.


I developed a program for the esp32 chip which turns a relay on if it detects a specific iBeacon. Via menuconfig you can configure the UUID of the iBeacon which triggers the led, the pin the led is connected to and the timeout – in seconds – after which the program turns the led off if the iBeacon is not detected anymore. You can moreover set a power threshold to control the distance at which the iBeacon is detected.

To parse the received packet and get the UUID value, in my program I used the method described in this article (parsing using a struct).

The program verifies if the received packet (event ESP_GAP_SEARCH_INQ_RES_EVT) was sent by an iBeacon checking that the packet length is 30 bytes and that its header contains the values listed above:

// iBeacon fixed header
ibeacon_header_t ibeacon_fixed_header = {
  .flags = {0x02, 0x01, 0x06},
  .length = 0x1A,
  .type = 0xFF,
  .company_id = 0x004C,
  .beacon_type = 0x1502

It compares the fixed header with the received one using memcmp, function that compares two blocks in memory:

if(memcmp(adv_data, ibeacon_fixed_header, sizeof(ibeacon_fixed_header)))
  result = true;

The source program is available in my Github repository, here’s a video that shows how it works:

Free PCB Sunday: Pick your PCB


We go through a lot of prototype PCBs, and end up with lots of extras that we’ll never use. Every Sunday we give away a few PCBs from one of our past or future projects, or a related prototype. Our PCBs are made through Seeed Studio’s Fusion board service. This week two random commenters will get a coupon code for the free PCB drawer tomorrow morning. Pick your own PCB. You get unlimited free PCBs now – finish one and we’ll send you another! Don’t forget there’s free PCBs three times every week:

Some stuff:

  • Yes, we’ll mail it anywhere in the world!
  • Be sure to use a real e-mail in the address field so we can contact you with the coupon.
  • Limit one PCB per address per month please.
  • Like everything else on this site, PCBs are offered without warranty.
  • PCBs are scrap and have no value, due to limited supply it is not possible to replace a board lost in the post

Be the first to comment, subscribe to the RSS feed.

App note: Current sharing in parallel diodes


Application note from STMicroelectronics on the performance of each diode in a parallel diode connection and how the forward voltage dispersion can have a great impact over thermal effect on the current imbalance. Link here (PDF)

The use of diodes in parallel is commonly found in power electronic design. An important consideration for this practice is the current sharing between diodes due to the difference of electrical characteristics. This application note highlights the cause of the behavior of several diodes are connected in parallel. Some recommendations will be given to help the designer to produce a safe design. An electro-thermal model is described which simulates the current and junction temperature of each diode for given application conditions. This tool is illustrated using an example.

App note: Hot plug insertion startup time delay for eFuse


App note from ON semiconductors about time delay on start up in conjunction with eFuse to compensate voltage spikes that can falsely trigger them. Link here (PDF)

The eFuse protection devices are used for limiting the system load current in the event of an overload or a short circuit. Many applications employ ON Semiconductor eFuses at the power input stage of the system between the main power input connector and DC−DC converters or power regulators. Such applications often tend to experience a voltage spikes and transients during a hot-plug events, especially when the long cables are used at the power input.

Although ON Semiconductor eFuses are extremely immune to voltage transients and eFuses with the Overvoltage clamp feature provide a fast response when limiting the output voltage during transients, sometimes various applications require a time delay between the hot-plug input voltage application and enabling of the eFuse in order for the input voltage to be stabilized before turning on the eFuse.