We have discussed in previous posts how to take a refrigerator and add actuators and sensors so the refrigerator becomes a diagnostic test-bed. Today we can start running diagnostic experiments and develop diagnostic algorithms and methods. An ultimate goal of ours is to build end-to-end diagnostic solutions in the context of repair, maintenance, or decision making.
Another goal is to create a diagnostic benchmark for continuous thermodynamic refrigeration systems. Of course in the process of experimentation we shall calibrate and validate our platform (convert sensors readings to Si units, inspect signal ranges, etc.). We want to have experimental controls, to be able to reproduce experiments, and to construct representative and validbenchmark. The approach of achieving this is by careful manual validation of the intermediate results.
Let us first define a diagnostic scenario. A diagnostic scenario is a set of time-series that contain information about:
all sensor data
the fault injection and the positions of all actuators
the conditions in the environment (these are preset constant values such as the thermostat position or the mains voltage)
A diagnostic benchmark contains many diagnostic scenarios. The length of most of our diagnostic scenarios will be 24 hours. The reason for that is there is a natural 24 hour cycle in the environmental temperature and that the slowest process of interest in our refrigerator (warming-up to ambient temperature) is several hours in duration.
Before anything else we collect data about the nominal working of the refrigerator. We will use this data for building nominal models, calibration, and validation. This is how the refrigerator temperature looks for one nominal scenario:
The plot above shows the readings from three DS18B20 temperature sensors and the thermostat position for the duration of one nominal experiment. The temperature in the freezer and in the refrigerator is oscillating around the set temperature as prescribed. The room temperature depends on the office HVAC and the outside temperature. There is a small bump in the room temperature probably due to closing the door for a noisy conversation.
The next plot zooms in the time and shows all temperature sensors and the thermostat position:
The plot above shows half an hour of the temperature and thermostat signals during the day. We can see that due to the fluid dynamics of the air in the refrigerator (the fridge is mostly empty except for the pipes that hold the sensors) some of the temperatures fluctuate more than others. The effect is pronounced for temperature sensors close to the evaporator.
More than 7% of the energy of a refrigerator is spent in cooling-down after opening the door. The door is an important refrigerator component and analyzing fault modes or fault regimes of the door (or the user that operates the door) is important for diagnosing the device.
To be able to open and close the door in a deterministic way, we have designed and installed a door opener. The door opener consists of a linear actuator, a motor controller and a 12V DC power supply. The video below shows opening and closing of the refrigerator door.
The linear actuator is a DC motor that drives a threaded rod. There are two switches that stop the motor when the rod is fully extended or fully retracted. The actuator can lift up to 200 pounds and is typically used in opening and closing truck doors. The threaded rod extends 12 inches (30.48 cm).
The motor controller is from model cars and can deliver of up to 2A of current at ±12V. It is very important that the controller uses a transistor-based H-bridge for reversing the polarity of the voltage so the door can be moved in both direction. The motor is controlled in an open-loop manner with the motor kept on for a predetermined amount of time (it takes approx. 18 s to open or close the door). The Arduino MEGA digital outputs connect directly to the motor-controller inputs and can use PWM to regulate the output voltage (and motor speed). We do not use PWM as it is not necessary to limit the speed of the linear actuator.
It is easy to get the "Hello, World!" of software radio to work with the USRP X310. Installing the hardware is straightforward, except it took some effort to discover the IP address of the 10Gb NIC which was not documented (I can imagine 10Gb interfaces are not common due to the still high price).
Compiling and running the software is also easy. Next is to learn it by copying the lab example of decoding and listening to an FM radio station (hopefully even after everybody moves to digital radio, they still keep some FM for testing.
This is how the GNU Radio implementation of an FM receiver looks like:
It turns out the strongest FM signal that I can receive in my office (our office in Palo Alto is very well shielded) is the KPFA public radio which transmits from Berkeley, California. The transmission antenna is 51.8 km away and there should be direct visibility.
It is always useful to see the spectrum of the raw signal. This is how KPFA looked like:
Finally, this is what I heard via the sound card (noise is not filtered and the SNR is relatively low):
Most common refrigerators and HVAC units are connected to the AC grid. Of course, there are also absorption, propane, kerosene, and other refrigerators but they are less popular and outside the scope of our study. Most of the electric energy consumed by a refrigerator goes into the electric motor that compresses the refrigerant (a very small portion is inevitably lost as heat due to resistance and other wastes). Sensing the details of a refrigerator's power consumption is as important as measuring the inside and outside temperature.
In this post we will describe the apparatus we use for measuring the consumed power in the refrigerator test-bed. One approach we could have taken is to use a home-appliance power measurement device such as the popular Kill-A-Watt appliance. It has been modified by the hackers community to interface with a Zigbee radio. Unfortunately, the low-resolution of the 10-bit Zigbee ADC, the relatively low sampling rate, and the difficulty to synchronize the hacked Kill-A-Watt makes it a bad candidate for our experiments.
Another approach would be to use an oscilloscope. While this would give us really good resolution and accuracy, it is not practical due to the long-duration of the experiments we envision. Continuously sampling with an oscilloscope during long hours and copying the result to a PC is achievable only with relatively high-end units. In addition to being expensive, the process is also unreliable and error-prone due to wiring and safety.
To provide more diagnostic information we have designed our own power logger. The PCB of this logger is shown below:
Of course, we can never be careful enough about electrical safety, so we put the power logger in a NEMA enclosure.
With the help of the above sensor we can log 24-bit power and voltage at 500 Hz. The sampling of two signals is synchronized, so we can easily compute the power.