If you’re wondering why my blogging has been light recently, there are two main reasons: I’ve been sick as the proverbial dog for the past few days (but now I’m recovering nicely), and I’ve been working on a humongous project. The guts of the project are pictured at right, and I’m sure nobody could figure out what’s going on from that little bit of a clue <smile>!
As usual, click on the small pictures to get a larger view.
The general point of this project is to upgrade the pitifully slow bandwidth of our Internet connection. Way out here in the boondocks of Jamul, the only choices we’ve got are dial-up and satellite. Dial-up is doggone slow, and satellite is just terrible for almost everything other than file downloading (it’s great at that!).
And there are two parts to this problem: the bandwidth that we experience, sitting in Jamul, suring the web or picking up email — and the bandwidth that our web site visitors experience. This project addresses both issues.
First, I’m locating two servers at a friend’s house (this maniac has oh-so-graciously allowed me to put all this stuff in his home!). My friend lives in El Cajon — a real city, with real services. I’ve installed a high-speed DSL connection to his home, and my two servers will be connected to that. This means that you, dear reader, should experience simply stunning speed improvements when reading this blog. This operation is scheduled to take place next Sunday, January 29th.
Second, in addition to the DSL I ran to my friend’s home, I also ran a pair of dedicated phone lines. Also in his home will be a special kind of router that will accept a pair of connections over the phone lines (doubling the normal dial-up speed) and relaying them to the DSL. At our home in Jamul, I’ve also installed two phone lines, and these will be connected full time to our friend’s home.
Saying it all like that makes it sound pretty easy — but there are some tricks here. First of all, the place my friend made available is in a somewhat dirty basement, not air conditioned. That dictates putting the equipment in a cabinet with a filtered air supply. Then when you start adding up what I mean by “equipment", you see some challenges: two servers, two routers, one dual modem router, two network switches, a DSL modem, and a UPS. Yikes!
But wait — it gets worser.
This cabinet full of tightly packed equipment will be located about a half-hour’s drive from my home. It’s not really practical to drive that far to reset a server whenever I make some change in my blog code that causes a crash. Or when any other of a zillion things happen. So I needed a way to remotely reset the servers. And taking that same thought to a (very) slightly more extreme level, I also needed to be able to power cycle the servers (sometimes a reset just doesn’t do the trick). Plus I needed to automatically manage the server shutdown and startup in the event of a power outage. And then I also need to manage the fan speeds — rather than just run them at full blast all the time (reducing their lifetime), I thought I’d monitor temperatures in the cabinet, and adjust the fan speeds automatically.
Oh, this got complicated really fast…
One saving grace: my friend’s son is a most excellent cabinet maker, just by happenstance. And he very graciously allowed me to use his shop and his skills to build a custom cabinet of my own design, just the right size to fit all my gear. Without his help (and his fantastic computer-controlled MDF-cutting machine!), this project would have been much more difficult.
The lower three pictures are various views of the controller board that I built to run the cabinet. It’s based on a Z-World Jackrabbit BL1810 board (with prototyping board), which has a processor that’s basically a seriously souped-up Z80 (and I wrote a lot of Z80 code in my day!). The pair of stacked PC boards visible in the lower-right photo are the Jackrabbit.
The rest of that mess is a piece of vectorboard with a bunch of circuitry that I designed on it. There are switches to turn the fans on and off, digitil potentiometers to control the fan’s speed, and a tachometer mux to allow all the fans to be individually monitored for speed. Temperature measurement is handled by eight digital temperature sensors, which are scattered throughout the cabinet and inside the two servers. Power control is handled by a pair of miniature hard-contact relays (with drivers); reset is handled by a pair of digital switches. The controller has its own sensing of the power mains, separately from the UPS. And of course there are LEDs (couldn’t build something like this without 'em!), and just for grins, a pair of optoelectronic reflective infrared door-open sensors. Finally, the controller has a pair of serial ports that I’m using for communications between the controller and the servers.
Whew! Just building all that hardware was a pretty big project. But then came the firmware for the controller… There’s some fairly tricky stuff in there, like a few interrupt service routines that really had to be done in assembly language (for speed) — and it’s been a few years, folks, since I’ve written any assembly language. Fortunately the old saw about never forgetting how to ride a bicycle appears to apply to assembly language coding as well. I had to re-familiarize myself with the Z80’s architecture, but within a few hours of starting I had the first ISR going. The rest of the firmware I wrote in “Dynamic C", supplied by the Z-World folks. This is a very modern and very friendly environment compared to the primitive tools I used way back when. It’s full of snazzy features and unexpected conveniences. But … it ain’t Java, and this ancient and venerable software engineer has gotten very comfortable with the cushy, safe, protected world of Java. I’ll give you just one example, which the techies amongst you will appreciate. In Java, if you intend to compare a variable 'i' with 2, you might write this code: if( i = 2 ). But that would be wrong, and it wouldn’t compile (so you’d know it immediately and fix it before you ever tried to run the program). With the C language, that code compiles just fine, and when it runs, that code will set i equal to 2 and then tell you it was equal. Yikes! I did that three times in 5,600 lines of code, and each of those took me quite a while to find. Sheesh! I miss Java!
But now the whole darned thing is working. All the hardware, all the wiring, and all the firmware — it’s all up and chunking along. Yee hah! All that’s left is configuring the network gear and servers, and that, my friends, is truly trivial compared to what I just went through with the rest of this project.
My wife is absolutely overjoyed to have this project come to an end — I believe she’s marked next Sunday on her calendar. The reason for her abundance of joy is one that I’m sure many of you will be sympathetic with: this project is being built in our livingroom. We simply have no other place to build something this large, so there it had to be. Oh, Debbie will be very, very happy to see that cabinet depart…
And so will I…
In the old blog, Simon said:
ReplyDeleteAny digital temperature sensors outside the cabinet? What if the temp in the basement is 100+ degrees as is possible in El Cajon. It might be nice to know that the temperature problem is outside the cabinet. And exactly what kind of house is this in So. Cal. that has a basement?
In the old blog, SlightlyLoony said:
ReplyDeleteThere is a sensor outside the cabinet (on the bottom), so I can get the ambient. In addition there is another sensor in the intake manifold, with only an air filter between the manifold and the outside world, so it should read very much like the ambient.On the basement: his house is on the side of a fairly steep hill, and the “ground floor” is at ground level on one side of the house, and elevated about 10' on the other side of the house. The space below the house is enclosed, but not excavated — so it’s sort of like a basement with a big pile of dirt in it on the uphill side…