Bill Baldwin's Work History

Employment History

DatesCompany
1996---2002POINT, Inc
1995---1996CUBIC Applications
1990---1995Park College
1995---1995Forthright, Inc
1991---1995Baldwin Computer Science
1984---1990Univeristy of North Dakota
1983---1984Univerity of Missouri, Columbia
1979---1982Iowa State University (TA)
1982---1982Middletown, Ohio
1980---1981Warren County, Ohio
1978---1979Boeing Computer Services
1975---1978Iowa State University (RA)

POINT, Inc (Formery Sokkia Technology)

While at POINT, AKA STI, I was developing software for the surveying industry. POINT is a subsidiary of SOKKIA Corporation. When the name was change from SOKKIA Technology to POINT the Novatel company computer development was merged.

Programming was done in Borland C++/C versions 4.5, and 5.01, Visual C++ version 6.0, Windows CE compiler version 3.0, as well as some programming in Delphi.

Projects

STICOMMs

STICOMMs is the communications interface used by POINT. It is used by the desktop software to communicate with the various devices. It was originally written in 1994, and I took over as the only programmer working on this task in about 2000, although I had worked on it in the previous years.

The major changes the I made:

One interesting aspect of this project was determining whether a stated bug was in the STICOMMs (desktop) code, or in the device (CE code). This often led to me running both the CE debugger and the Windows debugger at the same time.

The code is written in Borland C++ (and C). Recently, it has had a Visual C++ COM component added. (The component was written by another software developer for another project, and added after the fact.) Therefore, the project has required skills in writing and debugging code in Borland C/C++, Visual C++, and Visual CE compiler all at once.

Stratus and Gladiator Graphics

One big project was to write a graphic display for the the Gladiator project that was updated for the Stratus Controller project. This involved writing the graphics display portion of this Windows CE program.

This involved writing code to display a "Sky Plot" which is a plot showing the relative location of all the currently visible GPS satellites relative to the current location. Also, there was a "Plan View" which allowed surveyors to display graphically the last few points measured. There was also a "Setout Point" and "Setout Line" displays, which displayed the current location of the stratus receiver relative to some target point, or target line.

This project included having to write the code in such a way that the graphic could be upgraded on a real time basis.

This was written in Microsoft CE C++ (with a C interface added) using MFC. At the time I started this project I was not told how it would be used so I could not have seen that it would have to mesh with the Gladiator project (which is written in C) which does not use MFC. At the time the graphics were written I chose to use MFC because it works well with the Wizards. If I had to do it over I would not have used MFC, although I probably would have used C++ anyway. The MFC caused unforseen problems, but the C++ did not.

There were several interesting algorithms developed for this code, primarily because of the small size of the screen on the Gladiator and the Stratus. First, with the sky plot and the set out point, it was necessary to make the central "target" as big as possible while not having it overlap any of the other pieced of data on the screen. This was particularly interesting in view of the fact that different size screens were provided for, as well as landscape vs. portrait mode.

As I mentioned before, the screen was set up to be viewed on screens of various sizes and orientations. This required that all of the areas of the screen had to be recalculated with each screen.

I developed a slider control for use on the screen.

Since the set out displays had the current position displayed, I developed and implemented an algorithm for recalculating the scale factor (to some reasonable value) dynamically as the device was moved.

This code was written in Microsoft Visual CE C++ using MFC. It was developed and tested independently of the code that would eventually use it. Finally, it was integrated into the Gladiator code (which is written in C) and the Stratus code (which is written in C++).

Netrology Project

Several years before I joined STI (now POINT), software was written by a third party vendor. This was used for Theodolite surveying, primarily in a ship building environment. Although the object appeared to work, the code that was returned did not. It was poorly written C code, and I singlehandedly debugged the code so that the software could be released.

This code was significant primarily in that I was the only person involved with it. In addition to debugging this on Windows 95 (which I used at the time) it also needed to work in the other Windows environments. On one occasion I had to have a customers laptop computer shipped to me because we could not duplicate the reported bug. It turned out to be a hardware problem which I researched and fixed.

Prolink

Prolink is a piece of software that is used for interfacing between the surveying equipment and the desktop. It will analyse the results of the survey and provide reports to the user, as well as allow the user to translate data from one file format to another.

I was not in on the writing of Prolink, however, after the fact I was given the task of keeping this software up to date. This involved installing the STICOMMs software primarily. It also involved the generation of an install script using Install Shield.

The people that write Prolink did not install any means of checking the version numbers of the various dynamic libraries (DLL's) used. This was significant because Prolink consists of about 30 to 40 DLL's. I installed and updated the version information for each of these DLL's. In addition, I was in the process of developing a procedure that would allow the user to get the version numbers of all the DLL's actually used by Prolink by right clicking on the executable and displaying the properties page. The Dll's would have been displayed as a tree indicating the dependencies, with the version numbers of each of the DLL's, and improper DLL's would have been flaged on the display. The purpose was to give the help desk personell some information about the setup on a user's machine if a bug is reported.

This involved developing an Windows operating system extention that would put a new property page in the property page display for each executable and DLL. The programming was done using Visual C++, COM, but not ATL or MFC. The latter was by choice to eliminate unneeded dependencies.

This project was very close to completion, except for the installation in Prolink, which was not started yet.

Spectrum Survey etc.

Spectrum Survey was designed to be a desktop product to assist people in using GPS for surveying. The locally developed product was dropped after the partnership with Novatel in favor of a Novatel product.

This project was the first project I worked on at STI. I developed a database representation (although, as I recall, it did not have any representation on the disk at the point the project was dropped.

There was also a project named the Caspian project which was dropped as well. In this project I developed a "Low Level Graphics" component. This was frustrated by the rather sudden change from the locally written environment Object Server to the COM environment, which required the code to be rewritten.

I also developed a coordinate translation package for use with the Caspian project, and helped develop an extensible graphics translation file format. That is, a file format that would allow the user to store graphics translation parameters, and do it in such a way that new translation algorithms could be added after the file format was finalized. In addition, it was set up to accommidate any number of natural languages, an aliasing.

Conclusions

I enjoyed working at POINT because the work was challenging. There was an opportunity to work with new technology that I had not used before, such as COM, ATL, etc. In addition, I had the opportunity to work with Desktop and Handheld computers. There were opportunities to debug existing code, as well as develop new code. I also had the opportunity to work with a number of compilers.

CUBIC Applications

CUBIC Applications was a government contractor. I was working on a contract to analysis the networking capabilities of the United States Military bases both in the United States and abroad. Specifically, there was interest in making more use of the data gathered at Military training exercises, and it was envisioned that the information could be distributed via the internet. More to the point, in the days before internet streaming the interest was in distributing videos over the internet.

To do this I traveled to several Military Bases, and my colleagues visited many more. We gathered information about the networking capabilities of the bases, and presented a report on the feasibility of streaming the video. I think that in todays world most of the findings are already known to people who have tried to stream video over the internet---there is a definite decrease in the quality of the signal if it has to go through a T1 line or slower.

I did write some programs in either C or Pascal to do some of the data analysis. At one point my boss presented me with a paper saying that the task desired was not possible, however, I did it anyway.

I did not like working for CUBIC primarily because it required that I work in Leavenworth which is a long way from my home. I did have an apartment in Kansas City, Kansas, however.


Last Updated September 06, 2009. Resume page