Grayson Abbott - Recent History

(Last Updated May 17, 2007)

This document is a brief summary of what I've been doing, professionally, for the last twelve years (1995-2007). It tries to be a little less abstract than my regular resume. (Note: As a consultant, I do not normally give out the names of my clients, without asking their permission first, so I don't put names in written documents.)

Freelancing

In early 1995, I left my job as Director of Research at Universal Dynamics, where I had been developing the realtime digital signal processing (DSP) component of a vibration control system (shaker table controller). Essentially the whole technical staff quit around this time, due to differences with the company's owner.

I began doing private consulting full-time, under the DBA, Sofgry Systems, a name I had used before for part-time work. From that point until the present, except for involvement with the startup, stereo-link, I have worked on a 1099 basis for various clients. Most of these clients have been located outside of the Austin, TX area, and I did that work primarily by telecommuting, using phone, FAX, and the Internet. Telecommuting has worked well for my clients and myself.

In May of 1995, I began running my first Web server on the Internet, to provide the Austin Technical Events Calendar, listing events of interest to the local technical community (SIG meetings, seminars, etc.). This service was an experiment in community service and also in low-cost Web services. It originally ran on an old 386 PC, running Linux, over a 28.8 kbaud "always on" dialup connection. I continue to run this service, but I've upgraded the PC, the software, and the connection a few times. The Calendar has listed over 3400 events since its beginning and has a few hundred visitors each week.

I have been running a Linux system or two since 1993, when I was one of the testers on the NET channel mailing list, where the original TCP/IP code was developed for Linux. I'm happy to see that people can now actually get paid for working with Linux!

My first new consulting client was a company based in New Jersey and Belgium, with a partner in Germany. This company sold a suite of products for use by acoustical engineers and mechanical testing facilities. These products included Hewlett Packard workstations, running HPUX, with a data acquisition front-end, and my client's software. My role was to provide customer support and sales support in the field (the client's U.S. staff was very small). This work helped pay the bills, but I wanted to get back into development.

I got a new project, joining a team of developers, working on a vibration control (shaker table control) product, similar to what I'd done at Universal Dynamics. Now I was designing and writing code, primarily C (some assembly), running under the SPOX realtime operating system, on a TI TMS32C40 DSP processor, on a DSP Research Tiger 40 ISA card. I also did some programming, in assembly, for TMS320C31 processors, running on custom cards, connected to the Tiger 40. I used GoDSP's (now part of TI) CodeComposer IDE tool in this work and became quite skilled with it.

The system did realtime multi-channel analog data input, realtime processing, and analog output. It also communicated with a program running on the PC Host, which provided the GUI interface. I did not do any Host (Windows) programming. I was one of three designer/programmers for the realtime component, and I designed the overall architecture of that component. I also supervised a couple of junior developers. Generally, the other designers and I served both as domain experts (i.e. we knew the science and math) and implementers, as opposed to working from someone else's spec.

This project took up the majority of my time for nearly two years.

This development project involved about a dozen developers, spread over four different cities, in three states. To coordinate the effort, I built a project intranet. This consisted of a set of password-protected Web pages, where we stored project design notes, address books, a project calendar, glossary and other references, downloadable software tools, and current and archive source code. There was also a project mailing list (majordomo), and all Email was archived and browsable and searchable through the Web site. This was all accomplished with software I either wrote or found on the Web for free.

During this period, I also did some work for another client on a Linux device driver for a National Instruments ATMIO E Series data acquisition card. The driver was needed for a Linux port of the client's data acquisition and analysis software product, a kind of X-Windows based oscilloscope/spectrum analyzer/recorder. This was a quasi-realtime system. It was allowed to lose data, but it needed to produce complete blocks for the display, and it needed to know where there were gaps in recorded data.

I designed a device driver, in C, which included a pool of buffers and a smart buffer recycling scheme, so that only whole buffers of data could be lost and those only on the application side - data loss on the hardware (A/D) side was treated as a hard error. The recycling scheme was designed to prefer keeping the "freshest" data when it had to decide what to throw away. Also, the driver kept track of block numbers and returned the block number as the value of the read() (a non-standard approach). This allowed the display/record application to know exactly where data was missing and how much.

During this project, I became an active member of the LinuxLab (LLB) mailing list. I got the initial skeleton of my driver from this group.

The driver design was also a "thin" driver approach. Many device drivers know all about every function that the board can do (e.g. clock setup, input voltage ranges, channel configuration, etc.), so the driver itself is large and complex, using many ioctl() codes to access these features. (This particular board had more than 50 configuration registers.) The driver runs in kernel space, so "large and complex" is an undesirable trait. (It can't be swapped and a bug can crash the whole OS.) In my approach, the driver knows very little about the board - only the interrupts and buffer handling, etc. Instead, it implements a set of peek() and poke() functions, via ioctl(), and the full functionality of the board is accessed though an API library (which runs in user space). The API functions use the peek/poke operations to talk to the board.

At the time we did this project, National Instruments did not provide any support for Linux and were reluctant to even discuss it or provide programmer documentation for the board. I managed to get a few people there to provide me with documentation and even a loaner board. For a time after that, when other people approached NatInst for help on Linux drivers, they were referred to me.

A few months later, the client came back for more, and I modified the driver to support another, similar National Instruments board. I also worked on the Host side, writing the code that talked to the driver in their application.

Also during this time, I did a comparative analysis on a couple of embedded systems development tools (IDEs), for the maker of one of the tools. I wrote a detailed report, comparing the features of two tools, and explaining why certain features were important in DSP development work. (I've since considered writing a short book on embedded/DSP debugging techniques. I haven't ever seen a good resource in this area.)

Sometime in there, I became the coordinator/moderator of the monthly Internet Business Lunch, at the Entrepreneurs' Association (now the Business Success Center), in Austin. This was normally an open discussion, attended by local small business owners wanting to know more about how the Internet could help their businesses. I've continued in this role for over three years. Since I kept getting asked many of the same questions at every meeting, I wrote up a "Doing Business on the Internet FAQ", which I could hand out. Later, a friend and I set up the "biz-on-net" Email list and Web site, a by-invitation-only resource to help small businesses use the Internet to gain leverage.

When my vibration control development project ended, I got involved in a series of Web development projects with a friend. I think of this period as "my year of buying O'Reilly books", because I had to learn so many new things. (The stack of books from that year is about three feet tall.)

The first project was planned to be an online store, selling original art works. The idea was to make a simple kind of virtual reality, where each Web page showed a different room in a gallery or other interesting site, where the art works were integrated into the scene. A virtual tour guide would chat with you and would point out which items were for sale. I developed some Javascript code (after hurriedly learning Javascript) which would display the "chat" as text in one area of the page. The text would appear either on a timer or in response to where you moved your mouse in the scene. A rich set of utterances could be transferred to the browser, to be selected at random or according to certain rules. The download size of the utterance set was still small when compared to a typical GIF image. Unfortunately, funding ran low before we could complete the site.

At this point, we began building Web sites for other companies. My role was usually to do the programming parts (perl/CGI, Javascript, etc.), but I also did a little HTML. (We used FrontPage or Dreamweaver to do most of this.) I also developed some unique graphics, including animated GIFs for backgrounds. I wrote some perl programs to generate things like animated random noise backgrounds, with controllable densities, etc.

There was a team of 5-8 people working on the arts site and on the client sites, so I built a couple of intranets to support these teams, with features similar to the one mentioned earlier.

One of the sites we built was an E-commerce site, selling boomerangs. (The HTML was actually done by my wife.) I configured and tested the store (using CartManager - an ASP-style store, i.e. the actual transaction takes place on CartManager's server).

While working on these Web pages, we came up with an idea for a new venture - a Web site that would match up home owners with building contractors, to serve their home improvement needs. We called it OneStopContacting.com. A new partner joined us and provided some funding, and we built the Web site and started signing up contractors. I designed most of the Web site (we had a real artist do the critical graphics). The site had pages aimed at home owners and other pages aimed at contractors ("Join Us"). The home owner could either browse a list of contractors, by category, and call them directly or could fill out a form, describing what kind of work was needed, and we would forward that information to all of the appropriate contractors, who would call them with bids. Revenues would come from fees the contractors paid to be listed on the site and from advertising.

My visual design of the site was interesting. The home page shows the outside of a house, with hot spots related to contractor categories (e.g. a tree would represent Landscapers). Moving over the hot spot would highlight a corresponding labeled button, so you'd know what it represented. Clicking on the hot spot or on the button would link to the page for that specialty. Since there were so many specialties, only a dozen or so could be shown on a single page; tabs could take you to other views of the house (a cut-away, showing the interiors of walls and roof, a living room, a kitchen, etc.) where other specialties were offered.

One of my design ideas was that the house image would change for different times of the year. In fact, our first version was a Haunted House, as it was developed at Halloween. Later, it was replaced with a Fall Colors house. We hoped that people might visit the site more often, just to see what the latest house looked like.

The specialty page, besides listing the contractors, could also have a primer for the home owner (e.g. a quick course on drywall).

Hoping for a booming business, I designed methods to streamline things like getting requests for bids to contractors, tracking bids for the home owners, and managing our contractors list. I built an Access database to keep track of the contractors and made a private Web-interface (forms, CGI, and ODBC) to manage the list from either a local or remote computer. The different specialties' HTML pages were generated from the database, and then copied to the live site in a batch process. (We did not implement the automated request/bid processing, as traffic never got high enough to merit it.)

This site won a "Best New Product" award at the ITEC show in Austin, in 1999. But customer response to the site was tepid and eventually funding dried up. (At the time, building contractors in Austin had all the work they needed, without our help.)

While doing the Web sites, I also did some work for a client that sells software to the construction industry. I did computational geometry programming for a tool that estimates the wood needed to build a house, based on a digitized version of the blueprints. The digitization was error-prone, so I had to develop algorithms to clean it up, so that corners met and lines were straight, etc. This work was done in Visual Basic, under MS Access, both of which were new to me (I hadn't done any Basic in 20 years). This, of course, added to my stack of books.

Later, I did more work for that client, creating an ODBC interface, using Perl, to allow Web-based access to one of their database products.

Next, I started working on a DSP development project, for a client in Massachusetts. This client was building a prototype wearable device for monitoring vocal chord activity, for voice therapy. They had a non-realtime processing algorithm, written in C, running on DOS,. I took their program and ported it to Windows, and Visual C++ (really just using C features), and implemented various experimental changes to the algorithms for them. Then I ported the core algorithm to a Motorola DSP563xx processor, in assembly language, to operate in realtime. The system samples vocal chord vibration (via accelerometers), does some processing to extract key features (this is proprietary, but several standard speech processing techniques are used) and records the results in flash memory. At the end of a day, a physician can download the recorded data from the device and analyze it on his PC.

On this project, I worked with Motorola's standard development tools for the 563xx. I used the simulator, as there were only two prototypes and both had to stay in Boston. After I was satisfied with a new version, I sent it to the project leader, who did final integration and testing.

stereolink

While I was working on this last project, some friends started a new company, stereo-link, and asked me to join them. I agreed to a half-time position, while I continued to work on my existing projects.

stereo-link makes a USB DAC, an external computer sound card, designed for listening to music. I wasn't really involved in the technical design, but I planned on working on the next generation of products. Instead, my immediate role at stereo-link was mostly like a CIO and to take care of whatever came up. I interviewed and selected our Web site design house and managed the Web site construction from our side. I wrote marketing copy and most of the first draft copy for the Web site. I set up an intranet for the company (with ten workers in Boston and five remote), including multiple Email lists, with archives, a POP server, a VPN server, and a firewall, all using Linux. I dealt with commerce service providers, merchant account providers, hosting services, and UPS (shipping), to determine how to integrate our site and operations with each. I worked on plans for order processing. Later, I took over all maintenance of the Web site, which required me to learn Intershop 3 and 4.

stereo-link had an investor back out just after product launch, and, with no advertising, sales were slow, making it hard to support an expensive guy like me ;-)

(As of 2007, stereo-link is still a going concern. Please go to the Web site, stereo-link.com, and buy one!)

While continuing to help stereo-link, I started a GIS/GPS (road maps and vehicle locating) project for another client. I learned about GIS techniques and evaluated several tools, creating prototypes with a couple of them (using Visual Basic): MapInfo's MapX and Checkpoint Technologies' Checkpoint 2000. Eventually, I trained my client's developer in the use of the tool we chose, so that he could do the final integration with their existing software. Meanwhile, I moved on to learning about GPS, evaluating automatic vehicle locating (AVL) hardware and software, to be used with the previous work.

I also did another comparative analysis of DSP development tools, for another tool vendor.

The SigmaTel Years

Then, in March, 2001, I took a "sabbatical" from consulting, to work at SigmaTel - making the world safe for MP3s.

That was exciting! The company was downright shaky when I joined, especially the MP3 system-on-a-chip (SOC) product, which I was working on. But by September, 2003, we were doing so well, primarily based on sales of the MP3 chip, we went public!

I was a member of the Core Software Team for the MP3 chip. There were only 4-6 of us for the first couple of years, so we all did everything - writing device drivers, file systems, display code, and so on. And we'd all be called on to debug any part of the system that wasn't working. By 2006, the team had grown to over 40 people, including the Core and Apps team, and we'd produced about a million lines of C code.

The chip was a fully integrated, mixed signal SOC. It included a CPU (first a 5600-clone DSP, later an ARM9 core), A/D and D/A converters, FM tuner control, DCDC converter, USB interface, Flash memory interface, and lots more. You could pretty much add a NAND Flash memory or mini hard drive, a few resistors and capacitors, and a battery, and have a portableMP3 player. And we supplied enough software in our SDK that you could have it working very quickly. At one point, we were in over 60% of the MP3 players sold.

One of the first design projects I did was to add support for international (I10N) character sets (Code Pages and Unicode, Chinese, Japanese, and Korean) for the displays. (Try cramming a 6000-10,000 glyph character set onto a NAND and then access it at high speed!)

I also designed our second generation NAND Flash driver. This code had to support a wide spectrum of memory devices, with the constraint that our customers could swap in a different part on the assembly line, at any time, without needing to recompile the firmware. We had to have fast download speeds from USB to Flash or recording from a microphone, fast read speeds for playing back MP3, WMA, or other music formats - all using a FAT filesystem, and we had to deal with all the flakiness of MLC NANDs (error corrections, bad blocks, write disturbance, read disturbance, wear leveling, etc.). When I started, there were less than two dozen parts that we needed to support, and we expected about one new one per year. Soon, the Flash market exploded, and we were seeing new parts every few months. Despite that, my design, with a few tweaks, continued to do the job for the next four years.

More recently, I designed the Power Management software for the 3600 chip. That involved controlling frequency and voltage scaling for the processor, coordinating the power and processing needs of multiple software threads and various peripherals. That's a lot harder than it sounds; think about it for a while. (Our clock tree design was not real friendly to making quick realtime changes for frequency scaling. I wound up having to apply AI-like planning algorithms.)

In working on the software for these chips, I often got to collaborate the hardware designers on the architecture and design of the next generation chips. I think I enjoyed this the most. Anyone who has ever written code for an embedded processor has wanted to talk to the designers and suggest improvements, and I finally got to do it! (And they actually listened to me.)

But after a while, the product sales took a downturn, and it got to be less and less fun to hang around. I stayed longer than a lot of people, but I finally decided, after six years of pretty intense work, to take a break and spend some time with my kids before they grow up and leave home.

Now, I'm looking for another good startup opportunity...

Back to Gray Abbott's resume.