Hidden London: Highgate wilderness walkabout

It's no secret that I'm a big fan of the London Underground. To be clear, I don't consider myself a true anorak as I can't tell you the exact diameter of the wheels on an S Stock Car or the top speed of a fully laden A stock train, but I have an appreciation of the infrastructure and history of the Underground.

Having attended Hidden London tours of Aldwych, Euston and riding the Metropolitan No. 1 steam locomotive between Watford and Chesham, I grabbed some tickets for the newly announced 'Hidden London: Highgate wilderness walkabout' tour as soon as they were released.

My wife and I attended the tour today and both left a little disappointed, primarily due to the cost of the event - £31.50 each. Perhaps we had misguided expectations, however in comparison to Euston and Aldwych (£36.50) and the steam train (£20.00) which were all all fantastic experiences, the pricing seems a little ambitious.

If you plan on going on the tour and don't want any spoilers, stop reading here! However if you're not planning on going or are now having second thoughts and want to know a little more about our experience, read on.

Discovering and updating a guests hostname from the GNS3 API.

In a previous post, I reinvented the wheel whilst trying to discover the hostname of the GNS3 API from within a guest. Once I'd wasted an evening reinventing DNS, it was time to move onto the main objective - allowing a guest to discover its GNS3 hostname from the API and update the relevant entries in /etc/hostname and /etc/hosts, so next time the puppet agent ran it would pull the appropriate configuration.

I've chosen to use Python as it's the language I'm most confident with. You can view the GNS3 API documentation here

This script was created for Debian and Ubuntu based hosts but will probably work for other distros with minimal tweaking. If you want to skip the blog post and view the code, it's on github

Requesting custom DHCP options with dhclient, or in my case, reinventing the wheel!

Occasionally I do stuff that's not amateur radio related. Today was one of those days.

I'm currently preparing a virtualised 'lab' to experiment with VoIP (Voice over IP), networking, and potentially some DMR network (radio) stuff in the future. I will be using GNS3, a program that was created to emulate networking devices but now also does a great job of emulating servers and their associated network topology.

Historically when using GNS3 I've configured each 'node' manually, however its 2017, dev-ops is hot, and manual configuration is not. Enter puppet, a configuration management tool that treats configuration more like code. You create a 'manifest' that contains instructions and templates on how to configure a device, and then an agent will then pull the configuration from the puppet master and apply the changes. Simple.

As far as I can tell (It's early days), puppet relies heavily on using hostnames to figure out which device needs which configuration. However, virtualised nodes within GNS3 are usually built from a template, and will share the same hostname when first configured. Additionally when a node is created, I don't know its MAC address, UUID, or any other identifier until its created. GNS3 will allow you to configure a hostname 'label' however this isn't communicated with the node out the box.

So, the plan? Create a script that will run on each node, query the GNS3 API and discover its own hostname, update it, and then puppet can do its thing and pull the correct configuration. BUT. How will the node know the IP that the API is running on?

I figured I could use DHCP options to send the IP of the API to the node, so it could then query the GNS3 API and grab it's hostname. I did the research and leg work, and then had an epiphany - what if someone had already invented a service that allows a device to find the IP address of a service... like... the Domain... Name... System. DNS.... Already invented.

For the sake of posterity, I've written up my findings below.

Flashing MMDVM on an STM32 Nucleo using OS X

As you may already know from a previous post, I've been experimenting with MMDVM (Multi Mode Digital Voice Modem), software that can be used to operate a DMR radio hotspot or repeater. Historically I've been using a DVMega hotspot 'shield' on a Raspberry Pi, however I'm now taking it up a notch and building a 'proof of concept' DMR repeater.

The MMDVM Modem is made up of several components-

• The interface board - Interfaces with the radios and performs the necessary filtering and amplification of the Tx and Rx Signals
• The Modem - an embedded microcontroller for doing the analog to digital and digital to analog conversion and sampling.
• The Host - usually a Raspberry Pi. Manages the modem and performs actions such as relaying DMR frames to the network.

The MMDVM software will run on several different platforms including the Arduino Due, the Teensy's, and the STM32 Nucleo. The DUE's are EoL, and the Teensy's are expensive, which left the STM32 as the logical option.

This guide is aimed at flashing the STM32 Nucleo board (STM32F446RE) for use with one of F0DEI's highly recommended MMDVM boards using MAC OS X. If you're using another MMDVM board, you may need to tweak the Config.h file accordingly.

I've not used an STM32 Nucleo before, so I had to do some research to figure out how to flash it. I've written up my findings below.

If you're using Windows I recommend F5UII's blog post here

The STM32 Nucleo

F0DEI's MMDVM Board

I tested this on 03/05/2020 and it worked as expected!

Making a DIY programming cable for the Tait 8105 Radios

I am currently building a project that utilises two Tait 8105 UHF radios. I needed to upgrade the firmware and configure the radios, but couldn't find a programming lead in the UK for sensible money. After a bit of research, I managed to build my own using a FTDI TTL-232RL USB adapter and a DB9 Breakout board.

Using UDEV rules to ensure a USB serial device always links to the same location in /dev/

If you're using several USB serial adapters on a linux machine, you may have found that their /dev/ names change after a reboot. This can be frustrating if each serial port is plugged into a specific device and you want to always access it using the same /dev/ name.

Fortunately, udev rules exist that allow you to symlink a serial device to a name, persistently. Udev rules are very powerful and support lots of tweaking, but for now I will cover the basics of assigning a USB serial device a static name.

More engineering trains at Moorgate

I regularly pass through Moorgate Tube Station on the way to and from work, and one of the disused platforms is often used for storing engineer trains and equipment.

Recently there was a collection of diggers and a bull dozer, all with tracks and wheels for using the rails-