mitsake

Some things I've made

2025-07-05T00:00:00+00:00

I haven't posted anything for a long time now, so here's some things I've made over the past five years or so in no particular order.

rng-pcb: A CircuitPython Random Number Generator</h2>
This was built as part of the Boldport Club's</a> community PCB swap, which was a really fun project to be part of. I based this board on the Adafruit Trinket M0</a>, using a 12 V charge pump to power an avalanche noise generator. It uses a stack of circuit boards as an enclosure, and has two capacitive touch buttons in the front top corners. The firmware is pretty basic, but I think it's quite cool to 4096 bits of (probably) true randomness appear on the screen. It was also the first project that I documented on GitHub</a>, and most people managed to put it together despite me using tiny SOT-523 (1.6 × 1.6 mm including leads) transistors instead of the planned SOT-23 (~ 2.9 × 2.4 mm) ones.
</figure>
kbx's Nixie Clock</h2>
Another project from the PCB swap, this is probably the largest electronics/soldering project I've built. kbx published</a> display boards for most of the commonly-available types of nixie tubes and I went with IN-14 (ИН-14) tubes since they were a good balance of size and cost. Despite a few issues with hand soldering so many surface-mount components, it's been powered up and keeping time for seven years now.
</figure>
A breakout for the SAMD21E chip</h2>
I had some of these chips left over from the rng-pcb project and made this</a> to practice reading datasheets and PCB design. My original intent was for this to run a low-impedance crystal without load capacitors as the datasheet describes, but I couldn't seem to get this to work; my suspicion is that it's to do with the automatic gain control function not being available which I later read about in the errata.
The first boards were made by OSH Park</a> - as always, they were great, but I then received a US$50 voucher from Seeed Studio</a> to try their Fusion PCB service. They produced the revised board - the only change was to add footprints for load capacitors - and everything seemed to work fine.
</figure>
SiCK-60 - a 3D-printed keyboard</h2>
</figure>
I got hold of some Cherry MX compatible blue (clicky) switches as part of the Boldport 'travelling box' community project. As I did't have a lot of desk space, Fedor Sosnin's</a> SiCK-60</a> keyboard seemed like a good fit. I hand wired it using the procedure outlined by cribbet on the GeekHack forums</a> which worked well, though I'd definitely use solder-through enamelled wire if I were doing another build. Stripping the wire was by far the most tedious bit of the build.
</figure>
The controller is a Pimoroni PGA 2040</a> wired to a micro-USB breakout. To allow firmware updates I drilled a hole and mounted a tactile switch in the bottom soldered between the PGA2040's BOOT pin and GND. Since I was using KMK firmware</a>, setup was pretty easy, though writing a valid keymap took a few rounds of trial and error.
Matariki - a soldering kit</h2>
This circuit board was designed for my then-job as a first electronics project for people who wanted to learn to solder. Advice from Māori colleagues helped to get the star positions and names correct and the project ended up being really popular with people of all ages. I was particularly happy when someone who'd built a kit with their child came back the next week to repair an electric guitar that had a loose connection on the jack. I'm currently planning a revision to change the coin cell over to 2 × AAA batteries. The version below was put together by my colleague (as one of their first soldering projects!) and you can watch their video</a> of the process if you like.

Images by Blueprint Makerspace</a>.</figcaption> </figure>

Setting up a small videoconferencing server

2020-04-05T00:00:00+00:00

Update (6 April 2020): Having just updated my server, it appears that the latest version of Jitsi leads to some issues. I ended up reinstalling using the quick install guide</a>, which worked without any issues. Best to go with that for now! 

Like a lot of the world, we're in "lockdown" over here, with only a few businesses allowed to open. Obviously a lot of people are now working from home, so videoconferencing is now a key tool in everyone's arsenal. The defacto option appears to be Zoom</a>, but they have a fairly sketchy record</a> on user privacy which has left many</a> people</a> questioning</a> whether they ought to be trusted.

Rather than think too hard about whether Zoom was worth using, I decided to try another option - the open source Jitsi</a>. It offers many of the same features as Zoom, but since you run the server, you don't have to worry about where your audio and video are going. Although they have a quick install guide</a>, I've been having a few issues with getting them to work. Here are the steps I took to get things running.

To get started, you'll need a Linux server with:

Root access via ssh, and</li>
A DNS record pointing to it. This isn't strictly necessary, but it will make things much easier.</li> </ol>
I used a Nanode from Linode</a>, but the smallest Droplet from Digital Ocean</a> would also be fine, and both have promotions with free credit which would be perfect for a project like this. In terms of OS, I opted for Debian 10 (buster), but the following shouldn't be too different for any similar system.
Once you're logged in, start by updating everything and installing gpg (for the Jitsi repository) and the nginx webserver. Installing nginx first is the main change I made from the official documentation, but fixed some issues I was seeing where both nginx and the Jitsi module ended up listening on the same port, preventing nginx from starting.
# apt update && apt upgrade # apt install gpg && nginx </code></pre> Set the hostname of the server by running hostnamectl set-hostname subdomain.domain.com</code>, and editing /etc/hosts</code> so that 127.0.0.1 points to the same name. If you navigate to the domain now, you should see the nginx default page: From here, remove the default site, install the key for the jitsi-stable</code> repository, and then install Jitsi itself.# rm /etc/nginx/sites-enabled/default # echo 'deb https://download.jitsi.org stable/' >> /etc/apt/sources.list.d/jitsi-stable.list # wget -qO - https://download.jitsi.org/jitsi-key.gpg.key | apt-key add - # apt update && apt install jitsi-meet </code></pre> Visiting the site now should show you the Jitsi landing page: The final step is to use Let's Encrypt</a> to get a free SSL certificate, install it, and restart nginx. Jitsi provide a script to do this, so to finish off you can simply run it and restart nginx. # /usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh # service nginx restart </code></pre> I'm sure the Jitsi project is going to be changing fairly rapidly given the current pace of things, so I'll try to keep this updated.

Moving mitsake to makesite.py 2020-03-09T00:00:00+00:00 Welcome to the new-look mitsake! Most of the changes are behind the scenes, but I've also played around with the style a bit. The biggest change has been shifting from using Jekyll to generate the site to Sunaina Pai's makesite.py</a>. Over the last while, I've not really done much with Ruby, but I have had written a few scripts in Python and have started using CircuitPython</a> a fair bit as well. It's a great system and has been really easy to customise. I've moved away from automated deployment too - running rsync</code> isn't really that much effort. Design-wise, I've mostly kept the default style with some influence from BetterMotherfuckingWebsite</a> to help readability. I've kept Solarized Dark for code highlighting as it's still what I use day-to-day. Hopefully this year will see a few more posts here; I've completed a couple of projects and should really write them up. Playaway audiobook teardown 2019-06-17T00:00:00+00:00 I've been playing with electronics for a few years now, and given my interest in how things work, enjoy reading people's commentary as they take apart various devices. I recently found this Playaway</a> at a second-hand book sale and given it was just $1, decided to see what was inside. I hadn't seen one of these before, but they're a small digital audio player that comes pre-loaded with a particular audiobook and runs on a single AAA battery. Their website seems to be targeted towards libraries, so they're an alternative to digital distribution or sets of CDs. </a> Judging by their website, this is an earlier model of the player with a simple LCD and buttons for basic functions such as play/pause, changing tracks, adjusting volume, and power. The SP and EQ buttons adjust playback speed and equaliser preset respectively. However, this isn't particularly interesting, so let's get the cover off! </a> Opening the battery door and levering off the front cover gets us here. The keypad and LCD are held in place by the cover, and the contacts for both are clearly visible. The silkscreen tells us it was made by j.e. Unit Technology</a> in late 2009, and their website shows they're still making hardware for Playaway as well, with some newer products like the Playaway View in their portfolio. </a> The back is where the two main ICs are located. The rectangular chip is a 2 Gbit (256 MiB) Hynix flash, and the square IC is a SigmaTel STMP3770. This is a fairly interesting system-on-chip (SoC), designed solely for operating media players and carrying everything you'd need to make the next iPod killer. The only things needed are storage and passives for peripherals such as the voltage regulator. The Freescale logo on this one indicates that it was made after SigmaTel were bought, but following Freescale's merger with NXP it seems that the datasheets have disappeared. Fortunately, their popularity in media players means that the Rockbox project</a> has a lot of information on this family of chips</a>, including an archived datasheet for the 3770</a>. One thing I'd noticed when I took the back sticker off was holes to access a series of six test points on the PCB. At first I guessed that this would be for debugging, but the datasheet didn't show the pins associated with the SWD connector. Looking at where the traces from these pads went made the function fairly obvious though. T5 is connected on four sides to a plane and is continuous with the negative battery terminal, so must be GND. T4 and T6 connect to pins 77 and 78 of the IC, which are USB_DP (D+) and USB_DM (D-) respectively. This meant that T3 had to be the 5 V supply from a USB port, and sure enough it was connected to pin 53 of the 3770 - VDD5V. As far as I can tell, the other two pads aren't connected to anything on the STMP3770, though I'll go back and have another look. </a> I don't have any pogo pins (or a way to mount them), so I soldered some jumper wires to the test points. When I connected the player to my computer, I got this: It took some searching to find out what format these files were actually in. None of the common tools (e.g. VLC and ffmpeg) were able to decode them, which meant it wasn't Adaptive Multi-Rate - Wideband</a> (apparently common for audiobooks on Nokia phones). Guessing it was probably related, I tried to find a way to read the newer Extended Adaptive Multi-Rate - Wideband</a> format, eventually findinding a request for AMR-WB+ support in ffmpeg</a>, which in turn pointed me towards an encoder/decoder</a>. You'll need Windows (or Wine), but the syntax is very simple: decoder.exe -ff raw -if path\to\encoded\file.awb -of path\to\decoded\file.wav</code> produced a WAVE file of the audio. Automating Jekyll deployment, take two 2019-04-22T00:00:00+00:00 Back last year, I posted</a> about how I set up a non-bare git repository on NearlyFreeSpeech so I could work on the site from both my laptop and desktop. This has worked fine, but the fact that it's not the 'right' way to do it hasn't sat well with me. The issue I was having with a bare repository came down to deleting the temporary clone that was used to build the site. Despite working fine from the command line and via SSH, attempting to remove the temporary clone used to build the site gave Directory not empty</code> errors, all related to the .git subdirectory. Because the directory wasn't completely removed, creating the temporary repository failed when the script next ran. After converting the repository from non-bare to bare</a>, I started with the post-receive hook that I'd first tried (via Bart Lantz</a>). This threw the same error, but worked thanks to the multiple rm -rf</code> lines. Experimenting with adding a delay didn't seem to change much, but I found a very relevant Stack Overflow</a> question that tackled what was likely the same situation. The second answer gave me the solution: rather than using git clone</code> which creates the .git subdirectory that couldn't be removed cleanly, use git archive</code> to export a copy of all the files. This was the key to solving the problem and after a bit of trial and error gave me the final version of my post-receive hook. #!/bin/bash # set up variables REPO_PATH=/path/to/barerepo.git/ PUBLIC_WWW=/var/www TMP_CLONE=/tmp/repo # archive the repository to the temp directory mkdir $TMP_CLONE cd $REPO_PATH git archive master | tar -xf - -C $TMP_CLONE # build the site, putting it in the PUBLIC_WWW directory jekyll build --source $TMP_CLONE --destination $PUBLIC_WWW # clean up the temp repository rm -rf $TMP_CLONE exit </code></pre> I'm still not positive what causes the original issue, but other reading I've done makes me suspect that the instance of git running on the server during the execution of the post-receive hook is locking access to parts of the .git subdirectory. This would explain why I wasn't able to replicate the issue on the command line or when running the script via SSH, as well as why multiple rm</code> lines eventually removed the directory. Either way, using git archive</code> is an ideal workaround and it's nice to have learned a little more about git. Site changes 2019-04-14T00:00:00+00:00 Apologies to anyone who uses the RSS feed</a> and has seen posts being republished as I've been making changes to the site. Apart from fixing a few typos and updating the semantic layout, the major change has been a slight update of the colour palette to one that uses the Solarized</a> scheme. I've had a few projects on the go and will hopefully have something to write about them soon. In the meantime, here's a rough list of things I've done: New(ish) colour scheme.</li> Changed article headings to second-level (the site title is now the only top-level header).</li> Discovered there's a <main></code> element in HTML5, so substituted that in for the <div id="main"></code> that I've been using since first starting with CSS somewhere around the year 2000.</li> Added a link to the RSS feed at the bottom of the home page because most browsers seem to have removed buttons for feeds.</li> Post archive is now organised by year rather than month.</li> Got rid of the by tag archive because I'm bad at tagging and honestly I don't post enough here to justify it.</li> Changed the permalink structure to omit the month of the post, then remembered what 'permalink' means and reverted it.</li> Rewrote stylesheet using Sass</a></li> Updated stylesheet to add line spacing (21 April 2019).</li> </ul> Also, if you're using the Jekyll docs</a> to create an RSS feed, you'll see this line, used to include a short snippet from the post: {{ post.content | escape | truncate: '400' }} </code></pre> Because the truncate filter comes after the escape filter, the snippet can sometimes be truncated in the middle of an escaped character, e.g. &</code> becomes &am</code> or similar. This might cause undefined behaviour in some feed parsers (when I tested an affected feed, the W3 validator aborted), but it's easy to fix by switching the order of the filters so the post is truncated, then escaped. Unlocking the Siglent SDS1104X-E 2018-11-11T00:00:00+00:00 As a birthday present, I recently bought myself my first oscilloscope. After researching the various makes and models for a fair while, I eventually decided on the Siglent SDS1104X-E</a>. It's a four channel model, with 100 MHz bandwidth and options to add a waveform generator and digital input. Given this is my first 'scope, I started a bit of reading to find out how to best use it. In the process, I came across an interesting post</a> on the EEVblog forums indicating that it was possible to 'upgrade' the 1104X-E to the 200 MHz 1204X-E. This, of course, generated a fair bit of interest, with people eventually coming up with a method</a> to extract the license keys from the oscilloscope's memory. I didn't have a whole lot of luck with this, as I wasn't able to get the version of busybox linked in the post to actually save a core dump. In addition, I wasn't particularly fond of having to use a modified firmware file from a file sharing site as the first step in the process. After a bit of reading (particularly this blog post</a> from 2007 and a post on the chumby forum</a>), I managed to come up with a slightly different method. Download SDS1xx4X-E Operating System -V1 from the Siglent support site</a>.</li> Extract and mount the rootfs.cramfs</code> file:</li> </ul> # mount -o loop -t cramfs /path/to/rootfs.cramfs ~/tmp </code></pre> As cramfs file systems are read-only, we need to copy the files to a new directory. Make a list of the files in the original file system, copy them to the new directory, then unmount the cramfs file system:</li> </ul> $ find ~/tmp > filelist.txt $ cat filelist.txt | cpio -pdm siglentfs-mod/ # umount ~/tmp </code></pre> The only edit we'll make is to the /etc/shadow</code> file. Open the file using your favourite text editor, which looks like this:</li> </ul> root:$6$DZO.HiUy$JKaJGKC8ynyAn.7IF64GzC6cGnmJCQgGlqoPQ9QTc7EW8iF/8lMD00EtiiS3/GpgzN7rvfTbmfnAKzAg66dnu/:17177:0:99999:7::: siglent:$6$tOEDgvF2$A2zA0bgMZ9XU7LTZN5FVGl4iuDUoPGqGG8IrHoTRaPRJzYyIDXQ8lh8.E1PX98HS8UDRBgDdXwRHlWUG5fY4M1:17029:0:99999:7::: </code></pre> The hash is between the first and second colons in the line starting root</code>. Generate a new password hash, and replace the hash in the shadow file with this new one.</li> </ul> $ mkpasswd -m sha-512 yourpassword DZO.HiUy $6$DZO.HiUy$tws7P/jPrYETgX5rZCuyU5nhUTjaP//4o5W/6Ruq/Q95qUb5CLxB/i6uBMm7lMl6Y3P1ExXbMk3qPisxH14.H1 </code></pre> Finally, use mkcramfs</code> to compress the filesystem again. Current versions of Ubuntu include mkfs.cramfs</code>, which for some reason the Siglent doesn't seem to like. However, mkcramfs can be found as part of the original cramfs tools</a>. Once you've built them, compress the filesystem:</li> </ul> $ mkcramfs siglentfs-mod/ rootfs.cramfs </code></pre> Follow the instructions in the Siglent update file, replacing rootfs.cramfs with the edited version.</li> You should now be able to telnet to the oscillscope and log in as root with the new password. Plug in a USB drive, dump the contents of memory, and unmount the USB.</li> </ul> # cat /dev/mem > /usr/bin/siglent/usr/mass_storage/U-disk0/memdump.bin cat: read error: Bad address # umount /usr/bin/siglent/usr/mass_storage/U-disk0/ </code></pre> From this point, the steps are the same as those in the step-by-step</a> post, starting from step 21. Just in case they disappear, this is my interpretation of them: Open the memory dump using a hex editor search for the string 'SDS1000X-E'. It'll occur a number of times, you're looking for where it appears approximately 25-30 bytes before the scope ID (found by typing SCOPEID? at the web-based SCPI prompt) and the serial number.</li> After the scope ID appears twice, there will be five 16-character strings made of uppercase characters and digits. The first four are the licenses for 100 Mhz, 200 MHz, 50 MHz, and 70 MHz bandwidths respectively, and the fifth is the currently active bandwidth license.</li> The 'SDS1000X-E' string will also appear near the serial number which for me was repeated as well. Following the serial number there will be a 48-character (again, uppercase and digits) string. Separating this into 16-character strings will give you your AWG, WIFI and MSO keys respectively.</li> The bandwidth licenses need to be activated through the SCPI interface using MCBD <key></code>, while options can be activated either via the oscillscope's menus or using the command LCISL <option> <key></code>.</li> </ul> Hopefully these steps help someone else work through the process. Please bear in mind that playing with the firmware of your test equipment carries the potential for Bad Things to happen (up to and including leaving it entirely non-functional), so don't say you weren't warned. Getting started with the Pluto SDR 2018-08-16T00:00:00+00:00 Update (5 April 2019): the myraidrf repositories are now out of date. If you're running Ubuntu 18.04, your best bet is to install gnuradio from the default repositories and use the instructions on the Analog Devices Wiki</a> to build the gr-iio blocks from source. I've been interested in Software Defined Radio (SDR) for a while, and after tinkering with an RTL-SDR</a> for a while decided to get something with a larger tuning range and transmit capability. Although I was originally planning to buy a HackRF One</a> because of the well-established community around it, I ended up going with the Analog Devices ADALM-PLUTO</a> as I was able to get it for significantly cheaper (approximately NZ$100 including shipping - the HackRF is easily NZ$500+). My plan is to work through Michael Ossman's SDR with HackRF</a>, which uses GNU Radio</a>. The Analog Devices Wiki</a> recommends using PyBOMBS, but that doesn't seem to be working on Ubuntu 18.04 and their alternative, building from source, is something I try to avoid if possible because I almost always make a mistake somewhere. If anyone else is in a similar situation, the myriadrf ppa</a> has all of the packages you need. Since I was also looking to use Gqrx</a>, the commands below include that as well. Add the repositories to the package manager: $ sudo add-apt-repository ppa:myriadrf/drivers $ sudo add-apt-repository ppa:myriadrf/gnuradio $ sudo add-apt-repository ppa:gqrx/gqrx-sdr # Leave out if you don't want Gqrx. $ sudo apt update </code></pre> Then you just need to install GNU Radio, the gr-iio drivers and gqrx. $ sudo apt install gnuradio gr-iio gqrx-sdr </code></pre> Faster sampling over USB</h2> I found a page on the Wiki that compares throughput</a> between the USB and network backends (since the Pluto uses RNDIS to provide a virtual ethernet link). Playing around with a simple GNU Radio FM receiver seemed to give similar results as those on the Wiki, as I was able to push the sample rate to 5.25 MHz over USB without buffer underruns, compared with around 4 MHz over the network interface. I'm sure there's a standard Linux tool to find it, but I used iio_info from the iio_utils package. That gave me a URI in the form of [usb:x.x.x]</code>, which replaced pluto.local</code> in the Device URI field of the PlutoSDR block. Update (21 August 2018) to add performance improvement. Posting from multiple computers 2018-03-05T00:00:00+00:00 One of the issues with my current Jekyll</a>/NearlyFreeSpeech.NET</a> setup is that I haven't been able to post if I'm not working on my laptop which has the only copy of the site's git repository. That's not been a problem previously, but lately I've been working from my desktop a bit more and have a project on that machine that I'd like to write up. My goal with this little tweak was to migrate the repository to a server, though setting this up has been more useful than I expected. Git calls a repository that doesn't have a local copy of the code a 'bare' repository, and to make one you just have to run git init --bare site.git</code> on the server. I was wondering why all of the information I could find included the .git extension - it turns out that it's a convention</a> for identifying bare repositories. To migrate this to a server, I used commands I found in the answers to this StackOverflow question</a>: # I already had an 'origin' remote, so I had to remove it first: $ git remote remove origin # Begin tracking the new bare repository $ git remote add origin ssh://server/path/to/site.git/ # Push the master branch of the local repository to the server $ git push origin master </code></pre> Goal achieved! Running git clone ssh://server/path/to/site.git/</code> on my desktop worked as intended. Automating deployment</h2> However, while I was looking up how to do this, I found a few posts about automating deployment of Jekyll sites on NFSN using git hooks. My original plan was to use this method</a> by Bart Lantz, updating it with Jesse Squires</a>' more recent post. However, I ended up taking a slightly different approach as I didn't need to install or update Jekyll (as it's already present on NFSN), and cloning/deleting the repository each time caused Directory not empty</code> errors, even when using rm -rf</code>. My solution to this was to use a 'normal' git repository with a working tree, which I could then build from. Although pushing to a non-bare repository isn't recommended</a>, git has an option</a> for repositories where the working tree needs to be present on the server. The only caveat is that the server's working tree has to be kept clean - if you use the server to work on the site, you have to commit all of your changes, then pull them down to the local machine. Since I don't work on the server at all, this was perfect for my situation. Create a new repository in /home/private/git/site/</code> and run git config --local receive.denyCurrentBranch updateInstead</code> - this allows the server to be updated as long as its working tree is clean.</li> Set the local repository's origin</code> to the server address and push it to the server (as outlined above)</li> Create a bash script called post-receive</code> in /home/private/git/site/.git/hooks/</code>:</li> </ul> #!/bin/bash # set up variables REPO_PATH=$HOME/git/site PUBLIC_WWW=/home/public # build the site, putting it in the PUBLIC_WWW directory jekyll build --source $REPO_PATH --destination $PUBLIC_WWW exit </code></pre> Make the script executable:</li> </ul> $ chmod ug+x /home/private/git/site/.git/hooks/post-receive </code></pre> This script will then run every time the server's repository is updated via git push</code>, building the site directly into the /home/public</code> directory. No need to build the site locally and rsync</code> to the server! Building a Bus Pirate 2017-04-17T00:00:00+00:00 Back at the end of January, I entered one of the Dangerous Prototypes</a> free PCB giveaways, and was lucky enough to win a code. I've thought about getting a Bus Pirate</a> for flashing microcontrollers etc., and building one seemed like a good project that would net me something useful at the end. So, here's the two-month-long saga of how I ended up with two Bus Pirates. Obviously, the PCB needed components so while I was waiting for it to arrive from China, I put in an order with Digikey</a> for the parts along with a few extras to get to the AU$60 free shipping point. This took far longer than I thought - while I've ordered components before, this was a bit more of a learning experience. For example, I knew that the same part often comes in different packages, but I didn't know that there are often multiple variations of the same package. I also found out that ceramic capacitors have a huge number of possible dielectrics which all have different tolerances over different temperature ranges. Once the board arrived, I got to soldering. This was the first time I'd done 0603</a> (1.6 × 0.8 mm metric) and SSOP</a> packages, but with a lot of flux and some desoldering braid things went ok. Well, until I tried the surface-mount micro-USB connector. The first connector was the victim of too much solder, as it flowed into the socket and made it almost impossible for the jack to get in. After getting some replacement sockets, I tried again, but another failed attempts ended with me destroying the footprint: It was around this time that I decided to see if it was worth salvaging the damaged board, given all of the 'work' I'd done on the USB connector. Getting the firmware onto the PIC microcontroller that's at the heart of the Bus Pirate requires a programmer, but having only done a little bit of work with AVR chips before, I don't have a PICkit and didn't want to buy one just for this project. Before ordering the parts, I'd seen a solution on the Dangerous Prototypes forums</a> that used an ATmega and some Windows software (which was later updated</a>), but couldn't get it to talk to the ATmega. Given may failure to solder the USB jack and flash the firmware, I mentally scrapped the project and bought a Bus Pirate v3.6 from a Polish seller on eBay. The story should probably have stopped here - after all, I had a working Bus Pirate now - but of course, I couldn't resist trying to flash the Bus Pirate I'd been building, just to see if it worked. This was super-simple, as I just hooked up the two Pirates together and used picprog</a> to flash the combined bootloader/flash image. Since this went perfectly, it seemed a good bet that everything apart from the USB connection was working, so I set about trying to repair this. For my first attempt I tried scraping off the soldermask and attaching thin copper wire to the 'new' pads, but this left em with the same problem I'd had with the USB socket. However, in trying this I did (finally!) realise that the socket wasn't really necessary since its purpose was to provide a connection to the computer. Drawing from the massive supply of A-to-B cables I had lying around, I soon had a donor cable ready to go, and after carefully scraping away more soldermask was able to attach the wires to the PCB. Despite all of the abuse I dished out and the less-than-perfect soldering job, the LEDs lit up and when I connected to it, the self-test passed. The next step was to add insulation and strain relief using some Sugru</a> that I'd had in the fridge for a few years. I didn't think it'd still be any good, but it moulded well and cured properly, making a strong connection for the cable and a neat way to lift it a bit off the desk. So now the only thing I have to work out is what on Earth I can use two Bus Pirates for. Using Python to read weather forecast data 2016-04-15T00:00:00+00:00 When the Raspberry Pi Zero</a> came out last year, my love of small computers meant that I quickly purchased one along with a Scroll pHAT</a> despite not having a project in mind. Recently, I realised that the small size and low power requirements meant that it'd be great for displaying the day's weather forecast. The first task was getting the forecast data. For most countries the most accurate information is likely to come from government-funded weather services, which meant that my choice was the Bureau of Meteorology</a>. Their Weather Data Services</a> page shows the huge amount of data they have available, but since my display was a 5 x 11 LED matrix and I'm in a capital city, the 'précis' forecasts seemed like a good fit. If you're elsewhere in Australia, the BoM has 7-day forecasts</a> available in XML format. Since the data</a> I'd picked was in plain text format, it was pretty easy to write a script to process it: #! /usr/bin/env python from ftplib import FTP from datetime import datetime # Create a list for the forecast, and a simple function that appends lines to that list. forecast = [] def add_lines(next_line): forecast.append(next_line) ftp = FTP('ftp2.bom.gov.au') # Create FTP object ftp.login() # Log in (anonymously) to the FTP server line = ftp.retrlines("RETR anon/gen/fwo/IDA00100.dat", callback = add_lines) # Read each line of the file using the add_lines function ftp.quit() # Quit the server # Change the number in the square brackets below to choose the capital city: # 1 = Sydney 2 = Melbourne 3 = Brisbane 4 = Perth # 5 = Hobart 6 = Canberra 7 = Darwin forecast = forecast[4].split('#') # Isolate the line containing the city, and split it into fields. forecastdate = datetime.strptime(forecast[5], '%Y%m%d%H%M%S').strftime('%d %b') # Convert 14-digit date/time to date/month string. </code></pre> To display the forecast on the pHAT, I used code from one of the examples</a> in the GitHub library</a>, and added it to the end of the script: # Additional libraries needed for the pHAT import sys import scrollphat import time scrollphat.set_brightness(5) # Chosen by die roll scrollphat.set_rotate(True) # My Pi Zero sits upside down (ports facing up) scrollphat.write_string(forecastdate + ": " + forecast[6] + ". " + forecast[7] + " ") # Write forecast string to the pHAT while True: try: scrollphat.scroll() # Scroll 1 pixel every 0.1 s time.sleep(0.1) except KeyboardInterrupt: # Clear the screen if CTRL+C is pressed scrollphat.clear() sys.exit(-1) </code></pre> I think a diffuser in front of the LEDs would aid readability, but currently it looks like this when in action (you can click on the image for an animated GIF of today's forecast): </a> Although the script works, having to login to the Pi to run and quit the script means it's not likely to get used much as it's probably easier just to go to the BoM website. This should be fairly easy to alter as the pHAT communicates with the Pi over I2C, meaning there are plenty of GPIO pins left to add a button. This would make it much more practical as you could push the button and have the script start, scroll the forecast a few times, and then turn the LEDs off. It seems like a simple improvement, though the main obstacle is likely to be accessing the spare GPIO pins on the Pi, as the female header on the Scroll pHAT occupies all of them. I think this addition will be a desoldering/rewiring task for some future free time. Dynamic DNS using the NearlyFreeSpeech.NET API (take two) 2016-04-13T00:00:00+00:00 A few years ago, I hacked together</a> a way to updating my DNS record when my home IP changed. The script I wrote has generally been working ok, though recently I started seeing a few more errors than usual. Rather than debug them, I decided to rewrite the script using the more up-to-date python-nfsn</a> and Requests</a> libraries. Both libraries are available via pip, so getting them is super-easy: pip install python-nfsn requests # sudo was required for my particular setup </code></pre> The two new libraries make the script a bit easier to read, particularly the line that gets the current external IP. I've switched to using ipify</a> to do this, which means a regular expression isn't needed anymore. #!/usr/bin/env python from nfsn import Nfsn import requests from time import strftime, localtime user = "user" # Your NFSN username (not the one used to ssh into your site) key = "api_key" # API key (generate one from the Profile tab in the NFSN member interface: click "Actions", then "Manage API Key") domain = "example.com" # Your NFS-hosted domain subdomain = "subdomain" # The subdomain you're setting up for dynamic DNS nfsn = Nfsn(user, key) # Create the NFSN API object currentip = requests.get('http://api.ipify.org').text listedip = nfsn.dns(domain).listRRs(subdomain)[0]['data'] logtime = strftime("%Y-%m-%d %H%M", localtime()) if currentip != listedip: # Check to see if we need to update the record; if so: nfsn.dns(domain).removeRR(subdomain, 'A', listedip) # a) remove the old entry, nfsn.dns(domain).addRR(subdomain, 'A', currentip) # b) add a new entry with the new IP print (logtime + " DNS record updated from " + listedip + " to " + currentip) else: print (logtime + " No update required.") </code></pre> After making the script executable and setting it to run every few hours using cron, the script seems to be running well - hopefully it works for someone else out there too. Update (30 December 2021): A support request is no longer required for generating an NFSN API key. Thanks to Lewis from penwatch.net</a> for emailing to let me know. Exploring sampling error 2015-11-20T00:00:00+00:00 I've been teaching for nearly a full year now, and to say it's been a massive learning curve would be just a bit of an understatement. As is probably pretty normal for a graduate, some of my ideas have worked well, some have been ok and others have fallen completely flat. I figured I might share one of the ideas that worked well, particularly since it took two attempts to get it working. Since my Year 11 class is into the last section of Unit 2 of the new curriculum, we've been studying mechanical waves. A simple experiment is to measure the speed of sound in air, since it doesn't need much equipment or space. In years past the standard was to use a starting pistol as they produce a nice puff of smoke to use as the cue to start timing. Since we didn't have a starting pistol (they've been banned for a few years for safety reasons), my first attempt involved exaggerated clapping motions. Coupled with rain, student enthusiasm for this experiment hit a new low and we abandoned the attempt with pretty much nothing gained. A couple of weeks later, I gave the experiment another shot, this time with the school's starting pistol replacement - two pieces of wood, hinged at one end to make a clapper. Combining this with the lab technician's trick of using talcum powder on one of the pieces of wood to give a visual cue to replace the smoke gave us a much better starting point for the experiment. I had five students take stopwatches to the end of the 100 m track, and they all attempted to record the time between seeing the powder and hearing the sound. After a few trials, students suggested we try a larger distance to improve accuracy; unfortunately we only managed 111 m thanks to the school's small oval. Once all was said and done we had 42 measurements. We ended up getting an average of 348 ms^{-1, which is very close to the theoretical value of 343 ms^{-1 (based on the day's temperature from the}}Bureau of Meteorology</a>). The best part of the experiment for me though, was showing the students just how close we got to the calculated value using stopwatches and human reflexes. Despite the big range in speeds (from 119 ms^{-1 to 667 ms^{-1), the number of measurements we took overcame the significant sampling error.}} The main reason I liked this end result is because it shows the students something they've learned by rote since primary school: repeating experiments makes them more reliable. Although most students know this enough to repeat it - frequently - in assessments, it's actually pretty rare to have an experiment that shows this in action. Most motion experiments, for example, vary from predicted values simply because high school physics doesn't take into account significant factors such as friction and air resistance. Compared to these issues, measurement error is usually pretty small. Having a simple experiment where students can compare their results with a theoretical value and not have to account for a significant difference between them is, I think, a great teaching tool. In case you're interested in taking a look at the actual results and/or using them for your own class, they can be downloaded as a CSV file</a>. It's only the time and distance data, but could perhaps work well as an investigation where students need to process and interpret secondhand data. Replacing Google Reader 2014-11-08T00:00:00+00:00 For years prior to its demise last year, I used Google Reader</a> as an RSS aggregator - never really using the Reader web app itself, but instead using it to sync between my laptop (using NetNewsWire</a>) and phone (using Reeder</a>). It was a nice system that worked well, right up until the point that it was shut down. I've always intended to switch to one of the alternatives that sprang up (The Old Reader</a>, Feedly</a>, InoReader</a> etc.), but never quite got around to it. This meant that my RSS reading was done on my laptop, which in turn meant that if I didn't use it for a few days I'd come back to hundreds of missed articles. I could have probably avoided this with some judicious unsubscribing, but again - never quite got around to it. I'm not sure where I first heard about it, but about a month ago I heard about Tiny Tiny RSS</a>, a free RSS reader that's written in PHP. Once you've installed it on a web server, it's just a matter of logging in (multiple accounts are supported) and importing your feeds. Since getting a server up and running and then installing TT-RSS was going to be vastly more complex than simply creating an account on of the many sites above, it appealed to me straight away. I originally hosted it here at NearlyFreeSpeech.NET</a>, but the performance wasn't great (my fault, not theirs). After a day or so, I stumbled on Red Hat's OpenShift</a> and decided that their free tier would be perfect for this experiment. Originally, this post was supposed to be a container for all the tips I picked up - small things like getting the git repositories set up correctly, sorting out feed updates etc. It took a bit of wrangling, but after a little while I had a mostly working setup with just a few small issues. For example, every time the server restarted, the update daemon would also need restarting as I hadn't yet made that automatic and because OpenShift doesn't allow the PostgreSQL autovacuum</code> command to run correctly, the database tended to grow pretty quickly. It was while I was working out how to fix these things that I found this GitHub repository</a> which sorts out all of these little quirks. As a result, here's a much shorter guide to setting up your own RSS reader: Create an OpenShift account</a>.</li> Install the OpenShift client tools</a></li> Follow disconn3ct's great README</a></li> </ol> Once the last step has finished you should be ready to login, create an account and start importing and/or subscribing to feeds. Easy! My top three games 2014-09-06T00:00:00+00:00 A few months ago, a friend sent the following email around to a few people: Didn't know it was on, but put my vote in for ABCs good game top 100 games of all time. I challenge you to pick a better 3 than: X-COM: Enemy Unknown (2012)</li> Planescape Torment</li> Minecraft</li> </ul> </blockquote> This seemed to kick something off, with people offering their three favourite games along with really interesting reasons for their picks. I decided to pitch in too, so here are my top three games and the reasons I picked them. Total Annihilation</h2> This game defined high school for me. It did stuff that no other strategy game had ever even thought of and was so far ahead of its time that games now are only just starting to catch up. Some of the things I'm talking about: Choosing battle location. Want to fight in a forest? Be prepared for poor lines of sight and damage from the almost certain bushfire.</li> Holding higher ground. I don't think there have been many games (SupCom and PA are the only ones I can think of) that implemented this in the same way. High ground really mattered - troops trying to take hills can't see what's on top before they get there and hilarity (as well as a massacre) ensued if you put walls just behind the crest.</li> Wreckage. The result of an average-sized battle often meant that area was completely impassable for ground troops until cleared.</li> Ongoing support that added features (and units!) as well as fixing bugs.</li> The +sing option</li> Amazing storyline that really set the scene and tone.</li> </ul> Ok, perhaps that last one is a bit of a lie. 'What started as a battle over the transfer of consciousness from flesh to machines...' is not one of the greatest lines written for computer games. Portal</h2> While in my opinion Portal 2 was the superior game with better visuals, sound and plot, the first game had more of an impact on me. Aside from the whole first-person puzzle aspect (which was completely amazing), Portal stands out as the point that single player games went from being 'for gamers' (i.e. epic stories that required investments of hours to play) to something that everyone could consume as entertainment. The writing was engrossing, immersive, and for the first time I can remember as an adult, genuinely funny. It's true that games often used humour before Portal but its release at a time when games were pushing for gritty realism (e.g. the Call of Duty and Battlefield series) really set it apart. Frozen Synapse</h2> I was the last of my friends to pick this game up and will likely be the last to put it down, barring the possibility that when I die someone decides to host a memorial tournament. The most common phrase to describe it is 'chess with guns', but for me 'brain crack' would probably be more accurate. There certainly wasn't any game previously (and I kind of hope there isn't one in the future) that has grabbed me in the same way FS did - I've played over 500 games, put in countless hours (the 140 hours logged on Steam pales in comparison to the number played off-Steam) and peaked in the top ten. There are very few things for me that come close to the feeling of priming a turn and seeing a ballet of death</a> (watch the whole thing) unfold because you managed to predict your opponent's plan so perfectly. Honourable mentions (yep, way past three)</h2> Mario Kart DS: semi-regular beer and MKDS sessions are one of my fondest uni memories. The release of Mario Kart 8 had me seriously thinking about buying a Wii U just for reliving this.</li> League of Legends: another uni memory, with a regular group of us meeting up online and playing a few games. Had people not got real jobs, I think there's reasonable odds we'd still be sitting down from 8:30 most nights.</li> TF2: because this game cemented Valve as one of my favourite games companies. It's still being updated; not many games can boast that.</li> Johann Sebastian Joust: made me realise just how much fun local multiplayer is.</li> Spaceteam: if you haven't played this yet, you should (and you don't have any excuse because it's free). Similar to Joust, it emphasises why local multiplayer is awesome.</li> XCOM: Enemy Unknown: I'm rubbish at completing games. I played this through to the end and would still be playing were it not for the crippling bugs that made the final mission unplayable for me.</li> Left 4 Dead 2: the best part about this was that it generated the same kinds of awesome stories and in-jokes that tabletop RPGs do (one friend shooting another while he was carrying the last petrol can we needed to complete the mission, simultaneously downing him and setting us all on fire).</li> </ul> Playing with a NavSpark and R 2014-05-26T00:00:00+00:00 Back in January I managed to get in early on the Indiegogo campaign</a> for the NavSpark GNSS receiver. For no real reason other than the fact that it was US$17 including shipping, I decided to buy one of the NavSpark-BD boards. Besides being an Arduino-compatible board with built-in GPS, this version is also able to pick up satellites from the Chinese Beidou</a> constellation. While the modified Arduino client isn't available for OS X (according to the FAQ</a>, the LEON3 chip in the NavSpark doesn't have an OS X cross-compiler available), I decided to have a look at some of the GPS data just to see what I could pick up. This StackExchange answer</a> has been really useful for connecting to serial devices over USB, and the NavSpark uses the PL2303 chip which has an open-source driver</a> available for OS X. After installing the driver, I found the NavSpark port using ls /dev/tty.*</code>. Since the default baud rate is 115200, screen /dev/tty.NoZAP-PL2303-000012FD 115200</code> started showing the GPS data from the Navspark in NMEA format. There are plenty of places that this format's described, but the NavSpark resources page</a> has an easy-to-read PDF</a>. Using the lines starting with $--GSV and $--GSA, I decided to see if I could plot where the satellites were using R</a>. After the board had been running for a while I got the following lines: $GNGSA,A,3,05,07,10,28,26,08,,,,,,,2.7,1.6,2.1*28 $GNGSA,A,3,207,,,,,,,,,,,,2.7,1.6,2.1*18 $GPGSV,4,1,13,30,72,208,33,10,70,316,19,08,70,194,35,07,51,149,30*71 $GPGSV,4,2,13,28,42,006,21,05,36,230,21,13,33,095,12,26,15,240,26*79 $GPGSV,4,3,13,02,14,289,,04,09,326,,03,07,120,,23,06,075,*70 $GPGSV,4,4,13,19,02,105,*45 $BDGSV,2,1,08,209,73,292,,207,71,222,30,210,57,265,,206,55,004,*67 $BDGSV,2,2,08,203,52,348,,201,46,040,,208,02,016,,213,00,272,27*61 </code></pre> The third number in each GSV line indicates that there were 13 GPS (GP) and 8 Beidou (BD) satellites visible - not bad considering there were three layers of concrete between the antenna and the sky when I was testing this! As I was just working with the above data, I entered the satellite elevation and azimuth data by hand this time around: azimuth <- c(208, 316, 194, 149, 6, 230, 95, 240, 289, 326, 120, 75) azimuth.bd <- c(292, 222, 265, 4, 348, 40, 16, 272) elevation <- c(72, 70, 70, 51, 42, 36, 33, 15, 14, 9, 7, 6) elevation.bd <- c(73, 71, 57, 55, 52, 46, 2, 0) </code></pre> After I'd grabbed this data, I used polar.plot()</a> from the plotrix</a> package to visualise the position of the satellites (this satellite location data is from 2014-05-24 at 13:33:59 UTC). I made up two additional vectors (used and used.bd) that contained the numeric values corresponding to open and closed circles. Since these were entered in the order that I'd entered the azimuth and elevation data, they could be passed to the point.symbols argument to show which satellites were being used to give a fix. polar.plot(90 - elevation, azimuth, rp.type = "s", radial.lim = c(0, 90, seq(0, 90, 15)), start = 90, clockwise = TRUE, show.grid.labels = FALSE, labels = compass, label.pos = seq(0, 337.5, 22.5), point.symbols = used) radial.plot(90 - elevation.bd, azimuth.bd, rp.type = "s", radial.lim = c(0, 90, seq(0, 90, 15)), start = 90, clockwise = TRUE, add = TRUE, point.symbols = used.bd, point.col = "red") </code></pre> The end result was this (Beidou satellites in red, GPS in black): I'm quite pleased with this for something that came out of my first evening of hacking in quite a long time. With a better set of functions to process the NMEA data coming from the NavSpark, it should be possible to see how the satellites move over time, much as has been done in this post</a> by Gergely Imreh</a>. I'm hoping to try something like this in the future - perhaps it can be a project for the next long weekend. Building a quadcopter 2014-01-25T00:00:00+00:00 One of my Christmas gifts, both from others and myself, was equipment for a quadcopter. I ended up choosing the popular Flamewheel F450 kit from DJI, mostly because their parts are available locally and I anticipated (correctly, it turns out) a few crashes as I was learning to fly something bigger than my Crazyflie</a>. In the end, the complete list of things I needed to get flying: DJI Flamewheel F450 kit</a> with motors, ESCs and NAZA-M Lite flight controller</li> Futaba T8J transmitter</a> (including a receiver)</li> Turnigy nano-tech LiPo batteries (2 x 2650 mAh</a>, 1 x 4000 mAh</a>) & LiFePO4 transmitter battery</a>.</li> Accucel-6 battery charger</a> & 12 V power supply</li> Various plugs, connectors and wires (including many I didn't need in the end)</li> </ul> The kit was easy to put together but still took me about a day to finish. The main time sink turned out to be changing over the battery connectors - my little soldering iron struggled a fair bit with the huge 12- and 10-gauge discharge leads. I was really happy with the final result and with the help of a video</a>, setting up the flight controller was super-easy. After a successful maiden flight, I borrowed an old GoPro HD and tried filming from the air. This worked pretty well apart from a bit of vibration in the videos which turned out to be because I hadn't tightened the prop nuts sufficiently. This came to light when one of the props came off 20 m above an oval and it took another similar crash for me to hit on the obvious solution: nylon locking nuts. The nyloc nuts have been great and the damage from both crashes (a crack in the bottom plate and broken prop) was easily fixed. My next move was to add some navigation lights in the form of white</a> and red</a> LED strips. These are all wired in a continuous strip and can be switched on and off from the transmitter with a PicoSwitch</a> attached to channel eight of the receiver. I was originally planning to get a new-model GoPro for recording video but after some research found the Mobius ActionCam</a>. It's made by the same people that make the common 808 keychain cameras</a> and has become popular with RC flyers due to its balance of cost (US$70 shipped), weight (40 g) and quality. I did have the Mobius mounted under the base plate using these</a> 3D-printed leg extensions, but I'll need to reprint them and pay a bit more attention to the amount and pattern of the fill as a couple of hard landings this morning caused them all to break in the same place. The pictures below are taken from some videos I've recorded - click through for full-size versions. </a> This was taken during a twilight flight while I was still testing the camera and attaching it to the battery with an elastic band. The automatic white balance had a fair bit of issue with the contrast between the dark ground and sky, though the camera can be configured</a> with a fixed white balance setting which should improve it. </a> Mounting underneath with Velcro means the props aren't right in the centre of the frame. There's a bit of vibration apparent in the video, but hopefully I can fix this by balancing the props and adding a bit more cushioning. One thing I added to my setup was the ability to activate the flight controller's failsafe using one of the transmitter switches rather than having to switch off the transmitter. While there were a couple of videos on setting this up, all of them seemed to only work if the flight mode switch was in a specific location - not ideal for an emergency situation. To get around this, I used an offset mix on the flight mode channel (channel seven in my case) which shifted that channel by 50 units when triggered. Checking this with the DJI software indicated that it worked regardless of flight mode, and a field test was also successful. If you're looking for something similar, the steps I used were: Set up a programmable mix, with the master as 'OFS' (offset) and the channel you're using to change flight mode as the slave</li> Assign a switch and position - I used switch G in the down position</li> Check that the mix is enabled (i.e. not set to 'INH', which I only found out stands for 'inhibit' a little while ago)</li> Set the rate to around -50%. It's a good idea to have the Naza hooked up to the DJI Assistant software while you're doing this. Check that the failsafe switch works regardless of flight mode and if it does, you're good to go!</li> </ol> Bluetooth and VirtualBox on an OS X host 2013-11-12T00:00:00+00:00 I've recently been playing around with the Crazyflie</a> nano quadcopter, using the Ubuntu-based Bitcraze VM</a> to run the radio and Python client. I've been using a PS3 controller attached via USB, but recently decided to connect via Bluetooth so I didn't have to be tethered to my laptop while flying. Unfortunately, simply turning off Bluetooth in OS X doesn't allow the guest machine to take control of the Bluetooth adapter. Fortunately, this post</a> gives the commands for unloading the Bluetooth daemon and kernel extensions which in turn allows the guest operating system to use the Bluetooth device. The only hiccup I found was with the last command - in Mountain Lion, the kextunload -b com.apple.iokit.BroadcomBluetoothHCIControllerUSBTransport</code> command didn't work. Stealing the kextstat| grep -i bluet</code> command from the next post</a> down showed up the following extensions: com.apple.iokit.IOBluetoothFamily com.apple.iokit.IOBluetoothSerialManager com.apple.iokit.IOBluetoothHostControllerUSBTransport com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport </code></pre> Considering how close the last line was to the one in the post, I took a guess and it worked! So, to enable Bluetooth on a guest OS with a Mountain Lion or Mavericks host (I've since upgraded, but the commands still work), you need to run: $ sudo launchctl unload /System/Library/LaunchDaemons/com.apple.blued.plist $ sudo kextunload -b com.apple.iokit.IOBluetoothSerialManager $ sudo kextunload -b com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport </code></pre> And then to re-enable Bluetooth within OS X: $ sudo launchctl load /System/Library/LaunchDaemons/com.apple.blued.plist $ sudo kextload -b com.apple.iokit.IOBluetoothSerialManager $ sudo kextload -b com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport </code></pre> Melatonin in Australia 2013-08-18T00:00:00+00:00 A few months ago, one of my co-workers set off on a much-anticipated travel adventure. Like most trips out of Australia, there was a long flight involved (this one was to the US, so longer than most), and with that, jetlag. There are probably thousands of products that claim to help prevent or relieve jetlag, but one that's become quite popular is melatonin. Melatonin</a> is a hormone that has gained favour with travellers due to the key role it plays in circadian rhythms - melatonin production tends to increase during the evening, peak during the night before falling as morning comes. The theory goes that melatonin in tablet form will perform the same role as endogenous (natural) melatonin, helping you to sleep and therefore set your body clock to the new timezone more quickly. A review</a> of studies that tested the use of melatonin for jet lag supports the idea that it may be helpful if taken around bedtime once at the destination for a few days. The only catch is that unlike in the States, melatonin listed under Schedule 4</a> in Australia, meaning it's a prescription-only medicine. Which makes it seem a bit odd that you can find something like this</a> on the shelves of your pharmacy or supermarket: It turns out that at least one vitamin manufacturer produces homeopathic melatonin tablets that are allowed to be sold in Australia. Homeopathic remedies are a bit odd like this - although they don't contain a detectable amount of melatonin, you're still allowed to include the name on the label. In the case of this supplement, the homeopathic strength is listed as '6X', which means a dilution factor of one million</a>. Assuming an original dose of 3 mg (which this pharmacy</a> lists), this would mean that you'd need somewhere in the region of 166 000 tablets to get to even the lowest effective therapeutic dose (0.5 mg). Maybe I'm just a cynic, but my immediate thought is that the availability of homeopathic melatonin is linked to the wider availability of information via the internet. Melatonin is mentioned in just about every article when you search along the lines of 'avoiding jetlag' because it's available over-the-counter in the US. Even a couple of articles from Australian sources fail to mention the prescription-only status of melatonin here, so it's not too far-fetched that people would go looking for it on pharmacy shelves. I wouldn't say it's deceptive as there's the fairly obvious 'Homeopathic' logo on the bottle, but it's interesting to wonder how many have been sold on the back of an internet research session. WAHCKon highlights 2013-05-12T00:00:00+00:00 A few weeks ago I bought a ticket to the inaugural WAHCKon</a> which was held at ECU Joondalup over last weekend. It was a great event, with some interesting talks and a general 'good vibe' over both days. Mostly so I don't forget some of the cool things I heard about, I thought I'd quickly mention a few of the talks</a> that I particularly enjoyed. A Small Chain of Security Bugs Gone Astray</h2> Like most people, I've heard about cross-site scripting attacks before but never really understood how they worked or why they're a factor in so many site hacks. The underlying story was about a couple of bugs in the open-source portfolio system Mahara</a> which allowed an attacker to cascade from a simple piece of Javascript into full-blown shell access on the server. I also managed to have a chat with Hugh during a break - I'd be interested to hear some of the other talks he's given. Watering Hole Exploitation</h2> As with the first talk, this was a deeper look into how small vulnerabilities can cascade into serious issues for hacked targets. The focus of the talk was the idea of a 'watering hole' - a place that users located in the target organisation are likely to visit. If you're able to compromise or impersonate the watering hole, you can gain user-level access to an internal network and start elevating the access you have from that point. A lot of the methods used seemed similar to those that Mandiant</a> described in their report on the Chinese military's hacking group APT1</a>. The talk made me happy I don't have to look after any large networks as one small mistake by a non-admin user can lead to serious problems. ICANN & the DNS root</h2> I hadn't really been looking forward to this presentation - I know ICANN</a> is important to the functioning of the Internet, but it's never something I've looked into at all. The two parts of the talk I found most interesting were how many new top-level domains are about to be released and how the DNS root is able to withstand such heavy traffic (it turns out the key is anycast</a>). It's amazing that a not-for-profit that has so many different groups involved can make any decision, let alone ones that seem to work pretty well! Cyberwar and the Real World</h2> The Stuxnet</a> worm has perhaps been the most-publicised piece of malware in recent years, so I'd heard a fair bit about it before. Some of the in-depth information presented was really fascinating, particularly how precisely targeted the payload was. Even more interesting was the demonstration of how Stuxnet was targeted using a publicly-available picture</a> from the Iranian President's offical site that showed a number of the computers used to control the centrifuge cascade. WithIn the Groove: How To Be A Dick To Your Arcade</h2> One of my favourite presentations, mostly for the frequent use of #hashtagjokes and Gandalf. The talk itself discussed a method to trick the dancing game In The Groove 2</a> into running arbitary Lua code to give free credits. Although it's an arcade game, players are able to insert USB drives to store profile data and it's this that allows the attack - profile files can include Lua code. Although the game uses RSA to sign the profile files (so only signed profiles are trusted) and the private key is encrypted with AES-192, a flaw in the iButton DS1963S</a> used to calculate the AES key exposes the RSA key. Although it was only an attack on an arcade machine, it was a great demonstration of the fact that a single flaw in the implementation of cryptography can lead to a complete compromise. I also found a more technical overview of the attack by Ronald Huizer</a> who's also documented</a> a software attack on the DS1963S. The original fault attack on the dongle was presented by Christian Brandt and is also available online</a> if you speak German. Phreaking in a post copper world</h2> Before seeing this talk, I had no idea how big VoIP hacking was. It turns out that the cheap international telephony that the Internet has brought in has created more than a few options for those looking for a quick buck. Once you've got hold of someone's account credentials, you can use that to make calls at their cost. One option is to call premium phone lines that you control and profit from; those willing to play a long game have apparently set up calling card enterprises built entirely on hacked VoIP accounts. Hardware hacking and stretching the Parrot ARDrone platform to the limit</h2> At work, one of the ways we illustrate how quickly technology progresses is to show students an AR.Drone</a> - something that ten years ago would have been government technology is now available for a few hundred dollars at a nearby shop. As part of a final-year university project, these guys created the Intellidrone</a>. Using the original AR.Drone platform they added modifications for GPS, real-time telemetry and payload pick-up/drop-off along with a software package to control it all. This is definitely something I'll be looking to include in our presentations, though I might leave out the extended-capacity battery hacking. Another highlight along with these talks was the conference party and lockpicking contest on the Saturday night. Although I've been into lockpicking for a while, this was the first chance I've had to even meet other people that are into it in Perth let alone enter try a competition. I didn't perform that well in the end as the five-pin lock that was worth most of the points eluded me. It was great fun and as a bonus I even got to pick my first pair of handcuffs as part of the competition. For a first event the whole conference was amazing and I'll certainly be heading to the next one in 2014. Dynamic DNS with NearlyFreeSpeech.NET and Python 2012-10-27T00:00:00+00:00 Update (14 April 2016): I've since rewritten this script - you can find the new version in this post</a>. Since I got it, one of the things I've been looking to do with my Raspberry Pi</a> is to access it remotely. This is a pretty easy task - give the Pi a static IP and forward the appropriate port on the router. However, my ISP assigns a dynamic IP address and having to check what my IP is before being able to connect is tiresome. On top of that IP addresses aren't particularly memorable so assigning a domain or subdomain would make it much easier to use. If your ISP offers the option, the solution is as simple as requesting a static IP address and assigning the subdomain to that IP. Unfortunately my ISP only gives static addresses to business customers and the extra $30/month isn't really worth it just for the static address. Another option is to use a dynamic DNS service. They've been around for ages - I remember using one to run games of Total Annihilation over a 56k modem - but you have to either put up with the domain offered to you or pay a fee for their service. Since I already have DNS provided by NearlyFreeSpeech.NET</a> I wondered if I could set up some sort of dynamic DNS through them and promptly stumbled upon a post</a> by Joshua Arrington in which he did exactly that using the NFS.NET API</a> and a script written in PHP. Although the solution was a good one, there were a couple of things I wanted to change. Firstly, my site is static and switching it to a dynamic site just to implement one thing seemed a bit like overkill. I also preferred the idea of running the script from a machine on my network rather than having to secure a server-side script. Just to make things more difficult for myself, I wanted to avoid installing PHP and instead opted to port the script to Python as it's supported out-of-the-box on the Raspbian</a> OS. Making this much easier was the fact that the pynfsn</a> library implements the DNS part of the API. If you're interested in doing the same thing, these are the steps you need to follow: Install the pynfsn module:</li> </ul> $ git clone https://github.com/goncalopp/pynfsn.git $ cd pynfsn $ python setup.py install # you may need to run this using sudo </code></pre> Save the following Python script somewhere on the system you're using to update your DNS record. If you're planning to use cron</code> to run the script at a regular interval, it's a good idea to put it somewhere accessible to all users such as /usr/local/bin</code>. Don't forget to set the user, key, domain & subdomin variables for your particular setup.</li> </ul> #! /usr/bin/env python from pynfsn import pynfsn import re from urllib2 import urlopen from time import strftime, localtime user = "user" # your NFS username (not the one used to ssh into your site) key = "key" # API key (contact NFS for one) domain = "domain" # your NFS-hosted domain subdomain = "subdomain" # the subdomain you're setting up for dDNS ttl = 3600 # this is the default value (one hour) api = pynfsn.NFSN(user, key).dns(domain) currentip = re.findall(r"[0-9]+(?:\.[0-9]+){3}", urlopen('http://checkip.dyndns.org/').read())[0] listedip = api.listRRs(subdomain)[0]['data'].encode('ascii', 'ignore') logtime = strftime("%Y-%m-%d %H%M", localtime()) if currentip != listedip: # check to see if the ip has changed; if so: api.removeRR(subdomain, 'A', listedip) # a) remove the old entry, and api.addRR(subdomain, 'A', currentip, ttl) # b) add a new one print (logtime + " DNS record updated from " + listedip + " to " + currentip) else: print (logtime + " No update required.") </code></pre> The last step is to set up a cron</code> job for the script. To run the script I picked a user who didn't have sudo privileges just in case a mistake with the script made something go horribly wrong. Using sudo crontab -u <user> -e</code>, add a line to the end of the file that indicates how often you'd like to run the script. I found this chapter</a> of Running Linux</a> particularly useful and settled on the following line to run the script once every two hours, redirecting script output and errors to a log file.</li> </ul> 0 */2 * * * /usr/local/bin/nfsddns.py >> /var/log/nfsddns.log 2>&1 </code></pre> So far, this has been working well for me although the occasional 'Connection reset by peer' error shows up in the log file. I'm not entirely sure what's causing this; sometimes it happens twice in a row but the next four times the script runs fine. It's not a major problem as the script generally runs fine the next time and removing the comparison between the listed and current IPs should stop it completely. This is the first program I've written in Python, so if you do use it please be aware that there may be security or other issues that I haven't picked up. Please let me know if I've missed something obvious! Update (9 January 2015): Switched the order of the IP address variables in the output as they were back-to-front. Thanks to Paul for spotting it and letting me know</a>. Safari history tip 2012-10-24T00:00:00+00:00 I've been noticing for a while that pages that I click on in my Google search results don't show up in the history like I expect them to. Rather than showing the titles of the pages they display as Google URLs instead - not particularly useful if you want to retrace your steps. A quick search turned up this discussion</a> on Apple's support site where it's mentioned that this is a side-effect of Google's Instant feature. If you'd rather have history entries than the ability to see results as you type, you can select the "Never show Instant results" option on your Search Settings</a> page. Moving a League of Legends installation 2012-07-22T00:00:00+00:00 Over the weekend I replaced a few parts in my desktop. Since one of the parts I replaced was the motherboard, I also reinstalled Windows to avoid any driver issues. Every other time that I've reinstalled Windows, I've also downloaded and re-installed the League of Legends</a> client, reasoning that it didn't work after the reinstall because the client hadn't been installed correctly. Turns out that I was wrong and the smart people at Riot</a> don't use registry entries or anything like that. As long as you have Adobe Air</a> and DirectX 9</a> installed, you can simply run lol.launcher.exe</code> in the root LoL directory and everything should work as it did before. Images in Jekyll 2012-06-30T00:00:00+00:00 I like using Markdown</a> to write posts, but one of the problems I have with it is that the image syntax is a bit basic. For example, you can't give images a CSS class which is how I position both of the images I've currently got on the site. Using regular <img></code> tags works but isn't particularly neat. Fortunately, Brandon Mathis</a> (the designer of Octopress</a>) has written a plugin for Jekyll that adds a Liquid image tag. To add the plugin, simply add image_tag.rb</a> to your Jekyll _plugins</code> directory. The syntax (below) is straightforward; one thing I've picked up from the Octopress documentation</a> is that you only need to quote arguments that have spaces in them. {% img class /path/to/image.png width height 'title text' 'alt text' %} </code></pre> Update (28 January 2018): After six years of using this plugin, I've since moved a method that uses the standard Markdown image ![Alt text](link)</code> syntax. Credit to James Thorne</a> for writing it up Downloading podcasted videos with awk 2012-06-10T00:00:00+00:00 One of the workshops we run as part of our technology program gives students the chance to create a stop-motion animation using SAM Animation</a> and some modelling clay. Once they've finished taking the photographs, SAM exports a movie which is uploaded to our servers using the Podcast Capture utility. The workflow then adds the title and date to a splash screen at the start of the movie before publishing it to the Podcast Library wiki. I was pretty happy with how this all worked together (particularly given it was my first attempt at anything like it), but one thing was missing - an easy way to download the video files so students could have a copy of their movie. On the face of it, this should be pretty easy as Podcast Composer offers multiple options in the workflow for publishing the final file. Unfortunately permissions issues between the two computers processing the files plagued attempts to simply export the file into a shared folder. I'm sure someone that actually knew what they were doing with server administration would have been fine, but it was well beyond my knowledge. My first attempt to grab the files used Automator and worked pretty well apart from the fact that the videos were given the same 64-character filename as they had on the server ('export-plugin-quicktime-UUID</a>.m4v'). Having presenters manually rename the files at the end of every workshop wasn't really feasible, so I started looking for a way to rename the videos as they were downloaded. Given that the Podcast Library was able to play the videos, I figured that the HTML source must have links to the actual video files in it somewhere. Sure enough, this turned out to be the case - </code> tags similar to the one below are used to display the 'Play' button for each video. Handily, the tags also contained the title of the video as well as the path to the video itself. <span class="cc-token playbtn" style="min-width: 50px; text-align: center;" title="Rolling Ball" assetURL="https://server.local/podcastlibrary/document/uuid/7DF98AA3-CCEA-4158-84FA-BC4DEC04DCFF/export-plugin-quicktime-E43D860D-31BB-454F-83AD-B2ECFFED9E92.m4v"> </code></pre> I've used grep in the past and it seemed like a good starting point given that the tags contained a few unique identifiers such as the 'cc-token playbtn' CSS class. I'd also heard about awk, a programming language designed to work with text files. It seemed like a pretty good option, so I had a look at some</a> tutorials</a>. This didn't go particularly well because awk isn't really a command-line tool like grep, it's a full programming language. After a number of false starts over a few days, I got the following to work: curl "$@" | grep -o 'title=".*" assetURL=".*"' | awk 'BEGIN { FS ="\"" } ; { system("curl --insecure --create-dirs -o \"~/Desktop/Podcasted/" $2 ".m4v\" "$4) }' </code></pre> To make this easy for everyone to use, I made an application in Automater with the actions 'Get Current Webpage from Safari" and 'Run Shell Script'. The curl command downloads the HTML from the Safari page, after which the grep command pulls out the relevant lines from the HTML source and feeds them to awk. The awk command splits the lines up into fields every time it finds a double quotation mark, giving a total of four fields. The second and fourth field of each line are the title and url of the video respectively which are then used in a curl command to download the video. There are a couple of things I'd like to fix up but I was so happy that it worked at all, I haven't got around to them. Firstly, I'm pretty sure the grep command is unnecessary and the whole thing could be done with awk. The second is a situation where where this script is likely to fail: if two videos are submitted with the same name. This does happen in our workshops (particularly where the group is given a specific topic to create a video about), but I haven't figured out a solution yet. Although it started off pretty slowly and ended up a bit more hacky than I'd like, I'm happy with how this turned out. If nothing else, it gave me a chance to take a look at awk which will definitely be useful in the future. USB WiFi and sleeping - a quick fix 2012-05-21T00:00:00+00:00 Whenever my desktop machine running Windows 7 woke from sleep, the USB wireless adapter didn't seem to wake up with it. Disabling and re-enabling it in Device Manager got it working again, but I recently discovered a way to stop it happening at all. Under the adapter's properties in Device Manager, select the Power Management tab and make sure the option 'Allow the computer to turn off this device to save power' is turned off. Since I've changed the option I haven't seen the issue reappear so thought I'd share it here. Headphone repair for beginners 2012-04-30T00:00:00+00:00 I've had two pairs of headphones lying on my desk awaiting repair for ages and finally got around to doing something about them a few days ago. From the ashes of a pair of Koss KSC-75s that needed a new cable and some Sennheiser PX100s that needed a new jack was born this: I originally got the idea from this thread</a> on Head-Fi</a> where it's apparently a popular mod. The main reason I went for it is because it replaces the Koss earclips (which were just a bit too open to the outside) with a proper headphone band. I followed a similar procedure to one used in another Head-Fi thread</a>, though rather than drilling & screwing the 'ball' to the headphones I used superglue. Archives in Jekyll 2012-04-06T00:00:00+00:00 After setting up the RSS feed, the next thing I wanted to add to mitsake was a set of 'proper' archives by both date and tag rather than just the reverse chronological list of posts. Although this wasn't as straightforward as setting up RSS, a bit of searching turned up some sites that helped me get everything running. Tags</h2> Although there's built-in support for tags in Jekyll, there isn't an easy way to access them via Liquid. Fortunately, the Jekyll wiki</a> has links to a number of useful plugins</a> including Jose Gonzales' Generic Blog Plugins</a>. The one I'm using is iterator.rb</code>, which gives a new set of template data accessible from site.iterable.tags</code> (as well as site.iterable.categories</code> if you're using them instead). Once the plugin was installed, I used Liquid to access the tags along with their names and the posts filed under that tag. {% for tag in site.iterable.tags %} <h3>{{ tag.name }}</h3> <ul> {% for post in tag.posts %} <li><a href="{{ post.url }}">{{ post.title }}</a></li> <time>{{ post.date | date: "%e %B %Y" }}</time> {% endfor %} </ul> {% endfor %} </code></pre> Archiving by date</h2> Because a list of posts in reverse chronological order can be readily accessed in Jekyll through site.posts</code>, all that's needed is to use some clever Liquid markup to process it. I found a good example by Mike Rowe</a> he made to group his archives by year</a> which I adapted slightly to allow my archives to be broken down by month. {% for post in site.posts %} {% capture month %}{{ post.date | date: '%m%Y' }}{% endcapture %} {% capture nmonth %}{{ post.next.date | date: '%m%Y' }}{% endcapture %} {% if month != nmonth %} {% if forloop.index != 1 %}</ul>{% endif %} <h3>{{ post.date | date: '%B %Y' }}</h3><ul> {% endif %} <li><a href="{{ post.url }}">{{ post.title }}</a></li> <time>{{ post.date | date: "%e %B %Y" }}</time> {% endfor %} </code></pre> The above code uses the {% capture %}</code> tag to get the month and year of each post and the one that follows it before comparing them. If they're different, the month and year are inserted before a link to the post while if they're the same, the post is simply added to the list for that month. The only tricky bit I ran into was closing the <ul></code> tag at the end of each month's list. After checking out the Liquid documentation</a> my solution was to close the tag before each header, excluding the first by using forloop.index</code>. That's about it! Hopefully this is a useful reference for anyone that's looking to make their Jekyll archives a bit more accessible. Adding RSS to Jekyll 2012-03-11T00:00:00+00:00 Today I set about the task of adding a RSS feed to the site. I knew this was something that Jekyll supported as there's a Liquid tag for each post's unique identifier, but I didn't expect a Google search to deliver ready-to-use templates</a>. After customising the RSS template for my site, the only thing I had to do was add a <link></code> tag to the default layout. Many thanks to Dave Coyle at coyled.com</a> for making his Atom/RSS templates available and saving me a lot of time. Building mitsake 2012-02-25T00:00:00+00:00 To start off my posts here I thought I'd document the process I went through in setting up this site. If nothing else, it'll be handy for me to refer to if I need to jog my memory later on. I've been working on mitsake in some form for a few years but it's only now that anything has actually gone online. Procrastination is the main culprit, but I've also been trying to work out what to use to build the site. Over that time I've tried out Jekyll</a>, Nesta</a> and Octopress</a> and liked all of them in different ways. Despite this, I eventually decided to go back to Jekyll for a few reasons: Given the low-key plan I have for the site, static pages seemed a better fit than something running a dynamic CMS.</li> I like writing in HTML, CSS and Markdown and since I already know them, designing the site and writing posts didn't require me to learn anything else.</li> I wanted to be able to make a simple design for the site myself. While both Nesta and Octopress have great themes available, I found editing them more difficult than building one from scratch.</li> I've been interested in learning Ruby for a while. Since Jekyll's written in Ruby, extending it gives me a bit of practice.</li> </ul> Setting up Jekyll</h2> Update (16 August 2018): This modification has been obsolete for ages now - Jekyll includes this behaviour by default</a>. Rather than write yet another post on how to get started with Jekyll, I thought I'd just detail the few small things I've done differently. If you are interested in setting up and configuring Jekyll though, there's a tonne of articles and other information available in the Jekyll documentation</a>. So far I've only made one small addition to the default setup which is the introduction of a 'Read more →' button for longer posts on the home page. While it did require a plugin, I was fortunate enough to find code for something similar in a post</a> by Kjetil Valle. This is what I put into _plugins/preview.rb</code>: module Liquid module ExtendedFilters def preview(text, delimiter = '') text.split(delimiter)[0] end end Liquid::Template.register_filter(ExtendedFilters) end </code></pre> This is backed up by some Liquid markup in my site's index.html which looks for the HTML comment </code> in the posts that are listed on the home page. If it's there, the post is run through the preview filter and cut at the point the comment appears. {% if post.content contains '' %} {{ post.content | preview }} <p><a href="{{ post.url }}">Read more →</a></p> {% else %} {{ post.content }} {% endif %} </code></pre> NearlyFreeSpeech and deployment</h2> Like choosing Jekyll, it took me a while before I decided on NearlyFreeSpeech</a> as my host. Although both Heroku</a> and GitHub Pages</a> look like good free options for hosting Jekyll sites, I decided to go with NearlyFreeSpeech as it meant I could do domain registration, DNS and hosting all at the same place. I've also been able to learn a lot as their target market is people who don't mind getting hands-on with server administration. Most of the information I've needed has been covered in their extensive FAQ/documentation but since most of their setup uses standard Unix/Linux command-line tools, there's plenty of other places to look too. Since NearlyFreeSpeech offers SSH, deployment is easy. One option that seems common on is to host a remote Git repository with a post-recieve hook</a> that uses Jekyll to regenerate the site each time a commit is made. Although I'm planning to use this method in the future, for now I'm just using rsync over SSH. Although it's pretty straightforward, I found this page</a> on Simon Pascal Klein's blog quite useful. Design</h2> As with my plan for the site in general, I only had a few goals for the design. I obviously wanted it to be reasonably nice to look at but I also wanted the site to remain readable if someone were to read it without the stylesheet or with a device that doesn't use visual stylesheets such as a screen reader. Of course, for 99% of people this isn't an issue but I like the idea of keeping the web as accessible as possible. If you'd like to see what I'm getting at, you can check out the unstyled version</a> of this article. I think that's everything I've set up so far. I do have plans to add extra features such as an RSS feed but I'll probably document them as they're added. The first post 2012-02-19T00:00:00+00:00 As you might guess, this is the first post to my new website. Since this is the first post there's not much to it, but most things seem to be functional. If you're interested in the backend, I've built this site using the Jekyll</a> static site generator and hosted it using NearlyFreeSpeech</a>. The main reason I've made mitsake is to learn a little bit more about Ruby</a> and other things like SSH as I build and expand the site. I'm hoping to document how I've set everything up and the thought process behind the choices I've made in a later post. The only other functional pages so far are the about</a> and archive</a> pages. Please feel free have a look if you're looking for a little more content.

mitsake

Some things I've made

Setting up a small videoconferencing server

Moving mitsake to makesite.py

Playaway audiobook teardown

Automating Jekyll deployment, take two

Site changes

Unlocking the Siglent SDS1104X-E

Getting started with the Pluto SDR

Posting from multiple computers

Building a Bus Pirate

Using Python to read weather forecast data

Dynamic DNS using the NearlyFreeSpeech.NET API (take two)

Exploring sampling error

Replacing Google Reader

My top three games

Total Annihilation</h2> This game defined high school for me. It did stuff that no other strategy game had ever even thought of and was so far ahead of its time that games now are only just starting to catch up. Some of the things I'm talking about:</p>

Playing with a NavSpark and R

Building a quadcopter

Bluetooth and VirtualBox on an OS X host

Melatonin in Australia

WAHCKon highlights

Dynamic DNS with NearlyFreeSpeech.NET and Python

Safari history tip

Moving a League of Legends installation

Images in Jekyll

Downloading podcasted videos with awk

USB WiFi and sleeping - a quick fix

Headphone repair for beginners

Archives in Jekyll

Adding RSS to Jekyll

Building mitsake

The first post