Project Design Walkthrough: Airsoft Tracer Unit, Part 3

Get Started with Altium Upverter, Sign Up Now

Upverter Expert - Project Design Walkthrough_ Airsoft Tracer Unit, Part 3

We are back to work on the Airsoft Tracer Unit we started in Part 1 and continued in Part 2. We are building a unit that fits on the end of an airsoft gun and exposes the dark plastic BBs traveling through to UV light, exciting the luminescent material on the BB. This will make the BB glow brightly, making it easy to see during night games, or indoors. In previous articles, we selected our top level components, prototyped, and extensively tested the photogate for detecting the BB. We also ruled out the use of an LED lighting power supply for limiting the current on the UV emitters. In the first article, I mentioned looking at using an SR Latch to hold the state of the photogate after a BB passed through, but hoped that we would not need to do that.

In this article, we’ll be writing some code to run on an LPC11U24. We will be using the MBED online compiler platform to get the basics of our code written for the project, and see if we can do away with the SR latch. Ideally, we should be capturing the edge change of the signal quite rapidly so we can also use the LED unit as a chronograph as well as for ensuring the UV emitter array is only on when the BB is traveling past it.

Microcontroller Test Setup

In Part 2 of this series, we were able to test the photogate in real-world conditions using a 3D printed holder for the light gate components, and using that, we got some traces from the test board with the oscilloscope. We could use the same setup for testing the microcontroller code, however, it’s a little cumbersome to use such a setup for testing purposes. Therefore, I’m setting up a function generator to create a square wave that will closely simulate the timing of the live test I ran. I’m using a 30Hz square wave, which translates to a pulse width of 33.3ms. The square wave is present on two channels, the second of which has a phase of 353° relative to the first. In the airsoft world, 30 rounds per second is considered to be a moderate to high fire rate, which makes this a realistic test speed. The signal going low for 33.33 microseconds (99.9% duty cycle) matches what we measured previously quite well for the highest speed rounds, and the 353° phase of the second channel gives a 613μs gap between the first and second channel firing, simulating a BB traveling through the tracer unit.

Oscilloscope screenshot showing an active low pulse on the yellow channel and similar but delayed pulse on the cyan channel
Generated signal simulating BB entrance (yellow) and exit (cyan) with difference in time between the pulses of 613.6μs 

By using a function generator, we have a ‘best case scenario’ signal that we can use to develop firmware that will prove out the concept and give us reliable timing information to work with.

Using MBED

This code is being developed using MBED, which is an online compiler (which can also be installed on a computer) that uses an open source hardware abstraction layer for ARM Cortex M0 to M4 series devices and is developed by both ARM and the community. This means the code compiled with MBED is portable across many different devices without having to change controller-specific startup code or specific registers for each device’s peripherals. This is similar to the Arduino library, but only for ARM controllers. The online compiler provides a good user experience and makes collaborating with teams easy through built-in source control. There’s a wide range of useful functions built in, as well as many libraries for specific external devices published by the community that are easy to pull into your project.

Because it supports such a diverse range of controllers, my colleagues and I have experienced frustrating bugs that tend to be very platform-specific. For example, on one microcontroller, the timer has a 32-bit implementation, thus overflows after about 35 mins, but on another microcontroller, the timer for the same function has a 64-bit implementation and doesn’t exhibit the same failure. Also, due to the hardware abstraction layer, some portions of code can take significantly longer to execute than if you had used the register/peripheral directly with controller-specific code. The very slight delay this introduces is a common aspect of all hardware abstraction libraries (like Arduino), and is just something you need to work with for the convenience of the library. The platform-specific bugs do eventually get fixed when reported, but it can be a little frustrating when you come across one, and switching to another microcontroller can resolve the issues.

That being said, the bugs are few and far between, and code quality in MBED is generally very high. The platform allows rapid prototyping and evaluation of many microcontrollers to optimize cost, and makes development easy. Although the code for this project is going to be quite simple, timings need to be fairly tight to ensure the UV emitters turn on quickly and don’t stay on too long after the BB has exited the unit. The emitters generate a lot of heat, and we are doing away with current limiting, so to save them from premature failure we need to keep them on for the shortest period possible.

Software Requirements

In part 1, we looked at the overall specifications/requirements for the device, but didn’t go into details for the firmware. This is a very simple device, so it’s software requirements are brief.

Required Functionality:

  • Detect first photogate transition to low level signal.
  • Turn on UV LEDs while the BB transits the tracer unit.
  • Detect second photogate transition to low level signal.
  • Turn UV Emitters off when BB exits the tracer unit.
  • If the exit hasn’t been detected after 700μs, turn the UV emitters off.

Future “nice-to-have” functionality would include a Bluetooth chronograph with memory, allowing you to look back at velocity consistency at the end of the game.

Initial Test Code

We can implement this code in one of two ways:

  • Using a loop to poll the input pins to look for a state change.
  • Using interrupts to execute code when the pin experiences the changing edge we are looking for.

I’m going to go down the interrupt route, as the amount of code we need to run when the interrupt fires is very small, so implementation is going to be very easy. My main concern is whether the interrupt will be raised by the LPC11U24 microcontroller, and makes its way through MBEDs code to my user code quickly enough. If the delay is too long, it might make this infeasible.

A polling loop is an effective way to implement this functionality too, but if we have some code that will take a long time to run inside the loop, such as future Bluetooth functionality, it could block loop iteration for long enough to cause the microcontroller to completely miss the signal transition from high to low. On the other hand, with an interrupt, that long-running code will be paused while the interrupt is handled, and then execution will continue once the interrupt service routine is complete. This allows us to still perform any long-running tasks we may need in the main loop without having to worry about losing a pulse as a BB passes through the light gates.

Programming the LPC11U24

I’m starting out my code with the mbed_blinky template. This code just flashes LED1 on the dev board on and off every 200ms.

The first thing I like to do is set up some definitions for the pins I’ll be using on the microcontroller. This makes changing between dev boards easy, and makes it very clear where all the connections go if you pick the project up again at a later date, or are designing the schematic to go with the circuit board.

#define PIN_GATEONE P0_7 // p21
#define PIN_GATETWO P0_17// p22

#define PIN_LED2 p15 // for oscilloscope to watch

#define PIN_LEDOUT P1_8 // this is LED1
#define PIN_STATUSOUT P1_9 // this is LED2

I’ve defined my pins for both gates, a signal for my oscilloscope to watch, a status LED that will be flashed by the main loop, and another that will flash in time with the oscilloscope watch pin.

In a larger project, I’d have all the definitions in a separate header file to make it so I didn’t need to scroll through all the definitions at the start of the file. It makes it a lot easier to move pins around as you’re routing a circuit board to have all the definitions in one place with recognizable names, rather than having to hunt through multiple areas of code to change pin definitions.

Next, we need to define the IO objects. There are two interrupts for the light gates, and 3 digital outputs for the LEDs. That’s all the project requires—it’s nice and simple.

InterruptIn gateOne(PIN_GATEONE);
InterruptIn gateTwo(PIN_GATETWO);

DigitalOut led(PIN_LEDOUT);
DigitalOut led2(PIN_LED2);
DigitalOut status(PIN_STATUSOUT);

After this, we have two very simple functions to toggle led and led2 on or off depending on the interrupt that gets fired.

void triggerIn() 
{
    led = led2 = 1;
}
void triggerOut()

{
    led = led2 = 0;
}

triggerIn is for the first gate, with the BB going into the tracer, and triggerOut is for the second gate, where the BB is going out of the tracer.

Finally, we get to our main()function. This is going to turn all the LEDs off immediately on boot, and then configure the interrupts to trigger on the photogate edges.

int main() 
{
led = 0;
led2 = 0;
status = 0;


// Interrupt configuration
// Rising edge for end of BB transit through the gate
gateOne.rise(&triggerIn);

// Falling edge for start of BB transit into gate.
gateTwo.fall(&triggerOut);


while(1) {
status= !status;
wait(0.2);
}
}

The main loop is simply going to flash the status LED (LED2) on and off every 200ms.

Compiling the code is all done online, and programming is as simple as dropping the downloaded hex file onto the LPC11U24’s USB flash drive and hitting the reset button.

Oscilloscope screenshot showing the two pulses from the previous figure and the microcontroller response on the magenta channel
Introducing channel 3 (magenta) with the microcontroller response

It looks like it’s doing what it’s meant to do. There is a bit of a delay as we’d expect, but what’s most worrying to me is it seems to be jittering around a lot.

Oscilloscope screenshot showing pulse width and delay overlay on top of the previous figure
The oscilloscope provides us with pulse width data and delay data. The microsecond deviation is worrying.

Using the oscilloscope to measure this jitter, we can see from the falling edge of channel 1 (yellow) to the rising edge of channel 3 (purple) that we have an average delay of 19.73μs. However, the deviation is unacceptably high at 7.79μs. The total deviation of the pulse width is only 3.38μs, which I find interesting. The code should have highly repeatable results, so the delay and pulse width should be rock solid. The oscilloscope is in high-resolution mode, so we can detect as small as 97.14ns of deviation from the function generator pulse.

After some investigation, I removed the status LED flashing, and more importantly the 200ms wait call. Even though the code should essentially be paused during the wait call, it appears the wait state perhaps takes longer to interrupt than executing code does!

Similar to the figure above, but with more consistent delays and nanosecond deviation levels
All the delay and width measurements are now in nanoseconds!

Simply removing the wait call from the code gives us an absolutely stable pulse width and delay between the edge transitions. It’s actually significantly more repeatable than my new function generator is on average, which is quite encouraging for the code.

Improving the Code

We now have something that can switch on and off if the timing is right, but it’s fairly easy to get this code into a bad state. While the code is reading the signal reliably, messing with the function generator outputs (such as turning one off) makes it unhappy. It’s a valid proof of concept to show the interrupts are stable, however the code wrapping them is not, and it needs a few extra checks and balances in place.

bool triggeredState = 0;

I’m going to introduce a global variable to determine if the LEDs are active or not. I could check the led/led2 variable, but a global bool is going to execute a few nanoseconds faster, as well as make the code more readable and maintainable.

bool triggeredState = 0;

I’m also going to need to implement some code to ensure we don’t have the LEDs on for more than 700 microseconds, so we’ll need a Timer and a couple of timestamp objects.

Timer sysTime;
us_timestamp_t gateStartTime;

The Timer and gateStartTime are global. We’ll also add a local timeCheck variable to main(), which would also make the code more legible and maintainable even though we don’t strictly need it given the implementation.

us_timestamp_t timeCheck;

Now that we have the variables set up, we need to start the sysTime timer in the main() function, so I’ll do that right after we set the LED outputs to be off.

sysTime.start();

Next, I’ll relocate the contents of the interrupt routines into new functions so we can call them safely from other locations in the code. Because of the way MBED implements the interrupt service routine, we could call the ISR directly. Nevertheless, I feel it looks cleaner to have the ISR serve the single purpose of just handling the interrupt. If we were implementing the ISR directly with the microcontroller GPIO peripheral, it would need to be in it’s own single purpose function too.

void ledActivate()
{
led = led2 = triggeredState = 1;

gateStartTime = sysTime.read_high_resolution_us();
}

void ledDeactivate()
{
led = led2 = triggeredState = 0;
}

The ISR then gets changed to first check the triggeredState variable before calling these functions.

void triggerIn() 
{
if (!triggeredState)
ledActivate();
}

void triggerOut()
{
if (triggeredState)
ledDeactivate();
}

Finally, our main loop gets changed to be a check to see if the UV emitters have been on for longer than they are allowed.

while(1) 
{
// check for missed second gate
if (triggeredState)
{
timeCheck = sysTime.read_high_resolution_us() - gateStartTime;

if (timeCheck > LED_TIMEOUT)
{
ledDeactivate();
triggerTransitionRead = 1;
}
}
}

This will check the definition LED_TIMEOUT which is set to 700. If the LED outputs are on for longer than 700μs, the LEDs will be deactivated.

Oscilloscope screenshot showing active low pulse on the yellow channel and no pulse at all on the cyan channel and the finite response we expect on the magenta channel
Response is as we expect with the exit signal on channel 2 (cyan) removed.

With the device programmed, and the second channel on the function generator disabled (simulating the second gate missing the BB entirely), we now have a 716.8μs pulse. If we needed exactly 700μs, we could definitely optimize this further, however the code is doing exactly what it needs to at this point.

Oscilloscope screenshot showing no pulse on the yellow and magenta channels and an active low pulse on the cyan channel
It’s also as we expect with the entrance gate pulse (yellow) removed.

As we’d expect from the code, with no start pulse on channel 1, there is no reaction from the microcontroller.

Oscilloscope screenshot showing _ on the yellow channel and _ on the cyan channel and _ on the magenta channel

Finally, with both function generator channels enabled, our pulse is as we’d expect to see—switching on with the first pulse and off with the second.

Long Term Testing

I wanted to make sure we wouldn’t run into any overflows anywhere, so I left the setup running for around 9.5 hours, or 1,000,000 pulses. At the end of the period, the scope looked exactly as I left it, with everything functioning nominally. For the next 24 hours, I would switch on or off a channel on the function generator every time I walked by it, and at the end of the 24 hour period the device was still functioning well.

It appears that, for this project, MBED is going to be the perfect mix of functionality, ease of use, and speed of development. We also ended up not needing any latching of the signal, as the microcontroller is very capable of catching the pulse from the light gate, which will simplify the electronics further.

One Final Change

In the first article in this series I mentioned that I wanted to use the LPC11U12FHN33 microcontroller due to its compact size and low cost. The code I’ve compiled for the LPC11U24 *should* work on the LPC11U12 just fine, however, MBED have mentioned in several forum posts that you should really only use firmware for the exact chip configuration that is on the dev board, including the packaging, or weird things can happen. A friend of mine had this issue recently, in which he had compiled code that worked great on his dev board, but exhibited some strange behavior in his product which used a different package. I certainly can’t blame MBED for this, as most compilers would want you to select the exact part number you are compiling for. That being said, the LPC11U24 in the /401 package on the dev kit has a fairly large footprint—larger than I’d like to use on the circuit board for this.

As we’re only making a couple of these, the extra cost per unit is fairly negligible for a microcontroller upgrade when we are installing over hundreds of dollars (USD) worth of LEDs on the boards. I also have the MBED supported Embedded Artists LPC11U35 breakout board, which features a QFN package microcontroller instead of the QFP on the LPC11U24 dev board. This package change saves a significant amount of board real estate.

So after a quick change of target board in MBED and a switch of the input/output pins, the code is compiled and running on the LPC11U35 instead.

Oscilloscope image showing the response of an LPC11U35 instead of the LPC11U24
The response of the LPC11U35 instead of the LPC11U24

What I find very interesting about the code running on the LPC11U35 is that somehow, we have a much shorter period between the interrupt and the output pin state change. Both microcontrollers offer a 50MHz max speed and are running on a 12MHz crystal oscillator and, ostensibly, have the same architecture internally.

Well, whatever the cause, I’ll happily use this as an excuse to switch to the LPC11U35! A 24 hour test run with the LPC11U35 was also highly successful.

Next Time

We now have the test firmware completed and working reliably. We’ve selected our final microcontroller, and all of our electronics are tested (other than the basic linear regulator used to drive the microcontroller, which doesn’t need any prototyping). We’re finally ready to start on the PCB design in Upverter.

In the next article, we’ll be tackling the schematic capture, PCB layout, and output generation of the manufacturing files to send off to a PCB fabricator.

Which Types of PCBs are Best for Different Designs?

Get Started with Altium Upverter, Sign Up Now

Upverter Expert - Which Types of PCBs are Best for Different Designs

As part of our best practices and information for new designers and hardware startups, we want to give new designers the information they need to choose the right PCB for their next project. Any PCB is intended to provide a physical support for an electronic system and its components. The complexity of different types of PCBs varies widely, depending on the function of different circuits. If you’re designing a PCB for the first time, we’ll show you the different types of PCBs that will hopefully provide inspiration for your next project.

Rigid PCBs

As the name states, these boards have a rigid substrate which prevents bending or warping. These are usually made of solid, rigid material like fiberglass weaves, but more demanding industrial or automotive applications may require ceramic or metal core substrates. With the number of layers ranging from one to more than ten, they are the most common type of PCBs on the market.

Single-sided PCB

Just like its name suggests, a single-sided PCB consists of a single layer of conductors and components. There is usually a solder mask over the copper layer, and silk-screen can be used to mark the positions of different components. Despite the low-cost, the utility of these boards is limited because of the design complexity limitation. Due to only one surface available for connections the area of the board can grow very fast to accommodate all the components and connections.

Layers in a single-sided PCBSingle-sided PCB

Double-sided PCB

Double-sided PCBs are similar to single-sided except the conducting layer is on both sides of the substrate. Now the connections can run on both sides of the PCB, hence it occupies a smaller area or can have more complex circuits. The connection between top and bottom layer is made using plated holes called “vias”. These boards are used for moderately complex circuits. It is generally not a good idea to try and design high-speed or high-frequency PCBs on double-sided boards as grounding and power distribution can be a real challenge, especially as the number of components increases.

double_sidedLayers in a double-sided PCB

Multilayer PCB

Multilayer PCBs have several layers of copper separated by insulating laminate materials. Connections between layers are also made using vias. Typical multilayer boards start with four layers, and the layer count grows for more complex (and costly) boards. The extra planes can be used for routing, power distribution, and grounding planes, which helps to reduce crosstalk and electromagnetic interference (EMI). A four-layer board is usually a good place to start for a moderately complex board that will run at high speed (faster than TTL logic) and/or high frequency (usually hundreds of MHz or higher).

Layer stack in a multi-layer PCBLayer stack in a multi-layer PCB

Flexible PCBs

Rigid-Flex PCB

Rigid-Flex PCBs are a middle ground between one of the previous types of PCBs and a flex PCB (see below). These boards are best used in applications where a board requires precise molding to its enclosure or when different sections of a board need to move with the enclosure. These boards are also useful in small spaces where a standard connector will not fit in the enclosure. These boards can be found in pacemakers, digital cameras, and cell phones.

Layer stack in a multi-layer PCBRigid-Flex PCB from RayPCB

Flex PCB

These boards are not really boards; they are fully flexible PCBs that can be molded into nearly any shape without affecting circuits present on different layers. The substrate is usually made from polyimide with copper or other malleable metal used for conductors. These boards are more expensive than the other types of PCBs due to the additional fabrication complexity.

Rigid-Flex PCBFlexible PCB

Which Type of PCB is Best for Your Design?

The answer to this question really depends on the application in which your board will be used, your production budget, and the level of complexity of your circuits. One rule of thumb that will aid in your decision is this: if your new design works properly on a breadboard, you can expect your circuits to work as designed no matter how you layout your PCB.

For designs that run at high speeds and or frequencies, single-layer or double-sided boards are typically unsuitable, and you’ll want to start with a four-layer PCB. Here are some other points to consider for different types of PCBs in certain applications:

  • PCB for medical devices have severe area constraints therefore require dense routing with compact footprint. Multilayer PCBs are therefore quite common in medical and other advanced applications.
  • Industrial applications usually have high current requirements than in other applications. PCBs used in these cases have a thicker copper layers compared to normal PCBs.
  • Automotive and aerospace PCBs must withstand strong mechanical vibrations, hence flexible PCBs can be used for such cases.

No matter which types of PCBs you want to design, Upverter® provides the schematic design and PCB layout tools you need to design boards from start to finish in a browser-based interface. If you are preparing a complex PCB with multiple layers, Upverter gives an easy EDA teamwork platform for a live multi-user collaboration and real-time design rule check (DRC) features.

You can sign up for free and get access to the best browser-based PCB editor, schematic editor, and component database. Visit Upverter today to learn more.

A Guide to Arduino Shield Design

Get Started with Altium Upverter, Sign Up Now

Upverter Expert - A Guide to Arduino Shield Design

You probably have a great idea that you tested using your Arduino, breadboard, and what looks like a bird’s nest of connectors, and it works great. Congratulations! If only a couple of ICs and additional circuitry could be added to your Arduino to make it look like a finished product. We have two choices here. First, you could make a custom board that might be more organized, but will require some time to design. You’ll also have to replicate Arduino’s functionality in your custom board, or you’ll have to clone an Arduino board.

Arduino shield design by stacking multiple boards

Arduino shield design with expandable memory and an LCD display 

The other option is to take all the additional components and make an Arduino shield. If you are lucky, you might be able to find an existing shield that will hold your additional components. If you’re more adventurous, you can create your own shield board that plugs directly into an Arduino module. Here’s what you need to consider in Arduino shield design and how to create a custom shield for your new product.

What is Arduino Shield Design?

Arduino shields are small circuit boards that sit on top of existing Arduino boards and contain additional components to boost the capabilities of the system. There are a number of capabilities you can add to an existing Arduino, such as Wi-Fi, Bluetooth, motor control, a camera, or other features. Arduino shields provide some important advantages:

  • Stackable. The layout of a shield board will be compatible with a basic Arduino board, which means they can be plugged in straight away. Signals are sent from the GPIO pins or other MCU interface, and multiple shields can be stacked together to form a complex system.
  • Inexpensive. Shields are relatively inexpensive to buy or design. For a small manufacturing batch, you’ll find that they are cheaper compared to custom PCB.
  • Extensible. If you use a through-hole shield, you can add more components to the board or rework it as needed. Note that this is not generally the case with a custom shield, which is normally fabricated for a specific set of functions.

Arduino shields have the same form factor as that of a standard Arduino board. Power and ground pins are located on one eight pin header, the analog pins are placed on a six-pin header, and the digital pins are placed on the opposite side with an eight-pin and ten-pin header. An example footprint for an Arduino Uno shield is shown below.

Arduino shield design for an Arduino Uno
Typical shield form factor for an Arduino Uno

Some Arduino shields are designed to use every pin, while some shields leave open pins. Shields generally communicate using SPI, I2C, or serial communication, and some use interrupts or analog inputs. If you’re buying a premade shield, you’ll find that not all of these modules are extensible. Some shields include an array of plated holes for soldering through-hole components, while others are designed for a very particular application and are not expandable. Take a look at Adafruit for some good examples.

Types of Arduino shields

There are hundreds of Arduino shields on the market these days, and going through each will turn this article into a lecture. Here are a couple interesting shields that might inspire your next design.

Connecting to the world

Arduino WiFi or Ethernet shield. As the name says, this allows your Arduino to connect to the internet through Ethernet or via WiFi. Arduino has retired the WiFi shield, but similar shields can be found from other suppliers or from tutorial websites. You can also build your own shield that provides both capabilities.

GPS shield. You can easily add GPS capabilities to an Arduino with a simple chip antenna. You could even clone an open-source GPS module and easily adapt it as an Arduino shield.

Music and Sound

MP3 player shield. You can turn your Arduino into an MP3 player by adding some speakers, a microSD card, and a headphone jack.

Music instrument shield, You can turn your Arduino into different digital instruments. You can generate an analog signal with a DAC on the shield board, and you can use other components to modulate this signal. You can also use UART to control other devices via MIDI.

Display and Touchscreen

LCD display or touchscreen shield. You can easily add a 16×2 character LCD display with controllable backlighting to your project. You can use two I2C pins on the Arduino board, which leaves plenty of pins left over for interfacing with other devices. If you want to include a touchscreen, an Arduino board can provide sufficient power for place a small touch screen with decent resolution (240×320 is typical). You can also add a microSD card for storing images and videos.

Automation

Relay shield. A relay shield allows you to bring automation to our home appliances. This type of board can contain multiple relay switches that can be individually configured as normally open (NO) or normally closed (NC).

Motor shield. The Adafruit link shown above includes a great example for a motor shield. If you ever want to build a robot (who doesn’t!), you can use the digital output to power a DC motor. You can also use the PWM output from the MCU to control a stepper motor.

shutterstock_1312556210
Arduino shield design for a stepper motor control board.

Things to Consider in Arduino Shield Design

While there are plenty of shields you can create for a new product, there are some important points to consider when designing your own Arduino shield.

  • Pin-out. The pin-out on your shield should match the pin-out on the MCU board. Pay attention to the datasheet for your Arduino model when designing your shield.
  • Current rating. When powered with an external supply, the total current is limited from 500 mA to 1 A, depending on the exact model. Components connected on the shield board and wired to the power/ground pins will increase the total current used by the device.
  • Supply voltage. Some Arduino boards use 3.3 V while others use 5 V. The components you add to your shield should be compatible with the supply voltage used with the MCU board.
  • Through-hole vs. SMD components. Some shields come with an array of holes for through-hole components alongside some other functionality that is built into the board. You can certainly use these premade boards for your shield, but you will be limited to through-hole components. If you prefer SMD components, then you will be better off designing your own shield.

Design for Wireless Communication

If you add a Bluetooth, WiFi, GPS, or other wireless module to a custom shield as a chip antenna, you’ll likely need to include a ground plane in your shield board. Be sure to pay attention to your antenna manufacturer’s guidelines when working with your chip antenna. Unless your shield is much larger than your MCU board, your RF traces are unlikely to act like transmission lines, but you should still pay attention to impedance matching rules for your antenna.

Alternatively, you can use copper pour on your shield board to create your own antenna, such as an inverted-F antenna. This will provide a compact footprint compared to a larger rubber ducky antenna.

Arduino Shield Design in Upverter

Upverter® provides users with a simple yet powerful browser-based platform for designing boards from start to finish. You can easily pick from a vast range of existing open-source hardware projects to get started, or you can import Arduino shield templates from Eagle libraries available from Sparkfun or Adafruit. 

You can sign up for free and get access to the best browser-based PCB editor, schematic editor, and component database. Visit Upverter today to learn more.

 

Getting Started with Embedded Systems Projects

Get Started with Altium Upverter, Sign Up Now

Upverter Expert Getting Started with Embedded Systems Projects.jpgCoding is just one important part of embedded systems design

Have you ever started an embedded systems project? If the answer to this question is no, just know that an embedded systems project is easy to start but difficult to master. You’ll need to become something of a coder as well as a hardware developer, and you may need to learn a new programming language in the process. If you already have programming experience, then you’ve got a head start over other engineers. Otherwise, there are plenty of open source hardware and software packages you can use to get started with building and programming your next embedded systems projects.

What Are Embedded Systems?

There is no strict definition of an embedded system. In the simplest sense, an embedded system is any electronic system that includes some components that provide computing capabilities. These computing capabilities could be reprogrammable, depending on the processing and memory components used in a particular system. These systems often appear as part of a larger electromechanical system or other complicated product. They also contain some kind of mechanism to receive user input or interface with another electronic, whether it is a set of buttons, a touch screen interface, or a wireless connection.

If you’re questioning whether you should build your next project as an embedded system, think about this: does the device need to process some kind of input from the external environment or another device, and does the device then need to make some kind of logical decision based upon that input? If the answer is yes, then you’ve got an embedded system on your hands.

You can find an extensive range of embedded systems, and you can even get some good ideas for your next project, by looking throughout your home. From appliances like air conditioners and microwaves to smartphones and smartwatches, you are probably using many embedded systems at the moment. With IoT devices set to become more popular in consumer electronics, industry, and other areas, many more products will function as embedded systems.

Processing Capabilities

Your processor, whether it’s an MCU or other component, will form the cornerstone of your embedded systems project. It also determines how many external components your device can incorporate, as well as the communication protocol your system will use to send or acquire data from other devices. Different processors provide different processing speed, although they carry different costs and will consume different amounts of board space.

Microcontrollers are an excellent choice for providing processing power in applications that don’t require extremely high speed and variable bit depth. Affordable microcontroller ICs provide bit depths ranging from 8 to 32 bits, and are available in speeds reaching from 10’s to 100’s of MHz. The footprints vary as well; many microcontroller come in DIP packages, while more powerful microcontrollers will be available in SMD/SMT packages.

shutterstock_707972428This microcontroller board can provide the backbone for a simple embedded system

Different microcontrollers support different programming languages, although microcontrollers typically use some higher-level programming language like Java or C/C++ in an integrated development environment (IDE). As an example, Arduino’s IDE is its own variant of C/C++. Before selecting a microcontroller, check the manufacturer’s IDE to ensure that you are familiar with the language. Microcontrollers are typically programmed in higher-level languages such as C++ or Java.

Embedded systems can be designed with an FPGA, and their reprogrammable nature makes them more flexible than most microcontrollers. The costs for a single FPGA can reach hundreds of dollars, and FPGAs tend to consume more power than typical microcontrollers. This makes them unsuitable in devices where power consumption is an issue.

If your device requires access to steady power, must run at high speed, requires hundreds of I/Os for data processing, and/or needs to be periodically reprogrammed, then a microcontroller is the better choice for your application. There are a number of specialized languages for programming FPGAs, with Verilog being the oldest. C/C++/System C is one example of a simpler tool for programming an FPGA, although you’ll need to use the manufacturer’s core generator tools to translate your code to the hardware level.

These limitations in programming languages cause FPGAs to be less accessible to designers who do not have experience with these embedded languages. For these reasons, many designers will find microcontrollers much easier to use for embedded systems projects compared to FPGAs and other CPLDs.

Building Your PCB and Your Device

Once you do select an appropriate processor for your next device, you’ll need to design a PCB that integrates your processor and your other devices onto a single package. If you are not the type to design a PCB on your own, there are plenty of microcontroller projects that can help you get started with your design. You can take these projects and expand on them, or you can use a popular microcontroller platform like Arduino to build your next device. Other, more powerful options are a Raspberry Pi single-board computer, or the even-more-powerful BeagleBone Black. The prices for these products ranges from a few dollars upwards, and your processing power and built-in memory will scale with costs.

Working with a microcontroller board like Arduino limits you to the capabilities that already exist on the board; you won’t have any ability to expand the on-board capabilities unless you open the schematic and layout for your microcontroller board in your PCB design software and modify it manually. If your board will interface with a number of other devices that will run at high speed and/or high frequency, it can be difficult to ensure signal integrity unless you have some PCB design experience. In this case, it is better to include these little extras directly on the board.

If you want your device to connect to other devices wirelessly or through the internet, then you might be better off going with a single board computer, like a Raspberry Pi or BeagleBone. If you are in the business of incorporating these capabilities on your own, you’ll need access to an extensive component database with electrical models, schematic symbols, and PCB footprints.

Once you decide on the basic requirements your device needs, and you have narrowed down the processing unit you will use, there are plenty of directions you can go to expand the capabilities of your embedded system. All this takes the right PCB design software with an extensive set of design tools.

Embedded Systems Projects in Upverter

If you’re looking for a platform to build an embedded system, Upverter provides a massive component library with plenty of FPGA and microcontroller options to choose from. All the important board design, rules verification, and circuit simulator features are available in a browser-based interface. You’ll also be able to collaborate with other designers on your next embedded systems project.

FPGA2The Embedded Micro – Mojo project, built for use in an embedded system with an FPGA

With the browser-based design features in Upverter®, you’ll have access to the PCB design features you need to create embedded systems projects and design PCBs to support these devices. The schematic design and PCB layout tools are designed for taking your design from start to finish and preparing for manufacturing. These standard design features are accessible from anywhere. These features also provide collaboration and rules verification for your next embedded systems project.

You can sign up for free and get access to the best browser-based PCB editor, schematic editor, and component database. Visit Upverter today to learn more.

The Design Guide for Hardware Startups: Getting Started (Part 1)

Get Started with Altium Upverter, Sign Up Now

Building a hardware - Startup Part1Building a hardware startup is serious business

These days, software companies get all the attention, but it doesn’t have to be that way. The modern miracles we all know and love wouldn’t be possible without PCBs and the businesses that bring them to market. If you’ve got an idea for a great hardware product, then you’ll need to take some important steps before you’re ready to start marketing and selling it to the masses.

Before you start producing prototypes and planning your first major production run, there are some important steps that hardware startups should consider before moving their product into the marketplace. These steps are intended to help get you to the product design phase and maximize your chances of success in your new venture.

Market Validation for Hardware Startups

A cool design rarely sells itself. This means you need to take some time to validate the market for your new idea. Market validation is about much more than just estimating the number of units you can sell per year. It really comes down to weighing the costs involved in producing your products, the costs to market your products, and the revenue you stand to see as a result. The profit you produce from this can then be put right back into growing the business.

In addition to market validation, you’ll need to consider the type of startup you want to build. The range and number of products you plan to create, the links between them, and whether you are marketing to end consumers or other business will determine the best methodology for validating the market for your products. It will also determine your overall product development and growth strategy; this will be discussed in a future article.

Driving Innovation: Demand-push vs. Technology-pull

The drive to innovate a new product can take two forms: technology-push and demand-pull. Regarding the former, new technology allows an entrepreneur to create a product that the market might not know they even need or that is not currently in demand. The latter drive for innovation addresses a real need that is demanded by the market and is currently unsatisfied.

If you can identify a demand-pull innovation, then you have immediate market validation for your idea. Unfortunately, chances are that other companies and entrepreneurs have also identified this opportunity, unless you are targeting a niche market. This means that the first company to successfully create and market a working product will have serious first mover advantage and is likely to see major success. At that point, it is up to you to differentiate your product from that of your competitors and differentiate your product by targeting specific pain points in your market.

In contrast, a technology-push innovation is not always obvious to potential competitors. This also means it may not be so obvious to your potential customers. The problem is that you will spend more time educating customers and convincing them that your product is a better solution to their problems compared to existing products. The market for this type of innovation is more difficult to validate as potential demand for the product is not so obvious.

shutterstock_1421351774
Ditch the external oscillator before adding the new MCU

Sales Volume Estimation

Perhaps the most important point in market validation is to estimate potential sales volume and customer acquisition costs. If you are designing a piece of technology that is essentially an upgrade of an existing product on the market, it is easier to estimate the market for your product based on existing sales volume. You can then get an estimate of marketing and advertising costs using search engine data.

Once you have an idea of the potential market size, you’ll have to accept that you can’t satisfy the entire market from day one. You’ll need to set a realistic sales target once you launch your product. A good plan is to target a small segment of the market, normally a few percent. Once you have an idea of the number of potential market size, you can get an idea of your customer acquisition rate. This is where you can use search engine data to estimate your marketing costs for targeting your desired segment of the market.

In order to estimate sales conversions from your advertising efforts, you should devise best-case and worst-case scenarios. If you assume an average 10% conversion rate, then this means that only 1 in 10 visitors to your website will buy your product. If each click in a search engine costs $1, your click-through rate is 1%, and your only marketing strategy is pay-per-click advertising, then you will need to reach 1000 people and sell a single unit for $10 plus manufacturing costs to break even on a single sale. Obviously, you need to take this and your other advertising strategies into account when devising a marketing strategy, as there are plenty of other marketing strategies hardware startups can use to market their new products.

Defining Design Requirements

As you go through the process of market validation, you’ll inevitably get some better ideas of what your market desires and how your product should function. After validating your market and determining the functionality it desires, it’s time to start defining rigorous functional requirements for your new product. These functional requirements should define the capabilities required to produce the desired user experience. Initially, you need to focus on what the product can do, not on how the product is built.

Once the user experience and required capabilities are rigorously defined, you can start defining the technical requirements for your device. This is where you need to start thinking like an engineer; you’ll need to consider how data moves throughout your system, how the system interfaces with the outside world, and how it interfaces with other devices. This will inform the next step in the design process, where you start creating block diagrams and schematics for your device.

shutterstock_382398283
Hierarchical schematics take you closer to your PCB layout

Creating a schematic is the first step in designing a PCB to support your new product. This is where you select the components in your system and start linking them together to produce your desired functionality. This where you need to consider the design software you’ll use to create your product. Working with browser-based software is a cost-effective alternative to other desktop-based design programs as it provides automated backup, version control, and collaboration features within a single platform.

As you venture down the road towards turning your new idea into a prototype and eventually a finished product, you’ll encounter plenty of design and production challenges. With the right design tools, you can take a design from start to finish and overcome these challenges. The browser-based PCB design platform from Upverter® provides all the tools any hardware startup needs to build create their next electronics product and plan their production runs. This online design platform includes all the standard features designers have come to expect in electronics design software. You’ll also have access to an extensive library of electronic components for building your next product.

You can sign up for free and get access to the best browser-based PCB editor, schematic editor, and component database. Visit Upverter today to learn more.

HC-SR04 Ultrasonic Sensors Power Super Mario Brothers Staircase

HCSR04 Ultrasonic sensors project in Upverter

Following is the Mind Your Steps project, which I am conducting student workshops for at SUIC Digital Communication Design students. The goal of these workshops is to explore the possibility of using technology to augment daily experiences and promote new productive human behaviors in day-to-day life.  

The workshop’s timeline is only 1 week, so things need to move as quickly as possible to meet that deadline. In the first class, all of the five students, who had never been exposed to the subject of physical computing before, were lectured with a lot of case studies and learned the explanation for the technology behind it. Students were then told to brainstorm and pick the location for their projects by the end of the very first day. 

The students came up with two locations. The first one was in front of the mirror in a women’s restroom. Female students noticed that other women were spending too much time in front of the mirror, and that maybe we could make an interactive installation to change that behavior. The second location was a staircase between the 8th and 9th floors of the CAT building (which is located at the university). The staircase seemed to be a better location for everyone to be able to participate in the installation and not be limited by lack of access to the women’s restroom. During the lecture period, students were inspired by the piano stairs in the Odenplan subway in Stockholm Sweden, which was implemented to promote the use of the staircase as opposed to the escalator. This interactive project continues to promote healthy behavior by reducing human traffic for the escalator and making the stairs an entertaining choice.

A screenshot from Super Mario Bros
Super Mario Bros offered a great player experience among many mid-eighties games.

If you can recall any popular mid-eighties platformer game in which players attempt to avoid certain objects and catch other objects, Super Mario Bros is sure to be one of the first games to come to mind. Our goal was to bring this fun experience from video game to reality. Since all of the students were too new to the technology for the project to succeed, I was responsible for the technical part and the students were responsible for the overall aesthetics of the project. The Super Mario Bros graphic on the wall around the staircase, the floor, and an electronics enclosure were created by the students. We chose an 8-bit style graphic to give a retro mood to audiences and remind them of the fun experiences 8-bit games provided in their youth. The content of the graphic had to relate to the context of the place, which is Silpakorn University International College in Bangkok, and it had to be relatable to students of the arts.

Wallpaper beside the college’s staircase
The design of the wallpaper beside the staircase is done by the students.

The picture above is the Super Mario Bros-esque graphic design the students came up with, including a lot of 8-bit pixellated buildings and other environmental features. The strawberry pattern above is the symbol that refers to the arts faculty.

Staircase steps are decorated with rewards and traps
Staircase steps are decorated with rewards and traps that provide feedback when stepped on.

The students chose four Mario-like rewards and traps; bombs and turtle shells as traps, and strawberries and coins as rewards. The audience receives audio feedback when stepping on the symbols.

View of the staircase from the higher floor
View of the staircase from above.

Here is what we ended up with on the first installation day. As you can see, we still had too much free space on the wall which needed to be filled. The banner describing the project also seemed to be tilted a bit, so the students had to come up with a clever way to solve it.

Close up view on some of the electronic equipment in the staircase
You could see an HC-SR04 ultrasonic sensors blending in with the buildings in the wallpaper.

For safety reasons, we hid the wires alongside the staircases so that bypassers wouldn’t trip over them.

Side view of the staircase
Close-up of equipment on staircase.

 

The Hardware

A table with hardware on it
The hardware used includes prototyping boards and loudspeakers.

Here is the prototype I built at home. The whole project required four. Each set included one microcontroller (AVR on the Arduino), one DFPlayer Mini MP3 Player for Arduino, one microSD card, one speaker and two HC-SR04 ultrasonic sensors. For the prototype I chose Arduino Uno for the ease of hooking up the wires to the peripherals. The MP3 module has no problem supporting a 3W speaker, so I used it in the project, but for the prototype I chose a higher watt speaker that required an amplifier module to drive them. The SD card is loaded with the mp3 files which are matched to each symbol. All of the electronics sets are running on 5V, so one 5V 30A power supply should be more than enough to power the project.

Watch the prototype test SUIC stair sweeper here.

Here is how the prototype basically works. The HC-SR04 ultrasonic sensors are set with the appropriate distances to detect when human stepping on the traps or rewards. After the HC-SR04 ultrasonic sensor detects any objects in range a sound will play according to the symbol the sensor is paired with. Four different symbols are mapped to four different sounds.

A team member soldering pin headers to an Arduino Nano
Here is an image of the first time soldering. On the right-hand is 3W speaker. After we finish assembly all of the units in the lab. Its time for on-site installation.

Here is the schematic of each unit. The units are powered by a 5V power supply, + for VIN pin and – to GND pin. The schematic of the staircase circuit, built on Fritzing platform, including two HC-SR04 ultrasonic sensors, an Arduino Nano, an SD card reader, and a 3W speaker.

The schematic of the staircase circuit.
The schematic of the staircase circuit.

Here is the schematic of each unit. The unit is powered by a 5V power supply, + for VIN pin and – to GND pin.

Schematic diagram for Mario Stairs project
The schematic of the staircase circuit, built on Fritzing platform, including two HC-SR04 ultrasonic sensors, an Arduino Nano, an SD card reader, and a 3W speaker.
PCB layout for the ultrasonic sensor and audio player board
PCB Layout
Photo of final PCB
Final PCB board ready to be soldered on.

We had to place each box at the exact location we were preparing, because if we misplaced them, the triggered sound would be wrong and we’d need to reopen the enclosure and reinstall the code. The wire length needed to be adjustable due to the measuring error. 

The Ultrasonic required 4 pins to function: Vin, GND, Echo, and Trig. I used two black power wires—each with red and black wires inside to connect the sensor modules to the Arduino microcontroller modules, as you can see in the image.

Final top view of the staircase with Super Mario inspired electronics
Final view of the staircase ready for students in the coming school year!

Here is how the staircase project looked when it was ready to be tested—no obstructive wires in sight. We spent one more day debugging code and rewiring an electronics.

And here is the project in action. We finished the project in the summer, so no students were present at the time. We’ll need to wait until the semester starts again to see whether we’ve achieved our goal or not.

Code

#include "Arduino.h"
#include "SoftwareSerial.h"

//Library that I chose to control mp3 module
#include "DFRobotDFPlayerMini.h"

SoftwareSerial mySoftwareSerial(10, 11);  // RX, TX
DFRobotDFPlayerMini myDFPlayer;

// Two ultrasonic pins setting up
#define trigPin1 9
#define echoPin1 8
#define trigPin2 7
#define echoPin2 6

long duration, distance, distance1, firstSensor, secondSensor;

void setup()
{
  mySoftwareSerial.begin(9600);
  Serial.begin(115200);

  pinMode(trigPin1, OUTPUT);
  pinMode(echoPin1, INPUT);
  pinMode(trigPin2, OUTPUT);
  pinMode(echoPin2, INPUT);

  Serial.println();
  Serial.println(F("DFRobot DFPlayer Mini Demo"));
  Serial.println(F("Initializing DFPlayer ... (May take 3~5 seconds)"));
 
  if (!myDFPlayer.begin(mySoftwareSerial)) {  //Use softwareSerial to communicate with mp3.
    Serial.println(F("Unable to begin:"));
    Serial.println(F("1.Please recheck the connection!"));
    Serial.println(F("2.Please insert the SD card!"));
    while(true);
  }
  Serial.println(F("DFPlayer Mini online."));

  myDFPlayer.volume(30);  //Set volume value. From 0 to 30

}

void loop() {

  // read distance data from both sensors
  SonarSensor(trigPin1, echoPin1);
  SonarSensor1(trigPin2, echoPin2);
  firstSensor = distance;
  secondSensor = distance1;

  // I prioritize the first ultrasonic first, so the two sounds will not be overlapped
  if (distance < 40 && distance > 10) {
    myDFPlayer.play(1);
    delay(1000);
  } else if (distance1 < 40 && distance1 > 10) {
    myDFPlayer.play(2);
    delay(500);
  }

}

void SonarSensor(int trigPin,int echoPin)
{
  digitalWrite(trigPin, LOW);
  delayMicroseconds(2);
  digitalWrite(trigPin, HIGH);
  delayMicroseconds(10);
  digitalWrite(trigPin, LOW);
  duration = pulseIn(echoPin, HIGH);
  distance = (duration/2) / 29.1;
}

void SonarSensor1(int trigPin,int echoPin)
{
  digitalWrite(trigPin, LOW);
  delayMicroseconds(2);
  digitalWrite(trigPin, HIGH);
  delayMicroseconds(10);
  digitalWrite(trigPin, LOW);
  duration = pulseIn(echoPin, HIGH);
  distance1 = (duration/2) / 29.1;
}


Future implementation

There are several ways this project can be implemented in the future. First, we can make question mark boxes like the ones in the Super Mario games in the areas between both floors that require humans to jump or hit them. When we hit the box, something might pop up above the box by a linear motor—or an LED might light up. Second, the symbol on the floor only has sound feedback right now. If we add tactile feedback when we step on the symbol, this will make the project much more fun to play with. 

This workshop is doing an experimental project that serves as a mind opener to students, encouraging them to recognize that technology is not limited to smartphones and the internet, but that technology can be applied to many areas in our life which usually go untouched. 

Salutes to all the kiddos Yong, Nat, Petch, Kim, Kap! 🙂

With so many aspects of our lives run by electronics, PCBs are like the glue that holds modern life together. Do you have an idea for a project? Try Upverter today, or get more inspiration about the types of projects you can do in Upverter. 

By Natthakit Kangsadansenanon

A Guide to Starting a New Project

Get Started with Altium Upverter, Sign Up Now

Upverter Expert Makers6 Copy 2

I have been an Altium user for more than a decade, and I’ve just signed up with Upverter to work on some new projects for a friend. While the Upverter is new to me, my initial planning process is exactly the same, no matter what the software.

Determining Requirements

The first step of successfully starting a new project is turning your idea (or someone else’s) into a set of requirements, or a specification. You have to do this before you get started on selecting any components or doing anything else. For example, when I’m working on a complex project, this would involve developing a couple of Agile Methodology personas which I can refer back to during each step of the way. For a simpler project however, this could be just a quick Google document which identifies what inputs and outputs the device will have, and perhaps how I want to approach some of what goes on between the input and output. 

Even when working on a fairly simple device, the process of writing this requirements document will likely give you inspiration for scope creep – wait, I mean additional functionality! It’s much easier to deal with the additional functionality when converting the idea into a requirements document than it is to deal with as you’re halfway through the PCB layout. 

If you’re working as a freelancer or developing the project for someone else, this is a really great time to share your ideas with the client, as sharing your ideas shows your interest to the client and may spark even more ideas from the client. This can help give you a better project to tell future clients about, save you a lot of effort later in reworking the design, and potentially result in additional work, and pay, to integrate the new features and functionality you thought up, all whilst impressing the client.

My requirements document will give a brief overview of the concept of the product, which is typically just a paragraph or two detailing the original idea. Then, it will have a section on what the product will do. Following that, each input will get it’s own section, as will each output. Buttons, screens, and other user interface elements count as inputs and outputs, not just the connectors. If the system is battery-powered, the battery requirements will also be listed, such as expected battery runtime, current draw,  and any environmental constraints that might exist. Finally, I will add a section on the form factor and any size constraints. The form factor section will have some rough ideas of how big I want the device to be, if it will have an enclosure, and how the buttons or inputs might be grouped.

If you have budget constraints per unit for the device beyond “as cheap as possible”, you should also include this in your requirements document. If the budget is $10 and you need a microcontroller, it’s going to limit your choices. The volume this constraint applies to is critical too. If you think your production volume is only going to be 10 units, each component in the device is going to be significantly more expensive to purchase than if you are making 1000 units at a time.

If the device has firmware or software, these should be detailed as well. You might feel this is something you can leave until a later time, but by adding it now, you might find you need an extra button, LED, or connector, which can be a lot harder to add in later.

Determining Regulatory Requirements

If the device you are creating will be offered for sale, now is a good time to look into what certifications it might require. If you are selling a device with electronics in it, you will need to have it certified for compliance with regulations no matter how many you are going to sell. Functionality such as radio communications, battery charging, or AC power all require compliance with regulations. The markets in which you are going to offer your device for sale will also determine which regulations you need to comply with. I examine regulatory requirements early on, as these requirements coupled with the sales volume may heavily influence component choices. 

For example, if I’m building a device that will talk to a phone over bluetooth, but I’m only going to build 100 of them, I will be using a pre-certified radio module despite the higher cost and additional board space compared to using a bluetooth IC. This is because the cost of certifying the device as compliant with intentional radiator regulations doesn’t make sense for the volume of devices I’m building. Likewise, if I have a small volume, I might choose not to build charging circuitry into a battery powered device because the safety testing for a charging circuit is too expensive.

Choosing Parts

Now that I have my requirements, I’ll start another document where I choose high level components based on the required functionality. This is one of the parts I enjoy the most, digging through supplier websites to find all the possible parts that could meet my requirements, then digging through datasheets to determine the most optimal one among them. I’m sure some people loathe this step, but I get real satisfaction out of it. The parts we’re interested in are very high level blocks, not each individual capacitor or resistor.

As an example, if I am building a wireless temperature sensor, you might have the following blocks based on your requirements:

  • Microcontroller to take readings and log them
  • Memory for storing readings if the wireless link is down
  • Real-time clock to determine when a reading was taken
  • Wireless device to communicate readings
  • Battery
  • Voltage regulator
  • Temperature sensor
  • Humidity sensor

Some of these requirements could possibly be put together for a single device to take care of. Many ARM controllers have built-in real-time clocks that are as good as external ICs for example. Digital temperature sensors often only cost a little more with a humidity sensor built-in as well.

Because I know from our requirements that this device will be battery-powered, I can make good choices for low power components with low quiescent currents. I’d probably be looking at a microcontroller which has the deepest, lowest power sleep cycle if the requirements said this would be installed remotely and be running on primary batteries rather than something that gets charged every day. If I had more power to play with, I might be more inclined to look at an RF system on chip (SoC) that integrates the wireless unit and the microcontroller together. Depending on the radio frequency required, I might still do that. This is where the requirements document really comes into play – if the radio was a sub-1GHz unit, I know I would be going straight for an RF SoC from Silicon Labs in their Gecko series. If it needed to be WiFi, I’d probably go for an SiLabs Gecko microcontroller and a separate WiFi radio which I can switch off when I don’t need it. If the power wasn’t a problem, and this was to be a WiFi device that was always plugged in, I would likely be looking at an ESP32 RF SoC instead.

Because I have a requirements document, I can start in the relevant category of components on my preferred supplier’s website and start filtering down specifications that are most critical to my requirements until I have a very shortlist. After looking through the datasheets for parts in this shortlist, I can create an even shorter list with just a couple of highly relevant options.

Creating a High-Level Bill of Materials

It might seem too early to build a bill of materials, since I haven’t even started on the schematic yet, but this is not a BOM you would manufacture from. We’re simply looking at our part selections from above, so we can check our major components and connectors are going to fit within our budget. By making a very simple spreadsheet with each of our most likely candidates for each component, we can fill in pricing data at different volumes. This is when I typically go to a website such as Octopart and make sure the component I want to use is available in volumes at distributors that will allow me to make enough boards. If I know that the first run of boards is likely to be for 1000 devices, but globally, there are only 261 of that part at suppliers, it’s probably a poor choice of component. By using a price comparison website this early on, I can also check to ensure that the cheapest supplier has sufficient stock. By checking each component on the shortlist against stock and pricing comparisons, we can narrow our selection down to a single component that makes it to our ‘bill of materials’. 

This high-level bill of materials allows you to give stakeholders in the project a ballpark idea of how much the device will cost early on. This can really help keep expectations in check, and ensure everyone is on the same page as far as the budget goes.

Prototyping

Now that I have a pretty good idea of which parts to use, it’s time to order some breakout boards, or build them if they do not exist.

Despite the fact I just ‘committed’ to a component in our high-level bill of materials, I’ll typically prototype each component in my shortlist. Why you might ask? Well, specifications lie or might be lacking some detail. In a previous project, I committed to a specific radio module for communications because its datasheet made claims of a certain bitrate over the air. On that project, we ended up testing over ten radio modules to find one that could actually meet our requirements for data transfer, despite what the specifications in the datasheet claimed. If you’re working with a very tight power budget, it can be hard to understand from a datasheet how much power a device will consume in the real world. Not to mention, a table of minimum/typical and maximum values can be quite broad, so testing each device in your specific use case can quickly lead to selecting one component over another due to its power usage. In another project I worked on, I tried five different microcontrollers to determine their current draw in sleep. While some could get to incredibly low sleep values on paper, from a programming point of view, this was very tedious and difficult to achieve and required a lot of code. This made them a risk not worth taking. I ended up going with the SiLabs Gecko mentioned previously, because it was so easy to get it in and out of a very low power sleep mode that exceeded our requirements using only needed one line of code, rather than over a hundred for some others.

It pays off to prototype each major component. Even the components you expect to be a very straightforward choice might turn out to be less than optimal once you start talking to it with a microcontroller. If you are not building a high volume of devices, a slightly more expensive and perhaps less ‘perfect’ choice might have a nice library for your microcontroller, where the optimal choice does not. Being able to use someone else’s proven code to talk to that device could save sufficient time to justify using it over your optimal choice.

This prototyping stage can save you a significant amount of pain down the road if you find out that the component you chose to implement the design with can’t do what you expect it to be based on the datasheet, or that it is very difficult to make it do what the datasheet claims outside a lab. The small investment in time upfront to test your choices may save you days of work revising your design later on.

Writing Code

Having followed this guide,  you should now have breakout boards for each major component in your project, allowing you to build it on a breadboard and start developing code. I moved into electronics from a software development background because I was getting bored of software, so I’ll admit I am always itching to get to schematic capture and PCB layout now that I know which parts I’m going to use. Every time I do, however, it comes back to bite me. Get at least the rudiments of your code worked out on a breadboard or some other configuration that allows you to make changes as needed before committing to a circuit board. I’ve jumped the gun on numerous board spins, moving straight to a PCB only to find I need some additional hardware feature to optimize the firmware, or that perhaps the pin on a microcontroller has some caveat to its function, buried away in the manual, that means I can’t do what I wanted to with it. 

Simulation

If you have analog electronics or logic components beyond a microcontroller on the board, it can pay to quickly build the circuit in a basic SPICE simulator to check that your calculated values function as you expect. Likewise, with logic components, it’s worth making sure the circuit functions as you expect, before you commit to a circuit board only to find you goofed and swapped two inputs and only found out by testing a finished prototype with your oscilloscope.

Schematic Capture and Board Layout

Now that you’ve built your requirements document, chosen parts, and tested them both individually and as part of your entire project, you can enjoy building up the schematic and laying out the board. You’ve put in the effort to get to this point, and you can be fairly certain that the board you build will meet your or your client’s specifications at this point, and that this first revision will have a pretty good chance of working correctly right after assembly. If it doesn’t work, it should be fairly easy to track down the issue and fix the problem, as you have your breadboard to refer back to, allowing you to compare specific points of the schematic with an oscilloscope or logic analyzer to find the fault, and add little wires to the board to fix your mistakes. You probably won’t need to go and make major changes to components after finding them inadequate for the task, as you would if you had skipped the testing.

It might seem a little over the top, a waste of time, or a waste of money to go through all these steps even for very basic devices, but experienced engineers will know that it pays off in the end. The additional effort and seemingly slow progress early on make the rest of the process both much faster and much more risk-free.

I’m a big fan of reducing risk when it comes to design. This doesn’t necessarily mean simplifying the project to remove complexity, or taking the easy route, but rather means exploring complexities or challenges prior to committing to hardware. If you are a beginner just stepping into the world of developing your own hardware, you are likely to consider any circuit board to be a high risk until you have acquired more experience. If you are a seasoned professional, the threshold for high-risk designs is likely significantly elevated, and will allow you to prototype larger blocks of a project at a time, though proper documentation of your requirements would be every bit as indispensable.

See what is new in Upverter or contact us for more information if you want to learn more about the capabilities of browser-based design and product development. Or sign-up for our service today.