We’re really lucky in Christchurch to have a good number of quite well maintained tracks right on the back doorstep of the city.

A couple of weeks ago I took on my first decent sized mountain bike ride after suffering a ruptured Achilles tendon in my left leg back in January. That’s a whole other painful story which I do intend to write up a bit but in the mean time, enjoy some random youtube.

This blog post is a bit of a ramble and may not make 100% sense if you didn’t read my other icinga2 graphite post first. Check that out here.

The flaw in my plan wasn’t apparent because I was only looking at the output of the ping4 plug-in in my testing, whereas I should have been checking some other graphs as well.

Here we have a ping graph for five days of history on a server at work and it’s clearly working better than before as I only had one day of history originally.

This five day graph represents data in Archive 1 of the whisper file. In this particular instance I’m keeping 10 minute increments for a week which is different from my example in my first blog but the end result is essentially the same.

The six month view gives us a look at the data from Archive 2, which is set to 30 minute increments for a year and gave me a false sense of success up till the point I looked at some other services graphite was presenting into icingaweb2.

Load for 1 day is looking good and represents the one minute resolution records for a day in Archive 0, but when we view a graph that requires either of the other two archives the date range is clearly supported but the data is somewhat lacking.

Delve into the details

I dug a little deeper into the world of .wsp files to get an understanding of what was happening and rather than using a shovel for the excavation I used the whisper-dump utility.

Whisper-dump does what it says on the label and dumps all of the data in a .wsp file out in a relatively human readable format.

The dump output consists of the header information which I extracted with whisper-info in my first post and then a raw dump of the data for as many archives as you have created in the file.

Meta data:
  aggregation method: average
  max retention: 31536000
  xFilesFactor: 0.5

Archive 0 info:
  offset: 52
  seconds per point: 60
  points: 1440
  retention: 86400
  size: 17280

Archive 1 info:
  offset: 17332
  seconds per point: 600
  points: 1008
  retention: 604800
  size: 12096

Archive 2 info:
  offset: 29428
  seconds per point: 1800
  points: 17520
  retention: 31536000
  size: 210240

Archive 0 data:
0: 1543097400, 0.0015430000000000001006417171822704404
1: 1543443060, 0.0016889999999999999631683511580604318
2: 1543097520, 0.0016540000000000000882072193064686871
3: 1543443180, 0.00154600000000000006514233596988106
....... (1440 lines of data)

Archive 1 data:
0: 1543104000, 0.0016808000000000003059524855686390765
1: 1543104600, 0.0018087999999999999477945378245635766
2: 1543105200, 0.001638599999999999822300478236059007
3: 1543105800, 0.0016849999999999996491001352794114609
........ (1008 lines of data)

Archive 2 data:
0: 1543104000, 0.0017094000000000000253491672097538867
1: 1543105800, 0.0018563333333333330993353271765045065
2: 1543107600, 0.0016944000000000002028460732717007886
3: 1543109400, 0.0018723333333333334882464527026968426
........ (17520 lines of data)

The header confirms the archive structure we created using whisper-resize in the first blog post and the rest of the output is about 20,000 lines of text which I’ve cropped down for the sake of readability.

For Archive 0 there are 1,440 rows, which is the number of minutes in 24 hours.  Similarly Archive 1 has 1008 lines for 10 minute resolution across a week and Archive 2 is 17,520 lines giving 30 minute resolution over a year.

The data points are recorded as a record ID, Unix epoch time stamp and then the data value which in this case is ping return time in seconds.

Unix epoch time stamps are the number of seconds since 00:00:00 on January 1st, 1970 UTC for those not familiar with the dark arts.

Looking at that data you might have quickly realised that the ID column and timestamps are not in sync for Archive 0 which is because the whisper file writing “wraps around ” after a day and we don’t have one point of data per record.  More on that later.

Archive 1 and 2 are sequential though as they have not wrapped yet and there is always a data point for them as they are an aggregate of Archive 0 and 1 respectively.  In this case the average.

To make slightly more sense of the raw data I imported it into LibreOffice Calc and sorted by the time stamp.

If you’re really quick at maths you’ll notice that the Archive 0 data points are actually 120 second apart but for clarity I added the “diff s” column. 

This is because I’m only pinging things once every two minutes. Other than that little anomaly everything is good with Archive 1 and 2 showing average values so it still wasn’t obvious what was broken just yet.

Eureka!

Once I’d done the same import and conversion with the load service raw data and I had a eureka moment but only because I’d just spent more time reading the graphite documentation than I’m prepared to admit in polite company.

The data points are 300 seconds apart which makes sense as I’m only checking processor load every five minutes. If I were to optimise the whisper files for every service I’d probably use whisper-resize and carbon-cache storage settings to set all of the load files to 5 minute resolution in Archive 0.

The reality of that is that the time/cost benefit for me while rolling out icinga2 is not really there and even at work with 20,000 + graphed items in graphite / icinga2 so far it’s only a few GB of disk space being consumed.

What went wrong?

So at this point we need to refer back to the graphite, or more specifically carbon-cache documentation. The value of the xFilesFactor setting in the .wsp is where we need to be looking.

“xFilesFactor should be a floating point number between 0 and 1, and specifies what fraction of the previous retention level’s slots must have non-null values in order to aggregate to a non-null value. The default is 0.5.”

ref: https://graphite.readthedocs.io/en/latest/config-carbon.html

What that means is if you want the aggregation of data to flow to the lower resolution archives in your whisper file by default you need to have 50% coverage of possible data points.  In this example that means five data points out of the ten possible for each 10 minute slot to be averaged out and land in Archive 1.

This worked out on ping4 because the resolution of the Archive 0 was one minute and I was doing the ping every two minuets for 50% coverage.

To state it a different way: If I’d been pinging every 3 minutes I’d only have 30% coverage and the aggregation would not have worked.  Pinging every minute would give 100% coverage.

This was an accident though, as at that stage I had read just enough of the graphite documentation to make it work and having precisely 50% was good luck, not good management.

For load however I’m not even close to the default 50% when you look at the available data for aggregation down to the ten minute resolution of Archive 1 there are only two of the possible ten points available which is 20%.

Fixing things up

There’s two possible ways you can fix this problem; create individual rules in /etc/carbon-cache/storage-schemas.conf for each metric you keep in graphite / icinga2 to match your polling periods, or just hit it with a sledgehammer as I did and set xFilesFactor = 0 for everything.

If you had a small icinga2 installation you might consider polling everything every minute as well if all of the hosts were on one LAN and performance was not a concern.

Even with the modest config I run for my home office deployment I’m how over 800 services monitored on 38 hosts.  There’s even two remote monitoring zones across VPN’s to AWS and Linode.

Many of those monitored services are things like backup completion which you only need to check on once an hour at most.  Other things like available patches, SSL certificate expiration only needs to he checked once a day, maybe less.

On a larger deployment you’ll quickly have thousands of monitored services. The processor load and network bandwidth consumed to monitor things every minute can becomes a major issue.

So, with that in mind I kept my mix of monitoring periods and just changed all of my whisper xFilesFactors to be 0.  This means that you only need one data point per period in Archive 1 in Archive 0 for the aggregation to work.

To make this change I modified my default rule for new whisper files in /etc/carbon-cache/storage-schemas.conf to be:

[default]
pattern = .*
xFilesFactor = 0
retentions=60s:1d,5m:1w,15m:1y

And then re-ran a slightly updated bit of find-foo to update the existing files and ran it across the server again.

# cd /var/lib/graphite/whisper/icinga2
# find . -name *wsp -exec whisper-resize --xFilesFactor=0 '{}' 60s:1d 5m:1w 15m:1y \;
# chown -R _graphite:_graphite *

After a restart of carbon-cache and waiting a couple of days I now have Archives populating and graphs graphing.

In typical software-demo style there is a big glitch in that graph.  That was caused by a power cut last night for longer than my home UPS could hold the hypervisor up.

The graph however, is now a thing of beauty.

I’ve updated my original blog post to include references to xFilesFactor, so if you use the example settings from there you’ll be fine as well.  Post a comment below if you find any glaring errors or found this useful.

Note: I’ve updated this post since I originally posted it.  See my post about xFilesFactor here which describes why I updated it.

I’ve been on a bit of a journey over the last few months migrating from nagios to icinga2 for my systems, some customer stuff and the platforms at my day job after living through the love-hate that is nagios on and off for quite a few years now.

On top of the base icinga2 / icingaweb2 install I added the graphite graphing module which essentially worked out of the box give or take a couple of typos on my part .  You can find all the information you need for that part of the journey on the github page for the module.

The graphite module in the context of icinga2 has three moving parts:

• Carbon-cache, which receives the information from icinga2 and writes it out to disk as efficiently as possible
• Whisper which is the database format used to store the metrics which can be thought of as a more modern and efficient version of the venerable RRD which all sysadmins since Noah’s time probably have some sort of emotional response to.
• Graphite which renders the metrics into pretty graphs into PNG format graphs.

The problem, only a day of data

A few days back I discovered that despite a my fairly uneventful installation of the graphite module on my part the graphs, despite being very pretty were only keeping a day worth of data.

So off to Google (Who is, for the record, not evil) I go and although I did find the solution it was scattered across separate documentation sites and forum posts.  I also found that some of the information was a dated compared to the current versions of things I’m using so here’s a write up of my solution in one place in case anyone else is similarly searching for a one stop solution.

The symptom of the low retention time is best described with a video.  Essentially you select anything larger than a one day period in the icingaweb2 interface and the graph does not get any bigger.  Insert sad face here.

FYI: I’m writing this based on running Ubuntu 18.04LTS and icinga2 installed from the PPA.  Icinga2 is version 2.10.2-1.bionic, graphite-carbon is 1.0.2-1.

Retention settings in carbon

The retention settings for new graphs created by carbon are found in /etc/carbon/storage-schemas.conf and the default setting is:

[default_1min_for_1day] 
pattern = .*
retentions = 60s:1d

That is basically saying keep one minute resolution of data for a day.

Settings in the file are processed from top to bottom until a match for ‘pattern’ is found so if a metric matches the first pattern in the file that is the one used.  The patterns are python regex format so  ‘.*’ in the default above matches everything.

Just like RRD, whisper can retain multiple ‘archives’ of a metric with differing resolutions and time spans.  In the storage-schemas file for carbon cache that is represented as comma separated pairs of values in reducing resolution and increasing time span.

By way of example 60s:1d,5m:1w,15m:1y would keep a one minute resolution for a day, five minute averages for a week, and 15 minute averages data for a year.

The new entry in the config file for that would look like:

[default]
pattern = .*
xFilesFactor = 0
retentions = 60s:1d,5m:1w,15m:1y

Note that [default] just has to be unique, the actual text is kinda irrelevant but if you have two [billybob] entries in the file you’ll get an odd-ball error when you restart carbon.

Note the xFilesFactor setting as well.  My second blog post about Graphite and Icinga2 graphing describes what’s going on there.  Read that post here.

Fixing existing graphs

After you re-start carbon you’ll find that it only affects newly created whisper files, not your existing ones.

You could just delete all of the whisper files and let the system re-create them, or you can fix them up using the whisper-resize tool shipped in the graphite-carbon package.  To apply our new rule to a single file you could use the following incantation:

whisper-resize <filename>.wsp --xFilesFactor=0 60s:1d 5m:1w 15m:1y

Note that whisper-resize uses spaces instead of commas like the config file.

Note the xFilesFactor = 0 setting as well.  My second blog post about Graphite and Icinga2 graphing describes what’s going on there.  Read that post here.

All of the whisper files live under /var/lib/graphite/whisper/icinga2/ in a directory structure representing the metric names.  In the following example we’re working with the response time for a tcp check on port 80 to a machine called mailhost.vpn in icinga2.

If you’ve got this far and realise you don’t know what I’m on about can I suggest you back out slowly now and get your head around icinga2 before messing with tuning graphite…

In all of the command-line copy’n’paste I’ve put a pwd at the top and cropped the paths as they were waaaaay too wide for a blog post.

root@icinga: # pwd
/var/lib/graphite/whisper/icinga2/mailhost_vpn/services/http:80/tcp/perfdata/time
root@icinga: # ls -l
total 40
-rw-r--r-- 1 _graphite _graphite 17308 Nov 25 11:04 max.wsp
-rw-r--r-- 1 _graphite _graphite 17308 Nov 25 11:04 value.wsp
root@icinga: # whisper-resize value.wsp --xFilesFactor=0 60s:1d 5m:1w 15m:1y
Retrieving all data from the archives
Creating new whisper database: value.wsp.tmp
Created: value.wsp.tmp (462004 bytes)
Migrating data without aggregation...
Renaming old database to: value.wsp.bak
Renaming new database to: value.wsp
root@icinga: # ls -l
total 492
-rw-r--r-- 1 _graphite _graphite 17308 Nov 25 11:09 max.wsp
-rw-r--r-- 1 root root 462004 Nov 25 11:11 value.wsp
-rw-r--r-- 1 _graphite _graphite 17308 Nov 25 11:09 value.wsp.bak
root@icinga: # chown _graphite:_graphite *
root@icinga: #

Note: you need to change the owner of the file back to _graphite:_graphite after you make changes as root, or ‘sudo -u _graphite’ the commands.

You’ll see that the wsp file has grown out to 462k from 17k. That might be an issue for your system if you are tracking a lot of metrics.  On my test icinga2 instance I have 3,700 .wsp files so that equates to the wsp files expanding out to take 1.6GB of disk.

You can check the before and after using whisper-info:

Before:

root@icinga: # whisper-info value.wsp.bak
maxRetention: 86400
xFilesFactor: 0.5
aggregationMethod: average
fileSize: 17308

Archive 0
retention: 86400
secondsPerPoint: 60
points: 1440
size: 17280
offset: 28

After:

root@icinga: # whisper-info value.wsp
maxRetention: 31536000
xFilesFactor: 0
aggregationMethod: average
fileSize: 462004

Archive 0
retention: 86400
secondsPerPoint: 60
points: 1440
size: 17280
offset: 52

Archive 1
retention: 604800
secondsPerPoint: 300
points: 2016
size: 24192
offset: 17332

Archive 2
retention: 31536000
secondsPerPoint: 900
points: 35040
size: 420480
offset: 41524

The ‘After’  shows the three separate archives with different settings in seconds.  Did you know that there were 31,536,000 seconds in a year?

Obviously with 3,700 files to modify if I wanted the retention the same all round it’d take ages to manually modify all the files so find and a little testing gave me:

# find /var/lib/graphite/whisper/icinga2 -name *wsp -exec whisper-resize '{}' --xFilesFactor=0 60s:1d 5m:1w 15m:1y \; 
# chown -R _graphite:_graphite /var/lib/graphite/whisper/icinga2

Run from the host folder /var/lib/graphite/whisper/icinga2/mailhost_vpn changes all of the graphs for that single host, or you can go a level up and do everything in one shot.

If you’re concerned about resources and think a system wide re-size will kill things, this was my experience; the test system has 37 hosts with 785 services, 3,700 wsp files.  It’s running on a VM with two cores on a 2.8Ghz i5 and 1GB of ram. It took a shade over two minutes and disk space usage for graphite went from 72MB to 1.6GB when the .bak files were cleaned up.

Being Selective

If you’ve running a large system monitoring many thousands of metrics you probably don’t want, or need the same resolution for all metrics.

Carbon allows you to apply patterns in the storage-schemas file and the first match for a new graph wins, so to speak.

An example would be using the ‘apt’ check within icinga2 which I run every 12 hours on Debian and Ubuntu systems.  There is simply no point in recording data at any higher resolution than say 1 hour for that graph but the nice default we just applied to all of the whisper files has it storing thousands of useless data points.

As well as the disk space concerns, having multiple archives in the whisper files substantially increases processing overheads for carbon as it has to average data out and write it to each of the successively lower resolution archives in the file each time it writes a check.

That might not be an issue for a system with 700 metrics, but what about 70,000?  In larger systems it would quickly be justified putting graphite on a separate host for that reason, but I’m running everything on the one small VM.

Checking the name for the whisper files for the apt plugin we find:

root@icinga:/var/lib/graphite/whisper/icinga2/mailhost_vpn# find . | grep apt 
./services/apt
./services/apt/apt
./services/apt/apt/perfdata
./services/apt/apt/perfdata/available_upgrades
./services/apt/apt/perfdata/available_upgrades/value.wsp ./services/apt/apt/perfdata/critical_updates
./services/apt/apt/perfdata/critical_updates/value.wsp
root@icinga:/var/lib/graphite/whisper/icinga2/mailhost_vpn#

Taking that path information we can create a pattern regex match in the storage-schemas.conf file and apply a more sane retention for apt checks.

The metric names you’re matching on are the path in the whisper directory structure with ‘/’ replaced with a ‘.’ and without the .wsp on the end. 

That makes the full name for one of the metrics above:

icinga2.mailhost_vpn.services.apt.apt.perfdata.available_upgrades.value

All we need to do is match the end of that long mess to pick up everything for the apt plugin on all hosts.  Lucky for those of us who are regex challenged that’s really easy using the ‘$’ operator. 

The resulting storage-schemes.conf would look like:

[apt-upgrades] 
pattern = available_upgrades.value$ 
retentions = 1h:1y 
[apt-critical] 
pattern = critical_updates.value$
retentions = 1h:1y 
[default] 
pattern = .* 
xFilesFactor = 0
retentions=60s:1d,5m:1w,15m:1y

To check that this is working, and taking the example of another host (icinga.home) we check the original default-retention whisper file using whisper-info to find the single one minute / one day Archive:

root@icinga:# pwd /var/lib/graphite/whisper/icinga2/icinga_home/services/apt/apt/perfdata/available_upgrades 
root@icinga:# whisper-info value.wsp 
maxRetention: 86400 
xFilesFactor: 0.5 
aggregationMethod: 
average fileSize: 17308 

Archive 0
retention: 86400 
secondsPerPoint: 60 
points: 1440 
size: 17280 
offset: 28

To test the carbon config change:

• Change the retention settings in carbon per the example above.
• Restart carbon using ‘service carbon-cache restart’, or systemctl if that’s how you rock.
• Delete the value.wsp file for your test host.
• Re-run the check a couple of times using the icingaweb interface to force the re-creation of the wsp file.
• check it again with whisper-info.

Whisper-info should now return:

# whisper-info value.wsp
maxRetention: 31536000
xFilesFactor: 0.5
aggregationMethod:
average fileSize: 105148

Archive 0
retention: 31536000
secondsPerPoint: 3600
points: 8760
size: 105120
offset: 28

So only 100k of data to support a years worth of that metric and this will reduce the processor overhead of averaging and archiving data which is probably a larger concern if you’ve read down this far.

You can now apply this retention rule to all of your existing .wsp files using a little bit of find-grep-xargs-foo if you don’t want to delete the current history information.  Run this, or a variation of it, in the appropriate folder to pick up one host or all of them.

# find . -name *wsp | grep available_upgrades | xargs -n 1 -I % whisper-resize % 1h:1y 
# find . -name *wsp | grep critical_updates | xargs -n 1 -I % whisper-resize % 1h:1y 
# chown -R _graphite:_graphite /var/lib/graphite/whisper/icinga2

As with all bash-foo I’d suggest replacing the whisper-resize command with ‘echo’ until you’re happy that you’re not going to accidentally DDOS hotmail or cause a sudden loss of gravity in Jamaica taxi cabs.  A backup before you take anything I type as advice wouldn’t be a bad idea either.

Once you’re happy with the results you can remove all of the .wsp.bak files as well to fee up a bit of space.

SOTA pole on the lawn

Technically not really SOTA, because that would require a summit, but testing an Antenna I built for the purpose at least 18 months ago.

SOTA, Summits on the air is a slightly crazy pursuit within the larger sphere of amateur radio involving lugging radio gear, including batteries and antennas, up a mountain or random hillock to try and talk to other similarly afflicted amateur radio tragics around the country and around the world.

I made this antenna so long ago now I couldn’t rightly remember if it worked so before I venture out into the wild blue yonder over summer to try and scale the heights with a backpack of assorted technology I thought I should check it was working.

So there I am, lying on the lawn with the trusty FT857 and a LiPO battery from one of my model aircraft plugged into the back.

The dog is wondering what on earth I’m doing as he’s normally the one lying on the lawn on a sunny Saturday afternoon and he’s certainly not sure about the wire and string creation I’ve pegged up near the trampoline.

Rolled up linked dipole with hand mic for scale.

A quick test with the analyzer puts the resonant point on 40m at a shade under 7.100 Mhz and 14.150 Mhz for 20m which are the key bands for SOTA here in ZL-Land although there’s taps for 15 and 10m as well.

Those upper bands are a little tricky at the current low-point of the solar cycle so not a priority and I was meant to be mowing the lawn, not lying down on it so I plugged in the rig and spun the dial.

There was a contest on somewhere well north of us as R0ML and a couple of other Russians were calling CQ in consummate contesting fashion although whispering with 25W into a low dipole was probably a bit of a stretch from my end although I did shout breathlessly at the microphone for a few minutes.

Then along comes Steve, ZL1PWR calling CQ on 14.215.  At about 1,100km north up in the land of the Auck somewhere it was enough proof for me that the antenna is good and there’s always something a bit pixie-dust about portable HF operation even if it’s just on the front lawn.

After a bit of a rag chew I packed up and mowed the lawn leaving the dog content that order was restored in the shade under the trampoline.

As well as the safety aspect, not having to play with a glow starter around spinning props, most glow motors idle more reliably with the glow plug lit. This is even more so with four strokes due to the time between induction strokes being longer than with a two stroke.

The incoming methanol has a catalytic reaction with the platinum on the glow plug coil which causes the coil to get hot, which ignites the mixture. The longer time between charges of methanol, oil and air entering the cylinder mean the plug can cool between compression strokes and the idle gets a bit rough around the edges.

The benefit of on-board glow is greater if the motor is inverted where oil and combustion by-products can collect around the plug making the idle worse and the transition to high speed lumpy as the gunk burns out from around the plug.

Inverted four stroke, screaming out for on-board glow driver.

A few weeks back I was lucky to add a beautiful quarter scale fly baby to my collection.

There is an unwritten law that large, slow flying, classically shaped models have to have a four stroke Engine.  You can’t fight it, they are just not right with a screaming two stroke or the sterile urgency of brushless electric.

I bought a shiny new 1.2 ASP noise maker to fasten to the engine mount which of course needs an on-board driver. No problem; In a past life I ran a business that made 1,000’s of glow drivers so I was sure I’d have another one lying around somewhere.

Ohmark Glow driver, Circa 1997 with switch and pot poking through the heatshrink.

After turning my workshop and garage upside down it appears the last functional one I had was destroyed in the violent arrival to terra-firma of my 1/5th scale cub. This allowed the model to fit in a much smaller space than it did before the start of the flight.

Back to the drawing board.

So, 20-ish years after I designed the first Ohmark on-board glow switch I went back to the drawing board.

Primarily because I didn’t want to wait for postage but also because I’m an electronics nerd and it would erk me to have to buy something simple that I can make.

In the original design I used a small dip switch and pot to set the point and direction of the throttle at which the glow would come on but that is so last century.

These days transmitters are capable of collating the census results for a small nation, never mind controlling a glow switch. Along with the transmitter improvements, eight plus channel receivers are now cheaper than a good servo rather costing more than the air-frames we put them in.

This means the magic can be handled from the comfort of the transmitter and the switch itself can be simpler.

Into the bits box I delved and came out about an hour or so later with a functional prototype using a small 8-pin micro, a few discrete components and MOSFET rated to switch 55 volts at 29 amps which is far more than the 1.5 volts and around three amps which is the maximum you’d expect from a cold glow plug.

New glow driver prototype on Veroboard

For a battery I found a tagged 3.3AH NiMh from Jaycar which was a refugee from another project and although the finished unit is a bit bulky because it’s built on strip board it’s only 50x10mm or so and weighs maybe two grams. If I need another one I’ll get some PCB’s done for them and surface mount it.

The previous owner had already fitted a remote glow lead so all I had to was put the arming switch and status LED through the cockpit floor, wrap things in foam and cable tie them into the model. Job Done.

On the transmitter side I used one of the three position switches of my Taranis 9XD to control the glow driver. The three positions are effectively engine off, engine run and engine with glow. Some would refer to the later as ‘engine start’ but in reality I fly with the glow always enabled and it turns on / off at a low throttle position.

In my experience a good quality NiMH C cell will give you a solid hour of flying with 5-6 starts and you could extend that by going to the ‘run’ position if you had an extended idle / taxi period.

Programming for the Taranis

The programming for this is to set up the throttle throw without trim you have the idle you want and the switch position at ‘Cut’ applies an override value to the the throttle servo which completely closes the throttle no matter where the stick is.

Mounted in the model wrapped in foam. ‘C’ cell is behind the servo plate.

In the middle ‘Run’ position the switch does nothing at all allowing the the throttle to move through it’s full normal range.

The glow driver is plugged into Channel 6, which is set to ‘MAX’ and has a weight of -100% which means that is is held in the ‘off’ position unless something specifically overrides it.

The glow-on position is slightly more fiddly if you’re not familiar with the Taranis style of programming. It uses a logical Switch that is ‘on’ when the throttle is below 25% and a special function maps that logical switch to override Channel 6 to +100% which is where I’ve plugged in the glow driver.

For the sake of convenience I also linked an ‘Engine Off’ voice prompt to the off position and a beep for when the glow comes on so if you’re standing out at the flight line and my transmitter is beeping occasionally it’s because the glow has come on, not because my lunch is cooked.

Taranis settings

Now that I’ve typed that and read it back I’m not even sure it makes sense, so some photos of the programming on the radio are included and if you’re curious catch up with me at the field and I can explain it in gratuitous detail.

Build it yourself

For those interested in the gory details I used an AT-Tiny85-20P micro and IRFZ44N fet with a 3V9 Zener regulator so it can run on higher than 4cell NiMH/NiCD.

Schematic, click for larger view.

Here’s the schematic for those really curious, the funky mosfet is the default library file in kicad on Ubuntu Linux, don’t blame me.   

The source code is not a good example of coding by any standard, but can be found on github at this address: https://github.com/kiwichrish/on-board-Glow under the MIT license.

I suspect maybe it was just my google-foo letting me down, but there were some truly useless library files out there on the interwebs for the Nano, whereas there were some great libraries including 3D models for some of the other models of the Arduino.  Go figure.

You can find the files on github: 
https://github.com/kiwichrish/kicad_ArduinoNano

Pop a comment down below if you find them useful, I create a lot of custom library files for Kicad but most of them are pretty specific to what I need and never see the light of day.  I thought these ones were a bit more applicable for others to find useful.

PCB module view

Schematic View

In the same way that some IT cliques have un-cons instead of conferences.

The premise is that you have more of the social and less of the conference with a strong focus on community and learning.

The Kiwi DX group was for the most part just a mailing list run by a few different folks over the years. When I first became a ham it was run by Bill, ZL3NB who is one of the nicest guys you’ll ever meet.

The Kiwi DX mailing list bounced it’s last email some time in 2016 and although another mailing list is giving ZL DXers somewhere to blow off steam, it’s just not the same.

I miss the un-group-ness of the old list and the eclectic mix of folks who posted regularly even though the occasional flame war threatened to undo the very fabric of time itself.

While the group was essentially a random mob of hams rather than an organised club the mailing list did spawn some great collaborative efforts. The special even station ZM90DX that ran for a full year and crowd funding donations for some DXpeditions in the few short years I was an un-member come to mind.

This is obviously a bit of reminiscing on my part. I found some old emails that jogged my memory but that’s not my only intention, it’s also a bit of a sneaky shot at preserving a tiny little bit of amateur radio history.

The Kiwi DX group, being the un-group it is, has never had a website of it’s own. That hasn’t stopped a fair number of ZL Dxers using links to Lee, ZL2AL’s website that hosts the one ‘official’ mention of the group which is here: http://www.zl2al.com/kiw-dx-group/

Lee was another most excellent gentleman who sadly became Silent Key mid 2015. Lee created the KiwiDX logo at the top of this post and adorns quite a few ZL QSL cards.

Lee’s son is keeping the lights on over at http://www.zl2al.com but just in case it does fall into the cracks I’ve taken a copy of the little sliver of DX history and included the page contents below which is the sum total of the Kiwi DX Group web presence.

“The Kiwi DX Group is a group of avid DXers that formed in the late 1990s. The logo originated from the magazine NZDXR edited by ZL2AL. Although the magazine ceased publication after nearly 5 years, the bond was formed and Kiwi DXers became a formidable group in the pileups. ZLs are quick to support DXpeditions and a recent “pass the hat” exercise saw the ZLs raise a considerable amount of money to become a sponsor and support the upcoming FT5ZM Amsterdam Island DXpedition 2014”

In the spirit of the Kiwi DX un-group I’d encourage any ZL ham who’s fond of a bit of late night DX to use the Kiwi DX logo created by Lee on their QSL card or drop it on their qrz.com page.

We’ll see if we can have have the Kiwi DX group survive another 20 years even without the mailing list.

73, Chris
ZL3LF

I tried to raise some locals for a chin-wag on a couple of repeaters and got the silent treatment so went for plan ‘B’ and started scanning some local services channels.

17,748 km or so Google says

After listening for a wee while to some linesmen dealing with a power pole fire (not related to the big CHCH fires recently) I got bored and thought I’d go a bit lower down the spectrum.

Basically I started listening a bit below 500 khz and scanned upwards from there.

The squelch broke for the the local broadcast AM stuff you’d expect, along with some big noise sources in the 80m band and a local ham rag chewing on 40m who sounded like a duck as the HT only does AM/FM not side band.

Then well into the short-wave broadcast chunk proper I listened to a bit of the 8pm news on Radio New Zealand shortwave service that was thumping in as I plodded along behind the K9/p.

Short wave listening with a Rubber Ducky?

After the news I kept on scanning upwards and wound up listening to a movie review of the new Lego Batman movie where the scan stopped on 11.780Mhz.

I assumed it was ABC, the Australian Shortwave service or something else relatively close to home.

Listened for a bit longer to the entertainment news about Angelina Jolie making a movie with her kids you could have knocked me down with a feather when the announcer said it was China Radio International English service!

A good solid S4 – S5 signal into the standard rubber ducky antenna designed for 432/144Mhz.

I didn’t even hold the radio above waist height most of the time, I was just wandering along with it in my hand.

Checking when I got home I found that the transmitter was centred on 11.785 Mhz based in Cerrik, Albania!! That’s almost anti-podal at around 17,000km.

Once again, there might be quite a bit of science in this radio thing but every now and then there’s a wee dusting of magic as well.

156bpm max? Hmm.

For the record the dog and I did 6.55 km in a bit over an hour and a quarter. 8,606 steps apparently. I do wonder how many steps the dog took? Quite a few more I’m guessing!

I decided to spin the dial on 17m this evening before sneaking to bed and spoke to Eric, SM1ALH in Sweden for a few minutes but it was pretty rough, although 17m this late at night is always a bit of a crap shoot.

Conditions have been poor the last wee while due to a solar storm, with good visible aurora from my QTH but I decided to pop down to 20m to see if anyone was awake down there.

Low and behold the Scandinavian Activity contest has magically opened the band and I can hear a whole bunch of Europeans, JA’s and some VK’s plugging away in standard contest style.

Scandinavian Activity contest log

I promptly shoved a bit more coal in the direction of the afterburner and gave out some multiplier points to some folks up the other end of the planet before I got my beauty sleep.

In the mean time the propagation prediction tool in my logging software is saying “don’t bother” and the published solar numbers suggest getting shares in skype rather than HF gear.

So, once again, all together…

Turn on the radio and listen for a while, the bands are always open somewhere!

73, Chris

Back in the mid 00’s I was a big fan of a CMS called Etomite that begat MODX which I still use for some projects. You can read about the death of Etomite and the rise of MODX on wikipedia.

Anyway, I used etomite for an earlier blog site at www.ohmark.co.nz which is the name of an electronics development company I ran from about 1996 till 2004, ish.

When I sold the rights to the then-current products and designs the new owner wasn’t crazy enough to take on the meaningless company name and oddly spent domain so I kept it for my blog.

That blog was used to record progress on a couple of microcontroller projects I was working on at the time and got enough traffic that it was worthwhile putting google ads on the site.

As I was earning one or two cents a week in advertising revenue from the site I kept it online until May last year when I rolled my web servers over to Debian 8 which included PHP 5.6.x.

Unfortunately PHP 5.6 was a bridge to far for Etomite and my efforts were rewarded with a dreaded deprecation error which are quite often journey to no-where to unravel.

Deprecated mysql library error in Etomite

I was already running the last version of Etomite released, Version 1.1, and as it was the only site out of a few dozen on that box that did not survive the operating system upgrade I went for the cop-out option and put up a cop-out home page and forgot about it.

Cop-out offline message that lasted over a year.

Skip forward to this weekend and I decided to re-visit it as I’m back on the blogging kick again and I still get the odd email about broken links to one of the projects on the site for a CNC stepper motor controller design I posted to some forums.

Long story short, here’s how I fixed up my Etomite install so you can get your crusty old Etomite site working again as well and revel in the y2k feeling of the admin interface.

To silence the error handling, add a new line at the top of index.php:

<?php
error_reporting(E_ALL ^ E_DEPRECATED);
etc...

Then pop down to the executeParser() function and line 605 or there about’s and comment out the handler and reporting calls.

  function executeParser() {
    //error_reporting(0);
    //set_error_handler(array($this,"phpError"));

You should also comment out any other calls to error_reporting in index.php.  I had four of them but I think they were from my original half-hearted attempt to fix the deprecation error in 2015 but they may have been original.

Lastly put an ‘@’ in front of the deprecated mysql_connect statement on line 1323 or just after given you’ve added a new line at the top.

Change:

    if(@!$this->rs = mysql_connect($this->dbConfig['host'], $this->dbConfig['user'], $this->dbConfig['pass'])) {

to be:

    if(@!$this->rs = @mysql_connect($this->dbConfig['host'], $this->dbConfig['user'], $this->dbConfig['pass'])) {

And your Etomite will rise from the ashes, sorta, ish.

Now that you’ve got Etomite running again, shift the website to something else before you go much further.  There are some common open-source components in Etomite that have had long published exploits which could bite you in the proverbial bum if you leave it online.

At the very least make the entire site read-only to protect against the TinyMCE injection issues which surfaced after Etomite last received an update.  I’ve made mine read-only and have an IDS monitoring for file system changes but it is not what I’d call a ‘trusted’ site on the server and I’ll probably chroot it as well.

There was an attempt for a couple of years to get Etomite moving forwards called etofork on github but it seems to have died and if you want a similar CMS toolset MODX is the way to go now, or if your site was a blog you could go where everyone else seems to have and use WordPress.

For my part I’ll probably move the content to this site, as maintaining two blogs is kinda silly, but given my on-again, off-again blogging style that might have to wait another year or so.