General Motors Bulk Current Injection Test.
This is a very intensive test. I was given very little time to write this code. I had asked for two weeks time to write three different programs (Direct-Injection, GM BCI, and the TEM Cell tests) but was only given one week to do it, and it was the week before we were to be audited on these tests! I only had two days to spend on this test, and I was very proud that it ran flawlessly for the auditor. After the audit, a representative from GM commented that is was the first time he had seen any software outside their own lab that ran the test the way it was supposed to run.
Why is this test so intensive? Basically it has to do with the way the test level is reached. At each frequency, the test level is increased until one of several parameters is met. These parameters are:
Forward power 50 watts or more.
The required induced current is achieved.
Any of the 1st five harmonics are greater than -9dBc. *
(* The harmonics are less than 9dB down from the carrier frequency. The carrier or fundamental frequency is actually the first harmonic.)
So, starting at a very low level, the signal generator is turned on. The induced current is measured. If it is less than the target current, then the forward power into the BCI clamp is measured. If it is less than 50w, then the 2nd through 5th harmonics (injected onto the test cable) are measured. (But, you don't have to measure a harmonic if it is higher in frequency than the highest fundamental frequency to be tested, so the test gets a little faster towards the end.) If none of these conditions are met, then the signal generator level is increased and the process repeats.
Since the induced currents at the fundamental AND harmonics need to be measured, this must be done with a spectrum analyzer, or any instrument that operates in the frequency domain.
There were several tricks I had to learn. First, I knew I could use some simple math to determine how far away from the test level I was, except when it came to the harmonics. Harmonics are caused, among other things, by non-linearity in the system. This means that the harmonics will increase in amplitude faster than the fundamental, and I discovered that a good rule-of-thumb is that the harmonics will rise about twice as fast as the fundamental. At least that is what I observed with the equipment I was using.
How was I able to write this in two days? I used a lot of the existing code I had written. I like to keep my code VERY modular, and got in the habit a LONG time ago of keeping my code in Source-Safe. (I started using Source-Safe way back before it was a Microsoft product. It was originally from a Raleigh company called One-Tree Software. In fact, I am still using the One-Tree version!) When I needed to write this program, I decided which files could be used as-is, and which would have to be modified. I then created a new project in Source-Safe and "shared" all the files that could be used as-is. I then copied the files to be modified into the new project. I "checked-out" the files from Source-Safe and either modified the necessary files, or created new ones. Basically all I needed to do was to change the menus and the test execution code. All the instrument drivers, math library, file i/o etc did not need to be changed.
One real advantage to this is that if I make an improvement to one of the shared files, the change shows up immediately in all of the programs that share that file. All I need to do is to "get" all the files for the project and recompile.
Another rule of thumb I discovered: Always ask for twice as much time as you think you need. The boss always cuts the required time in half. (Or, maybe that was HIS rule of thumb. Hmmm.) Another good idea is to ALWAYS have a design spec and system requirement document for anything that will take more than a week to do, even if you are the only person writing the program. When I started one project (the original RadCon program) I did just that. I broke the program down into modules and came up with an estimate for the time required. I also kept track of all the time I was given to write code. At one point I was asked why I had not finished the program, and I showed my boss how much time I was actually given to write code, how far I had actually progressed, and the time I had estimated it would take me. I was right on target given the time I had spent.
I've gotten pretty good at estimating time needed. The only variables are when I don't know how to perform a particular function (either manually or programmatically) and must do a little investigation, a knowledge quest, or a proof-of-concept test. I must admit this part is the most fun to me.
BUT, I digress...