Tag Archives: agile hardware

  • -

How do we get to the customer?? A startup with a great idea, an identified need, a prototype and…

Tags : 

I was recently cleaning out a storage area and came across one of the prototypes from a startup I co-founded in 1993. It is a prototype battery powered portable digital audio sound processor for the hearing impaired.

Background
High quality audio processor prototype for hearing impaired
At the time my partner and I were working on a joint venture project to pioneer the first generation of all digital hearing aids. The hearing aid project was tough because the enormous constraints of a very small device that will run on very low power continuously for days. In learning about hearing aids we realized that they are not good for listening to music. Hearing aids have a very limited frequency range, so low and high frequencies are not amplified. Listening through hearing aids is sort of like listening to an AM radio, but worse. The limitations of analog technology caused a technical barrier to better quality. The other main limitation was that hearing aid users wore them for long periods so they demanded convenience and small discrete size above all else.

The big idea

We realized that the hearing impaired could hear much more music and have a great listening experience if they had a device that would treat the full spectrum of sound available to their impaired ears. Headphone, Walkmans, and portable CD players were common, so people were willing to carry music devices. We envisioned a portable device that you could take to the concert or use in your home.

Testing our idea
inside the prototype
To be able to test our idea we ran some quick tests using a PC with an audio card. We processed some music with hearing loss algorithms and did A/B testing with a few hearing impaired to see if they notice a difference. We got mildly positive results. However testing in a Lab is quite different than a user using this processing in their own home or wherever they needed it. We also wanted to be able to test different settings and algorithms for compensating hearing loss for music. This meant we had to build a portable prototype that would allow us to program different processing ideas quickly, yet would run for a few hours on a battery. We also needed to do it for the lowest cost in the shortest amount of time, since this was money from our own pockets and time from our evenings and weekends.

Building the prototype

Motorola 56002 Digital Signal Processor Motorola 56002 DSP Evaluation board
PC JTAG interface audio inputs and outputs User interface
We built the prototype using a combination of off the shelf components and custom circuits. The first consideration was could we power the device circuitry using a battery? We discovered we could use a large rechargeable cell phone battery and a switching power supply component to get the power we needed. Around that time Motorola released an evaluation board for their 56002 Digital Signal Processor (DSP). I had been programming this DSP off an on for 4 years and it was excellent for audio processing, so we had our main logic board and processor. Most evaluation systems need some adjusting to your application, and this was the case for us. In additions to adding battery driven power supply, we needed to increase the system’s memory and add flash memory to store the settings and programs. We also needed to add buttons and LEDs for users to control the settings and volume. We also added a high quality digital audio interface to connect headphones, a microphone and line audio inputs for sources such as a CD player.

Testing with users

A number of hearing impaired users volunteered to test the system for us. We set them up with 4 different programs that they could select and a volume control they could adjust. We then sent them off with the device in a waist pack with the goal of using the device whenever they listened to music or went to a show. We also asked them to compare the quality of music and audio to their hearing aids. In the device we could track what programs and volume levels they were using. After a number of field tests, users reported mild improvements in listening to music, and a preference for certain settings in the device. The algorithms I had developed were working, however I knew we could continue to greatly improve the effectiveness of the hearing compensation processing.

The missing link – distribution

We proceeded with marketing and sales discussions with Audiologists. Audiologists are the Medical clinicians who test people’s hearing and prescribe hearing aids. This was the natural channel for our device, since it would need to be customized for the hearing impairment of the user. In learning about Audiologists’ business we discovered hearing aid manufacturers were heavily incentivizing them to sell hearing aids with high margins, discounts and free trips. A good quality hearing aid cost on the order of $800 to $1000 per device. Because Audiologists were focused on selling hearing aids to improve speech perception, there was little interest in offering our product to the hearing impaired. In doing our market research we found a simple device that offered some of our features for amplifying audio without the ability to do custom hearing compensation. Sales for this device were struggling and Audiologists were lukewarm to the device. Hearing aids were so expensive that most customers would only pay for them. The high margins hearing aids provided Audiologists meant they’d rather sell and fit hearing aids then a specialized device for music and audio.

After more conversations and demonstrations we put the business idea and this prototype on the shelf. We saw that while there was a need in the market and the technical solution to meet that need, the realities of the distribution channel meant the device would likely not succeed in reaching the customers. Trying to build an independent marketing and distribution channel through pro-audio retail channels such as stores was explored, but looked overwhelming and risky. The devices required hearing testing for baseline data, hearing compensation and user validation, a process far too complicated for a retail setting.

Our expensive lesson: If you are doing a Startup and using Lean Startup methods, identifying a need in the market and the solution is not enough. We found a need and a solution, we tested it and proved our solution worked. We discovered that you also need to prove you can get your solution into your customer’s hands. Perhaps now, 20 years later, we could do something similar with a smart phone. The challenge of getting the product properly configured for a user’s specific hearing loss remains.

I am ever grateful to my fellow investors/learners in this experiment:
Dr. Abram Gamer and Don LaFont.
– Robin Dymond.

  • -

The Agile Hardware Design Mindset.

Tags : 

Moving to Agile development in hardware is more about mindset than it is about technological limitations. Let’s consider some of the limitations that are often used to resist Agile hardware development, and show how these limitations are more to do with thinking then with technology.

PCB board design and layout.

We can’t do Agile because we need to complete the full board design before sending the design for PCB fabrication and population of parts. Manufacturing is costly and takes a lot of time, so we want to minimize these costs.

Let’s examine each of these points:

Myth: Manufacturing a PCB takes a lot of time.

Facts: The last 30 years of continuous high speed innovation in PC motherboards and mobile phones has driven the PCB manufacturing business to be very quick and responsive. A five minute search for fast turnaround PCB manufacturers revealed many companies that can turn an 8 layer PCB in 24 hours. With overnight shipping, you can have your PCB in 2 days. If you plan ahead with the manufacturer to get parts ordered so it can be populated, this can be done at the same time.

Myth: Manufacturing a PCB is costly.

Facts: The costs for quick turn around PCBs are trivial when compared to the cost of an engineer waiting for hardware. You can calculate costs from a variety of quick turn manufacturers at http://www.ladyada.net/library/pcb/costcalc.html For a 3″x5″ PCB the highest cost for a 2 day turn around was $215, shipping included. For comparison, that average loaded cost of an engineer to their employer is (salary, benefits, office, etc.) is $80-200 per hour. An engineer who spends one day waiting for hardware is far more expensive then the fastest most expensive quick turn PCB manufacturer.

Myth: We need to complete the full design.

Facts: A well designed PCB is modular, with modules for CPU, memory, I/O, RF, etc. Each module is designed as a unit, with interfaces to other modules, just like software. Therefore we can design a module, or part of a module, and that completed design can be treated as a testable deliverable. For example, the CPU and the memory could be designed and shipped as a populated PCB ready for developers to start using. The developers can start to use that platform for coding while the hardware designers work on the next module. The hardware designers will need to implement some features, like a JTAG or USB port and terminate some pins so developers can use the PCB, but that is a small price to pay in exchange for getting hardware into the hands of the software developers.

Deploying iterative and Incremental hardware development.

If we change how we think of hardware from being a single physical device that has to be designed, to a set of functional modules that are deployed as hardware, then we can map the manufacturing process of PCBs to the deployment of code into production. If we can deploy functional modules into a physical device (PCB+parts) in a few days, then we can deliver hardware functionality using an iterative and incremental approach. For example we could deploy a PCB with a basic input output (I/O) circuit that meets our simplest design criteria. This circuit would be deployed into hardware and then could be used by developers for coding and testers. If it is determined from programming and testing that the simple I/O design needs changes, a revision of the I/O could be completed to make the desired improvements. This ensures that the designers are delivering a design that meets the needs of the developers and testers. Once the developers and testers were satisfied, the I/O could be evaluated by the customer to gain their feedback and ensure it meets their needs.

Iterative and Incremental firmware with the hardware.

If hardware is thought of as deployed functional modules, then firmware is the glue that enables these modules to provide customer value. Firmware engineers have numerous well understood options for software development when there is no hardware. Software simulators, emulators, evaluation boards, and FPGAs all provide different options. With every design there are business priorities and technical risks. Based on these risks and priorities the developers need to figure out how to slice the design into components of firmware and hardware that will deliver the most business value and risk reduction with each iteration. For example if I/O is risky then the hardware and firmware developers should figure out how to build, code and test the I/O module before the CPU module. For example this could be accomplished using an I/O PCB that interfaces to a CPU evaluation board.

Using business value to drive product design.

We are faced with the continual expansion of software into the hardware space. Shrinking device sizes, massive gate arrays, generic open source platforms like Arduino, and smart phones all are changing the hardware development game. However software will always need something to run on, and as more devices connect to the internet, the importance of real world interfaces will continue to expand. Great hardware developers like Hewlett and Packard always emphasized getting out of the lab and meeting your customers. As hardware is increasingly used to wire up the connected world, it is more important than ever that hardware designers find ways to quickly respond to the changing needs of their customers. Agile principles and values provide good ideas to help you get there… just replace the word software with firmware or hardware :).

PCB Art by Artist Steven Rodrig
Artwork “Post Apocalyptic Data Hunter: RONIX” by Steven Rodig at PCBCreations.com