Author Archives: Alex Wende

Enginursday: Understanding Thermal Resistance

via SparkFun: Commerce Blog

One of the byproducts of electronics is heat. Understanding how hot you can expect your components to get can not only save you from burning yourself, but it can also keep them working longer.

When parts get hot, you can use a heatsink, but will a small heatsink work, or will you need a large heatsink? How do you know if passively cooling will be enough, or whether you’ll need to add a fan to your cart before you place that order? Our latest tutorial on thermal resistance can help answer some of these questions.

New!

Understanding Thermal Resistance

May 14, 2020

Discussing what thermal resistance is, how it’s used for thermal management, and how to maximize the life of your project.

The tutorial not only explains what thermal resistance is, but also how effective different materials are at transferring heat, from PCBs to metal fins.

The tutorial provides a few real world examples using voltage regulators to compare the numbers that were calculated. For example, with a maximum input voltage of 35V and 1.5A of output current, this 5V regulator wouldn't need a heatsink if it was connected to a 12V source and only drawing 200mA of current, right? For a linear regulator, wasted power is the difference between the input and output voltage, multiplied by the current draw, or 1.4W.

Using the datasheet, we can see that the thermal resistance in this case would be 50°C/W. That would mean the junction temperature of the regulator would be around 70°C above room temperature (23-25°C), which would put the absolute temperature up to 95°C! How does that compare on the bench?

thermal image of a 5V regulator without a heatsink under load

Only off by a couple of degrees! So if you too are tired of using your fingers to see if you should be using a heatsink, this thermal resistance tutorial might have exactly what you need!

comments | comment feed

Enginursday: Fixing the ESP32 Thing Plus

via SparkFun: Commerce Blog

Recently, we released v20 of the ESP32 Thing Plus board. After releasing v10, we received some feedback that some boards weren’t able to upload code and the CP2102 was getting hot. It wasn’t a widespread problem, but it was a consistent problem for people that had the issue. When I was testing the board for example, I was able to upload code using both the USB ports on the computer, as well as my powered USB hub without issue. The USB power adapters didn’t cause any problems for me, except one, which helped figure out what was causing the problem.

FLIR image of a toasty CP2012

The problem was a result of inrush current, specifically with switch mode power supplies. Switch mode power supplies have soared in popularity because they allow for smaller and more efficient power supplies, and can be found in nearly all electronics from phone chargers to desktop computers. They achieve this by increasing the AC frequency, which allows the transformers to be smaller by switching at a higher frequency, and by using a buck converter, they switch current through an inductor to charge a capacitor to a specific voltage.

Buck Converter Switching Circuit

Without diving too much into the theory, inductors store energy in a magnetic field and resist the change in current. When an inductor sees a change in current, it tries to maintain that current by increasing the voltage until they run out of energy. This is why in our relay boards we use a diode across the coil to limit flyback voltage spikes, which could cause damage the switching transistor, as shown below.

alt text

Click the image for a closer look!

Finding the problem


Back to the ESP32 Thing Plus though. Now that I had a power supply that was able to replicate the problem some of the users were experiencing, I was able to connect my oscilloscope to the VBUS pin to see what was happening:

Oscilloscope trace of VUSB

After seeing the peak voltage of 8.24V, I went back to the datasheet for the CP2102 and saw that the absolute maximum input voltage on VBUS was 5.8V. I performed the same test with a linear power supply, which still had a small overshoot, but at only 5.68V it was at least below the limit:

Linear Power Supply Response

I suspected the problem was a result of inrush current and I turned my attention to the ceramic capacitors, which have a low equivalent series resistance (which you can learn more about here). Having a small ESR value is good because it allows the capacitor to respond quickly to voltage ripple, but when it first charges up it can cause a large initial spike in current. At first it might be tempting to just remove capacitors, but as the waveform below shows, without capacitors the ripple from the switching power supply would generate too much high frequency noise on the VBUS rail.

Oscilloscope trace of VUSB without bypass capacitors

Without the capacitors though, we can see that the initial voltage spike is gone. Knowing that the low ESR capacitors are causing a problem but that removing capacitors creates a new problem, I needed to find the middle ground, which can done by adding intentionally adding ESR to capacitors with a small value resistor in series with the capacitor. Another problem, however, is that because of where the capacitors are placed, adding a series resistor to the capacitors would add a lot of time reworking the board to move traces and vias.

Highlight of Capacitors connected to VBUS

Before investing the time moving traces around, there was more room available around the CP2102, which gave me another idea. After checking with the datasheet again to see that the input current for the CP2102 was around 20mA during normal operation, I wanted to see if adding a resistor in series between VBUS and the supply pins of the IC could fix the problem. After using my decade resistance box, I settled on value of 10 ohms, which produced the following result:

Oscilloscope traces on the high side and low side of the 10 ohm resistor

The yellow trace is on the high side of the resistor connected to VBUS, and the blue trace is connected to the low side of the resistor connected to the supply pins of the CP2102. As you can see, the spike still makes it through the resistor, but instead of reaching a peak voltage of 8.3V it only peaks at 4.48V. The time scale of 5us/div makes it look like the CP2102 drops back down to around 3V and stays there, but the actual voltage drop with this supply is around 200mV and gets to a steady state voltage within 200us.

As engineers, the goal is to have a test procedure that can thoroughly test your design to identify limits and fix them before it lands in the hands of customers. But just like when the Raspberry Pi added USB-C, mistakes can still happen when you use components for the first time.

comments | comment feed

Enginursday: How to Build a Levitating Light

via SparkFun: Commerce Blog

A couple years ago, I showed off a project where I made a levitating light.The post had some traction initially, and slowly fell back into the shadows of the internet...or so I thought. Recently, there's been an increase in the comments from customers that were trying to build one themselves but having some difficulty getting it working. If you didn't see it, below is the original video I filmed for the post.

Because of the renewed interest, and the complexity of the build, a short video doesn't go into enough detail. So I wanted to revisit the project and make a tutorial that walks through the more intricate details involved. If you were someone that saw the post and wanted to make it but needed more information, or if this is your first time hearing about it and you would like to build one, check out our new tutorial!

New!

Magnetic Levitation

November 20, 2019

This tutorial will show you how to build a magnetic levitation circuit using common parts

comments | comment feed

Enginursday: Using an ESP32 for Home Automation

via SparkFun: Commerce Blog

In a previous Enginursday, I showed off our MQTT tutorial using an ESP32 Thing and a Raspberry Pi. I mentioned at the end that you could use open source software such as Home Assistant to have your ESP32 control your house, and after many months the wait is finally over.

New!

Using Home Assistant to Expand Your Home Automations

May 9, 2019

An introduction to Home Assistant, an open source home automation hub.

In this new tutorial, we load Home Assistant (specially Hass.io) on to a Raspberry Pi and get MQTT back up and running. Unlike the previous tutorial, with Home Assistant you can use much more than just MQTT. You can add Z-wave devices, smart thermostats like Nest, Amazon Alexa, Google Assistant and much more. By having control over both the hardware and software, you can use Home Assistant to create automations that are triggered from MQTT and control devices on other protocols. If you'd like to learn how to create a remote trigger switch over MQTT to control a WiFi plug, check out the tutorial linked above!

comments | comment feed

Enginursday: Using Both ESP32 Cores

via SparkFun: Commerce Blog

For the last year I’ve been working on and off on my OLED clock code. If you haven’t read my previous blog posts, you can read about part one here, and a follow up here. But as a quick overview, I’ve been working on a clock that uses our ESP32 Thing to communicate with a Network Time Protocol (NTP) server to get the current time and display it on my OLED displays. With the WiFi radio, I can also scan for the available access points and provide the password to the access point I’m trying to connect to. The problem is the scan takes a few seconds to complete, and during that time, the displays freeze until the scan is complete.

wifi configuration page

Occasionally, some of the NTP servers from this list can go offline without a warning. So as a backup, I check all of the servers until I receive a UDP packet. With a 1000ms timeout, if I lose my Internet connection, I have to wait 14 seconds before I’m able to update the time again. As a workaround, I tried updating the time after each failed attempt, but everything I tried resulted in the ESP32 crashing and rebooting.

NTP code

That’s when I had fellow Funion Engineer Andy recommend I use the other core of the ESP32. Honestly, I hadn’t thought of that. After doing some digging, I came across this tutorial by RandomNerdTutorials.com. After uploading the duel LED blink code, I started to understand how to use it.

/*********
  Rui Santos
  Complete project details at http://randomnerdtutorials.com  
*********/

TaskHandle_t Task1;
TaskHandle_t Task2;

// LED pins
const int led1 = 2;
const int led2 = 4;

void setup() {
  Serial.begin(115200); 
  pinMode(led1, OUTPUT);
  pinMode(led2, OUTPUT);

  //create a task that will be executed in the Task1code() function, with priority 1 and executed on core 0
  xTaskCreatePinnedToCore(
                    Task1code,   /* Task function. */
                    "Task1",     /* name of task. */
                    10000,       /* Stack size of task */
                    NULL,        /* parameter of the task */
                    1,           /* priority of the task */
                    &Task1,      /* Task handle to keep track of created task */
                    0);          /* pin task to core 0 */                  
  delay(500); 

  //create a task that will be executed in the Task2code() function, with priority 1 and executed on core 1
  xTaskCreatePinnedToCore(
                    Task2code,   /* Task function. */
                    "Task2",     /* name of task. */
                    10000,       /* Stack size of task */
                    NULL,        /* parameter of the task */
                    1,           /* priority of the task */
                    &Task2,      /* Task handle to keep track of created task */
                    1);          /* pin task to core 1 */
    delay(500); 
}

//Task1code: blinks an LED every 1000 ms
void Task1code( void * pvParameters ){
  Serial.print("Task1 running on core ");
  Serial.println(xPortGetCoreID());

  for(;;){
    digitalWrite(led1, HIGH);
    delay(1000);
    digitalWrite(led1, LOW);
    delay(1000);
  } 
}

//Task2code: blinks an LED every 700 ms
void Task2code( void * pvParameters ){
  Serial.print("Task2 running on core ");
  Serial.println(xPortGetCoreID());

  for(;;){
    digitalWrite(led2, HIGH);
    delay(700);
    digitalWrite(led2, LOW);
    delay(700);
  }
}

void loop() {

}

For my application, I wanted to keep everything WiFi related to core0, while updating the displays was handled by core1. You can see my full code in my GitHub repository, but here’s a snapshot of what I added.

Snapshot of task1 code

You can more or less treat the while loop as a second main loop. By moving my webserver handleClient() function into Task1’s loop, every client is automatically handled by core0. There were a few gotchas for me, however. The time library has the ability to automatically update the time, but it will use core1. I was able to get around this manually updating the time by using a non-blocking, 10-second delay and calling the NTP request function. I also ran into an issue where creating the task caused the ESP32 to crash, which I was able to work around by using vTaskDelay() function. The issue could have also been a result of not changing the size of the stack in the setup.

I’ve been making slow and steady progress, including working on a clock using our new LuMini 8x8 Matrix LEDs that I’m hoping to be able to show off in the near future. But in the meantime, have you used both cores to parallel tasks for your ESP32 project? If this is the first time you’ve heard about using both cores on your ESP32, what could you see it being useful for? Let us know in the comments below!

comments | comment feed

Enginursday: Introduction to MQTT

via SparkFun: Commerce Blog

The Messaging Queuing Telemetry Transport (MQTT) protocol is a publish/subscribe messaging protocol that works on top of your home TCP/IP network. It provides a fast and reliable way to connect your IoT devices together and create responses to messages.

MQTT Nodes

Every MQTT network needs a broker. The broker is the heart of the MQTT network and is just a server that receives information from devices, also known as clients, and distributes that information to other clients based on the topic.

Topics are arranged in a directory-like structure. A topic might be “LivingRoom,” or “LivingRoom/Light” if you have multiple clients within that parent topic. The subscriber client will listen for incoming messages from the subscribed topic and react to what was published, such as “on” or “off.” Clients can subscribe to one topic and publish to another as well. If the client subscribes to “LivingRoom/Light,” it might also want to publish to another topic like “LivingRoom/Light/State,” so that other clients can monitor the state of that light.

With home automation services like Home Assistant that can run on a Raspberry Pi, you can easily integrate your own MQTT clients with your commercial IoT devices to create additional temperature nodes for your smart thermostat, or maybe just a basic remote switch to control the lights in your house without having to get up, for maximum laziness.

To see how to do that, stay tuned for a new tutorial dedicated to Home Assistant. In the meantime however, if you’d like to learn more about MQTT and how to get started using just a Raspberry Pi and ESP32 Thing, check out the new tutorial below.

New!

Introduction to MQTT

November 7, 2018

An introduction to MQTT, one of the main communication protocols used with the Internet of Things (IoT).

comments | comment feed