Automating the Winlink

So, no big surprise, I'm lazy.  I realize at some point I'll quit checking Winlink regularly.  Of course, that is exactly the time someone will send me something interesting.

So how to make my Winlink messages visible with no effort.  Of course, put them in the email inbox.

I already have pat running on my LAN so checking Winlink is a simple matter of pointing my browser. My email client checks for email from my provider every so often, so the first step is to have pat check for inbound Winlink messages every so often.  This is no big deal, simply put a pat connect command on the cron tab and away we go.

I decided to check via telnet since from time to time I will swipe my Winlink radio for some other service. I do intend to fix that in the near future so I can be assured the RF path is available.

I decided to log the results.  Since the dialog from the RMS is usually pretty boring, I only keep the most recent.  Errors, tho, I want to see whether something happened when I wasn't looking.  So I wrote a little script:

So, now any Winlink messages are sitting on the Raspberry Pi, how to get them to the inbox.

pat puts everything of interest in the ~/.wl2k directory tree.  Received messages are put in the ~/.wl2k/mailbox/(call)/in folder.  The messages are stored in plain text, so it would be a simple matter to mail them.  Rather than try to keep track of wich messages have been mailed, I decided to move the processed messages into Winlink's archive folder.

The Linux mail command makes this pretty straightforward.  Note that your ISP or email provider may have some hoops to jump through in order to make this work. In my case, it was pretty easy.  The only slightly tricky part was fishing the subject line from the original messages so when they got to my email client I knew what I was looking at.

The Raspbian implementation of bash seemed to be a little different than those with which I am familiar, and I am not that much of a bash maestro anyway, so I decided to script it in php.  This does mean you need to install php, but that is pretty easy.

The following is my script:

<?php
  /* Send incoming Winlink to email, then move to archive
   *
   *  jjmcd - 190628
   */

  /* Location of Winlink mailbox */
$mailbox="/home/winlink/.wl2k/mailbox/WB8RCR";
/* Address messages will be coming from */
$from_address="wb8rcr@chartermi.net";
/* Address to send messages to */
$to_address="wb8rcr@arrl.net";
/* Subject prefix to ease processing on receiving end */
$mail_prefix="PAT01:: ";

$list = dir($mailbox . "/in");
/* Loop through files in inbox */
while ( false !== ($file = $list->read()))
  {
    if ( substr($file,0,1)!="." ) /* Ignore this directory */
      {
        $got=0;
        /* Read the file until we find the subject line */
        $f = fopen($mailbox . "/in/" . $file,"r");
        while ( $line=fgets($f,1000) )
          if ( !feof($f) )
            {
              if ( substr($line,0,7)=="Subject" )
                if ( !$got )
                  {
                    /* Strip off the "Subject:" part */
                    $subj=substr($line,9,strlen($line)-11);
                    /* And remember we found it */
                    $got=1;
                  }
            }
        fclose($f);
        if ( $got )
          {
            /* Build the mail command */
            $command = "mail -s \"" . $mail_prefix . $subj .
                     "\" " . "-r \"" . $from_address . "\" " .
                     " \"" . $to_address . "\" <" . $mailbox .
                     "/in/" . $file;
            exec($command);
            /* Move the processed file to archive */
            $mvcommand = "mv " .  $mailbox . "/in/" . $file . " "
              . $mailbox . "/archive/";
            exec($mvcommand);
          }
      }
  }
$list->close();
?>

If you are lucky, the only things you might want to change are the first few lines. After that, the script does a directory listing of the inbox (ignoring the . and .. files). It then loops through that list, opening each file and finding the Subject: line. It pulls the string Subject: off that line and adds $mail_prefix (the mailer will add Subject: back).

The mail command is formed and sent to the shell, then the mv command is also sent to the shell. The script then goes on to the next file.

This script is then scheduled on the crontab shortly after the mail was retrieved from the RMS.  I suppose it might have been better to do both in one script, but it can be easier to take a step at a time.

Winlink On Your Browser

Recently the profile of Winlink has increased around the Section quite a bit. The addition of the CMEN Winlink network to the existing VHF relays and the myriad of HF relays has made Winlink a significant contributor to moving text via radio.

For those not familiar with Winlink, it is basically radio email.  You compose a message in an email-like client. You then connect to a mail server and off your message goes. The interesting thing is that you can connect to the mail server by Internet, but also by radio. There are hundreds of HF servers around, but even easier, there are now dozens of VHF and UHF servers around Michigan.

Connections

You connect your computer to the radio using a TNC. Most modern programs don't require a lot of smarts in the TNC, so there is little advantage to an expensive TNC over a cheap one.

The most common program is Winlink Express.  But this requires leaving your computer connected to the TNC, which may or may not be convenient, or switching to a dedicated computer. Again, not as convenient as it might be.

Of course, these days, everything we do seems to involve a Raspberry Pi. This is a really cheap computer we can dedicate to a task.  Better yet, there is a cheap TNC available for the Raspberry Pi called a TNC-Pi.  And to top it off, there is a Winlink client called pat that will present itself as a web page.  So if you put a Pi with a TNC-Pi on  your LAN, you can send and receive Winlink messages over VHF or UHF from any web browser on your LAN.

I will detail below how to make this work for you.  You will need a Pi, and a TNC-Pi.  I am using a Raspberry Pi model 3B+ and a TNC-Pi 2.  Older TNC-Pi models will be the same, and older Pi models should be virtually identical. You will also need a keyboard, mouse and display, but once the system is configured these are no longer needed. I am assuming that you will connect the Pi into your LAN ver a normal Ethernet, so you will also need an Ethernet cable. For newer Pi models you could also use WiFi, but I won't go into setting up WiFi.

I tend to find an unusual keyboard annoying, so once the first few setup steps are done, I use SSH from my regular computer.  Linux and Mac have built in SSH clients. I found that MobaXterm is a very nice SSH client for Windows. You could also use PuTTY, but it is somewhat limited. I understand that the PowerShell in Windows 10 has an SSH client, but have not tried that.

So, start by getting your TNC-Pi built and tested. Go through the steps outlined in the TNC-Pi manual to set up and test ax25-tools on your Pi.

One change I made to W2FS's instructions; I named my port wl2k instead of 1. I find that I tend to overlook 1 on some commands, and that field is a text field, so if you have named your TNC-Pi Suzie, then you could call the port Suzie.

axports

Of course, your kissattach command will look slightly different:

kissattach command

You should now be able to do the axcall command outlined in the TNC-Pi documents replacing 1 with your preferred name.

pat

Now that you have your TNC-Pi installed and tested, time to get on with making the Winlink client work.  Download and install the .deb package from
https://github.com/la5nta/pat/releases/download/v0.6.1/pat_0.6.1_linux_armhf.deb
 following the instructions at
https://github.com/la5nta/pat/wiki/Install-FAQ

You are going to want your web interface to be available all the time. To make that happen, you are going to want to have a dedicated user on the Raspberry Pi. I chose the creative user name winlink.  You will not want to log on to this user once pat is set up.

Log on to the user and type
        pat config
You will enter the editor with the configuration file.  Once you have run pat for the first time, you may instead prefer to edit ~/.wl2k/config.json with your favorite editor.

You need to tell pat what relays you will be connecting to.

Part of config.json

You will obviously need to enter your call.  If you got your Winlink account a while ago, the call and password will need to be in upper case even if you originally provided it in mixed or lower case.

The "http_addr" is significant. In most cases you will probably be using an IP address assigned by your router. You can use ifconfig to determine this number.

ifconfig

In this example, your "http_addr" line might look like:
    "http_addr": "192.68.0.38:8080",
Depending on your router, you maybe able to cause the router to assign a specific address to the Pi's MAC address, shown as "ether" above. This number is unique to every device.

Depending on your LAN, you might be able to assign a friendlier name to that address.  In my case, I called it "pat01".  This name or address must match what address you give your browser.  In this case, you might expect I could connect with 192.68.0.38 but in fact, pat won't answer to that address, even though it is the Pi's address.

The aliases are optional, but they will appear in the (select alias)  menu when you connect.  For an RMS you can reach directly, the format is:

If you need to use a digipeater

You may add multiple digipeaters, but you are likely to get timeouts with more than one.

Once you have saved the config file, type
    pat http
and return to your "normal" computer, leaving pat running on the Pi.

Using pat

Open your web browser, and type the address in the "http_addr" line into the web browser's address bar.  You should see something like:

pat - nothing in inbox

If you do not have a Winlink account, leave the password blank, and then simply connect and not send a message. Then connect again and you will receive a message with your Winlink password. Put that password in your configuration.

Now, to prove we have a working pat, let's send ourselves a Winmail message using the Internet.  Click on Action, then Compose...

You will see the compose a message dialog:

 Put your call into the To: box and formulate a dummy message.  Click on Post to post the message to the Outbox.

Next, select Connect... from the Action menu. The sending dialog will appear:

Choose telnet from the (select alias) menu then click Connect. You will see some activity in the black area at the bottom of the window. It should end up something like:

Any messages in your Outbox will be sent to the server.

Now connect again, and your message should be seen in the Inbox.

Setting pat to start automatically

Now that we have it working, we would like it to start on boot so that we never have to actually log in to the Pi.

If you haven't already, stop pat (with Cntl-C).

Then add the following two lines to the bottom of ~/.bashrc:

    sudo kissattach /dev/serial0 wl2k 10.1.1.1
    /usr/bin/pat http 

where wl2k is your port name.  If you have an assigned 44.x IP address you may choose that instead of 10.1.1.1, but since it isn't used in the case, it won't matter. It could be handy, tho, if you log on to the Pi and want to work with a node that supports the Internet Protocol.

At this point you may wish to log off and log back on again to be sure pat starts automatically.  You will need to stop pat in order to log off.

Assuming you installed the default Raspbian distribution, you can do the next steps logged on as the pi user, which is logged on the the graphical console by default.

Edit /etc/systemd/logind.conf. Uncomment the first two lines after [Login] and change both 6 to 5:

    [Login]
    NAutoVTs=5
    ReserveVT=5
    #KillUserProcesses=no
         ...

Now, cd to /lib/systemd/system/

Copy getty@.service to  pat-winlink.service

    sudo cp getty@.service pat-winlink.service


Edit pat-winlink.service as follows:

Change
     Description=Getty on %I
to
     Description=Winlink client on tty6

Change
     ExecStart=-/sbin/agetty --noclear %I $TERM
to
     ExecStart=-/sbin/agetty --noclear tty6 38400 -a winlink
where winlink is the user code you chose to run pat.

At the bottom of the file change
   [Install]
   WantedBy=getty.target
   DefaultInstance=tty1
to
      [Install]
       Alias=getty.target.wants/pat-winlink.service

Now you need to let the system know you have messed with these files:
    systemctl daemon-reload

If you have logged off your winlink user, you should now be able to start pat by typing:
    sudo systemctl start pat-winlink
and cause it to start automatically with:
    sudo systemctl enable pat-winlink

You can (and should) check the status of pat with:
     sudo systemctl status pat-winlink

the result should be something like:

pat service status

pat should now start whenever the Pi is rebooted.

Finding an RMS

If you go to https://winlink.org/RMSChannels you will get a map of RMSs. With the TNC-Pi you will only be able to connect to packet RMSs, so click on the Packet button and zoom the map to the appropriate area:

If you then click on one of the markers, you can see detail about that RMS:

Turn your radio to the desired frequency, put the callsign into the target: box on the connect dialog, and you should be able to send and receive messages over the radio.

If you use an ordinary email address instead of just a callsign, the message will be delivered over email.  You can be reached by email at (your call)@winlink.org if the sender has received a Winlink message from you in the past few months.

Two Thousand Seventeen

To All ECs adn DECs
Please Forward

As we plummet headlong into 2018, I thought it might be worthwhile to recollect what an amazing 2017 we had, and I am looking forward to an even more exciting 2018.

All our ARES members, and especially our ECs, did yeoman duty this year. We began the year with the news that our Section reported more volunteer hours than any section in the country. I don't know how it will turn out for 2017, but certainly there was a lot of reporting.

A few years back, FEMA asked us for a database on what capabilities we
had at public facilities, and our ECs updated that database this year. In addition, ECs reported how many folks they thought they could
muster in various circumstances and with specific skills. These
reporting tasks may seem mundane, but they are important to understand
so we can plan effectively.

I would like to ask each EC to take on another task immediately. Thank each of your members for their generous service. Those folks often come out for rather boring, but necessary duties. But each and every one is important, and each deserves recognition.

In March and April and again in June we had a number of severe weather events, including flooding in the U.P. and flooding in Central Michigan. In July and August we had additional, but localized, severe weather events.

Folks came out to support numerous walks, runs and other public service events, perhaps most notably the Labor Day Bridge Walk, where members from Luce to Antrim impressed the professionals with the kind of accountability APRS offers.

Besides actual activations, we participated in a large number of drills and exercises. As a Section, we participated in the "Statewide 2017" exercise as well as our annual SET. The SEOC crew additionally activated for three radiological exercises and the 100th anniversary special event station.

We had our first, in-state AUXCOMM class this year, and another planned for the end of January. We also had the first, amateur radio focused MI-CIMS training, and expect to have more in the coming year.

We had an amazing Division convention at MIS, which I hope we can repeat in coming years. Rick Roderick was an amazing speaker, and it was great to see so many folks that we don't get to see so often.

Your SEC followed a number of SEOC activations that ended up not requiring communications assistance, as well as three tabletop exercises.

The Auxcomm Working Group is finishing up the volunteer radio portion of the Michigan Emergency Communications Plan, and will shortly be turning to the Michigan Emergency Management Plan. In addition, we hope to update the rather stale "Michigan ARPSC Guidelines" in the coming year. Further, we will be providing input to the State Communications Interoperability Plan, so we are well entrenched in that state's communications planning. With all this planning in the works, the state is offering the assistance of their planners.

The FEMA Region V Auxcomm Committee has established a region wide frequency plan, and will be documenting activation procedures shortly. If you need assistance from outside the state, look to 60 meters channel 4, if busy, try 5, 1 2, 3 in that order. If conditions warrant, go to 40 meters, 7.180 and up. If Internet is available, look to REF024A on D-STAR (we hope to have a dedicated reflector before too long) or R5AUXCOMM on DMR. Of course, in most cases you will go to the SEOC first and they will make the out of state contact, but you should at least be aware of the frequencies.

So what will the new year bring? We have heard that changes will be coming to ARES, and we will hear more about that at Interop in February. From what we can tell so far, it looks as if those changes will be positive.

As mentioned, we have a number of plans to work on. We will essentially re-run our SET on April 28. We will be working with the state's Training and Exercise Section to include us more meaningfully into the state exercises.

We will be asking the ECs to provide us details of their primary repeater. We have had a questionnaire ready for some time, but we were hitting the ECs with one request after another, so felt it best to hold off. Meanwhile, KE8CRV will be providing us with MI-CIMS boards for that purpose, which should be a lot easier to use.

At the SEOC, we still need to get the Pactor station on the air. The packet station is up, but I hear not working properly, so that is something to investigate. We still need to identify and acquire a new tuner so we can get a power amp on the air. We also plan to have an intercom system so that the place won't be quite so noisy when there are multiple stations on the air, get additional Internet connections into the station, and perhaps move some of the positions a little so the VHF/UHF seats aren't so crowded.

We have some really good presentations planned for Interop. Looking forward to hearing from Mike Horn, Chuck Cribley, Dale Williams, Mike Corey, Ron Peterka and others. it promises to be a very ham-heavy conference.

We had some good success providing a training video on voice communications, and plan to prepare more videos in the future. We have been offered assistance from both the League as well as the state's Training and Exercise Section. We may well incorporate those videos into Mi-Train so that folks can track the videos along with other courses they have taken.

So a lot happened in 2017, and we expect a lot more to happen in 2018.  Again, thanks to all of you for your service and dedication. I may get to schmooze with the bureaucrats, but the folks in the field do all the heavy lifting. Thank you all so much.

73 and Happy New Year
de WB8RCR

Update on SEOC station

(Some of this was posted on Facebook, but not everyone is on FB, and there are some details at the end that weren't in the FB post).

 

Pretty interesting (and tiring) day at the SEOC Saturday. A group of us were there to install the HF antennas. It was a LOT slower than expected. It took us some time to locate the color codes for the feedlines coming in from outside. We had previously dragged cables inside the Auxcomm room, but the furniture turned out to be not what was expected, so about half those cables still need to be dragged somewhere else.

But the outside cables were an experience. There are 40 cables coming into the building, 13 of which are ours. For some reason the contractors decided to use only two colors of tape on the 23 feedlines from the big tower. So, were there 14 pieces of white tape on that cable or only 13?

Just a few of the incoming cables

We had not previously located the surge protectors for the control cables for the tuners, so we had to tear up even more floor. Of course, that made every step inside something of a challenge.

Things were even worse outside. There was a couple inches of mud over frozen mud, so half the time when you picked up your foot your boot would stay put. The other half of the time you would slide on the frozen ground lubricated by quicksand, so a few times one or another of us would be unable to avoid getting horizontal. Not much fun in that mud, but at least it was soft.

Inside not a lot better. There is a LOT of equipment, most of it not where it belongs. A lot of things I didn't recognize, and things I expected to find I didn't. But we got plenty of exercise carrying heavy stuff around. Do you have any idea what a 50 amp Astron weighs? Or an 87A? There is so much stuff in the room a lot of things we couldn’t find until after we needed them. We kind of cobbled up end insulators, and Bob found a center insulator, but it turns out there was a box of insulators, baluns, pulleys, other antenna stuff hidden under boxes of power cables.

In the end we only got a single antenna up, and we're not all that happy with that one. But we have something for Wednesday, anyway.

A big thanks to WD8BCS, KE8ACA, KC8LTL, and especially K8RDN for some really hard work under very suboptimal conditions. Still plenty of work to do, but I think it is going to have to wait until it gets drier, or colder.

So, remaining work to be done:

• Move the MARS and CAP feedlines across the room
• Move the VHF/UHF feedlines down one slot
• Get holes drilled in the blue workspaces
• Finish moving the equipment to the proper slots
• Locate CAP and Trbo radios
• N connector on CAP feedline under floor
• Might need connectors both ends of Trbo feedline
• Get Fred or Jeff to program Trbo radio
• Arrange some sort of mount for VHF heads
• Set up packet station
• What is the deal with the tuners?
• Get correct wire antennas in place once the ground is firm
• Set up Pactor station. May want to chat with WB2FTX on the best way to set up the software.
• get power to the digital position
• Build or acquire cabinets or shelves for storage

Lots of work to do, a few areas of concern:

• Not real sure what power supplies are what, and if we have enough.  Seems like there is a bunch but it gets skinny when you start assigning them
• The tuners appear to be only for long wires.  Not clear that they will work for the G5RV antennas.  We do have some 4:1 baluns that might work OK for CW (the radio has a built in tuner), but for Pactor that will limit us for the time being (will have to use a manual tuner so we won't be frequency agile unattended).
• We need to upgrade the tuner on the loop so we can use the Alpha.
• We probably need some lessons on the Alpha
• We definitely need some lessons on the MotoTrbo

 In addition to this, the MARS and CAP stations are pretty much untouched.  There is a CAP VHF antenna and feedline, and feedlines and towers for MARS, but not much else has been done.

2015 Overview

Sorry this is so long in coming.  But probably worthwhile to review 2015.

First, and most importantly, Michigan ARES members reported over 100,000 volunteer hours in 2015, with a volunteer value of almost $2MM.  Emergency Coordinators reported 202 planned incidents (walks, runs, etc.) and 119 unplanned.  Included in the unplanned were 41 SKYWARN activations, 28 Search and Rescue outings, 6 power outage and 5 fire responses.

Hours contributed in direct emergency response have fallen slowly over the past few years, but that has more than been made up for in drills, exercises and other preparedness work.

In terms of statewide exercises and preparedness, in 2015 we participated in the statewide tornado drill in April, the Northern Exposure exercise in June, an improvised nuclear device seminar also in June, a radiological awareness workshop in August, an exercise involving the alternate SEOC in September, the D.C. Cook nuclear plant series of exercises in September and October, and the annual Training and Exercise Planning Workshop (T&EPW) in November.

Last year our annual Simulated Emergency Test was built around a zombie apocalypse.  Participants made heavy use of NBEMS and some use of D-Star.  Counties sent their ICS-205 forms to the state reflecting the disruption to communications caused by a zombie outbreak, and were reminded of the importance of keeping their 217A up to date, and of the utility of the 201 and 202 when things go south.




In 2015 the SEC took the FEMA Auxcomm class, and co-authored an updated Amateur Radio Emergency Service manual.  The state's Interoperable Communications Board named the SEC and Marc Breckenridge, the EMC for Washtenaw County, as co-chairs of an Auxcomm working group.


One of the more fun bits as we headed toward the new year was wrapping up construction of a new state EOC.  The ARES/RACES station will feature a full size 160 meter loop for phone, G5RVs for CW and Pactor, and a 150 foot tower housing our VHF and UHF antennas.


All in all, a pretty good year last year.

SET 2014

Some years back we made the decision to use SET as an exercise, rather than a contest.  At that time Michigan was routinely on top of SET scores across the nation.  While the contest flavor did encourage interest, it did little to help us improve.

We moved to making SET an exercise, and while many jurisdictions submitted their Form A (or Form B for nets) to the League, the makeup of the SET did nothing to encourage high scores, instead focusing entirely on our need to improve skills and identify weaknesses.

In the wiki to collect input for the 2014 SET, there were some comments about scoring to encourage local jurisdictions to engage in some activities locally that could be useful in the event of an incident.  The idea of having our own scoring system is interesting.

This year for SET we are going to try a combined score sheet that includes the ARRL scoring categories, as well as a few categories where previous exercises have indicated a need to improve.

The above image shows a first draft.  Because some categories are somewhat population dependent, the Michigan score will be partially scaled based on the population of the jurisdiction.  Most categories, tho, are not affected.  For example, whether or not you activated based on a written plan (something that was a clear issue in the Spring tabletop), has no relationship to population.

It is not clear at this time whether the ECs will be given blank spreadsheets to report or whether we will provide a web page for input.  In either case, reporting to the League is still encouraged.

The October 4 scenario will be similar to what we actually experienced this Spring; severe cold and widespread flooding.  We will be focusing on digital and simplex, and again will encourage the use of MI-CIMS.  DECs will be getting more details shortly.

And once again, the Section component should be a small portion of your local activities.  Each EC should evaluate the needs of the jurisdiction and prepare local activities the reflect those needs, but still attempt to tie into the State scenario.

Pi Toppings

Boy, labels can really help.

As soon as I had a few Raspberry Pis, I began to realize that knowing what the MAC address was for a Pi was handy, so I put a label on each Ethernet connector with the MAC address.

In working on the Midland Hamgate with multiple TNCs, I was having some initial issues that seemed to be related to the particular Raspberry Pi.  At that point it became obvious that I needed quick access not only to the MAC address, but to the name my dnsmasq server would assign to that Pi.  So, more labels:

MAC and nodename labels

At first I had two TNCs, one for my home JNOS and one for my portable JNOS.  But the Midland Hamgate will require multiples, which means assigning an I2C address to each TNC.  Since I can't see what I2C address is programmed, and it is pretty clumsy to even read it once JNOS is running, labels for the I2C addresses seemed necessary:

I2C address labels

OK, that was pretty good, but once I started doing RF testing it became evident that it is useful to know what frequency the TNC is assigned to.  Even more important, once it is in service it will be very handy for debugging, so:

Channel Labels

So now my TNCs are all covered with stickers, but they seem to like it.  As best I can tell, they are all working:

Heard List

More Pi-JNOS fun

So, you have your TNC-Pi built, JNOS up and running on your Pi, but you know there are things that you could be doing, but don't know how.  Well, let's do a (very) short tutorial on bash and the crontab.

bash is the Linux equivalent of the DOS batch files, but it is way more powerful.  crontab is the scheduler which lets you have your Pi do things at a predetermined time.

Unlike DOS, file extensions don't mean a lot to Linux.  But they are often used, and some programs pay attention.  For example, many graphics programs expect a file with the extension .jpg to be a JPEG image.

The command ls for listing files has settings that can cause certain extensions to be listed in specific colors.  By default in Pidora, images and videos are purple, sound files light blue, and archives of various types red.  In addition, files with executable permission are shown in green, and directories in blue:

When you write a "batch file" (in Linux called a bash script), it must have an executable permission.  You give it that permission with the chmod command:

chmod +x myscript

By default, unlike DOS, the current directory is not on the path, so to execute a script you must specify the path. For example:

./myscript

(like DOS, the current directory is . and recall that in Linux, you separate directory levels by / rather than \.

It is traditional, and sometimes helpful, for bash scripts to begin with the line:

#!/bin/sh

And like DOS, we can type commands to be executed, and there is an echo command which displays to the terminal.  So if we had a bash script like:

#!/bin/sh
echo "Say something, anything!"

It would echo to the terminal:

Notice that some of the commands seem a little odd.  We have already seen that the ls command is kind of like the DOS DIR command.  There actually is a Linux dir command, but it is rarely used because it isn't nearly as flexible as ls, which has dozens of options.

You can learn about the options of ls, or any command, by typing man followed by the command.  For example, man ls gives the following screen:

You can page back and forth, in this particular case there are about 11 screens of information. You can even search for specific things within the man page.

bash scripts may also have variables.  You can assign a value to the variable with the equal sign.  Since most Linux commands are lower case, it is customary to make variable names upper case so they stand out.

You can use the variable by placing a $ before its name.  Because there could potentially be some confusion on where the variable name ends, it can be a little safer to enclose the name in curly braces, but this isn't usually necessary.

So if we add a little something to the script:

#!/bin/sh
MYSTRING="dadadididit didididadah"
echo "Say something, anything!"
echo "Here is a string -- ${MYSTRING}"

The result would be:

So far not all that exciting, but there are a few neat features.  bash can loop through the words in a string, which can often be very handy.  For example:

You can also assign the result of a command to a variable by surrounding the command with backward quotes (on most keyboards at the upper left under the tilde).

So for example:

The date command is amazingly flexible.  See the man page for details.  JNOS names its log files as a two digit day of the month, a three character month, and a two character year.  So the log for February 4th, 2014 would be 04Feb14.

Suppose I want to move all of last month's logs files into a single zip file.  I want to do this after the month is over, so I want last month's date.  To further mess things up, I would like the month in the name of the zip file to be numeric, so when I look at a directory listing they are shown in some sensible order.

So, let's consider the following script:

#!/bin/sh

# Get the various date pieces:
#  Month as a 3 character string
MONTHA=`date -d "15 days ago" +"%b"`
#  Month as a 2 digit number
MONTHN=`date -d "15 days ago" +"%m"`
#  Year as a two digit number
YEAR=`date -d "15 days ago" +"%y"`

cd /jnos/logs
zip -om9 Log${YEAR}${MONTHN} *${MONTHA}${YEAR}

The -d switch tells the date command to use the specified date rather than the current date.  There are a number of ways to specify a date, but since I might not get to run this right at the first of the month, "15 days ago" is very likely a date in last month.

The date command also gives me plenty of options for formatting the date.  The + sign tells the command that a format is to follow.  The formats used here return the date as a three character month name, a two character month number, and the last two digits of the year.

If I were to run this today, February 4, 2014, this would move all files in /jnos/logs with names *Jan14 into a zip file named Log1401.zip.

If you are not familiar with the zip switches, -o says to set the date on the zip file to the same as the newest file in the zip, -m says to move files to the zip rather than copy, and -9 says to use maximum compression.  Following common Linux practice, one-character switches can be stuck together behind a single minus sign.

Linux has another neat feature called the crontab.  This is a table of things to do at specific times.  Each user has his own table.  You can list the crontab with:

crontab -l

and edit the crontab with

crontab -e

The lines in the crontab have a kind of peculiar format.  There are five numbers, separated by spaces, a tab, and then a command.  The five numbers are minutes, hours, day of the month, month and day of the week.  An asterisk may be used to mean every possibility.  Multiple occurrences can be separated by commas.

If we called our script compLogs.sh and stored it in a directory called bin off our home directory, the cron line:

36 8 3 * *        bin/compLogs.sh

would cause our script to be run at 8:36 A.M. on the third of every month.

I have a script that sends a finger command to the hamgate four times a day to check the health of the hamgate.  The crontab entry:

0 0,6,12,18 * * *    /root/finger-hamgate

causes the script to run at midnight, 6 A.M., noon and 6 P.M. every day.  Notice that I have multiple hours separated by commas.

This can get pretty gangly.  The Midland hamgate grabs radar images from NWS every five minutes.  Although this could have been done on one line, there are three entries just to make it a bit more readable:

2,7,12,17,22 * * * *      bin/WxImages.sh
27,32,37,42,47 * * * *    bin/WxImages.sh
52,57 * * * *             bin/WxImages.sh

Generally it is good practice to start cron jobs at odd times if possible.  Since there can be multiple cron tabs, if you make a habit of starting jobs at the top of the hour it can cause things to get real busy at certain times, and you might even have a hard time recognizing why.  These things tend to be "out of sight, out of mind" in pretty short order.  By starting jobs at odd times, you reduce the odds that a large number of jobs will start at the same time.

There are lots an lots of bash features that I haven't mentioned.  There are plenty of references, but the real flexibility of bash comes from your imagination, and that is tough to get from a book.  Best plan is to play around, write a bunch of scripts, and when you find something you don't know how to do, look through the man pages, online references, and ask around.  Chances are you can't figure it out because it's so obvious!

As you do this, one man feature that is really handy is a keyword search.  The -k for keyword switch allows you to search all the man pages for a particular keyword, so if you want to do something and don't know the command, this might help.  For example, if I wanted to see what the man pages know about ax25:

So go have some fun!

How'd He Do That?

A number of folks have asked about the rendering I did of the proposed antenna farm at the new SEOC.  I'm not an artist, I can't draw worth a darn.  The images were produced using constructive solid geometry - that is, the images are the result of a bunch of equations.

The way this works is simple, at least in principle.  You write a bunch of expressions describing a bunch of objects, and the computer figures out what it will look like.  Skilled artists can make breathtaking images, but for a tecchie like me, it can be very helpful to try to visualize something.

The first time I realized this was back in the 90's, and it really hit home when Chip Cohen, (then NI1R) began talking about his patented fractal quad yagi (FQY) antenna.  His claims were fantastic, but people just couldn't understand it.  Try as he might to explain it,  he kept getting accused of trying to hide what he was actually doing.

I made a tracing for myself to try to understand it, and sent some images to Chip, which he used in an article in Monitoring Times.  That led the magazine to commission me to do their cover artwork, which remains my only published artwork.  These images are all created with POV-Ray, a rather old, open-source program, but one capable of amazing results.

While creating a scene like this was can be tedious, it really isn't all that hard.  In the antenna case, I began by modeling an aluminum tube, 1 inch in diameter and 12 inches long, by writing

 cylinder { <0,0,0>,<0,1,0>,1/24 texture {Aluminum} }.


(I used units of feet, so a 1" diameter tube has a radius of 1/24 of a foot).


I then arranged four of these in a square

One foot of tower

and put quarter inch tubes diagonally across each edge.

This gave me one foot of tower.  OK, perhaps it will be a triangular tower, it probably will be a little different size, in fact, we haven't specified the tower as it has to comply with FEMA standards.  It probably won't be your typical ham tower.

5 feet

I had towers of 20, 30, 35 and 125 feet, so I combined the one-foot sections into five-foot sections, which I could then combine into the appropriate heights.



The sky is a standard "texture", and while I probably could have used a more aesthetic sky, the first one I tried looked OK so I just stuck with it.

  sky_sphere { S_Cloud1 }


The General Office Building (GOB) is in the background and mostly obscured, so I simply modeled that as boxes.

  #declare GOB1 = object { box { <-95,0,0>,<95,35,2*95>  texture { Brick } } }
  #declare GOB2 = object { box { <-34.34,0,0><34.34,50,148> texture { Brick } } }
  object { GOB1 translate <-39,0,333> }
  object { GOB2 translate <-39-34.34,0,422> }

 
I had intended to get fancy with the "Brick" texture, but I ended up with simply a light brick colored pigment, and for the GOB, probably quite a bit different than reality.

One wall

For the SEOC itself, since many of the walls are at odd angles, each wall was modeled as a box, and rotated into position.  Since the measurements were taken off a relatively small drawing, the odds are they aren't very accurate, but they can at least give a feel.  I again used the "Brick" texture because I have no idea what sort of texture will be used on the new building.







Finally, oversized cylinders were used for the wires.  Modeling drooping wires is possible, but a pain in the neck, and copper colored wires of a realistic size would be invisible, especially in the movie, so I used 1.2" diameter black cylinders.

Adding a few trees (from an example macro that produces pretty ugly trees), a little fog to make some things appear a little less prominent, and we have something that can give us a feel for the antenna farm.  I have to admit to being terminally lazy, and even though someone else did the hard work of figuring out how to model a tree, I wasn't about to write a line for every tree.  So, I wrote a C program to generate code for 800 trees in four rows, two on each side, of randomly varying heights and distances.

For the movie, 99 frames were made of the same scene, moving the camera between each frame.  The individual frames were combined with ImageMagick.

Hams in Important Places

A few months ago, K8RDN, KA8DDQ and I sat down with the architects for the new SEOC to talk about antennas.  For VHF/UHF antennas it is pretty simple; put up as tall a tower as we can manage and stick the antennas on that.

For HF it's a little messier.  We currently run CW and SSB stations simultaneously, and want to add a Pactor station.  Since we are interested in in-state, beams and huge height aren't useful -- we want wire antennas fairly close to the ground.

We decided on a loop (which has worked well for us) and two G5RVs.  Add to that the inverted Vee for MARS and you have quite a pile of towers.  We were sure to specify power and weatherproof boxes at the bases of the towers to support remote antenna tuners.

WB8RCR rendering

What we (I) didn't consider is that running the feedline from a tower at the end to the center of the G5 could get a little messy.  I thought of that later, but figured we could cobble something together.

When the drawings arrived from the architects, there was a 6 foot riser with a weatherhead specified at the center of each G5.  Obviously at least one of the architects was a ham.