Introduction:

I've worked on a wide range of projects over my career, and have developed a broad background from which I can draw when I solve problems or create new products. Here's a small selection of some of the other work I've done.

Operations Research

In the Advanced Systems Group at the Naval Air Engineering Center, we performed lots of Operations Research studies. The Navy is a large organization that has to execute many operations and processes to do its job. Analyzing them requires a good bit of technical creativity, as the first and biggest hurdle is in figuring out how to analyze those systems. The report at left is an example of the kind of work we did. At the time, the Navy was evaluating the effect that adopting the Bell/Boeing SV-22 "Osprey" Tiltrotor would have on its operations. The SV-22 is a much larger aircraft than the SH-60 Seahawks that were being flown off of air-capable ships at that time. The question was, could the SV-22 take off, land and perform Helicopter In-Flight Refueling under the same conditions? I and another member of the Advanced Systems Group created a set of analysis tools (software) that we used to make the evaluation. In the end, because of what we were able to show, our work was responsible for the creation of an effort to develop automated deck handling equipment for air-capable ships.

At iTV Corp. we created a television set-top internet appliance. The WebTV system had recently been released. The idea of WebTV was to allow people to email and surf the web without using a PC. All-up, that system retailed for around $350. We felt that we could produce a better system for a cost of about $10 per unit, and a retail price of around $100. The secret to our system was the processor that it was based on. Designed by Chuck Moore, our i21 processor could perform general purpose computations, but also contained a selection of coprocessors, one to perform DRAM refreshes, one to handle the keyboard, one to operate an ethernet or serial port, etc. The processor had a 20-bit instruction and performed 21-bit math. It was asynchronous--that is, unclocked--and ran as fast as its hardware would allow. It was very fast and drew very little power. With another member of the group, I cowrote a PC-based cross-assembler and cross-compiler for the system. It produced an executable file that could be loaded onto an EPROM or flash ram on the i21 board. I wrote many of the low-level library routines, like +, -, *, /, if, then, do, loop, etc. Then with another member of the team I cowrote a TCP/IP stack. I wrote a number of network applications to run on the system, including TFTP, FTP, TelNet and HTTP clients. The Pegasus system worked very well. It did both email and web browsing. Our company President actually prefered using Pegasus to a Windows PC for email, because Pegasus was much faster. The brochures to the right talk a bit more about the system.

At CaphNet, we created a WML web browser for mobile devices. In 2000, data rates to cell phones were quite limited. This meant that sending an HTML web page to a cell phone could take a long time or even fail before completing. The WAP forum created WML as a wireless markup language, providing a subset of the features of HTML with a smaller file footprint, using a paradigm of "decks" and "cards", rather than pages. In HTML, you have a "site" composed of "pages", which are displayed by the browser. In WML, you have a deck composed of cards. The cards are displayed by the browser. Most companies supplying smart phones wrote programs for the phones that were simply display and input programs, making the phone kind of like a dumb terminal. Processing of both HTML and WML files was done on servers, with only processed, refined data being passed on to the phone. We created a native WML browser that resided right on the mobile device, receiving the raw WML data file and processing it in-situ, on the device. It presented the WML deck as a set of cards, with text and links presented clearly. It took a year of development and our product worked very well. It was small. On the Palm, the executable was only 25kB in size. It also ran very fast. If a user tapped on a link, the card or deck was displayed instantly. After a short time, data transfer rates came up and mobile processors got more powerful. When HTML pages could be transfered rapidly, there was no more need for WML. The marketing sheet to the left shows the browser in use.