Choosing Components for a Design

Although it has been a while, my most recent post about the design of the Wireless Sensor Module discussed the power subsection. Today I’m going to briefly talk about the choices for some of the other components.


I knew I wanted to include the USB interface on the sensor module for several reasons:

  • Bootloader programming – simple re-flashing of the firmware image without using the debugger.
  • Changing parameters – having the ability to change update rates, calibration, channels, etc. dynamically.
  • Charging – the USB interface provides a convenient charging interface and I have 100’s of chargers and cables laying around.
Schematic capture of USB Interface I/O

Schematic capture of USB Interface I/O

The connector I chose is a Mini-AB ‘OTG’ type USB. I’ve put these on lots of designs that required a USB interface. The Mini provides better a more rigid mechanical attachment than a Micro, and my collection of USB cables with Mini-B far outnumber the ones with Micro connectors.

I placed an EMI-suppressing ferrite chip in series with the VBUS to filter power transients and noise that might be generated by the charger or USB port on a PC. This particular one allows 1.5A and offers 30Ω impedance @ 100MHz. I also included a 10nF decoupling capacitor.

The VBUS here is used as the source for the battery charger IC. This will also supply power to the board if the battery is disconnected or depleted. VBUS is also used connected to an input on the STM32, to detect when USB is connected to the board. This will allow the firmware to control the interface, enumeration, etc. when the cable is plugged into a PC.

Switches and LEDs

No embedded device is complete without the addition of indicators and switches for the user to interact with. On this design, I included a RESET switch that can be used to reset the STM32, and a switch that I’ve labeled “MODE” but can really be used for anything as configured in firmware. The intent was to have different sample and transmit modes that I could cycle through. At this point I haven’t yet written its use into the firmware. Both switches are active LOW, the MODE switch having a pull-up. The STM32 has an internal pull-up on the NRST input, so here I’ve included a footprint for an external pull-up, though it is marked with “DNF,” which means “do-not-fit.” I also included an 0.1uF capacitor to reduce the slew rate of the RESET switch.

Throughout my designs I will often include 0.0Ω resistors (jumpers) or footprints where no part may be needed. This pull-up is one example. This is done because you may not know at design time if additional components are needed, or to give yourself the flexibility to change something for testing. It is a minimal amount of effort to include an additional component (if you can afford the extra space), and a minimal additional cost during PCB manufacture. When given the choice between adding a few extra components during the design phase, and having to re-spin a PCB because you need to switch two pins, add filtering, reduce current, etc., it is much less costly to include them in the design phase.

Sometimes I also include 0.0Ω resistors in the VCC path of an IC. I do this so that if I am troubleshooting a PCB that has power issues, I can remove them systematically to determine where the issue might be. Also, if you remove the resistor, you have a convenient way of measuring the current consumption of an individual IC.

User switches and LED indicators.

User switches and LED indicators

For the LEDs, I wanted to be able to indicate when the device is taking a sensor sample as well as when the device is transmitting a data packet over-the-air. For these I used two green 0603 SMT LEDs and made them active-low to the microcontroller.


32kHz oscillator for the RTC

32kHz oscillator for the RTC

32MHz RF oscillator

32MHz RF oscillator

The data packets being transmitted needed to have timestamps, which means that the unit needs to be able to keep accurate time. In addition, I want to be able to sample and transmit at regular intervals. While the internal oscillators can be calibrated, including the 40 kHz LSI, the system can maintain more accurate time using an external 32.768 kHz crystal oscillator. This also allows the STM32 to run in a low-power mode that uses the RTC only to time events, extending the battery life of the device.

For this XTAL, I chose an Abracon ABS07 series device. They are small and cost-effective. I’ve used them before with success, but you have to be mindful of the load capacitance.

The RF oscillator has an allowable range of 32-44 MHz. The reference designs all spec 32 MHz, and the register settings are based around the frequency of this oscillator. For simplicity’s sake I went with the same frequency. It is also important to choose an oscillator that has a tight stability and tolerance when the application is RF/wireless, to prevent frequency offsets and drift. This particular crystal is 10ppm, but often times high-quality RF circuits will use TCXO (temperature-compenstated), VCO (voltage-controlled), or even OCXO (oven-controlled) type oscillators.

This XTAL is a TXC 7B series part.

RF Output and Antenna

The RF output of the CC1175 device needs to be impedance matched in the band of interest to the characteristic impedance of 50Ω as well as to the antenna if there is a mismatch. For this circuit, I used one of the TI-recommended antennas as well as a baseline matching network that was calculated in one of the reference designs.

RF Output Matching Network and Antenna

RF Output Matching Network and Antenna

For this particular circuit I am not too terribly concerned with RF efficiency, but in other devices what I have done in the past is use the RF Toolbox in MATLAB to create a matching network made of discrete elements, in this case L-networks. This requires the S-parameters of the source and sink (CC1175 and antenna). I don’t think that TI provides this information. This can also be done manually. One of the easiest-to-understand references for impedance matching I have come across is in Christopher Bowick’s RF Circuit Design. (Warning, Amazon link.)

One of my biggest issues with this design so far has been the antenna. To begin, the layout recommendations are confusing.

Layout recommendations for the Pulse W3012

Layout recommendations for the antenna

The chip antenna has two terminals, but the layout has a three-terminal footprint. The source terminal is basically shorted to GND. Most chip antennas like this have a source terminal, and the other terminal is either attached to GND or left open, sometimes even with microstrip termination. So this was unusual, but I followed the recommendations.

What makes this antenna even worse is the solderability. I placed it by hand, after reflowing the rest of the PCB. I should have included the antenna in the reflow process, because hand soldering is tricky with this part. You can only do it once, because the metallization layer COMES OFF if you try to re-solder it.

I started testing with this device and noticed immediately that it wasn’t radiating nearly as much as it should have. With the chip set to 0dBm, about 5 feet away I was seeing signal strength in the -70dBm range. That’s equivalent to 80m line-of-sight without accounting for other losses. So the first thing I did was cut the third terminal and immediately noticed an improvement. Thinking that maybe it was soldered incorrectly, I attempted to restore a connection between GND and the outside of the antenna with copper tape, and that is when I discovered that it would no longer solder.

Needless to say, I’ll be using another antenna for testing. I’ve already ordered some replacements to try out. Someone recently pointed me towards some stubby antennas made my Linx, the JJB series. They do require a counterpoise GND plane, which might not be big enough in this design, but they might be worth including on the design revision.

Hub Shields Arrived!

I’m getting a bit ahead of the posts here, but I just received the bare boards for the other end of the Wireless RH/Temp Sensor system.

On the other end of this system, there needs to be a device to collect the data being generated by the sensor modules. I chose to go with a daughter board to the BeagleBone Black, which already includes an Ethernet interface to push the data to a server. The shield (cape, etc.) contains the radio device for receiving the data, the standard cape EEPROM, another RH/Temp sensor, a buzzer and some LEDs for indication.

The board has already been designed, and I had three PCBs fabbed. You may recognize the signature purple solder mask, courtesy of OSH Park. Well they arrived the other day and I wanted to share.

Bare Hub Shield PCBs.

Bare Hub Shield PCBs.

Power Requirements

Now that the critical elements of the Wireless RH/Temp Sensor Module have been chosen, it’s time to determine the power architecture.

We’ve chosen the devices such that both the STM32 microcontroller and the TI CC1175 transmitter will be powered by the same voltage – 2.5V. One thing I’ve learned in doing mixed-signal designs is that you generally don’t want to share a voltage rail between the analog and digital submodules. The rationale is that in the digital domain IO lines are switching constantly, causing transient current requirements at the regulator. If your PCB is poorly laid out (interruption in the return path for a signal, coupled traces causing cross-talk, analog and digital traces adjacent to one another, mismatched trace impedance, etc.) then there is a possibility that these transients can cause noise in the analog circuits.

In low-power designs there may be no issues. In designs where high switching currents are required, or the power regulators are sensitive to changes in current, then it could easily become an issue.

One way to remedy this is to use separate regulators from the main system voltage rail. Another approach is to place EMI filters, spec’d for the correct frequency and impedance, in series with the regulator output to filter the voltage rails each to the analog and digital circuits. Having bigger output capacitors also helps.

Before I discuss the choice of regulators, let’s talk about the powerhouse, the battery. In the past I have had success with using single-cell Li-Ion packs, and coupling them with a TI Battery Charger IC. I have already designed circuits with the TI BQ24073, so there was an opportunity for some design re-use. This device has a power path circuit for using the battery and the DC input together to provide power to the circuit. The device also monitors the battery and has external resistor-based settings for the charge parameters. It allows the designer/user to select between USB 100mA, 500mA, or externally limited charge currents up to 1.5A. The output voltage is boosted to 4.4V, which will provide the source for the rest of the power section.

So we need to knock 4.4V down to 2.5V, and for this design I opted for using two separate regulators for the digital and RF circuits. Here, I opted for two TI TLV70225 LDOs in the SOT-23-5 package. They provide 300mA of current each, are simple to design in, and only require ceramic output caps.


Schematic capture of the charge IC and LDO regulators.

Schematic capture of the charge IC and LDO regulators.

For the battery, I chose a single-cell, 850mAh capacity, Li-Ion pack from Sparkfun. I have used these in the past and they work well. Some quick calcs based on estimations:

  • The CC1175 consumes ~26mA in transmit mode (@ 0dBm), 170uA in XOFF mode, and 0.5uA in power-down mode. Let’s assume it spends most of its time in XOFF mode. This is also spec’d at 3.0V, not 2.5V, so it will probably be lower.
  • It’s hard to estimate the dynamic consumption of the STM32, but in other projects with the mcu in stop mode with the RTC running, I’ve seen currents as low as 15uA, so I’ll use that for this estimation.
  • Quiescent current of the LDOs is spec’d as 30uA. There are two, so 60uA.
  • Quiescent current of the battery charger IC is spec’d at between 50uA and 1.5mA. Let’s assume worst case.

These are the major current consumers. There are various pull-ups and downs in the circuit, which can be considered as well, but I’m trying to get a rough estimate of standby life of the battery.

So, on the 2.5V rails, we can assume:

170uA + 15uA = 185uA

The power requirement on 2.5V then becomes:

2.5V * 185uA = 462.5uW

If we assume 85% efficiency from the regulators:

462.5uW / 0.85 = 544.1uW at the input

At 4.4V this becomes the input current estimate (including the q-current) of:

544.1uW / 4.4V = 183.7uA

Let’s assume the efficiency of the boost regulator in the charging IC is also around 85%:

544.1uW / 0.85 = 640.1uW (from the battery)
640.1uW / 4.2V (fully charged) = 152.4uA

With a capacity of 850mAh:

850mAh / 152.4uA = ~5577 hours of standby time (232 days).

That’s a significant amount of time, and of course this is all based on estimates. The battery will cut off at some point, reducing the available capacity. Also when the voltage begins to drop, the current increases through the boost regulator. Also, this doesn’t take into account the dynamic current when the device is awake and transmitting. So this would be a best case scenario. I think we will find that measurements of current are actually less, but we’ll test that at a later time.

Which Brain to Use?

With the widespread availability of devices today, you would be hard-pressed to find a microcontroller that didn’t meet the needs of simple hardware designs. A system such as this could easily be driven by an 8-bit core, like the ever popular Atmel AVR series devices, which are now driving millions of Arduinos worldwide.

As a side note, my embedded hardware design background began in the early 2000’s, using Motorola (now Freescale) 68HC11 devices. For anyone that doesn’t remember this series, it was extremely popular in the 80’s and early 90’s. The particular variant I was working with used EEPROM for the code space, and was UV-erasable. So, any changes you’d make in the firmware would require placing the devices under a UV lamp for a period of time to erase them before reprogramming. Often times they didn’t erase properly, and you’d end up with flipped bits in the code. The emulators for those chips were the size of a mini PC tower, with a complex array of parallel wiring and socket adapters. The firmware engineer at the time had also just transitioned to using a C compiler, instead of writing the code in Assembly Language. Why we were still doing all of this in 2001 was mind-boggling.

Motorola 68HC11

At that point I decided that for new designs it was time to transition to something more modern, with flash memory for starters. We ended up settling on the Atmel AVR series. It was a world of difference, being able to use C development IDEs, real-time debugging via JTAG, and the ability to erase and flash firmware in seconds. Over the course of my career there, I probably designed the ATMEGA128 into over 20 projects.



It wasn’t until a few years ago that I started venturing outside of the AVR realm. The demands of the projects I was working on were really too much for the Atmel chips. I started needing things like floating-point math, higher speed clocks, USB interfaces, Ethernet, etc. On several projects I went with a TI MSP430 device, which is quasi 16-bit. The ecosystem for the MSP430 series is very well established, and there are a plethora of development kits available. The TI CCS IDE is also pretty good if you don’t mind Eclipse. It can be slow and temperamental, but once you get a stable environment set up it tends to be rock solid.

I’ve also worked with Cypress PSoC3 devices, which have an 8051 core (8-bit) and a host of analog attachments on the chip. I was surprised with these at how easy the development environment was to use. Unfortunately my experience with these is in recovering someone else’s spaghetti code. I have messed around with the PSoC5 series (Cortex-M3) on their development kits, and my first impressions were generally good.

In the Wireless Sensor Module, I would be needing something with the following requirements:

  • Low-cost
  • Low-power
  • USB, SPI and I2C interfaces
  • RTC capability
  • Small package

I’ve been working a lot with the STM32 series devices, so I decided I would go with something in that line. This particular application doesn’t require much in the way of performance, and I’ve been wanting to work with the Cortex-M0 cores for a while now, so I settled on an STM32F042C6, a 32K Cortex-M0 in a TQFP-48 package. The intent is to have the mcu in sleep most of the time, waking up once per minute to sample the sensor and transmit a packet then going back to sleep. I was planning on running it with a small Li-Poly battery, ~800mAh. When the STM32F042 is in one of its low-power modes (with the RTC running), it should consume less than 10uA.

STM32 Schematic Block.

STM32 Schematic Block.

Since I’ve been doing a lot of development in the IAR EWARM IDE lately, I wanted to stick with that as the development environment. It’s not particularly aesthetic, but it’s fast and capable. For now, I’ve been using the Kickstart version, which is code-limited to 32K. I haven’t needed anything more, but I’ve gotten close. Unfortunately the full license is around $4,000.

Now that I’ve chosen the micro, it’s time to decide a few other things:

  • Battery + charger IC
  • Regulators
  • Peripherals
  • User interface hardware
  • Oscillators

I’ll address these in the next topic.

Intro to the Wireless RH/Temp Sensor Module

For a while now, I’ve wanted to have the capability to monitor isolated environments for changes in relative humidity and temperature over time. There are certain areas of our house that always seem hotter or more humid, especially in the summer. I’d like to have measurement nodes to confirm this by logging it over time, which will allow my to take some corrective action in the worst areas.

So the major requirements become:

  • Must be able to measure RH + Temp.
  • Must be wireless.
  • Must be battery powered.
  • Must allow remote data to be collected somewhere for future reference.

There are already available products on the market that do just this. One such product is the Wireless Sensor Tag System. These devices are small, relatively low-cost, battery powered, and wireless, with a backend for tracking and data. There are three things that I felt could use improvement, however: battery type/life, range, and the backend application.

Also, I like making things. So I decided to design my own. In addition to the above requirements, I had some additional ones:

  • Uses a Li-Poly or Li-Ion type battery.
  • Operates in the 900MHz ISM band.
  • Has some local intelligence.
  • Has a USB interface for battery charging, FW updates, and parameter changes.

I had the option of making the devices true IoT (Internet of Things) products by putting something like the TI SimpleLink WiFi devices on there, but I was concerned about battery life. Granted, the devices only need to wake up once a minute (or every five minutes, etc.,) transmit a data packet, and go back to sleep. Still, it takes time for a device to register on the network. By opting for just a low-bandwidth, low-power transmitter, the device can wake up and transmit a packet within several milliseconds, where WiFi can sometimes take 10’s of seconds to register on a network. According to the datasheet for the CC3100, TX mode can consume anywhere from 160-272mA.

The radio I decided to go with was the TI CC1175 transmitter. By comparison, the spec for transmit mode in the 900MHz band for a +10dBm output is 34mA. I chose this radio for several reasons: low-cost, low-power, flexibility of configuration, and ease of implementation. I’ve had experience with this series of radios before, so the interface feels familiar.

Full disclosure, I’m already pretty far along with this project, but I wanted to walk through the design process for everyone else. In the next post I’ll either detail the selection of sensor or micro.

The TX radio section of the wireless sensor module.

The TX radio section of the wireless sensor module.