Thanks to a few brilliant minds over the course of the last hundred years or so, wireless technologies have become ubiquitous, but that hardly means they have become easy.  Yes, there are many options out there that make things ‘easy’, but those easy things come at a cost which involves compromises on cost and/or capability.                                                                                    

If they say, “Hardware is hard”, then “RF is FM” is freaking magic 

1. Define requirements
   
   

What do you need the wireless component of your system to do?  There are scores of protocols and technologies out there for wireless devices.  Most are familiar with the standard ones like Bluetooth and Wi-Fi, but even in each of those there are many components.  Also, the standard ones are only worth it, usually, if you need to communicate with other existing devices.  If you are creating your own system, and you don’t need to talk to phones or other networks, then a proprietary network can be a large cost savings.  

Range and battery life are other requirements that define which wireless system to use.  These two are usually at odds with each other.  Even when you don’t have battery life issues, there are maximum output power limitations that will affect range capability.  

2. Pick a protocol
   
   

As stated above, a key requirement is to define what other devices you’ll want to communicate with. These are divided into two categories, proprietary and standardized. Standards are great because you can talk to common and existing devices. However, they can cost more to implement and you usually have to pay a fee to use them. Proprietary protocols are great too, as you can choose components that fit your requirements. If designed properly, proprietary protocols can be as secure or more secure than standard ones as well. It all depends on what features are more important in your application.

3. Determine volume
   

Almost all engineering design tasks are haunted by the volume question.  Final product cost can almost always be driven down with volume. Of course, the catch is that while new products are being developed, the number of units that will be sold is mostly a guess at best.  All the market research in the world can lead the best and the worst companies to the wrong conclusions.  Take the best guess you can, be conservative, then be more conservative, and start there.  Once the market is validated, more engineering can always (and more justifiably so) be put into the product to reduce production costs.

One of the most common ways to reduce upfront costs when developing a wireless product is to utilize a module.  Sure they cost about 2 – 10 times the cost of the raw components, but they can save $10K to $300K in development and compliance costs.  For instance, it may make sense to use a Bluetooth radio system module for up to a few thousand units.  A cellular radio system module may be cost effective up to 50K units.

4. Choose a Country of Operation

Yep, where you operate a radio system matters.  Radio (wireless) emissions are regulated throughout the world (FCC in the USA) and the rules change everywhere.  Luckily, there are some common bands or frequencies that can be used throughout the world (thanks to the microwave oven).  The most common is 2.4GHz; this is where Bluetooth and Wi-Fi operate.  However, these frequencies aren’t the best for long distance communications.  900Mhz (ISM) is a band that is used in the USA for high power and longer range communications.   However, this same band is not legal in Europe and only parts are legal in other countries.  It can get complicated and these are just the open or public radio bands.  There are myriads of bands that are used for government, police, air traffic and maritime uses.

Keep in mind also that these regulations in various countries require compliance.  This means they must be tested by an independent lab that states that your device works properly, follows the rules, and plays well with others.  Compliance is a significant cost and is one of the major up-front cost savings when using a pre-certified module.

5. Specify
   

This is the hard work where the rubber hits the road.  You need to write down your requirements and be prepared to make compromises.  Items like range, capability, and overall system operation need to be carefully thought out, then validated with an engineer.  We are here to help you do this.  Check out our blog at 5 Tips for Writing Your Specification for Product Development for help writing your specification document.

Creating or adding wireless communication to a product is a complex task, but with the right help it can be a fairly deterministic process.  Carefully thinking about all of the parameters and requirements from a business and technical perspective is key to getting the right radio system designed and developed.  Also, the radio system is just part of your product design.  For more information about designing your electronic system, check out our e-Book below.

Printed wiring board (PWB) is an older term used for PCBs.  It was exactly what it sounds like, it was a way to print wiring.  This term could still be used for very simple PCBs where the function is more for mechanical wiring than active circuitry.

A look inside a modern cell phone is a PCB that reflects the ‘work of art’ side.  It’s a finely crafted network of wiring and components, flexible and rigid PCBs which all work together perfectly to provide the functionality we’ve come to take for granted in modern technology.

No matter what your needs are, it’s important to realize that all PCBs are a combination of at least 2, if not more engineering disciplines.  Understanding what these disciplines are and how to specify your requirements are important aspects of getting your PCB done right the first time.  The disciplines are:

Electrical engineering – this is the obvious one. The goal is to wire electronic circuits together.  Of course we’ll need some electrical engineering.

Mechanical engineering – while perhaps not so obvious, we live in the physical world. We are wiring in the physical world so there are mechanical requirements to consider.  Some PCBs have very few mechanical requirements like put 4 holes in the corners.  Others move towards the work of art level, but most are in between.

Software engineering – Almost all PCBs these days have some level of software in them. If there is a microcontroller, then there is software.

Thermal engineering – Many times grand assumptions are made about the environment something will operate in. The environment something will operate in can change the design drastically. Specialties – If there are lights, then perhaps there is an optical engineer involved.

Other specialties can be involved just depending on what needs to be done.

Below is a How-to guide to help you communicate details of the PCB to your engineer for design of your circuit board

{{cta(‘c11f1602-72cd-4abd-be0b-41cfad610249’)}}

High Level Functionality – The first step is to write down what you want it to do.  You can start out with very broad definitions of your inputs and outputs and what it does.  Provide whatever level of detail you can.  Helpful aspects to think about are parameters like: 

Think about these types of questions and have an understanding about how it all goes together. Of course your engineer will be happy to fill in the gaps, but the more effectively you can communicate, the better chance of getting what you want and saving costs due to miscommunication. 

For more details on how to write a specification, please check out this article. 

Mechanical and Thermal Requirements – We know we need to understand the kind of space you want to put your PCB into.  Sometimes it’s as simple as ‘put it in this box’.  However, even that can lead to issues.  What about these questions:

Software Requirements – While many boards have very basic functionality like ‘turn this on when this happens’, other PCBs can have very complicated logic built into them.  In some cases, software can drive 75% of a PCBs design cost, and sometimes more.  Software is a double edge sword in modern day PCB design.  On the one hand, it offers extreme flexibility and capability to create complex functionality and control.  On the downside, all of the flexibility and control can lead to software never being finished.  If there is a new idea to implement, it’s likely you’ll be able to add it in to the software.  This is great if it means you can sell more of your product with a software change.  It’s not so great if changes are made haphazardly because software changes are ‘easy’.  A specification is very important for this phase.  Make sure you can answer these questions:

What does the software have to do in all cases? Not just in the main case, but in everything you want it to do.

Other Specialties – If other specialty engineering disciplines are required, specification and design can get more complicated.  Some companies, like ours, are familiar with LEDs where we can cover most of the requirements for a LED lighting project without an optical engineer.  However, there are other cases where complicated instrumentation may need to be researched or subcontracted for very specific design aspects.  Below are some examples of some non-standard engineering requirements.

In many of these cases, modules have been developed by 3rd parties that can help reduce the engineering requirements of the specialty work to the level of skilled engineer.  In some cases, it is the scientist who needs the PCB built and they can provide the first-hand expertise on how the other engineers need to interface to their specialty systems.

One more very important engineer that was not mentioned is the manufacturing engineer.  This isn’t necessarily a specific engineering discipline, but to consider how your PCB assembly will be produced.  Placing a surface mount component is cheaper than placing a through hole component.  (Machines do the surface mount work.)  There are scores of items to review to ensure high yield PCB development.  Many are standard practices, but the skill lies in the hands of the engineers building the board.
Printed circuit board development is a complex and highly skilled craft.  With all of the various skills involved, it is best completed by a team of engineers.  Sure, there are many design challenges that are small enough to be completed effectively by a single engineer in a reasonable amount of time.  However, as the saying goes, two heads are better than one.  Having an engineering team develop your PCB where there are design processes and reviews in place help ensure a high quality design for your product.

 {{cta(‘c11f1602-72cd-4abd-be0b-41cfad610249’)}} 

So just as the name states, the goal here is to prove the concept of the product you want to ultimately produce.  The goal is fairly clear, however, the way you define that goal gets a bit trickier.  The three things you want to accomplish at this stage are:

1. Lean startup mentality – fail fast, fail cheap.  You have the idea, now does anyone want it?  Having a POC that is cost effective to create is important here.  Assessing validation of the idea and product at every stage of prototyping is paramount.  You must avoid phrases like, “I just know this will be big.” 
2. Determine your next incremental step.  If you have X resources, what do you expect to accomplish after expending X resources?  For instance, if you are willing to put in 100 hours of time and $200, there should be a goal at the end of that stage.  It can be as simple as answering the question, does anyone like my product to determine if it is worth investing more time.  It could be more complex such as, I need to be able to raise $20,000 for my next step of development with this POC. 
3. Does it work?  This may seem obvious, and so many times ideas seem so clear in your head, but once you start working on it, you find details that just do not pan out. 

Building hardware isn’t cheap, but it is getting better all the time.  Here is where places like Spark Fun and products like the Raspberry Pi and Arduino come in.  You can mock up some hardware, display, some buttons, and show how your product can work.  Of course this is great if you are technical, but if you are not, then you have a few more challenges ahead of you, but you can still validate.  Perhaps you can make up some renderings and tell the story of your product visually.  Or, you can partner with someone technical.  In either case, technical or not, you should always build a team.  Techs need non-techs and vice versa, but this is another blog. 

Your POC needs to tell the story, show the story, and validate the product.  The definition of a POC is the goal.  It is defined by the early stages of accomplishing these goals.  Keep in mind that a POC is also typically limited in looks and function.  It is not a minimal viable product (MVP).  It’s just the first stages on your way to a functional prototype, and pilot run, and MVP.