Electronics Design: Technology Selection

Technology Selection

Before we look at how to choose a Technology, what does Technology mean?

In very general terms, Technology is understanding how stuff works and how to get it to do what you want.

Technology Selection

Technology Selection

There is lots of different stuff available. In the case of Electronics Design this stuff is the type of Electronics you will use and how you will make use of it. The most important choice to make is to determine:

  • What functions will I implement using Electronic Hardware ?
  • What functions will I implement using Embedded Software ?
  • What functions will I implement using local or Remote Communications ?
  • What does the user do?
  • How is it powered?
  • How is it packaged?
  • Does it need to sense anything?
  • Does it involve any chemical processes?

In looking at the answers to these questions I also need to consider:

  • Cost to Design
  • Cost to Manufacture
  • Cost to support
  • Production Volume
  • Power Consumption
  • Performance
  • Time to market

In the process of Product Development it is often Technology Selection that can make the biggest difference.

 

Electronics Hardware

If there is no software involved, then this is the choice of which devices can be used to implement the design and how best to use them.

Electronics Hardware

Electronics Hardware

A recent example for us was the interface and power supply for a new GPS module for the Yarra Trams Passenger Information Systems. There was a problem with the existing GPS modules in scenarios where buildings either side caused the GPS module to lose position. And guess what you have a lot of in the central part of a city? That’s right, taller buildings. The Passenger Information Systems required an accurate GPS position to work correctly. So the GPS module had been selected including the use of dead reckoning to update the position based on the wheel rotation and the interface between this and the rest of the tram had to be designed including some level shifting to adjust voltage levels. We also manufactured the interfaces for them.

Yarra Trams VPIS

Yarra Trams VPIS

So that is an example of a project that required no Software.

But most of the time there will be Embedded Software involved. And there are several really good reasons for this:

  • Embedded Software costs less in manufacture – see Reducing Electronics Manufacturing Parts Cost
  • Embedded Software is extremely flexible
  • Embedded Software can test itself
  • Embedded Software improves field support, service and upgrade capability
  • The Electronics Hardware to run Embedded Software gets cheaper every year
  • Remote Communications is getting cheaper all the time

So today we spend 80% of our time writing Embedded Software in C and C++ to run on the Electronics Hardware we design through the PCB Prototype or even Production. This is known as an Embedded System.

For this typical project type we do as much in Software as we can.

 

Embedded Software

Embedded Software is the software that runs on the Electronics Hardware. Unless the product must be super Low Power Electronics, we will do everything in Software except for the power supply and physical interfaces to the outside world. But there are a few caveats:

  • signal filtering is usually more power effective in Analog Electronics than DSP
  • sleep and wake timing for high powered systems is often best done with external Electronics Hardware
  • you have to be able to select a Microcontroller that has the right combination of price, features and performance
Embedded Software

Embedded Software

Given the enormous range of devices available today you would think the last point was easily covered but a recent project we did ended up with only 1 possible choice in the whole world for the Microcontroller. Here is the requirements list:

  • Run from a button cell for at least 2 years
  • Has a beeper
  • Has an LED
  • Operated from -20C to +70C
  • After a period of dormancy, start flashing the LED and activating the beeper
  • Beeper frequency, on time, off time, number of cycles and gap time are configurable
  • LED on time, off time, number of cycles and gap time are configurable
  • Dormant period is configurable
  • Unit timing must be accurate to better than 1 hour per year
  • Unit price in 100K quantities must be less than US$1
  • Software must be protected from copying

The solution was an MSP430 based device from Texas Instruments with a 32KHz crystal. Actual cost ended up at US$0.71. And absolutely everything was done in Software.

 

Remote Communications

With ubiquitous Internet enabled devices, knows as the Internet of Things or IoT, it is more cost effective than ever to add Remote Communications to products. This can have many benefits that reduce the cost of field and service support for a product and also makes possible features you could not have provided any other way.

Remote Communications GSM Modem Cinterion

Remote Communications GSM Modem

An example from a recent water metering project we undertook. This is a remote water dispensing system, also known as a Bulk Filling Station, that records who took water, how much water, when and where. The transaction is sent to a website via GSM modem and the Council can get the records to bill for the water without having to travel. It also means the tanker drivers don’t have to manually fill out log books and the Council don’t have to chase them for the data. Great savings there alone. But there were some extra benefits for us and the client that they hadn’t considered. These were:

  • Remote updates to the system application
  • Maintenance monitoring of batteries and valves
  • Regular check in to confirm the system was still operational

So if a new feature is needed, we can update the software and remotely distribute it the units in the field. Since these are currently spread over half of the east half of Australia that is an enormous saving.

Internet of Things - IoT

Internet of Things – IoT

And we can also determine when the batteries need to be swapped out so that can be a preventative maintenance operation at a time of the Council’s choosing and not an emergency call out when a truck driver can’t get water. It is quite common for the first tanker to fill up before dawn when the solar charging has been off overnight and the temperature is at its minimum for the day. The worst timing from the batteries perspective so it just works better all round if we known for sure how the batteries are travelling by keeping track. It also means that if a solar panel is damaged the Council can see there is an issue before the system stops working.

And the regular check in allows the Council to know if a unit is still operational or not. A recent example from NSW was a fire fighting crew going to a water dispensing point to refill their tanker during a bushfire only to find it had failed sometime last winter and never been repaired. With Remote Communications you can avoid that and although it costs more to design, manufacture and operate (due to SIM costs) it can still reduce the overall cost of a system significantly.

So that is the general process. Once we have decided what we will do in Electronics Hardware, Embedded Software and how much Remote Communications to use we are ready to get into the Electronics Design in detail.

 

And of course, no post like this is complete without an input from Dilbert.

 

Technology Selection - Get It Right

Technology Selection – Get It Right

Successful Endeavours specialise in Electronics Design and Embedded Software Development. Ray Keefe has developed market leading electronics products in Australia for nearly 30 years. This post is Copyright © 2014 Successful Endeavours Pty Ltd.

Embedded Development: The Interview Part 1

Embedded Development

Embedded Development is the process of creating a computing system that is encapsulated within a self contained object. This object may or may not be part of a larger system. In it’s own right it is an Embedded System. So how do you go about creating an Embedded System?

 

Lance Harvie of People 4 Embedded and a LinkedIn connection of mine has wanted do do a series of interviews with Embedded Developers to go over issues, tips and career advice from those of us who have been in the industry for a while. For our first attempt we decided to try a Skype video call and record it. But Skype was not working well. So then we thought we would try out a Google Hangout and video record the interview.

 

First tip: never try a process that isn’t fully debugged when it has to work first time.

 

Second tip: have a backup plan.

 

From that you might be able to tell that both the Skype and Google Hangout processes didn’t go to plan.

 

Third tip: don’t rely on debugging during a live demo.

 

Those who don’t regularly read this blog won’t know that I got into electronics because I was the electric lead guitarist that thought it would be cool to be able to design and build my own amplifiers, racks and effects. I have a post covering my background in Music Electronics.

 

So I had an audio recorder with me and recorded the audio from the speakers of my laptop. I know there are other ways to do this but I hadn’t expected this to end up being the only thing that worked on the night and I had to make it work right then and there. So the audio you hear is Lance from my speakers sounding a little thin and far away and me in the room. This is also why the video is static but it does have our contact details on it.

 

Fourth tip: have a fall-back position you know will work.

 

There will be a transcript soon but you can check out the conversation above. If you want to get a copy of the transcript then either subscribe to the blog or leave a comment.

 

Successful Endeavours specialise in Electronics Design and Embedded Software Development. Ray Keefe has developed market leading electronics products in Australia for nearly 30 years. This post is Copyright © 2013 Successful Endeavours Pty Ltd.

Software versus Hardware

Electronics Hardware

The idea for this post came from an interesting article by Bryan Murdoch who also writes a blog on technology topics. In the article he looked at why some developers can be Averse To Change and made some interesting observations about why that is so. One of those conclusions I agree with very strongly.

 

Before I come to that, let’s look at the basics of the Embedded System.

 

An Embedded System is a computer that lives inside a system and is dedicated to that system. It has specific control functions and can be quite simple or quite complex depending on the system. An Embedded System therefore has Electronics Hardware that Embedded Software runs on.

 

Electronics PCB

Electronics PCB

 

The Electronics Hardware can be as simple as a tiny 8 bit processor such as the Atmel ATtiny13 or a full blown Intel multi-core processor. But the key is that it is dedicated to that system and not a general purpose computing device such as a Windows or Linux PC that we just happen to be using for that purpose today and can use for something else tomorrow.

 

Electronics Hardware is not generally reconfigurable in the field and where it is, such as FPGAs, it is really the software control portion that is changed and not the underlying hardware itself.

 

Embedded Software

 

Embedded Software

Embedded Software

The Embedded Software is therefore the software that runs on the Embedded System. This can be as simple as a few lines of assembler through to a full Information Kiosk product running on Windows Embedded. As usual with software, it can be anything. We are not going to focus on what it is, but why we prefer to use Software for much of a modern system’s functions.

 

Why Software?

The real reason for the focus on software, is that once you deploy the hardware, the only thing you can easily change to improve it is the software. This is one of the core points made by Bryan Murdoch that I agree with.

 

Another point he made in a post on Software Cost is that software becomes more valuable and more usable when we make the effort to make it simple, testable and compact. This makes it more readily reusable and also more easily maintained. These are two life cycle costs not often considered at the front end development phase of a project. It is also a good reason why the number of lines of code is not a good indicator of the real value of a piece of software.

 

Product Development

So this is where the rubber of the New Product Development process hits the road. Amongst other things, you have to be able to decide what you will do in software and what you will do in hardware. And it also depends on your core competencies as a company and those in your supply chain. During the development of the XBOX processor Microsoft told IBM that they were a software company and so any issues with the silicon they would fix in the drivers. This was done to reduce the development time frame and fits with the comments from Bryan Murdoch about one of the primary reasons people use software, its changeability. It also played simultaneously to both IBM’s and Microsoft’s strengths and was a smart business move on Microsoft’s part.

 

Successful Endeavours specialise in Electronics Design and Embedded Software Development. Ray Keefe has developed market leading electronics products in Australia for nearly 30 years. This post is Copyright © 2011 Successful Endeavours Pty Ltd