The Black Linux Tower

Browser-Based Data Logging

2005-11-21T12:21:00.000-08:00

Finally! After several months the Black Tower has a general-purpose data logging program for the Atmel interface. There were some distractions: I had to take the cylinder head off my truck engine and put the thing back together. And there was the dead tree that fell across the power lines coming into my house. But after several week-ends coding away in Perl, the results can now be shared.

The idea was to have a completely HTML-based GUI to the Atmel ATMega32 midcrocontroller interface. Data logging could be configured from anywhere in the world via the Internet. Each input channel of the ATMega32 could be configured so that the data was recorded in engineering units or Vdc. The readings from each channel can be displayed on demand and data files downloaded directly into Excel using FTP.

In addition, I completely customized a webpage to generate graphs of the collected data using a Java freeware linegraph applet. Up to five traces can be defined and the X and Y limits of the graph set by the user. A sample screen is shown below.

I have been running the data logger continuously for a week or so and so far no problems. There are a few bugs still to fix in some of the Perl code, but it pretty much works the way I had intended.

A detailed description of the data logger is given in the Projects section of the University Linux website at www.documatrix-usa.com. If you have any suggestions or want a copy of the perl programs, e-mail me.

2005-11-21T09:08:00.000-08:00

Browser-based Data Logger for Serial Interface

Adding ATMega32L Digital I/O to the Webpage

2005-04-27T07:48:00.000-07:00

Once the ATMega32L analog inputs were accessible from a browser, it was time to add the digital I/O. The easiest thing to add was the digital input states. It was just a matter of having the ATMega32 analog input server also request the digital input states and then appending this to the output string of analog data sent to the client. The digital input string consists of four characters, one for each input, and are 1 (for an open input) and 0 (for a closed input). The ATMega32 has internal pull-up resistors on each input, so you simply connect an SPST switch from the input to ground. When the switch is closed, the input goes low; open the switch and the input is pulled high. On the client side, the four character string is parsed out channel by channel and printed to the bottom of the webpage containing the analog input readings. The designations are Open or Closed depending on the character received in the string from the server.

All this seemed to work well enough. I wired in a dual channel DIP switch to ATMega32L digital inputs 0 and 1 on the protype breadboard, and could view their state on the webpage over the LAN. The next step will be to use some contact closure type sensors. This might be a limit switch to detect position of some moving part. Or maybe a door sensor to detect if the door is closed or open. (These sensors are available anywhere home security devices are sold.) Magnetic switches are another possibility. These close in the presence of a permanent magnet. So you could know the position of a moving part without any physical contact with the switch.

Setting the digital output bits proved to be a bit more complicated. The ideal webpage interface for this is a checkbox that reflects the state of the output. But the state of the output bits must be stored somewhere so that the webpage can be initialized on first viewing. When the state on an output is changed, the ATMega32L must be updated, the new output states stored and the page re-printed thru the browser reflecting the current values.

The original idea was to have a single server handle all of the ATMega32L serial communications for reading inputs and setting outputs . The server for reading the analog and digital inputs is very simple. A client calls it and receives a string of values in return. Modifying the server to first accept a string output states added another layer of complications, so I took the easy way out.

The Perl code called by the browser that displayed and saved the digital output states was modified to include the serial port calls to the ATMega32L for setting the state of each digital output bit. I added two new navigation links on the left margin of the Black Tower homepage: ATMega32 Inputs and ATMega32 Outputs. The inputs page will fetch the analog readings and digital input states and displays them on a webpage. The outputs page fetches the current state of the digital outputs as checkboxes on a webpage. On both pages buttons are used to actuate the new settings or fetch new readings.

For an initial experiment, I wired an LED to digital output 1 and turned the photocell light sensor to be near the LED. The analog readings can pick up the change in photocell resistance when the LED is lit. So now there is positive feedback for the state of the digital output. So far there have been no glitches in the serial communications to and from the ATMega32L.

I now have two channels of digital inputs and two channels of digital outputs working smoothly. The next step is to add some relays and contact closure sensors so that real work can be done.

2005-04-19T08:18:00.000-07:00

ATMega32L Controller Webpage

Perl Code for the ATMega32

2005-04-19T07:43:00.000-07:00

Once the ATMega32L circuit was operational it was time to write some Perl code so that it could be accessed in University Linux. The first priority was to have a way to view the analog input channels from a browser. The best way to do this is to write a server in Perl so that any application running anywhere on the Black Tower can call up data coming from the ATMega32L.

I adapted the Perl server from the temperature sensor. I simply changed the port number (to avoid conflicts) then added some code to request the counts from each analog input channel via a call to the serial port. Perl treats any device just like a file, so it was a matter of opening /dev/ttyS0. Perl is a bit fussy about reading and writing to the same file, so the eventual open statement looked like this:

open (SPOut, "+>/dev/ttyS0");

I wrote a "0" to the serial port, and then read in the reply from the ATMega32L in counts, multiplied this by 5 and divided by 1024 to get the Vdc reading for analog input channel 0. Since there are 8 channels, I put this into a loop. Turned out that the serial port had to be opened and closed to get each separate reading. This was not as elegant as I had hoped, but it seemed to work OK.

The next problem was how to pass the values back to the client. I decided a single long string would be easiest, and individual readings could be parsed out from that. For this to work, however, each channel reading had to have the same number of digits. A reading of 4 volts, for example, would have to be 4.000 and not 4.0 or something else. I decided that three digits to the right of the decimal would be sufficient since the 10-bit A/D converter was reading only to 5 mV.

The solution to this was to take each reading and pad it by concatenating three 0's to it, then extracting a substring consisting of the first five characters. This seemed to work in every case and produced consistent 5 character readings for all channels.

All 8 readings, now five characters each, were concatenated together, separated by a space. This was passed back to the client by the Perl server. The client code parsed out each reading from the large string, and created a webpage displaying all the readings in Vdc with a channel label. A button on the webpage calls the server and generates a new page of readings. When the page is first viewed the readings are blank, but pressing the "Get Readings" button fills the page with current values.

The update goes fairly fast considering that the webpage has to enable a Perl client that calls a server that has to open and close a 2400 baud serial port 8 times. It has proven reliable in a few days of continuous testing; serial ports can be prone to locking up. Everything is situated on the Gamma machine in the Black Tower which is the newest and fastest PC. The ATMega32L controller page now is accessible from the Black Tower homepage, as shown in the screen shot.

The first application for the new interface was to connect a photocell in series with a resistor and the +5 V supply to form a light level sensing circuit. When it is dark, the photocell circuit puts out about 4.9 V, and when in bright light, about 1.5 V. This signal was connected to channel 1 of the ATMega32L analog inputs. I put the work light directly over the photocell and used the X10 control page to turn the light on or off and to vary the brightness. The photocell signal gives a positive indication of a change in light level, so now I can confirm the state of the X10 light switch remotely using the ATMega32L web page.

The next step is to add digital input and output controls. But to do this, I will have to figure out how have the Perl client pass a value (desired switch state) to the server calling the ATMega32L. Taking over the world is never easy...

Microcontroller Interfacing

2005-04-06T09:29:00.000-07:00

Everyone knows the world will be taken over by microprocessors. To control the world, however, you need a microcontroller. A microcontroller is a sort of muscular cousin to the microprocessor: slow, not too smart, but able to deal effectively with the outside world. So to bring the Black Tower to its full potential, there needs to be an easy way for Linux to interface to the real world through microcontrollers.

There are thousands of microcontrollers and choosing one can be confusing. Probably the most popular microcontrollers are the PIC series, but after looking around, I settled on the Atmel ATMEGA32L. The ATMEGA32L has a number of advantages and features that made it the best choice for the Black Tower project. First of all, the ATMEGA32 is available as a through-hole component. That means you can use it with breadboards and other easy-to-get prototyping tools. Most of the newer microcontrollers are coming out as surface-mount only. And this is a big problem for those of us who aren't going to spend hundreds of dollars developing a circuit board and contracting for outside assembly.

Another feature of the ATMEGA32L is it has a lot of I/O capability: 8 channels of 10-bit analog input, 8 bits of digital I/O and 2 counter-timers. Most microcontrollers have only 8-bit A/D converters and a limited number of other I/O. With the ATMEGA32L you can specify each of the digital bits as input or output in software. And the output bits can sink 20 mA so they can be used with solid-state and low-current reed relays to switch real 110 VAC power. And the ATMEGA32L is self-contained: no clock crystal is needed and it has a built-in serial UART so it can be configured to communicate with a PC running University Linux.

But the most compelling reason to use the Atmel microcontrollers is the software support. BASCOM offers a Basic compiler for the Atmel microprocessors that supports all of the I/O and communication functions. So you can write code for the ATMEGA32L in a high language, compile and burn it into non-volatile memory and you are ready to go. I found an Atmel training board from Futurelek that provided all the cables and supporting circuitry needed to develop and test my ATMEGA32L software.

There were the usual false starts and mistakes to be made, as with any new project, but I quickly got the Bascom code to upload and work on my ATMEGA32L in just few days. After that I built up a stand-alone circuit for mounting to the Black Tower. You need a level-shifting IC for the serial port because the ATMEGA32L port is TTL and the PC serial ports are based on 12 V signals. But the whole thing fit on a protoyping board I got from Radio Shack, including a +5 V regulator circuit for power. A description of how to build this will appear on the Documatrix website as a new project.

The ATMEGA32L accepts a series of commands from a PC serial port and then responds to those commands with information. If you want the analog voltage reading from one of the A/D input channels, the PC simply sends the channel number. The ATMEGA32L then responds with an integer value between 0 and 1023 that represents the magnitude of the voltage reading from that channel. To set one of the four digital output bits, the PC sends the letter A and the ATMGA32L sets bit 0 low; sending the lowercase a sets bit 0 high. (This seems backwards but to light an LED or drive a relay, you need to set the bit low. "A" seemed a better choice for "ON".) The input bits are read from commands W, X, Y or Z and you get back a value of 0 or 1 that reflects the state of that input bit. There is some handshaking and error messages, etc also.

So now all that is needed is some Perl code to communicate to the ATMEGA32L over the PC serial port. And then the fun begins, because you can easily enable the Perl code from a browser page and get readings and control things using the ATMEGA32L from anywhere over the Internet.

Adding Temperature Readings

2005-03-22T11:06:00.000-08:00

The next phase for the Black Tower was to get the temperature sensor hooked up and running. The sensor interfaces to the PC parallel port and provides a 12 bit reading for ambient temperature. This is a project on the UL website, so I reconstructed the Perl code that reads the sensor, converts the bytes to degrees and writes a webpage. I FTP'd the relevent files into Sigma, connected the sensor and tested it successfully.

The next step was to organize the webpages. What with the X10 control page, and the three temperature pages, I needed some way to access everything conveniently without typing in the explicit URL and web page each time. I made a simple webpage that included frames so the navigation is by links in frame that makes up the left margin of the web page. Now I can go to the X10 pages, and do control, or view the temperature pages and get the current reading or look at a file of readings.

I soon had everything working, more or less. The graphing script for the temperature file seems to be malfunctioning. I expect I will have to do some debugging on the Perl code that parses the readings out of the ASCII file. But this should be straightforward.

The Black Tower Control Page now looks like that shown below. As functions are added, I can just add a new link to the frame on the left. New webpages will appear in the main center frame. This scheme also eliminates the need to do a lot of browser backspacing when trying to get several current temperature readings, for example. The Perl scripting is fairly complex and actually re-builds the entire temperature webpage. Just clicking on a link in the left-hand navigation frame is much faster.

Once I get the temperature graph working agin, I will start integrating a new serial analog/digital interface and attempt to hook up more sensors...

2005-03-22T11:05:00.000-08:00

Control Web Page

Telnet Magic

2005-03-17T09:12:00.000-08:00

You really have to love Telnet. So simple, so unassuming yet so very useful. Now that I have Sigma running as the server with X10 functions operational, I decided to try an experiment.

Today I powered up both the Sigma and Beta machines. Sigma at IP 192.168.0.125 has all the Internet ports and services forwarded to it from the router. I changed the IP for Beta to 192.168.0.122, so it is just another machine on the LAN and normally not accessible from the Internet.

When I got to work, first thing I did was to Telnet into Sigma at my static Internet IP address. The log-in prompt came up, as usual, and I logged in as root. After starting the webserver, I decided to try Telnetting from Sigma to Beta. This proved to be as simple as it sounds. While logged into Sigma, I typed in "telnet 192.168.0.122" and the Beta log-in screen appeared. I logged in as root, and now I was inside Beta looking at files, directories, etc, just as if I was sitting at the Black Tower console.

Another plus for Telnet is that when I use HyperTerminal from my Win XP computer at work, I can run Pico on the target University Linux machine. So I can edit and write files remotely. This makes remote programming possible.

Backing out was similarly straightforward. While in Beta, I typed "logout" and I was out of Beta, but still inside Sigma. I logged out of Sigma and the Internet connection was terminated, just as always.

For my next experiment, I telnetted back into Sigma and invoked FTP to the Beta machine. The FTP log-in came up and I logged into Beta as ftp (since no password required using that username). I changed directories under FTP and used the GET command to transfer a file from Beta into Sigma. And it worked, just as if I was sitting next to the Black Tower.

The robust character of simple telnetting suggests that I can probably use this to control various operations as I add them to the different machines on the Black Tower. One thing is for sure, I will have to remember how to add a machine identifier to the screen prompts. I will also probably do some housekeeping with the hosts file so I can use machine names instead of IP address. This will make telnet navigation from Sigma much easier.

I will also probably try to write some scripts that invoke FTP to move files between the various Black Tower machines. I don't have NFS running on UL, so maybe I can come up with something similar, if a bit kludgy, with some clever Perl programming. Anyway, lots to try and do!

Adding More X10 Functions

2005-03-16T07:56:00.000-08:00

With the ON/OFF and light level control for my X10 lamp module now working via webpage, it was time to add a second X10 control module. In addition to the A1 lamp controller/dimming module, I have an X10 controller for inductive loads like fans or small motors and appliances. I dug out the motor control module, set it to X10 address A2, and plugged it into a handy power strip. Next, I plugged my table radio into the A2 module and verified that everything was functioning correctly by switching A2 with the handheld X10 control pad. The new X10 module was working reliably, even at some distance from the receiver module.

The next step was to test it with the Bottlerocket drivers running on Sigma. I typed in a command line for the new A2 module, and, as expected, Bottlerocket was able to switch A2 on and off reliably. Next came the hard part.

In order to make A2 accessible from the Internet, I had to modify the existing X10 webpage form and Perl scripting needed to call Bottlerocket. I decided to control the A2 module from a checkbox on the webpage. I had already used some radio buttons for the state of the A1 module. And using a checkbox is actually a bit simpler. Even so, I had to revise the reading and writing of data to the status file, detect the state of the checkbox and create the correct Bottlerocket line command syntax. After about two hours I had it all working, but it was not easy.

I started by using two Bottlerocket system calls, one for A1 and one for A2. This caused confusion in the X10 system. A1 was coming on when it was supposed to be off and A2 was supposed to be on. After some trial and error i discovered that the Bottlerocket command line can be structured to send commands to more than one module. So I created one system call to include the state of both modules and the dimming parameter for A1.

This fixed the problem. The new X10 control screen is shown in the posting below. it was a bit of an exercise to get the form working, and to pass the correct state of each module to the X10 status file, and to subsequent webpages. (When you Submit the page, it executes a Perl program that creates the Bottlerocket command line from the form controls, saves the status of each control to the file, calls the Bottlerocket driver and then re-builds the webpage/form with the state of all controls reflecting the previous choices.) So there was a fair amount of de-bugging involved.

But now I have complete control via the Internet over all the X10 modules that I own. Time to move on to a more challenging interface...

2005-03-16T07:50:00.000-08:00

New X10 Controller Screen

More on Controlling Lights

2005-03-15T10:31:00.000-08:00

The Beta machine turned out to have a flaky serial port and the X10 wireless controller was therefore not completely reliable. So I decided to move everything over to Sigma, since it is a newer machine and I trust the power supply not to burn up during the extended testing I have planned for the X10 controls. I fired up Sigma and Beta and telnetted into Beta, getting the Bottlerocket driver and relevent X10 HTML and Perl files. Everything worked fine on Sigma after changing a few file permissions. I then changed Sigma's IP address to 192.168.0.125 so it would be Internet accessible.

My next task was to add a dimming control to the existing X10 controller webpage. In addition to turning the lamp on or off, I wanted to be able to set the light level. I experimented with drop-down lists, but eventually settled on a text box for light level entry. Text boxes are easy to implement in HTML pages and the data can be anything. Drop-downs are limited to the number of entries I was willing to include, and this would be tedious. Because the light level value passed to the Bottlerocket driver must be a number from -12 to +12, the selections would be numberous. Besides that, the selected value would have to be parsed later, and so a consistent number of characters would be needed. All of this had complications I was too lazy to deal with, so I scrapped the drop-down idea even though it is probably better to give the user only valid choices. I also finally figured out the light dimming syntax of the Bottlerocket driver line commands and was ready to go.

The text box I added to the existing X10 controller web page was set to accept just two characters. This limits the valid light level choices to -9 to 12, but I figured this would be an acceptable compromise. I wrote some Perl code to take the text box value (characters) and convert them to integers. You need to do this anyway to formulate a valid Bottlerocket command line, but it has the additional benefit of turning everything that is not a number into 0, which translates into no change in light level by Bottlerocket. I should probably put some limits on it as well; if the converted value is greater than 12, then I should set it equal to 12.

Anyway, this worked. The X10 webpage now presented to the user by Sigma includes radio buttons for Lamp On and Lamp Off, and a text box entry for light level. When executed, my lamp goes on or off, as before. But now, if set to On, the Black Tower work light then dims to the selected level. The level is also saved in a status file so it is presented to the user on first reaching the X10 control webpage.

I have some clean-up and testing to do, but this definitely extends the X10 capability of the Black Tower. Just another small step in the master plan...

2005-03-09T07:37:00.000-08:00

Unorganized Cables on the Back!

Power Controller by Browser

2005-03-08T19:03:00.000-08:00

I have decided to put the wireless networking problems on hold for now. I spent another two hours trying different access point settings, but the end result is that the access point just does not seem to be communicating wireless to the router. So I will wait until I get the wireless USB network adapter running and try troubleshooting with that.

In the meantime, time to go back to Taking Over the World. I decided to get my X10 modules running again with University linux. This forms the subject of a Project on the UL website. X10 modules are inexpensive, readily available (Radio Shack usually has them) and they can turn 110 VAC power on or off. They can do this cleverly via a serial interface port and wireless transmitter. There are Linux drivers for the wireless X10 serial interface (Bottlerocket) that work quite well. So I decided to write some improved Perl scripting to allow a browser page turn my Black Tower worklight on and off.

I have always wanted to improve on the UL project. As it was originally described on the UL website, there was no way for the state of the X10 module to be known when the browser page loaded. So I added a Perl script that executes when a button is pushed from a web page. A file carrying the state of the X10 module (On = 1, Off = 0)is loaded and the state of radio buttons on a browser page is set depending on the contents of the file. The file is changed according to the selected state when the Bottlerocket drivers are activated. The result is that you can load the X10 control page over the Internet, see the state of an incandescent light, for example, change the state, and return later. The actual state of the lamp will be loaded by the browser page on each visit.

All of this went together quite well and I put it up on the Beta machine. Beta was set to IP 192.168.0.125 (the firewall's virtual server address) and the necessary HTML and Perl files loaded. I powered up Beta, started its webserver and went off to work.

I commute about 45 miles by train, so this is a good test of remote control capability. I fired up my Internet Explorer at work and typed in my static IP into the browser URL address bar. The X10 page came up, just as expected. I tried changing the state of the lamp, but got a text error message: "permission denied on ttyS0". So I had forgotten to allow browser users (nobody's in the UL passwd scheme) to be able to read or write to the serial port. Because Perl calls take on the permissions of the browser calling them, nothing could happen with the Bottlerocket serial drivers.

This was quickly fixed by Telnetting into Beta as root, and changing permissions with a couple of chmod commands. This worked and the browser page was soon able to turn my Black Tower light on or off.

Because the work light is a 50 watt incandescent, the X10 dimming commands should work. These are supported by Bottlerocket also. I should be able to put a drop-down menu in the browser page that specifies the intensity of the lamp. The Bottlerocket syntax on this is a bit elliptical, in my opinion, but it should just be a matter of following the Bottlerocket Helps.

I also have an X10 hand-held remote control so when I am working around the Black Tower I can switch the light on or off locally. And of course the switch on the top of the light also turns it on or off. But what fun is that?

Heartened by this success I plan to add a second X10 module to the system. This will make the browser page more complicated, but turning one light on and off is hardly a giant step towards Taking Over the World.

But it is a start.

Wireless Problems

2005-03-04T20:06:00.000-08:00

If you are plotting to Take Over the World, everyone knows it has to be done wirelessly. Just look at the cell phone companies; you can see that they are trying to take over the world, and they may do it, too. The Black Tower uses standard network cables and hubs to connect the 5 PCs, but what about to the outside? Right now there is a Cat 5 cable running from one of the hubs, across the floor and to the LAN router. The ultimate plan, however, is to make the Black Tower PCs a part of the LAN wirelessly.

The first step was to put a wireless router on the LAN. This proved to be much more difficult than I had thought. The Airlink AR315W wireless router I got for Christmas seemed like a good choice. It has four cable connections, including a cable uplink, and it has 802.11g wireless capability. I plugged it into our main D-Link router thinking I could make it a sort of wireless hub. Eventually this was accomplished, but only after a certain amount of frustration and anguish.

The problems began when the default IP address of the AR315W was in an entirely different range than the D-Link. I spent a lot of time trying to reset the AR315W IP address to somewhere within the range of the D-Link. To do this, I had to set a static IP address on my laptop to be within the range of the AR315W default network. Then I had to go into the AR315W confiuration screens and try setting things. To be fair, the configuration screens are fairly straightforward. But going back and forth between networks was a real pain.

Even so, the upshot was that when the AR315W's IP address was within the range of the D-Link router, nothing connected to the AR315W would ping to anything else, and the Internet was unreachable.

The problem was finally solved by my son, who seems to have developed an instinct for network settings. The IP of the AR315W was returned to its default setting (outside the D-Link network). But the AR315W WAN IP address was set to a value within the D-Link address range. Then the AR315W Gateway IP was set to the D-Link's base IP, and everything worked. My laptop could be connected by cable to the AR315W, and I was able to reach the Internet and ping both routers. I can also reach any of the University Linux PCs through the AR315W, so presumably a wireless PC could connect to The Black Tower right now. I have yet to test this however.

Buoyed by this success, I began a similar process to configure the Airlink AP411W access point that I had bolted to the Black Tower. The idea was that I could unplug the cable running from the Tower to the D-link, and have the networks connect wirelessly. Eventually, my laptop and the Tower could be anywhere I needed them, as long as there was power.

The AP411W had a fairly straightforward interface, but you have to reach it at its default IP 10.0.0.1 I then changed it to something within the range of AR315W on the theory that it would look like a hub on that network, and the wireless connection between it and the AR315W would, magically, give me a wireless connection to the Black Tower. I would have to reset all the PCs in the Tower to IP addresses within the AR315W network, and the Internet virtual server configuration would be interesting now that two routers and two networks were involved, but this seemed a reasonable price to pay.

Problem was, it didn't work. I spent a fair amount of time trying the different RF settings for modes, channels, SSIDs etc. But no combination, however logical, would cause the thing to do what I wanted. A look at some postings on the Internet has me convinced I can make this work, especially since the wireless router and the access point are both Airlink. I will probably have to re-read the CD manuals more closely, but it is obvious that wireless has a way to go before it can be said to be easy to set up.

My plan is also to configure the laptop for wireless network operation with the USB adapter I have. But first I have to upgrade to Windows ME; a process I am procrastinating on. It should be easy to get the wireless adapter to talk to either the router or the access point. Maybe this will help determine how the whole system should be configured. But if anyone has any suggestions, please let me know what else to try.

In the meantime the Tower is operation on my LAN and accessible over the Internet, if still by cable. So while I am solving the wireless puzzle, I can continue with the main task at hand: configuring the various University Linux PCs and servers for measurement and control.

Networking The Black Tower

2005-03-04T14:22:00.000-08:00

After the PCs were up and running, the next chore was to get them networked together. I had already mounted two hubs, and a wireless access point into the Tower, so I was ready to get the PCs talking to each other and the rest of the LAN.

The first task was to make sure all of the network cards were functioning. I had no trouble with Alpha, Beta and Gamma. Beta and Gamma had old ISA cards and the Linux ne driver module found them right away at the usual I/O address. Alpha has a Linksys PCI card which uses the ne-2K module. The only trick here is to be sure to boot from a floppy. Otherwise the Win98 PCI controller takes over and the Linux driver gives a "resource or system busy" error message.

The Delta machine had ISA slots, so I found another of the old network cards and ne found it right away. The Sigma machine, being a newer Compaq, had PCI slots and some sort of generic network card. None of the usual University Linux modules could make it work. This sometimes happens; the cards were not even in existence when Linux kernel 2.0.34 was compiled. Eventually I found another Linksys PCI card and ne-2k took care of it.

The next step was to assign IP addresses. These were assigned from 192.168.0.122 to 192.168.0.127 as these addresses are in the router's allowable space. I added these to each manchine using the ifconfig and route commands placed in the /etc/rc Liunx boot-up file. Now all of the PCs come up network ready at their assigned IP addresses.

I decided, for now, to reserve 192.168.0.125 as the server address for any PC to be accessible from the Internet. This is a convenience because it is easier to change the IP address of the PC then it is to re-program the router's virtual server page. The D-Link router that connects our network to the Internet has been in use for two or three years, and I like its straightforward configuration screens. But it is tedious to change things.

I have also been thinking of a way to experiment with changing Tower PC IP addresses remotely. Unlike Windows machines, a Linux PC can have its IP address changed at any time. So there might be some way to dynamically change the machine that it accessible from the net, depending on the purpose.

With all the machines networked, the hubs filled up with CAT 5 cables fast! In fact it is quite a mess on the back of the Tower. I have a bag full of big cable ties so as soon as everything looks stable, I can begin to clean up the wiring.

Right now the laptop is connected by cable to the Tower, and so is the D-Link router. That violates the original intent of having just one network cable. But I had also installed a wireless access point on the Tower. I have a wireless USB adapter for the laptop, but I first need to upgrade to Windows ME and I haven't started that yet. The plan is to get the laptop and wireless access point on the Tower communicating with the wireless router that is currently (also) cabled to the D-Link. If you think that sounds complicated, it is, and is became the cause of much grief!

So far, everything was going according to plan, but then I tried to set up the wireless access point...

2005-03-04T10:10:00.000-08:00

The Black Tower - Alpha, Beta and Gamma PCs installed.

Populating the Black Tower with PCs

2005-03-03T21:52:00.000-08:00

It took about three week-ends to finally get the Black Tower assembled and in place. Now it was time to go through all the old PCs in the garage and see which ones were still running. Because these machines were all going to eventually be networked into a cluster, I named them with the traditional Alpha, Beta, Gamma, etc designations.

Alpha Machine
The first machine I installed was actually one that I was using on a regular basis. It is a 233 MHz AMD K-6 with 64 MBytes of RAM and 5 GByte hard drive (in two partitions). It has Win98 and all of the applications I normally use, but I put this PC on the Level 1 and have the monitor and keyboard normally connected to it. University Linux is on the Alpha machine, of course, and I boot it off a floppy when I want to have it in the Linux mode. I plan to use the laptop more for everyday tasks and try to leave the Black Tower PCs to run just Linux.

Beta Machine
The Beta PC is an old friendly 66 MHz 486 with 8 MBytes of RAM and something like an 80 MByte hard drive. One of the kids had it for a while and so the case was hand-painted in a kind of sickly blue. Even so I still love this machine and it has a place of honor on Level 3 of the Black Tower. At one time this was a state of the art PC and I still maintain that I could do everything on that old machine that I now need a multi-megahertz Pc to do. When it was new it ran Windows 3.1. I remember using Word and the orginal Netscape browser on that PC with a dial-up Internet connection. University Linux was easy to get running on Beta. Best of all, the BIOS has an "ignore keyboard test" setting so I don't need a keyboard attached to it just to boot up. The Beta machine is strictly a DOS box so I have a batch file to run UL. I can just turn it on, and a few minutes later I can log into it over the network.

Gamma Machine
The Gamma machine in the Black Tower is a stray. Someone brought it home because a friend's office was upgrading and they were just giving away their old PCs. I think I know why. Gamma is a Compaq Prolinea 4/50S. Prolinea must be Latin for "really slow" because even at 66 MHz, this 486SX seems to labor. Worse, Compaq has a habit of making the BIOS impenetrable, so it sits in the Black Tower with a keyboard next to it. This is also strictly a DOS box, although the original owners were running Win95 on it at one time, hard as that is to believe. But it runs UL nicely and has a useable network card. So it sits next to the Beta machine on Level 3.

Delta Machine
The Delta machine is something of a mystery. No one knows where it came from. Like coat hangers, PCs in your garage just seem to appear sometimes. Delta has the distinction of being the oldest, slowest PC in the Black Tower so far. It is a 386 SX running at 40 MHz with 16 MBytes of RAM. Delta is so old, it does not even have a fan on the CPU! UL runs fine, if a bit more slowly. The controller card won't run the floppy drive anymore and the BIOS allowed for disabling the keyboard test on boot up, so it is true "blind box" and it sits on Level 3 next to Beta and Gamma. Delta, however, is also important as a test bed for embedded computing. There are low-cost 386SX single-board computers available now that have 16 MBytes of RAM and a 16 MByte Disk on Chip. Maybe someday University Linux will be hiding in a junction box running on such a machine. Delta will be used to see how feasible control and data capture will be on the most limited of embedded platforms.

Gamma Machine
The Gamma machine is probably the fastest PC in the Black Tower. It is a 500 MHz K-6 machine with 64 MBytes of RAM. It is a Compaq Presario, and so naturally the BIOS has been dumbed down so that it is practically useless. It has a CD drive and might be a candidate for upgrade to one of the bigger Linux distributions. But right now it runs University Linux (really fast!) and we use a floppy to start it up. It has Win98, but even with all its clock speed, you need a calendar to time its boot up under Windows. Rather than just trash that just now, however, a floppy is a handy way to simply proceed directly to UL. Gamma has a tall (some might say pretentious) case so it sits next to Alpha on Level 1.

There is still one more PC in the garage, but it won't start up. Probably a power supply, but for now I am going with five PCs in the Tower. If I get time I might see if I can get the sixth one running. As a result of putting all the old PCs into the Tower, I now have an assortment of old spare monitors.

Nothing can now stop me from Taking Over the World!

Building The Black Tower

2005-03-03T21:29:00.000-08:00

Building the Black Tower was not that difficult. I had some experience with rough carpentry, so I got a bunch of 2" x 3" studs and cut them to length with a circular saw. The Black Tower is really just a frame of 2" x 3" pieces nailed together. On the sides I decided to use bolts to hold the cross pieces so they could form a level surface for the shelving. When the frame was complete, I painted it black (of course!) to give it that air of sinister respectibility that you want when Taking Over the World.

The Black Tower has four levels. Each level is made standard 1' x 2' particle board shelving nailed to the cross pieces of the frame. Particle board used to be really ugly, but the shelves I found had a nice white finish that looked good against the black frame. I left a 1/2 inch gap between the shelving pieces so I could add some sliding clamps to secure each PC. The lower level holds two PCs, the second level has a monitor and keyboard (at the ergonomic height of 27" off the floor). The third level has three more PCs, and the top level is for setting up breadboards or other experimental equipment.

The wheels for the Black Tower are three inches in diameter and come with a mounting flange so it was easy to fasten them to the base. These wheels were about $4 each, which is a good price, but they are a bit too small to easily roll the Black Tower over carpet. If you make your own Tower, try to get wheels at least 4 inches in diameter.

On the sides of the Black Tower I mounted several power strips. You really can't have enough of these. If you try to take over the world with your own Black Tower, be sure to have at least four power strips. Above the power strips I mounted a wireless router, two network hubs and a wireless access point. The soft wood made it easy to install screws for mounting everything. A clip-on 50 Watt work lamp finished it off.

Now that the Black Tower was built, the next thing was to add the old PCs and get them all going again...

Why The Black Tower?

2005-03-03T20:03:00.000-08:00

If you are like me, you have collected a bunch of PCs through the years and you can't quite bring yourself to throw them away, Or even give them away. At the same time, life, and applications software moves on and pretty soon you have six or seven old PCs sitting in the garage, none of which is capable of running the Windows software you are using. University Linux allows these old machines to function again in a 21st century way. They can be networked, organized into a cluster, or configured as network and Internet servers. New life for the good old machines!

I went to work getting each old PC running again and installing University Linux. At first, I had all the PCs scattered around on the floor. Network cabling and power cords were everywhere in a giant tangle. And worst of all, every time I wanted to get access to a port or connector on the back panel of a PC, I found myself down on all fours swearing at the lack of light and at my sore knees.

I had actually completed several projects with University Linux when I decided that there must be a better way. First thing, access to the back of the PC is essential if you are doing experimental work with interfacing to take over the world. I realized that what I really needed was a way to walk around to the back and stand up to work on the computer. I had seen something like this in industrial installations with 19 inch relay racks, so this was a conceptual starting point.

You can now buy computer racks, and they look pretty nice, but I thought I could do better and spend less. I decided that what I wanted would have wheels, so I could pull everything out from the wall and work on any part of it. I also decided that it should be sized to roll through a doorway so I could move everything to where I was working, or even out of sight, if needed.

So gradually the Black Tower took shape in my brain. It would have just three cords connected to it: power, network and phone. (And I hope eventually to go wireless with the LAN.) It would hold all the hubs, power strips, and external accessories so that it would be completely self-contained. And I added a clip-on lamp so that I would always be able to have enough light on any part of it.

The PCs in the Black Tower would be as stripped-down as possible. Everything would be run over the network by Telnetting into the Tower from my laptop on a desk. One monitor would be included in the Tower so I could program locally on any PC by moving the video cable around. But the idea was that it would be operated remotely whenever possible.

So with these ideas sketched out, I took a trip to the lumber yard...

I Plot to Take Over the World

2005-03-03T15:43:00.000-08:00

Today I begin to put into action a plan I have been perfecting for some time. It is a plan that will allow me to Take Over the World using only Linux and old computers that nobody wants anymore. To do this, I have built The Black Tower. The Black Tower now holds five more or less obsolete PCs, all running University Linux.

The PCs have been all been networked together, with CAT 5 cable for now (but I am working on wireless). Each PC has its own IP address on my internal LAN, and I have a DSL line, modem and router that allows virtual servers. So the Black Tower can host my own webserver, FTP server, Telnet and other web-based services. The Plan is to use these in conjunction with real-world interface devices to measure, record, display and control things: all over the Internet from anywhere in the world.

The PCs in the Black Tower vary greatly in age and horsepower. The oldest is a 386SX machine running at a the breakneck speed of 40 MHz. It has 16 MBytes of RAM and about 80 MBytes of hard drive. The best machine is a 500 MHz Compaq with 64 MBytes of RAM.

More about the residents of The Black Tower in a later posting...