Linux in the Real World
A year ago I installed Linux at home on my 386-20 and fired up X11 on my Hercules monochrome graphics adapter. I edited a source file with GNU emacs and compiled it with gcc. A real “Unix” system at home! I was so thrilled I walked around grinning for days. “This is so cool!” I exclaimed. “That's nice, but what do you do with it?” was the reply. I didn't have much of an answer then—but I do now.
This article describes a real world Linux application. The requirement was for an unattended computer to gather data from three different fluid level measurement devices and relay that data to a remote location.
The site is a coal-fired power plant about 100km away from the computer. The three measurement devices are mounted on an upright cylindrical tank with a height and diameter of approximately 7m. The tank holds water which will be mixed with ash to produce a slurry that is easier to handle than dry ash. There is 120VAC power at the tank, but no telephone line. The environment is benign, other than the constant presence of a powder-fine dust that resembles a cross between Portland cement and cake flour.
The measurement devices all use different serial protocols and physical layers. Two protocols use printable ASCII with each frame terminated by CR/LF. The first of these (ASCII Modbus) resembles Intel hex records on an RS-232 physical layer. The second is a proprietary command interface that utilizes shell-like commands over an RS-485 physical layer.
The third protocol (RTU Modbus) consists of binary data with the end-of-frame marked by a gap larger than 3 byte times. The physical layer is half-duplex FSK. The interface to the computer is an RS-232 port connected to a proprietary FSK modem.
The hardware selected for the system is a rack-mounted, industrial 486 machine with 16M of RAM and a 500M IDE disk drive. The industrial PC chosen has several features useful for unattended operation:
Ability to boot without a keyboard.
Ability to boot without a video board.
A hardware watchdog timer that can reset the computer in case of system lockup.
Since no phone line was available to provide communications between the data gathering system and the central host, a cellular phone was used.
Cellular communication—all you need is money.
For this task I purchased a pair of Microcom DeskPort 14.4K modems that support the MNP-10 “cellular” feature set. Cellular telephone connections vary much more in quality from minute to minute than do land lines, and drop-outs are more frequent and longer. For reliable cellular communications, modems need the ability to re-equalize and adjust baud rates and packet sizes accordingly. With the MNP-10 features disabled, I was unable to maintain a reliable connection even at 300 and 600 baud. With the error correction enabled, the connection was usually maintained at 9.6K or 12K baud.
UUCP was chosen over SLIP due to UUCP's ability to queue work and to automatically redial and restart a transfer after a call is dropped.
The cellular telephone is a Motorola “Bag” style 3-watt cellular which was on hand and available for use. A “cellular connection” box had to be purchased for the phone. The cellular connection is a black box, about the size of a pack of cigarettes, that plugs between the handset and the radio. It provides an RJ-11 jack, generates dial tone, responds to the modem's switch-hook transitions and converts DTMF tones to handset key presses.
Since one of the ASCII interfaces runs on the RS-485 physical layer, a board from Opto-22 was chosen that had a standard 16450 UART with opto-isolated RS-485 drivers and receivers.
The system required unattended, remote operation and simultaneous communication on four serial ports. While all of this would be possible under MS-DOS it would require a significant amount of effort, while a Unix-type OS would support all of them right “out of the box”.
Copies of Coherent and ISC SVr2 were available for use, but I chose Linux for two reasons. First, I was (and still am) running Linux at home. More importantly, Linux source code was available in case something needed to be customized or fixed.
A borrowed Fall 1993 Yggdrasil CD provided the base system, although uucp and mail didn't work as installed. I downloaded new copies of smail and Taylor UUCP, and they installed and configured with no problems. getty-ps was installed to allow the modem to be used both as a dial-out device by uucp and as a dial-in device for remote logins.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- New Products
- Linux Systems Administrator
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Designing Electronics with Linux
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- Nice article, thanks for the
9 hours 1 min ago
- I once had a better way I
14 hours 47 min ago
- Not only you I too assumed
15 hours 5 min ago
- another very interesting
16 hours 58 min ago
- Reply to comment | Linux Journal
18 hours 51 min ago
- Reply to comment | Linux Journal
1 day 1 hour ago
- Reply to comment | Linux Journal
1 day 2 hours ago
- Favorite (and easily brute-forced) pw's
1 day 3 hours ago
- Have you tried Boxen? It's a
1 day 9 hours ago
- seo services in india
1 day 14 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?