Trail run: Barnes and ridgeline

A first attempt at running to Barnes and Brett trigs, this didn’t work out quite as well as I’d expected (I ran out of time before I’d hit Brett trig). The area wasn’t as steep as I’d expected, being mostly rolling grazing land with fire trails. Lots of gates and now facilities, but stunning views of southern Canberra from the ridgeline. 11.11km and 421m of vertical ascent.

Trail run: Pine Island South to Point Hut with a Hill

This one is probably a little bit less useful to others, as the loop includes a bit more of the suburb than is normal. That said, you could turn this into a suburb avoiding loop quite easily. A nice 11.88km run with a hill climb at the end. A total ascent of 119 metres. There isn’t much shade along the run, but there is some in patches. There are bathrooms at Point Hut and Pine Island.

Be careful of mountain bikers on this popular piece of single track. You’re allowed to run here, but some cyclists don’t leave much time to notice other track users.

Trail running guide: Tuggeranong

I’ve been running on trails more recently (I’m super bored with roads and bike paths), but running on trails makes load management harder — often I’m looking for a run of approximately XX length with no more than YY vertical ascent. So I was thinking, maybe I should just write the runs that I do down so that over time I create a menu of options for when I need them.

This page documents my Tuggeranong runs.

NameDistance (km)Vertical Ascent (m)NotesPosts
Cooleman Ridge9.78264Cooleman and Arawang Trigs. Not a lot of shade and no facilities.25 April 2019
Pine Island South to Point Hut with a Hill11.88119A nice Point Hut and Pine Island loop with a hill climb at the end. Toilets at Point Hut and Pine Island. Not a lot of shade. Beware of mountain bikes!21 February 2019
Barnes and ridgeline11.11421Not a lot of shade and no facilities, but stunning views of southern Canberra.2 May 2019
Lake Tuggeranong to Kambah Pool (return)14.11296Partial shade and great views, but beware the mountain bikes!11 May 2019
Tuggeranong Stone Wall loop668Partial shade and facilities at the Hyperdome and Pine Island.27 April 2019
The base of Urambi Hill10.21243Not much shade, more vertical ascent than it looks, but very pleasant.9 June 2019

Trail run: Cooleman Ridge

This run includes Cooleman and Arawang trig points. Not a lot of shade, but a pleasant run. 9.86km and 264m of vertical ascent.

Using a MCP4921 or MCP4922 as a SPI DAC for Audio on Raspberry Pi

I’ve been playing recently with using a MCP4921 as an audio DAC on a Raspberry Pi Zero W, although a MCP4922 would be equivalent (the ’22 is a two channel DAC, the ’21 is a single channel DAC). This post is my notes on where I got to before I decided that thing wasn’t going to work out for me.

My basic requirement was to be able to play sounds on a raspberry pi which already has two SPI buses in use. Thus, adding a SPI DAC seemed like a logical choice. The basic circuit looked like this:

MCP4921 SPI DAC circuit

Driving this circuit looked like this (noting that this code was a prototype and isn’t the best ever). The bit that took a while there was realising that the CS line needs to be toggled between 16 bit writes. Once that had been done (which meant moving to a different spidev call), things were on the up and up.

This was the point I realised that I was at a dead end. I can’t find a way to send the data to the DAC in a way which respects the timing of the audio file. Before I had to do small writes to get the CS line to toggle I could do things fast enough, but not afterwards. Perhaps there’s a DMA option instead, but I haven’t found one yet.

Instead, I think I’m going to go and try PWM based audio. If that doesn’t work, it will be a MAX219 i2c DAC for me!

1-Wire home automation tutorial from linux.conf.au 2019, part 2

For the actual on-the-day work, delegates were handed a link to these instructions in github. If you’re playing along at home, you should probably readĀ 1-Wire home automation tutorial from linux.conf.au 2019, part 1 before attempting the work described here. Its especially important that you know the IP address of your board for example.

Relay tweaks

The instructions are pretty self explanatory, although I did get confused about where to connect the relay as I couldn’t find PC8 in my 40 pin header diagrams. That’s because the shields for the tutorial have a separate header which is a bit more convenient:

GPIO header

I was also a bit confused when the relay didn’t work initially, but that turns out because I’d misunderstood the wiring. The relay needs to be powered from the 3.3v pin on the 40 pin header, as there is a PCB error which puts 5v on the pins labelled as 3.3v on the GPIO header. I ended up with jumper wires which looked like this:

Cabling the relay

1-Wire issues

Following on the tutorial instructions worked well from then on until I tried to get 1-Wire setup. The owfs2mqtt bridge plugin was logging this:

2019-04-08 19:23:55.075: /opt/OWFS-MQTT-Bridge/lib/Daemon/OneWire.pm:148:Daemon::logError(): Connection to owserver failed: Can't connect owserver: Address not available

Debugging that involved connecting to the owfs2mqtt docker container (hint: ssh to the Orange Pi, do a docker ps, and then run bash inside the docker container for the addon). Running owserver with debug produces this:

owserver fails

Sorry to post that as an image, cut and paste for the hassos ssh server doesn’t like me for some reason. I suspect I have a defective DS2482, but I’ll have to wait and see what Allistair says.

1-Wire home automation tutorial from linux.conf.au 2019, part 1

I didn’t get much of a chance to work through the home automation tutorial at linux.conf.au 2019 because I ended up helping others in the room get their Orange Pi is booting. Now that things have settled down after the conference, I’ve had a chance to actually do some of the tutorial myself. These are my notes so I can remember what I did later…

Pre-tutorial setup

You need to do the pre-tutorial setup first. I use Ubuntu, which means its important that I use 18.10 or greater so that st-link is packaged. Apart from that the instructions as written just worked.

You also need to download the image for the SD card, which was provided on the day at the conference. The URL for that isĀ from github. Download that image, decompress it, and then flash it to an SD card using something like Balena Etcher. The tutorial used 32gb SD cards, but the image will fit on something smaller than that.

hassos also doesn’t put anything on the Orange Pi HDMI port when it boots, so your machine is going to look like it didn’t boot. That’s expected. For the tutorial we provided a mapping from board number (mac address effectively) to IP address allocated in the tutorial. At home if you’re using an Orange Pi that isn’t from the conference you’re going to have to find another way to determine the IP address of your Orange Pi.

The way we determined MAC addresses and so forth for the boards used at the conference was to boot an Armbian image and then run a simple python script which performed some simple checks of each board by logging into the board over serial. The MAC addresses for the boards handed out on the day are on github.

An Aside: Serial on the Orange Pi Prime

As an aside, the serial on the Orange Pi Prime is really handy, especially with the hassos image. Serial is exposed by a three pin header on the board, which is sort of labelled:

Orange Pi Prime Serial Port
The Orange Pi Prime Serial Port

Noting that you’ll need to bend the pins of the serial header a little if you’re using the shield from the conference:

Serial port connected to a USB to serial converter

The advantage being that suddenly you get useful debugging information! The serial connection is 115200 baud 8N1 (8 data bits, no parity, 1 stop bit) by the way.

Serial debug information from an hassos boot

The hassos image used for the conference allows login as root with no password over serial, which dumps you into a hass interface. Type “login” to get a bash prompt, even though its not in the list of commands available. At this point you can use the “ip address” command to work out what address DHCP handed the board.

The actual on-the-day work

So at this point we’re about as ready as people were meant to be when they walked into the room for the tutorial. I’ll write more notes when I complete the actual tutorial.

Introducing GangScan

As some of you might know, I am a Scout Leader. One of the things I do for Scouts is I assist in a minor role with the running of Canberra Gang Show, a theatre production for young people.

One of the things Gang Show cares about is that they need to be able to do rapid roll calls and reporting on who is present at any given time — this is used for working out who is absent before a performance (and therefore needs an understudy), as well as ensuring we know where everyone is in an environment that sometimes has its fire suppression systems isolated.

Before I came along, Canberra Gang Show was doing this with a Windows based attendance tracking application, and 125kHz RFID tags. This system worked just fine, except that the software was clunky and there was only one badge reader — we struggled explaining to youth that they need to press the “out” button when logging out, and we wanted to be able to have attendance trackers at other locations in the theatre instead of forcing everyone to flow through a single door.

So, I got thinking. How hard can it be to build something a bit better?

Let’s start with some requirements: simple to deploy and manage; free software (both cost and freedom); more badge readers than what we have now; and low cost.

My basic proposal for such a thing is a Raspberry Pi Zero W, with a small LCD screen and a RFID reader. The device scans badges, and displays a confirmation of scan to the user. If the device can talk to a central server it streams events to it; otherwise it queues them until the server is available and then streams them.

Sourcing a simple SPI LCD screen and SPI RFID reader from ebay wasn’t too hard, and we were off! The only real wart was that I wanted to use 13.56mHz RFID cards, because then I could store some interesting (up to 1kb) data on the card itself. The first version was simply a ribbon cable:

v0.0, a ribbon cable

Which then led to me having my first PCB ever made. Let’s ignore that its the wrong size shall we?

v0.1, an incorrectly sized PCB

I’m now at the point where the software for the scanner is reasonable, and there is a bare bones server that does enough roll call that it should be functional. I am sure there’s more to be done, but it works enough to demo. One thing I learned while showing off the device at coffee the other day is that it really needs to make a noise when you scan a badge. I’ve ordered a SPI DAC to play with, which might be the solution there. Other next steps include a newer version of the PCB, and some sort of case solution. I’ll do another post when things progress further.

Oh yes, and I’ll eventually release the software too once its in a more workable state.

Brilliant Smart Wifi plug with Tasmota

A couple of weeks ago I was playing with Tuya derived smart light globes (Mirabella Genio from K-Mart Australia in my case, but there are a variety of other options as well). Now Bunnings has the Brillant Smart Wifi Plug on special for $20 and I decided to give that a go as well, given it is also Tuya derived.

The basic procedure for OTA flashing was the same as flashing the globes, except that you hold down the button on the device for five seconds to put it into flash mode. That all worked brilliantly, until I appear to have fat fingered my wifi details in Tasmota — when I rebooted the device it never appeared on my network.

That would be much more annoying on the globes, but it turns out these smart plugs are really easy to open and that Tuya has documented the pin out of the controlling microprocessor. So, I ended up temporarily soldering some cables to the microprocessor to debug what had gone wrong. It should be noted that as a soldering person I make a great software engineer:

Jumper wires soldered to the serial port.

Once you’ve connected with a serial console, its pretty obvious who can’t be trusted to type their wifi password correctly:

I can’t have nice things.

At this point I was in the process of working out how to use esptool to re-flash the plug when I got super lucky. However, first… Where the hell is GPIO0 (the way you turn on flashing mode)? Its not broken out on the pins for the MCU, but as a kind redditor pointed out, it is exposed on a pad on the back of the board:

The cunningly hidden GPIO0.

…and then I got lucky. You see, to put the MCU into flashing mode you short GPIO0 to ground. I was having trouble getting that to work with esptool, so I had a serial console attached to see what was happening. There I was, shorting GPIO0 out over and over trying to get the magic to work. However, Tasmota also setups up a button on GPIO0 by default, because the sonoffs have a hardware button on that pin. If you hit that button with four short presses, you put the device back into captive portal configuration mode

Once I was back in that mode I could just use a laptop over wifi to re-enter the wifi password and I’m good to go. In hindsight I didn’t need the serial port if I could have powered the device and shorted that pin four times, but it sure was nice to be told what was happening on the serial console while poking around.