CPU and I/O Utilization Display - Details

In the  post Server Box With Utilization Displays I showed a system which displays CPU and I/O utilization in real time.  If you are using the Raspberry Pi in GUI mode, then there are numerous tools to display this type of data on your screen, such as gnome-system-monitor or Conky.

However, when the system is used in an embedded mode (sometimes called head-less because it uses no monitor) you need alternative methods for tracking this information.  I sometimes will open an SSH connection and use shell utilities to provide this information.  Some of the options are: top, mpstat, iostat, and sar. 

I really wanted the “lots of blinking lights” effect for my server, so I developed the software below to provide that. The basic concept is to periodically (once per second, or more) read files in the /proc and /sys file systems to collect data and then update banks of LEDs appropriately.

CPU Utilization

The file /proc/stat provides a lot of information about the system, including CPU utilization.  The first line is a total for all CPUs in the system.  This is followed by lines for each individual CPU.  For the Raspberry Pi, reading the first line is all that is needed.  There are four values that we will be interested in:

• User mode CPU time – this is the time the CPU spends running programs that are in user mode at standard execution priority.
• Nice mode CPU time – this is the time the CPU spends running programs that are in user mode at a priority other than standard.  See the nice command for more info on this.
• Kernel mode time – this is the time the CPU spends running in kernel mode.  This is the protected mode that the operating system uses.  This will include things such as device drivers and system API calls as well as the core OS itself.
• Idle mode CPU time – this is the time the CPU spends doing nothing.

These values will be constantly updated, so the utilization program must track the changes over time.  It will store the values each time it computes CPU utilization and compute the change for each.  The CPU percentage utilization will be 100 x (user + nice + kernel) / (user + nice + kernel + idle)

I/O Utilization

The file /sys/block/DEVICENAME/stat provides information about the specified DEVICENAME.  The device sda is my external hard drive but you may want to use mmcblk0, the SD card.  I decided to keep this simple and only track the number of sectors read and written.  Like the CPU data, this data is constantly updated, so the change over time is what is tracked.  One difficulty with I/O utilization is that the program has no way of knowing what value 100% should be.  I provide a function to set this value, but you can simply let the program track it dynamically.  100% percent will always be the maximum usage seen so far.

Displaying the Utilization

The next challenge is to display this data.  If your system has an LCD display, you could just show the percentages directly.  Alternatively, you could make this data available via a web interface.  I chose to use 10-LED bar graphs controlled via GPIO.  You could use a single LED that lights up when a threshold is passed.  You could use 10 separate LEDs, but the multi-segment LEDs are easier to connect and take up less space.  A good compromise might be three LEDs to indicate low, medium, high and very high utilization.  The software below supports 10-segment LED displays.  I will leave the other options as an exercise for the reader.

Software

The software I am using can be obtained from google code using the git command.

git clone https://code.google.com/p/raspberrypi-utilization-display/

See the included README file for further instructions.

If you just want to browse the source code, you can do that at this address:
https://code.google.com/p/raspberrypi-utilization-display/source/browse/

This is still a very rough version of the software but should still prove useful to some.  In the future I hope to add a configuration file that will define the update rate, the number of LEDs to use, and what GPIO pins the LEDs are connected to.

Automated Home Brewing

Brewing Controller User Interface

I have been a “home brewer” in the electronic hobbyist sense for decades, but I am also a “home brewer” of beer.  I mentioned this in my post on Reading Temperature With Thermistors.

I now use digital temperature sensors (typically the DS18B20) read over an I2C bus.  Adafruit has a good tutorial on how this is done located at http://learn.adafruit.com/adafruits-raspberry-pi-lesson-11-ds18b20-temperature-sensing/overview

It is fairly common to control a refrigerator and heater to keep a constant (or slowly changing) temperature during the fermenting process, especially with lagers.  I have done this using the Raspberry Pi, thermistors, and an A/D convertor.  Now, I decided to get a lot more ambitious.

I won’t go into all the details of the brewing process since there are many resources on the web to provide that.  For a quick look at this process, see the article on my photo blog.  I wanted to be able to control at least the following items for one of the simpler methods of brewing (called partial mash.) 

• Valve to a tank of propane
• Grill ignitor to light the burner
• Sensor to detect if the burner actually did light
• Temperature sensor for the wort (the brew of water, malt extract, and hops)
• Pump for circulating water through the wort chiller

What I needed to do this:

• A relay to output 12V to control the propane valve
• Another relay to output much higher amperage of 12V to run the pump
• A relay connected in place of the button on the grill ignitor
• A connection for one or more DS18B20 temperature sensors

The hardware is described below.  I also wrote software for the Raspberry Pi (in C, my language of choice) to manage this hardware and the brewing logic.  C# .Net provides the user interface on a Windows laptop. That is the image at the top of this post. The laptop and the Pi communicate via socket calls over wifi.

There were three major problems that had to be overcome once I started testing.  One is that I tried using a DS18B20 to detect the flame.  Well, the maximum for that sensor is 125°C and I did not use a high temperature version.  The flame is VERY hot (duh!) and the sensor eventually melted, shorting 5V to ground and shutting down the Pi.  Fortunately it was not damaged.  I doubt changing to a high temperature version will help, but I will try that next.  Another option is to do what every furnace, stove, and hot water heater does for its pilot light – use a thermocouple to detect the heat.  I may have to investigate this to see if I can devise a simple interface for one.

The second problem was that the wiring for the ignitor kept shorting out and creating a spark too far from the flame to light it.  Additional insulation and a change in how it was mounted solved this problem.

The third problem was that the EMI created by the ignitor caused massive interference on the I2C bus that made it unusable.  This was corrected by re-wiring my temperature probes with well shielded cables.  I used shielded audio cables commonly used for microphones.  I am also a musician so I had some of this already.  If you have to buy a small reel you may find that it is rather expensive.  Cat-5 cable may also work well.  That is what I use for my hot tub controller, but it is not subjected to the massive EMI of this system.

I disabled the flame detection logic. This is a critical safety feature and must be corrected for this system to be trusted.  However, this did allow me to successfully use this system to brew.

This is a good place to state that working with flammable gas and boiling liquids can be hazardous.  I take no responsibility for your use of the advice provided in this post.  BE CAREFUL!  And drink responsibly.

Hardware

Control of all of the above components is pretty straight-forward.  Search my blog or the web and you will find how to control relays.  The Adafruit link above will show you how to connect the I2C temperature sensors.

I used audio connectors since they are cheap and readily available.  ¼ inch mono for the relays and stereo for the I2C bus.  Using an audio connector for the I2C bus gives the added benefit of being able to use pre-made splitters and extension cables and these tend to be well shielded and relatively inexpensive.

The 5V line from the GPIO connection is only used for the I2C bus.  I already required 12V (which is actually 13.8V) for the valve and pump.  However, the relays I used were controlled with 5V.  This voltage does not need to be accurate, so I made a simple voltage divider using three 100Ω resistors.  Two 100Ω resistors are used for R1 and one 100Ω resistor is used for R2.  This divides the input voltage by 3 to provide 4.6V, which is adequate to control the relays.

The final interface box looks like this. The red and black power connector you see is called an Anderson Power Pole.  I chose to use this since I already have 12V supplies for my HAM radio equipment.  (I think maybe I have too many hobbies.)

Modified Grill Ignitor

The ignitor can be found in many hardware stores as a replacement for repairing gas grills.  The cheaper versions of these use a spring and a piezoelectric voltage generator to create the spark.  These are not suitable for this application.  You must get the more expensive type that uses a battery.  I removed the push button and made my own connection that runs to the relay in the interface box.

I still have a few kinks to work out in this system, but I am sure that this automation will make the process of brewing much easier and more consistent.  This is definitely the most enjoyable project that I have done so far with the Raspberry Pi, and that is not just because I end up with great beer.

The system set up for brewing

The temperature sensor is a water-proof high temperature DS18B20 covered in food grade shrink tubing.  These are available at Adafruit.com

Here, the system is set up for chilling the wort.  

The cooler has water and 10 pounds of ice cubes.

Stupid Simple Tip #4

Murphy was an optimist. I have repeatedly had problems with USB cables.  USB cables are held in place only by the friction of the connector.  Repeated insertions and removals WILL wear out a USB connector.  Anyone with an old laptop has probably encountered this problem.

Another problem is in systems that get moved around a lot or are subjected to a lot of vibrations.  Here is what I did to eliminate this problem in a recent project.  Zip ties are wonderfully useful.

Server Box with Utilization Displays

A while back I built a server with the system root moved to an external hard drive.
Blog Post - Running From an External Hard Drive

That system has now failed. I shouldn't be surprised since it was built with very used parts. I decided to rebuild it and put it into a nice enclosure this time, rather than just having parts all stuck together. I also decided to add LED bar graphs to show CPU and I/O utilization.



The first step was to build the LED interface. This was accomplished using two 10-segment LED bar graphs and a GPIO extender. The GPIO extender is needed in order to drive all 20 LEDs. I used a MCP23017 I2C GPIO extender which provides 16 GPIO bits. Another 4 GPIO bits were taken directly from the Raspberry Pi.

The LED board is shown here before the GPIO lines were attached.



The next step was to attached the LED board and a Raspberry Pi to the top of the case.  The LED board is attached using epoxy with the LEDs showing through holes cut in the plastic case.  The Pi is attached using
plastic offsets and machine screws.

Notice that the analog video output connector has been removed from the Pi.  The case was just a little to tight a fit for it to work with that in the way.

A power connector will supply 5V to the LED board and to the USB hub and will use the power supply that was included with the hub.  The Pi is powered through the GPIO pins.

A hard drive salvaged from an old laptop is placed in the bottom of the case.  It is connected using an IDE to
USB adapter.  The USB cable is fed out of the case and then back in to the USB hub.  This part is a little odd, but is the only way I could get it to fit in a case this small.

Here, the power connector has been  mounted, the USB hub has been added, and all other connections have been made.  It's time to squeeze it all inside this plastic enclosure.












Here are a couple of pictures of the completed server.


















Below is a video which shows how the utilization LEDs look in action.