Most of the work I have done is proprietary, so I cannot publish examples or give extreme details, but I can describe in general. In addition to the projects and articles listed in the 'Pages' section of this website, which incudes the ever-popular One-Wire Weather Service for Java, and a series on an analog amplifier that I'm still developing (slowly, as time permits), the list goes as follows, in roughly chronological order, oldest to newest:
- New Studio-Transmitter Link (STL) for KCID-AM. I was the chief engineer of KCID-AM, and one of my first projects right out of college was to convert the radio station from a telephone line to a microwave Studio to Transmitter link. This involved doing the site survey, specifying equipment, filing the construction permit pursuant to FCC section 74 rules, and performing the actual installation and setup. The AM station sounded as good as FM on a good receiver.
- As an audiophile by hobby, I was always on a quest for better sound. I completely rewired the studios (two production studios and the control room) for better flexibility and modularity, and better sound quality. I designed and built custom amplifiers, monitors, tone sensors, low-distortion calibration tone generators, program automation interface controls, and a whisper-quiet program switching system.
- New KCID-FM station for KCID-AM. By the mid-1980s, AM only radio stations were beginning to lag in popularity to FM stereo. I specified new and upgraded studio equipment, as well as an entirely new program automation system, which could run without direct operator supervision. Also did the site survey for a new radio station, including the propagation curves and service area analysis, specified antenna and radiofrequency feed equipment. The FM transmitting antenna was to be mounted on the existing AM antenna structure, so this required diplexing equipment, and a complete engineering analysis of both transmitting systems. Filed the FCC section 73 and 74 construction permit (the new FM required its own separate STL system. The two STL transmitters and receivers were also diplexed onto the same transmitting and receiving antennas).
- My first introduction to programming in C-Language was at IGM communications. I was chosen to maintain IGM program automation software because I had programmed computers before. My first act of rebellion was to refactor this software to use dynamic memory allocation and a better file format for the user-defined program sequence file. I also simplified the (MS-DOS text based) user interface, added color-coded status indication for hardware ready indication (if a tape wasn't loaded, a player would show up as not ready in the control panel UI). This was the basis for a custom version of the product that we built for Radio Free Europe/Radio Liberty. They had a number of requirements that a normal radio station would not have, such as the ability to control sixteen studios in sixteen different languages, and the ability to control a Grass Valley Group switching system, with its own control protocol.
- We started development of a digital audio based 'radio station in a box' at a time before most computers had any standardized audio or multimedia capabilities. We were programming the user interface/client code in Windows 3.1 in C++, and the back-end (server) side in C and SQL on Windows NT. Computers were (and really still are) a hostile environment for digital audio. Therefore, we imagined a client server based system, in which the A/D and D/A conversion was done using stand-alone codecs, wired back to the audio server using AES/EBU cables. Our server consisted of a time division multiplex bus, capable of handling 128 simultaneous 32-bit audio channels at sample rates up to 67 kHz. This was unheard of at the time. We designed three audio cards that could plug into the server (and our audio bus) and scale to as many PC cards, in any combination, as the server could physically accommodate: A digital audio I/O card, capable of 32 channels of simultaneous input and output, A DSP card, capable of a variety of channel throughput, depending on the DSP algorithms being used (which might include summing, filtering, sample rate conversion, or whatever other applications we might eventually create). The DSP card had multiple 24-bit Motorola 56K DSP chips, plus FPGA glue logic, and a unique shared memory subsystem for parallel processing of audio channels. I was the lead developer of the I/O and DSP boards. My highly esteemed co-developer designed the disk storage board, which also included some ground-breaking inventions for the time. We had working prototypes, but the company ran out of time and money before we were able to bring it to market. IGM sold the project to Custom Business Systems, Inc. of Reedsport Oregon (CBSI), but it was too little, too late. That was one of the greatest regrets of my career.
- When the digital audio workstation project was shut down by CBSI, I moved on to Wall Data. This was a complete change in focus, from audio and computers, to Mainframe host access. I started out programming for Windows 3.1 and Windows 95. I had a jump on multi-threaded design, having come from working on Windows NT for the digital audio project. I quickly gravitated to the Mainframe protocol area (TELNET TN3270 datastream). I advocated and pioneered a state-machine approach to protocol encoding and decoding, which was more efficient and easier to understand, maintain and extend. Performance and small size were immediately recognized as advancements over existing designs.
- From datastream protocols, I moved to web services, where I implemented a dynamic service generation system. The specification required toolable web services using industry standard WSDL and WS-* definitions, similar to JAX-WS, only our application had to make web services from user-defined stored procedures. So I had to implement the WSDL generation and XML parsers from scratch. Again, using a state machine based design, the implementation could be implemented using Java enums, and a pluggable, modular architecture, that once again, was extremely high performance, but easy(er) to understand, maintain and extend than other designs. I have used this approach to implement virtual machines and script interpreters in subsequent projects.
- I am currently the lead developer of a migration to the cloud, of a 20 year old application. Moving it from old school designs into a 12-factor, secure and containerizable application is a long-running and challenging task. I can't say what the ultimate solution will be, because it is an on-going project.
Hobby Projects
I also have hobby projects, which I work on as time permits. They are not production quality, or necessarily even completed. I make them available here because I think they're interesting.
One Wire Weather Service for Java
- I have provided read only SVN server access to the source code for my One Wire Weather Service for Java that I mentioned earlier. Sorry, the server uses a self-signed certificate, so your browser will warn you about that. Should you choose to proceed, you will be prompted for a username and password. Log in with Guest/readonly.
- Note: Yes, I am using Subversion for source control at the moment. It started out on CVS, and I ported it to Subversion a few years later. I now use Git all the time at work, but I haven't felt a critical need to port a hobby project to yet another repo at this time. I did recently switch the project build tools from Ant to Maven, so you have that going for you.
- This is actually a rather large project, and it might be a bit much to take in on a quick read. But if you want to see what I'm most proud of, you might check out wxservice.sensor.task.Barometer.java as an example of a rather low level and complex serial encoder/decoder. The pressure sensor has its own data and clock lines, which are controlled by two 1-Wire switches, which have to be programmed separately. So to send commands, I toggle the data, and then toggle the clock, one bit at a time, until the entire command has been sent; then I toggle the clock, and read the data, one bit at a time, until the entire message has been received. And since this is relatively time-consuming, this has to proceed while all the other sensors continue to operate in real-time, without interruption or interference.
- The 1-Wire protocol is quite sensitive to noise and RF interference, so I had to design in extreme fault tolerance to handle errors and retries. This happens in the base class for all sensors, wxservice.sensor.task.SensorTask.java. The private non-fault-tolerant, non-exclusive methods at the bottom of the file are used internally by the exclusive, fault tolerant (EFT) methods.
- Averaging wind direction is another interesting design challenge. wxservice.sensor.task.WindVane.java collects raw data from the wind vane, which has rather coarse resolution. However, wind tends to have quite a bit of turbulence, which effectively dithers the instrument, which we can average into a much higher resolution. This article (and updated here) describes that process. See also wxservice.sensor.data.WindVane.java.
No comments :
Post a Comment