Friday, August 29, 2014

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.

Michigan Form A

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.

Tuesday, August 12, 2014

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


Monday, July 28, 2014

Activating your Program


During the Spring Tabletop, it became clear that while many programs have plans for activating, many do not, and those that do have some significant shortcomings.  Although they were not targeted for the tabletop, I suspect that the nets are even less prepared to activate in the event of need than the individual counties.

In most counties, the EC sits on the county EOC, and as such, gets a page whenever the EOC is activated.  But most incidents don't rise to the level of requiring an EOC activation.  Many are handled by a single agency such as Red Cross, County Health or Salvation Army.  If those agencies need our assistance, in many places they don't know who to call.

The Red Cross in particular is somewhat problematic.  In recent years they have reduced the number of chapters dramatically, so chances are the chapter serving your county isn't in your county.  In fact, you might not even know who the players are.

Each EC should be reviewing those agencies that might service their jurisdiction and be reaching out to those agencies to help them understand what you can offer, what you cannot, and who to call if a need arises.

The other issue that shows up has to do with bench depth.  Your served agencies should not have just one phone number.  There should be multiple paths, phone, email, page, twitter, whatever, and multiple levels.  I would suggest at least three deep.  In some northern counties where many of the members head south for the winter, three might not be enough.

And it isn't sufficient to simply have the list of names.  They have to know what to do when they get the call.  Each EC should personally review what needs to be done with each assistant, and the plan should be written and available to all the members.  At least the EC, the AECs and the EOC station should have a paper copy of the plan.  Most of the time an online copy is adequate, but there should be a hard copy in the hands of critical players.  Each county has a slot on the ARES web site where they can place these plans, and if there is sensitive information in the plan it can be password protected.

It is important to keep it up to date, too.  Yes, chances are you will need to re-print the paper copies every few months.  But that is a small price to pay for being prepared.

This Internet/paper thing does get interesting.  Recently, Joi Ito posted a TED talk on "becoming a now-ist" (http://tinyurl.com/lwdcu24).  The interesting thing abut his talk was that many of his ideas revolved around the Internet.  The Internet opens up entirely new ways of innovating.  My work with Fedora has given me some insight into just how powerful these tools can be for those that are willing to learn them.

But we have these competing needs.  While we need to be very quick to respond to new and challenging situations, we also need to be able to operate in conditions where we do not have access to the Internet.  Unfortunately, that has caused many members to totally distrust the Internet and be unwilling to use it, even in places where it is appropriate.

These days everyone is very busy, and getting folks together to work on new things is difficult.  Internet tools, especially those that allow for asynchronous input, can be very helpful.  We all use email, which is one such tool.  For many things, the wiki can be a much more powerful tool.

Back in 2012 I created a wiki on github to collect thoughts on ARES and NTS, and there is currently a page collecting input on the 2014 SET.  There has been a lot of good input on SET, but unfortunately only from a few folks.  A wiki is a web page that people can edit.  You can, for example, throw up an outline of some proposed policy and get your members to provide their input.  You now can benefit from the input from all your members to develop the policy more fully before you commit it to paper.

I particularly like the wiki on gitorious.org and github.com for two primary reasons; first, since they are backed by git you can see the history of changes and undo any change, and second, they are crude.

Why do I like crude?
  • Crude means easy to learn
  • Crude means you won't waste time making it pretty, and that means
  • You will focus more on content than cosmetics

I have a slight preference for gitorious because it is open source, which means that if gitorious goes away, we can load the wiki somewhere else.  Internet sites have an annoying habit of disappearing at inconvenient times.  In fact, gitorious even provides a link where you can download your entire wiki to your PC.

I would encourage each EC and Net Manager to
  1. Set up an account on gitorious
  2. Create a project
  3. Create a wiki for the project
  4. Add a page for something that needs to be worked on
  5. Encourage your members to contribute

In fact, your activation plan might well be a good place to start.  (see this wiki  for an example of a starter wiki).



Monday, March 17, 2014

Voyager Saturn Flyby

Our Section Manager mentioned in his newsletter a recent award I received, and when it was presented, N8ERF went through many of the things I have done in amateur radio over the years.  Larry's note caused me to recall one of the more interesting things I did, many years ago.

It seems like I have always been fascinated with computers.  Back ages ago, when I was maybe 8 or 10, I spent many an hour playing with my uncle's Geniac (http://en.wikipedia.org/wiki/Geniac), a "computer" consisting of nothing more than switches and lights.  In the 70's I built a number of computers, the longest lasting being an Ohio Scientific "superboard".

This thing was quite a beast -- basically it consisted of a number of 8x10 circuit boards and a huge pile of wires.  I couldn't afford a Model 33 teletype, which was kind of the standard, but I was able to get a Model 15.  The 15 was baudot, rather than ASCII, and required a different electrical interface, so my superboard was cobbled up with my own, hand-assembled, boot ROM and teletype interface.

I was eventually able to afford a graphical display board (very low resolution) and got a small, Sony Trinitron to use as a monitor.

Back at that time, computers were rare enough and slow enough (the IBM PC didn't appear until 1981) that slow scan TV was generally done with complex (and expensive) electronics.  I spent many an hour developing SSTV software in assembly language (there just wasn't the storage available to make compilers an option, and it wasn't too hard to hand-assemble small programs into binary that could be typed into the console).

When Voyager flew by Saturn, the Jet Propulsion Laboratory relayed the images from the spacecraft in real time over SSTV on 20 meters.  Not only was I able to view these images, but I could talk to the folks at JPL and ask about specific features of the images.

Getting live pictures from Saturn, and being able to talk to the scientists about them, had to be one of the most exciting experiences I've ever had.

The facets to amateur radio are just endless.

Tuesday, February 4, 2014

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!


Thursday, January 30, 2014

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.



video

Wednesday, January 29, 2014

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.
Antenna Image
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.

Tuesday, January 28, 2014

Monitoring Emergency Frequencies

The recent spates of bad weather have served to remind us of the importance of monitoring our emergency frequencies any time we suspect there may be an issue.  If someone really needs us, they are in deep trouble.  They need a place to go to get help and our frequencies are that place.


It would be nice if it were as simple as a single frequency.  But propagation isn't always a kind mistress, so we need to be prepared to operate on different bands depending on the mood of the sun, and different modes as different modes are affected differently by propagation.  Plus, someone with only simple equipment or little power available may need to operate CW, and only a relative handful of us can do that.  But if someone can afford a large power budget and has capable equipment, then modes that are easier for the untrained are possible.

Here in Michigan, we primarily use 3 bands; 80 is our default, 40 is for times of high flux, and 160 for low flux.  In practice, 40 is daytime, 80 is nighttime, but at the sunspot peak in the summer "daytime" might extend 24 hours, and at night in the winter during the sunspot minimum the flux may be low enough to demand 160.

Our frequencies are as follows:

            CW      NBEMS     SSB
   160     1.812    1.803    1.932
    80     3.563    3.583    3.932
    40     7.068    7.043    7.232

Note that we check CW at the top of the hour, NBEMS at quarter past, and SSB at the bottom of the hour. 

IMPORTANT NOTE: You should have these frequencies available on paper at your EOC station.  You may remember them, but you might not be the operator at your EOC when they are needed.

In addition to HF, monitoring should include your local repeater, 146.58 and 146.52.

We should use the 160 meter frequencies whenever the F2 critical frequency is below 4 MHz, and the 40 meter frequencies if the critical frequency is above 8 MHz.  If you have Internet available, you can check the Near-Real-Time F2-Layer Critical Frequency Map. If you really need to call out on these frequencies chances are you don't have the Internet.  So you should always be aware of where we are in the sunspot cycle.  Basically, 80 is the default, go up in frequency in the daytime, down at night, up near the solar maximum, down near the minimum.

You can also tell by listening.  If you can hear close in stations then you aren't too high in frequency.  If the noise is so high you can't hear anything, then you are probably too low in frequency.

For monitoring purposes, we use Olivia 8/500 for NBEMS.  MT-63 1K long works well too, as long as there aren't thunderstorms in the area, but for calling and monitoring, Olivia 8/500 is the ticket.  

For CW, call at a relatively low speed.   The Michigan CW nets operate at 20WPM or higher, but the station in trouble might not have that skill.  Call at 15WPM or less.

When monitoring, it is useful to announce your presence.  This shouldn't be some long dissertation, QRV de WB8RCR is adequate.  Even if you can't hear the station in trouble, them hearing you gives them some confidence that someone is listening and they should keep trying.

And also keep your station status up to date in MI-CIMS if at all possible whenever an incident is available.  The SEC watches this closely and has a number of communications paths to MSP.  If someone is in trouble it can be a huge help to know a station is on the air in a particular area.  If you don't have access to MI-CIMS, ask your county emergency management coordinator if access can be arranged.

So when there is any reason to suspect a problem, please monitor.  Even if you simply leave the radio on in the background on the appropriate frequency, it could be a real benefit to someone in trouble.




Friday, January 17, 2014

Good Morning Michigan

This is an attempt to sort out whether this can be a useful vehicle for communicating with the Section, and more importantly, can I keep it up?

I occasionally send out, sometimes long, emails to the DECs and ECs, and once in a while I also post those to the MIARPSC Yahoo group. But there are plenty of ARES members who may be interested in some of the ramblings but don't get a chance to see them.


I'm not real happy with the cosmetics of this thing, and over time perhaps I'll work on that.  But for now I'll try to make it a point to get useful content here so that those folks around the Section interested in emcomm can be included in some of the news.

The coming months

So, my schedule for the next few weeks does have a few significant items on the docket:
  • Feb 1 - MCSAR Training
  • Feb 6 - Midland Amateur Radio Club
  • Feb  8 - District 2 EC meeting - Detroit
  • Feb 11-13 - Interop conference - Traverse City
  • Feb 20 - MCSAR General Meeting
  • Feb 24 - D3 AuxComm Meeting - Standish
  • Mar 1 - MCSAR Training
  • Mar 4-6 - IEMC Training - Lansing
  • Mar 6 - Midland Amateur Radio Club
  • Mar 8 - Section Staff - Lansing
  • Mar 20 - MCSAR General Meeting
  • Mar 21-23 - Docs FAD - Raleigh, NC
  • Apr 1 - E. Fermi II Drill #1 - Lansing
I'm sure other stuff will pop up.