Issue 102 January 1999
In the Face of Medusa
Part 1:Developing Reliable Control

---

FLYING THE 4Q

Now, let’s apply the 4Q to the Medusa experiment. Medusa’s only function is to nourish the life in the petri dishes. The actual laboratory experiment has Medusa feeding three sets of eight petri dishes.

The inner workings of Medusa consist of a series of syringes containing liquefied nutrients that are delivered to the petri dishes by pressure applied from the shaft of a linear stepper motor. A cross section of the Medusa is shown in Figure 2.

(Click here to enlarge)

Figure 2—Looks pretty simple, but the machining is very precise with those funny register names.

Medusa is the first module of our experiment in which we will embed a 4Q. The linear stepper motor is driven using an Allegro UNC5804B. The UNC5804B is a BiMos II Unipolar stepper-motor translator/driver. The logical depiction of the UNC5804B is shown in Figure 3.

(Click here to enlarge)

Figure 3—A few years back, I wrote an application and hacked some hardware to do what this little IC does.

This IC provides complete control and drive for a four-phase unipolar stepper motor. The PicStic-4Q need only supply STEP, DIRECTION, and ENABLE signals to the UNC5804B to move the linear stepper, which in turn puts the squeeze on the syringe plungers.

Each step of the HSI linear stepper is one half-thousandth of an inch, so a small amount of nutrients are supplied at each plunger move. The object is to feed the experiment without drowning it. Seems like a waste to only use three I/O lines on the module, but I haven’t finished telling you about the other things the 4Q attached to Medusa needs to perform.

Again, NASA is synonymous with redundancy. Redundancy implies safety, and safety improves the possibility of success. I pointed out that a single point of failure exists when using a single processor complex to do the entire job. I also suggested that peripheral processing was one way to eliminate a single point of failure situation.

The 4Q comes equipped with a battery-backed real-time clock, and there’s also a built-in serial communications function. The embedded ’x86 system is also capable of keeping experiment time and communicating with peripherals serially. We can use these attributes to build a did-I-get-fed safety factor.

The ’x86 is ultimately the boss here. Although the 4Qs have their own intelligence, the ’x86 controls and monitors their programmatical movements. It’s safe to say that the ’x86 embedded board is able to reset any of the 4Qs as well as command them to perform preprogrammed functions at the predetermined times.

What if the ’x86 experienced an I/O component failure? What if the firmware running on the ’x86 hung?

My first thought is that the ’x86 onboard watchdog timer would reset the hung embedded complex and things would resume as normal. Watchdog timers are great for software hangs, but I haven’t seen one yet that can fix hardware.

So, let’s assume the ’x86 hardware is down. What are the 4Qs to do? After all, they can’t work without the direction of the big daddy ’x86, right? Wrong. The solution is to use the hardware incorporated into the 4Q to enable each one to continue to function until the ’x86 problem is repaired.

It’s a given that catastrophic failure of the ‘x86 hardware would result in the loss of critical data and, ultimately, experiment failure. But if the 4Qs are programmed to continue their assigned tasks according to mission time, and buffer any gathered data during the ’x86 downtime, depending on how long the ’x86 hardware was inoperative versus how much data the 4Q could store, data loss wouldn’t be total.

The 4Qs can also be programmed to poll each other to see if an unsuccessful data transfer to the ’x86 occurred for other modules in the experiment. This is akin to how the mission computers on the Orbiter vote each other out if a computational discrepancy occurs.

If all the 4Qs involved with Medusa can speak to each other and not speak to the ’x86, it’s logical to assume that the ’x86 is offline. I fight with this concept in my mind, but the 4Qs can also be programmed to attempt to reset the ’x86 embedded system if a consensus of them decided to do so.

I see a never-ending loop in that idea, but it can be implemented as long as the proper controls are put into place. The key to success here is to synchronize the module’s clocks with the clock of the ’x86 at experiment startup. If the ’x86 system doesn’t issue a feed command within the specified time limits, then the module responsible for driving the linear stepper motor assumes command and executes the process.

Any resulting feed operation status that should have been transmitted to the host ’x86 is stored in the 4Q, just in case the ’x86 was busy at feeding time or was unable to recover from a crashed condition. The inverse of this scenario is that the module performing the feed function fails.

The bad news is that the experiment would fail because there would be no backup for the 4Q. The good news is that the probability of this module failing is minimal. All of its parts have proved reliable in a variety of real-world applications.

Besides applying pressure to Medusa’s plungers, the same 4Q could be configured to measure temperature and humidity as well. The 4Q is also equipped with a pair of ADCs. Depending on the accuracy and number of inputs required, you can choose from a 4-channel 8-bit or a 2-channel 12-bit ADC.

Each ADC is based on a 5-V full-scale value, so sensors and interfaces must be chosen accordingly. A good choice here is the HyCal monolithic IC humidity sensor model IH-3602. This sensor measures relative humidity as well as temperature and is packaged in a six-pin TO-5 package.

Temperature is measured using a thin film platinum 1000-W RTD. The temperature sensor can be used to provide temperature compensation or to measure temperature independently.

The real plus is that this sensor interfaces directly with the 4Q. A nominal 0.8–4-V linear output for 0–100% relative humidity is provided when the sensor is powered by 5 VDC.

Temperature is measured by detecting a change in the RTD resistance. This is done by supplying a small constant current to the RTD and reading the voltage across the platinum resistance.