Get Started with Altium Upverter, Sign Up Now. 

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.