After working QRP only for a few months I opted to drop the purist aspect on that front. After talking with some locals and reading VK2QR’s write up with interest I took the plunge and ordered a MX-P50M fresh from ebay.

Being somewhat under prepared for AusPost to deliver before Easter I was surprised to have the amplifier delivered with perfect timing. I quickly asked around and was lent a 60W dummy load and an Avair AV-601 from Tony VK2KZ. Now armed with the required test equipment to not burn out my poor Z817 tuner I started soldering up the power poles and control lead. For the FT-817ND control lead I used the pinout schematics again from VK2QR. In case hosting related things go awry in future I’ve extracted the pinout diagram here.


Testing Setup

While its far from completely scientific, these results are a step in the right direction. While I can’t validate the unit I have particularly there is a incredibly detailed write up by GM4SLV on the amplifiers RF performance. If you’ve made it this far and are waiting for “YES BUT LOOK IMD” go read Johns write up, I am not covering that.

The details I was looking for however have more to do with my choice of power. Unlike most SOTA activators carrying Lithium battery packs up the hills I’ve been using a Goal Zero Sherpa 100 (ok its still Lithium). But the little box includes a 12v regulator fused for 10A along with a 5V USB feed and support for Solar, DC or AC charging. Its a neat package but needs a bit of consideration, on the other hand it doesn’t look like a bomb and has high wife approval factor for camping related power needs so its a win-win / least bad choice!

Here is some fabulous 1 minute ASCII art of the test environment.

          +------------------+  +----------+  +-----+
RF        |                  |  |          |  |     |
          |                  |  |          |  |     |
          +                  +  +          +  +     +
          FT-817ND          MX-P50M       AV-601    60W Load
          +                    +
          |                    |
DC        | +------------------+
          | |
          | |
          + +
          WARS Power Pole Dist
          In-line DC meter
          Goal Zero

Or for the visually inclined here is a photo while testing 40M at 5W input RF.

40M TX test at 5W

Initially I was powering the rigs using a bigger, heavier Goal Zero unit (Yeti 150) which was AC connected. I only clicked as I almost completed the testing that this was not going to replicate SOTA conditions. So you see data for both a mostly stable 13.8v power supply as well as a second table where I switched to testing with the Sherpa 100 on internal battery.

The difference between the two power supplies is mostly that the Yeti 150 is NIMH SLAB type with ~150Wh while the Sherpa 100 is a LiPo pack and 98Wh.

Needless to say I only recorded detailed voltage supply for the battery powered test.

Testing Data

Yeti 150 + AC charging

Band Frequency Mode In RF watts Out RF watts In Amps
10 28.85 PKT 0.5 7 4.26
15 21.225 PKT 0.5 9 3.85
20 14.175 PKT 0.5 8 3.8
40 7.15 PKT 0.5 8.5 3.9
80 3.6 PKT 0.5 8 3.95
10 28.85 PKT 1 15 5.75
15 21.225 PKT 1 18 5.2
20 14.175 PKT 1 17 5.2
40 7.15 PKT 1 18 5.4
80 3.6 PKT 1 17 5.4
10 28.85 PKT 2.5 26 7.52
15 21.225 PKT 2.5 29 6.38
20 14.175 PKT 2.5 26 6.4
40 7.15 PKT 2.5 26 6.6
80 3.6 PKT 2.5 29 6.7
10 28.85 PKT 5 35 8.6
15 21.225 PKT 5 35 7.2
20 14.175 PKT 5 30 7.3
40 7.15 PKT 5 30 7.3
80 3.6 PKT 5 39 7.6

Sherpa 100 Internal Battery

Band Frequency Mode In RF watts Out RF watts In Amps TX voltage RX voltage
10 28.85 PKT 0.5 7 4.29 11.16 12.09
15 21.225 PKT 0.5 9 3.86 11.16 12.06
20 14.175 PKT 0.5 8 3.83 11.15 12.03
40 7.15 PKT 0.5 9 4 11.13 12.02
80 3.6 PKT 0.5 8 3.98 11.14  
10 28.85 PKT 1 15 5.7 10.92 12.03
15 21.225 PKT 1 17 5.08 11.03 12.02
20 14.175 PKT 1 16 5.07 11.02 12.03
40 7.15 PKT 1 17 5.29 10.99 12.03
80 3.6 PKT 1 17 5.37 10.95 12.03
10 28.85 PKT 2.5 25 7.05 10.66 12.03
15 21.225 PKT 2.5 26 6.14 10.78 12.03
20 14.175 PKT 2.5 24 6.17 10.78 12.03
40 7.15 PKT 2.5 25 6.26 10.76 12.03
80 3.6 PKT 2.5 27 6.45 10.82 12.03
10 28.85 PKT 5 30 7.94 10.54 12.09
15 21.225 PKT 5 30 6.91 10.82 12.09
20 14.175 PKT 5 30 7 10.81 12.09
40 7.15 PKT 5 30 7 10.79 12.04
80 3.6 PKT 5 31 7.22 10.73 12.04

On Air

So I set off this morning to entertain the inner Sydney morning dog walkers by taking my new SOTA pack off to Blackwattle Bay to get some clear space for the inverted-V. The goal was to test a few things;

  1. At JMFD 2017 we had great success using this antenna with VK2KZ’s digital station and tuner across most bands. I hadn’t thought of this before so wanted to see what the LDG Z817 would tune to
  2. Test the amplifier and get on-air signal reports
  3. Let the blue smoke out before I find myself on top of a hill doing it live.

Here is the setup for the morning.

Antenna upright at Blackwattle bay Note: SOTABeams squid pole and 40/20 linked dipole in inverted-V.

Station equipment on the air Note: Left to right - FT-817ND, MX-P50M amplifier, LDG Z817, In-line DC meter, WARS Power Pole Kit, Sherpa 100.

For those that miss my scrawl in the log, just prior to this photo I made a contact with FK4QX on 15 meters at ~20w after I answered a CQ DX call. There was some initial difficulty with Philippe’s beam pointing to NA rather than VK but with a 5/5 report I was happy with that.

In fairness - this morning propagation on the higher bands did seem more forgiving. Andrew VK1AD/P wrote up his SOTA activation with a NA contact at 5w on 17m.

Never the less the little MX-P50M has made a welcome addition to the SOTA pack while the longer term options of learning CW and upgrading to an Advanced license take a bit more time!


Good news everyone! I passed my exam and as of earlier this year joined the ranks of radio amateurs around the world. It has been a fun few months exploring all manner of things.

Using the WIN System with a cheap Baofeng GT-3 MK II handheld during my trip to Austin where I spoke at Art Into Science. I was astounded by the density of repeaters in the US compared to our sparse coverage in VK.

handheld radio with towers in background Taken looking west from the Colorado Tower in downtown Austin. The tower lights in the distance mark the AUSWST APRS repeater.

I’ve been building myself up to do Summits On The Air (SOTA) style activations as my main HF radio outlet since getting things working in inner Sydney would require herculean efforts. Here you can see where I stood up my squid pole and linked dipole to test everything and was making contacts into VK3 on 40 meters successfully despite it being nearly noon!

park bench with antenna and solar panels A shot of my park bench overlooking Black Wattle Bay. I opt’ed to lug everything I had planned for a SOTA activation much to the amusement of on-lookers.

I achieved my first SOTA activation for a grand total of one point recently by activating VK2/HU-094 Mount Yakaba. With only the FT-817 when 40 meters started fading it was time to pack up. Fortunately I just scraped in with the required four contacts! The view from the summit while only a few hundred meters was well worth the heat.


It has been a bit quiet around here for a while. I’ve been busy at work helping to build a new logging platform on top of Splunk and recently attended Kiwicon X which was fricken amazing. Having met lot’s of interesting folk during the con and with a few super relevant (Shout out to Karit for his SDR + GPS hacking talk) presentations I figured it was time to dust off the old SDR that has been dumping 1090 for ADS-B since god knows when and actually start to listen to the radio. The astute among you will see where this is going …

Yup, I am studying for my Amateur Operator’s Certificate of Proficiency (Standard) (AOCP(S). It feels long over due to stop just playing with ISM microwave band’s and get a bit more understanding of all of the various digital modes we take for granted when passing packets around.

Some history though! Many years ago during my NTFreenet days I ran into some members of VK8DA and actually attended a meeting at their Fannie Bay site. But back then it didn’t stick. The SDR revolution (if you can call it that) wouldn’t start for a couple more years and cheap and readily available SOC’s like Raspberry Pi were just not a thing.

Fast forward to now and I’ve started participating in the Waverley Amateur Radio Society VK2BV. Listening in with an RTL-SDR to their FM nets has been a quaint reminder of the simple but effective technology that we have taken for granted and I feel probably neglected in the light of streaming services like Soundcloud (Trust me it still blows my mind streaming HBR1 via 4G LTE while walking into work with nothing noticeable at all - https://www.youtube.com/watch?v=0kzjqBacF1k).

I am hoping to do a bunch of interesting things with WICEN and emergency response packet radio. The things you can achieve these days with 5 volt equipment and emerging technology like LoRa and Outernet is super super exciting.

So uh, stay tuned!


This instalment of my blog is as usual a bit of a rant and a thinly veiled “Documentation to myself when I next forget how to do this”.

So I’ll set the scene - I have been gradually migrating things back to my home based hosting in Sydney (what with stable power and not abysmal VDSL2 NBN) rather than hosting in AWS, Vultr and about fifty other random SaaS services.

Not to mention that I got very excited to get on board with Redhats Developer program, So what is one to do? Install it obviously.

Well - things have changed a bit since I did my RHCE on RHEL 5 it would seem. First lets cover what we are trying to actually do here

There are four 2TB SATA disks in a five bay hot swap caddy. As you can imagine I want a semi-respectable performance so I chose RAID10. Since I can’t boot on RAID10 I need to also create a RAID1 for /boot. We also want to use LVM because we are not scrubs (or on AWS).

md0 - RAID 1 /boot
md1 - RAID 10 LVM Physical Volume
    lv_root - /
    lv_home - /home
    lv_var - /var

Ok that plan looks great - install time!


Note: Total caveat here is EFI. Since my old X9SCL+ hasn’t yet shed MBR based booting I don’t need to stuff around with EFI partitions. So I have skipped them since I was beyond patience by that point. If you need EFI I am keen to hear what lengths it takes to mirror the boot volumes.

So I apologize for what is normally a blog light on screen shots but since this all anaconda GUI here we go.

  1. Select your physical disks.


  2. Don’t click the temping “Click here to create them automatically” button. Nooo we click the + sign button at the bottom left to add our first boot partition.

    • Mount point = /boot
    • Desired Capacity = 500M
  3. Now we need to change the /boot partition on /dev/sda1 to a RAID1 array.

    1. Click the Device Type accordion menu then select RAID.
    2. The RAID level defaults to RAID1. Keep this for our boot volumes.
    3. Click Update Settings to save this partitions configuration. If you clicked away already joke is on you - start from 1. again. The number of times I fell for this is embarrassing.


  4. Ok now we assign our root mount point by clicking + again.

    • Mount point = /
    • Desired Capacity = 10G
  5. If your thinking “Oh yeah we just did this, I select RAID in the Device Type here”, your going to hit one of my pet peeves. No actually we Modify the Volume Group (Think about it afterwards and it makes sense).

    1. Click Modify
    2. Click the RAID Level accordion menu then select your desired RAID level (We use RAID10 in this example).
    3. Click Save


  6. Finally we just need to add a swap volume. Clicketh the + button once more.

    • Mount point = swap
    • Desired Capacity = 1G

Believe it or not the swap volume is the least painful since it is just an additional logical volume on the existing RAID10 physical volume. If you wanted it in another volume group on a different physical volume I feel for you son.

Ok so we are installing at last! Shortly your system should boot and your layout will be something like this.



So that all seems fairly easy? Well hopefully yes! But in case you come unstuck like I did here are the traps I hit.

Zero any disks first

If your reinstalling over an old deployment your almost sure to hit blivet bugs during the partitioner which annoying only happens after you spend a silly amount of time clicking around the partitioner GUI and the installer actually starts trying to get going.

So first boot to rescue mode and create new MSDOS labels on each disk you plan to use for the install but do not create any partitions.

The bugs you will hit look something like this;

:The following was filed automatically by anaconda:
:anaconda exception report
:Traceback (most recent call first):
:  File "/usr/lib/python2.7/site-packages/blivet/formats/__init__.py", line 405, in destroy
:    raise FormatDestroyError(msg)
:  File "/usr/lib/python2.7/site-packages/blivet/deviceaction.py", line 651, in execute
:    self.format.destroy()
:  File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 377, in processActions
:    action.execute(callbacks)
:  File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 374, in doIt
:    self.devicetree.processActions(callbacks)
:  File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 224, in turnOnFilesystems
:    storage.doIt(callbacks)
:  File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 186, in doInstall
:    turnOnFilesystems(storage, mountOnly=flags.flags.dirInstall, callbacks=callbacks_reg)
:  File "/usr/lib64/python2.7/threading.py", line 764, in run
:    self.__target(*self.__args, **self.__kwargs)
:  File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 227, in run
:    threading.Thread.run(self, *args, **kwargs)
:FormatDestroyError: error wiping old signatures from /dev/mapper/vg01-rootfs: 1

Expanding an existing RAID’ed PV

So you noticed your disks are a little light on the way of free space eh? Turns out that if you didn’t fully allocate your disks during partitioning the installer no longer fills your disks for you. That physical volume is exactly large enough to fit the logical volumes you asked for and not a errant gigabyte more.

So lets expand the disks because actually we really did want to add more logical volumes. Just not during install time.

  1. fdisk each physical member of the RAID array

    1. Delete the partition containing the RAID array - d
    2. Recreate the partition - n
    3. Change the partition type - t, you will want fd for mdadm arrays
  2. reboot to clear your kernel partition tables
  3. Expand the array via mdadm

    $ mdadm –grow /dev/md1 –size=max

  4. Finally resize the PV

    $ pvresize /dev/md1


A couple of ShipIt’s ago I noticed a snazzy looking Atlassian Connect plugin for Bitbucket called Aerobatic. On the tin it said;

Smart hosting for static web sites. Ideal for Jekyll sites, JavaScript
single page apps, and any HTML / CSS / JavaScript web site. Link your
Bitbucket repo, push your code, and your site is updated automatically. CDN,
SSL, custom domains, API proxy, and more.

A few months later and having read (only a few) pages complaining about Github pages lack of certain features I thought it was time to take a look at what this add-on can do. Turns out I migrated last weekend and this blog is now coming at you from Aerobatic. Woo!

Peeking under the hood

Installing Aerobatic is about as painful as logging into a new SaaS service using Oauth. The Getting Started page has literally two steps. Not very exciting - But the really exciting stuff is a little bit deeper.


In one of the articles I linked earlier, Eric Mill pointed out the issues with Github pages HTTPS support at the time - Have a read https://konklone.com/post/github-pages-now-sorta-supports-https-so-use-it.

So what is the problem?

  • Github only support HTTPS on *.github.io domains
  • Github doesn’t support custom domains with HTTPS
  • A hack for custom domains using Cloudflare’s “Flexible SSL” doesn’t provide end-to-end encryption

How does Aerobatic help us here? By leveraging the Amazon Certificate Manager (ACM) to issue free TLS certificates for any domain that is validated by ACM they can configure a AWS Cloudfront distribution with end-to-end encryption and delegating cipher suite hardening to AWS (which they update regularly - just have a look at your ELB policies).

The process for ACM domain validation is no different to that of other email based certificate validation. So yes, your still getting certificates from vending machines. At least now you know the value of them.

After that configuring Aerobatic to use the CNAME is trivial. It will take a fair while for the Cloudfront distribution to be configured.

Jekyll Plugins

Aerobatic’s docs on automated builds is quite a cool read and gives you a good idea what is going on. By passing your Jekyll payload to AWS Lambda they can provide more support for plugins than the current Github pages solution.

The really exciting part is that this architecture affords Aerobatic a path to support more static site generators like Hexo, Pelican and Hugo.

Private git repository

Don’t get me wrong - I am a open source advocate and am quite happy to contribute interesting projects. But pushing commits that say things like “fix typo” makes me feel bad for polluting your inbox. So Bitbucket makes a really great choice there where the HTML and user facing content (like this post) are available for all to see. Meanwhile my shameless typo’s and spelling issues can be fixed quietly.

The bad parts

None that I am aware of but if any of the below concerns you, well - good luck with that.

That is all for now folks!