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