Mike's Processor & Work 

Being a good engineer, I did some Goggle research into CI performance before I got my own CI and thought that I might be able to make some improvements.

So why didn't I just write new stim software for the existing AB speech processors?  Because I have no information about them and would be unable to get it.  For example, there's a switch to select the different microphones and aux input.  I'd have no idea how to control that switch, or how to talk to the headpiece, or how to control the AGC, or even how to get new software onto the speech processor...

While there is also no public documentation for the protocol between the speech processor & the implant, it can be easily observed by putting a loop of wire on the back of the headpiece and watching the radiated emissions when the headpiece talks to the implant.  I watched it with a deep memory oscilloscope.  I hoped that I would be able to figure out the protocol from the pattern of 1's & 0's.

In the most simplistic case, even if you don't understand the pattern of 1's & 0's, if you drive the headpiece with the same exact pattern of 1's & 0's that you captured with the deep memory oscilloscope, you should get the same behavior from the implant.

But I was able to figure out enough of the protocol to allow me to build my own speech processor & to utilize the full capabilities of the implant.

But I only implemented the processor talking to the implant.  The processor can also ask for information from the implant, like the implant serial number (to pair a processor with an implant), or internal voltages, or whether the headpiece fell off.  I felt I didn't need that capability.  If my headpiece falls off, I must manually restart the speech processor.

In Googling, I found that the body processor (PSP) uses a commercial Texas Instruments DSP (digital signal processor) chip.  So I bought a TI development board with a 2X faster version of that processor.  The faster processor would allow me to write less efficient software and still execute the routines fast enough. 

I write my software in the C language, which does not execute as quickly as routines written in native DSP assembly code (that all the manufacturers utilize).  But it's quicker & easier to write software in C, and as long as the routines run fast enough, I'm not concerned about battery life (for now), just how well you hear with a CI.

A picture of my processor is HERE.  I had to add circuitry to talk to the headpiece which you can see wired on a piggy back board.

I put it in a nice box so I wouldn't spill coffee on it as easily.  That picture is HERE.

While all other CI researchers focus on speech performance, I've focused on music.  CI's don't do low frequencies well, so when someone talks, some of their voice frequencies are not captured by the CI.  I don't know how someone should sound if part of their vocal energy is missing.  I don't have a target to shoot for. 

But when most folks sing, their voice is now high enough in frequency to be fully captured by the CI, and I figured that if I had all their vocal energy, I should be able to make John Denver sound the way he did when my hearing was good.  I have a target to shoot for - making John Denver sound correct.  And if music is correct, speech should be reasonably good, given that part of the speech spectrum is missing.

Return to: CItheory Home

Send mail to: mike@CItheory.com with questions or comments.

Last modified: 14 July 2010

(c) 2006 by Mike Marzalek