Tech Archives - Blake Drayson

Mechanical Keyboard Prototype With V-USB & QMK

6th September 202012th October 2020 blake1 Comment

This is a relatively complete guide on how to build a mechanical keyboard prototype and get it functioning with QMK. Two different microcontrollers will be demonstrated (ATMegs32A, ATMega328P) and it should provide a solid starting point for anyone wishing to build a keyboard from the ground up. This is going to the the base I build on with an aim to designing, testing and producing a selection of full keyboards.

Required Hardware

The hardware you will require for this project is as follows

A ATMega32A or ATMega328P AVR microcontroller, either will do for this test, the 32A may be preferred if you plan to build a larger keyboard as it has more available lines.
Something to program a bootloader on the microcontroller, I use a Pro Micro for this task, you can use a Raspberry Pi.
An old USB cable or a USB header, something to get the connection from your pc to the microcontroller. I used a handmade cable for one setup and a USB-C header board for another. It makes no difference what you use, you just require VCC / GND / D+ / D – from a USB port to your project.
A 16Mhz crystal, part of the clock circuit.
2 x 22pF ceramic capacitors, part of the clock circuit.
2 x 68R resistors for the USB data lines.
A 4.7uF electrolytic capacitor to smooth the USB power lines.
A 1.5k resistor, part of the USB data line voltage drop circuit (level adjustment).
2 mechanical keyboard switches, any at all will do (actually any momentary switch).
4 x 1N4148 diodes two for the keyboard matrix and two to drop the USB data lines to the correct voltage (technically these should be 3.6v zener diodes like these but 1N4148 have worked for me and I had them already, and it should be ok for testing).
A selection of solid cable to make up jumper wires or pre-made jumper cables.
A breadboard to plug all the parts into.
A two pin header or dip switch or a jumper wire, something to short two pins to force the microcontroller into bootloader mode.
Soldering iron, snips, etc

Software Required

I do all of my work on Macs so the software will be presented as if the reader is using this platform, I believe all the tools are cross platform but I cannot comment on their use or setup on Windows or Linux as they are not platforms I have used them on.

QMK Toolbox, this is used for flashing firmware at various points in the process.
Pro Micro ISP Programmer firmware, to flash on to the Pro Micro (will not be needed if you are using different programmer hardware).
A working standard build environment.
A working QMK build environment.
USBaspLoader source files.
The relevant files from my dev_scarlet build of QMK that contains the keyboard.

References To Guides

It is only fair that I reference the guides that helped me with this project, they may be helpful for people reading my guide for use as additional points of reference.

One of the primary sources that I was able to find to initially get me going was a Reddit post by oldoverholt. This linked onto a very high level guide to setting this kind of project up with an ATMega328P.

I also used the Discipline keyboard project as another source of reference for both QMK code. design ideas and an overview of how this should work. The Discipline keyboard uses a ATMega32A microcontroller.

Construction

Throughout the construction I will primarily refer to the ATMega32A process but will give examples wherever it would deviate if you are using an ATMega328P. I will also provide two overview finished schematics for both microprocessors.

Flashing a bootloader and setting fuses

The first stage to the project will be flashing a bootloader on the microprocessor of choice, the process will be exactly the same regardless witch of the two chips you use (but fuse settings will be different). To flash a bootloader you will require a device to do the loading (a programmer), I chose to use a Pro Micro board as I have a few available, you could use a Raspberry PI or a Teensy. For this guide I will discuss using a Pro Micro and leave other options to the reader.

Preparing the programmer

First must flash a specific firmware to the Pro Micro, the firmware in question is mentioned above and is derived from the QMK ISP Flashing Guide. Download the firmware and QMK toolbox, install QMK toolbox and connect your Pro Micro.

You should open QMK toolbox and see that it has detected the Pro Micro, it should say something similar to the following.

*** Caterina device connected
    Found port: /dev/cu.usbmodem14501

At the top of the page, click open and locate the firmware file you downloaded. Then make sure that the MCU is set to ‘atmega32u4’ (this is only if you are using a Pro Micro, otherwise the MCU will be different).

When ready click flash and you should see an output similar to the following (click for large version), you will also see at the end I have disconnected and reconnected the Pro Micro and it how reads as an AVRISP device, this confirms it is correctly configured and ready to program other microcontrollers.

Mechanical Keyboard Prototype - Flash Pro Micro With ISP Firmware — Mechanical Keyboard Prototype – Flash Pro Micro With ISP Firmware

Preparing the microcontroller and wiring the programmer

You will need to layout the microprocessor on a breadboard, provide power and ground lines and wire up the crystal (including two capacitors) to provide a clock signal. You will then need to connect the relevant pins from the programmer to the breadboard. I have produced a simple Fritzing diagram of the required wiring for both microprocessors. Please do not connect an external power source to the breadboard, connect the VCC and GND lines from the programmer as shown (click for large version).

Mechanical Keyboard Prototype - ATMega32A Flash Bootloader Circuit — Mechanical Keyboard Prototype – ATMega32A Flash Bootloader Circuit

Mechanical Keyboard Prototype - ATMega328P Flash Bootloader Circuit — Mechanical Keyboard Prototype – ATMega328P Flash Bootloader Circuit

Configuring, compiling and flashing the bootloader

Now we have our programmer wired and ready to go we need to configure the bootloader before we flash it onto the microcontroller.

I am going to assume you have a working build environment and have downloaded (and setup) QMK source and the USBaspLoader, if not please set this up now.

We need to make some changes to the bootloader config to reflect what microcontroller we are using and to also configure the default USB pins (QMK uses PD2 and PD3 for USB to make life easier we will use the same).

In the root directory of USBaspLoader make the following changes to the Makefile.inc file, make sure you set the correct microcontroller.

F_CPU = 16000000
# this will either be atmega32 or atmega328p depending on the 
# microcontroller you are using
DEVICE = atmega32

FLASHADDRESS = 0x7000

# you will need to update the port (part after -P) to reflect the name of your
# usb port, or completely change this command if you are not using a Pro Micro
PROGRAMMER = -c avrisp -P /dev/cu.usbmodem123451

In the folder ‘firmware’ make the following changes to the bootloaderconfig.h file.

#define USB_CFG_INTPORT_BIT 2
#define USB_CFG_DMINUS_BIT     3 
#define JUMPER_BIT           6

With these changes complete we can now compile the bootloader. From the root directory of USBaspLoader run the following commands.

make clean
make firmware

We are now ready to flash, but before we do we are going to check we can see the microcontroller and set some fuses on it.

Execute the following command from a terminal window, adjusting the -p atmega32 to -p atmega328p if you are using the 328p and changing -P to the correct usb port.

avrdude -c avrisp -p m32 -P /dev/cu.usbmodem123451 -v

You should get a return detailing the programmer and attached microprocessor, you should see it read ok and return normally as per the following image. If not check your wiring and make sure the programmer flashed successfully.

Mechanical Keyboard Prototype - AVR ISP Read — Mechanical Keyboard Prototype – AVR ISP Read

The final stage before flashing the bootloader is to set the fuses. Fuses are persistent settings that are written to a specific area of the microcontroller, they control such things as clock speed, debug interfaces and various other options, caution must be taken when setting as incorrect values can brick the microcontroller (more detail on fuses can be found in a video here).

Our purpose here is to set the microcontroller to use the external 16mhz clock and to ensure that brownout detection is off. Fuse settings are derived from the fuse calculator.

There are different fuse settings for the two different microcontrollers, but they are set using a similar method, execute the following commands depending on which microcontroller you are using.

#ATMega32A Fuses
avrdude -c avrisp -p m32 -P /dev/cu.usbmodem123451 -v -u -U lfuse:w:0x1F:m
avrdude -c avrisp -p m32 -P /dev/cu.usbmodem123451 -v -u -U hfuse:w:0xC0:m

#ATMega328P Fuses
avrdude -c avrisp -p m328p -P /dev/cu.usbmodem123451 -v -u -U lfuse:w:0xFF:m
avrdude -c avrisp -p m328p -P /dev/cu.usbmodem123451 -v -u -U hfuse:w:0xD8:m
avrdude -c avrisp -p m328p -P /dev/cu.usbmodem123451 -v -u -U efuse:w:0xFF:m

Assuming these fuses were set correctly we can finally move on to flashing the bootloader.

From the root directory of USBaspLoader run the following command.

make flash

This should now flash the bootloader and you should get an output similar to the following, you have now successfully flashed the bootloader.

Mechanical Keyboard Prototype - AVR ISP Flash Bootloader — Mechanical Keyboard Prototype – AVR ISP Flash Bootloader

Wiring The USB Interface & Keyboard Matrix

As the circuit starts to add complexity in regards to layout I am going to move to schematic diagrams rather than Fritzing ones. This is due to the fact it is very difficult to scale component sizes and make them fit in Fritzing.

I have produced two different schematics for wiring the two different microcontrollers. Feel free to construct the physical layout of the circuits as you see fit but ensure the correct pins are used on the microcontrollers otherwise they will not function correctly. Click on the images to see the full SVG version of the schematics.

Mechanical Keyboard Prototype – ATMega32A Schematic

Mechanical Keyboard Prototype – ATMega328P Schematic

The above schematics outline how to wire the rest of the components used in the project, please follow them closely and check your wiring, also shown is how to wire a very basic keyboard matrix using two keys and two diodes (if you would like some further background on keyboard matrices and how to hand wire them please take a look at my hand wiring post).

Net Ports (the little labels like ROW1, COL1, SCK etc) are used to indicate how the different circuits are wired together without having to run wires, just match up the names.

Whilst the schematics show the programmer and how it is wired please feel free to disconnect this as it will not be required as the bootloader is already programmed. If you do not disconnect this please make sure it is not still plugged into your pc.

Flashing QMK

Now everything is wired we can proceed to configuring and flashing QMK on the keyboard, once this is done you will have a functional prototype.

I am going to assume you have configured a working QMK build environment, if you have not yet done so please do this now before proceeding.

Copy the relevant files from my dev_scarlet build of QMK into the keyboards/ghostseven/scarlet folder in your QMK environment.

Depending on what microprocessor you are using change the keyboards/ghostseven/scarlet/rules.mk file accordingly.

#Both ATmega328P and ATmega32A have been tested and work with USBasp, please ensure you configure the right one.
#MCU = atmega328p
MCU = atmega32a

Issue the following command from the QMK root folder to compile the QMK firmware.

qmk compile -kb ghostseven/scarlet -km default

This should compile and produce an output similar to the following, you should end up with a ghostseven_scarlet_default.hex file in the QMK root folder, this is the firmware.

Mechanical Keyboard Prototype – QMK Compile Firmware

We now need to connect the circuit via the USB port (or cable) that has been wired to the microprocessor (do not connect the programmer USB). Before we do this we need to make sure we have attached the bootloader jumper or shorted pin PD6 to GND.

Plug the circuit in and open QMK Toolbox, you should see USBAsp device connected. If this does not appear double check your circuit wiring and make sure you have shorted PD6 to GND.

Select the firmware you created in the previous step and make sure the MCU is set to the correct microcontroller (ATMega32A or ATMega328P), then click flash. You should see a positive output similar to the following.

Mechanical Keyboard Prototype – QMK Toolbox Flash Firmware

Unplug the circuit and disconnect the bootloader jumper (or wire between PD6 and GND). Reconnect the USB and you now have a working two button keyboard prototype!

Testing The Keyboard

By default the two buttons should present the letters s and d, if they do all is working fine!

Thoughts

Whilst in this form the keyboard is not really that useful or practical, it should give you a good grounding on how to build a larger or full size keyboard from scratch. I hope that you found this helpful and informative and it has give you the knowledge to take this further.

I want to add a few reference documents in this section that may be of use for anyone working on this project.

3D Printed Hand Wired 40% Keyboard

27th August 2020 blake15 Comments

The subject of this blog is a build log, that will cover my build of a 3D printed hand wired 40% keyboard. It will include basic details on 3D printing, hand wiring, general assembly and software programming with QMK along with references to the guides I used.

About a month or so ago I was looking around for a new project (as I frequently do) and I stumbled upon a mechanical keyboard sub-reddit. This ended with me in fairly short order, purchasing the parts to build my first keyboard. Skip forward to today and I have just finished building my third full keyboard and three macro-boards. Clearly this hobby is going to be a money sink!

Required Hardware

The hardware you will require for this project is as follows

The required hardware list is a little more daunting than usual as it will require access to specialist equipment (a 3D printer). You could always buy a case and plate to use instead of printing one and then adjust accordingly.

A 3D printer with a build plate that is at least 220mm x 220mm, or alternatively buying a suitable keyboard plate and case.
47 x MX type mechanical keyboard switches, I used Gateron Blues.
48 x 1N4148 diodes for the keyboard matrix.
A EC-11 rotary encoder, for the volume control.
A Pro Micro controller board.
6 x M3 6-10mm screws to hold the case together (assuming you are using the 3D printed one).
A suitable set of keycaps for a 40% ortholinear keyboard.
A grippy knob…
Suitable wire for building the keyboard matrix, I used a combination of old network cable wire (solid core) and some 26 AWG solid core cable I had from other projects. Any insulated wire will work but solid core is a little easier.
Line wire to go between the microcontroller and the keyboard matrix, you can use whatever wire you like but I highly recommend using ribbon cable as it is flat and easy to work with.
Soldering iron, snips, glue gun etc

3D printer, printing a keyboard case — 3D Printed Hand Wired 40% Keyboard – Printing The Case

References To Guides

It is only fair that I reference the guides that helped me make this keyboard. They may be helpful for people reading my guide for use as additional points of reference.

A modern handwiring guide – stronger, cleaner, easier

A Complete Guide To Building a Hand-Wired Keyboard

Printing A Case

I wanted as make where possible all the components for the keyboard, ideally 3D printing where I could. I searched around for different 3D printed cases and was originally going to do a split ortholinear keyboard based on the lets split case. However once it was printed I realised there was not a lot of room to hand wire as it was designed for a PCB. After a bit more hunting I found the Void 40 a 40% keyboard case and plate that was designed for hand wiring. It really is an excellent case design, by Victor Lucachi who rightly deserves credit for releasing it freely for everyone to use and build on.

You will need to print this case or have it printed for you, additional you will need to also print one of these EC-11 to MX switch plate adapters. This will allow you to easily pop a rotary encoder into the top left switch socket (or any other socket should you desire).

Once you have these printed, you can socket all of your switches and the rotary encoder.

3D printed case with mx switches inserted — 3D Printed Hand Wired 40% Keyboard – Socketed with Gateron blue switches.

Wiring The Keyboard

Basic principles: Keyboard matrix

To save us from having to wire directly to each switch, which would be laborious and honestly not practical in any way, a keyboard matrix is used instead. This wiring pattern allows us to only need one wire for each row and one wire for each column, dramatically reducing the wiring that needs to go back to a microcontroller.

However there is a trade off, having independently wired switches means that it is easy to know what switches are pressed at the same time without any false positives or unregistered keys (called ghosting). When a keyboard matrix is used we need to add diodes to each key to prevent the black flow of electricity connecting circuits that are not intended. In practice this means a little bit more fiddly soldering but a far more manageable keyboard build. To read more about keyboard matrices and the ghosting effect I have found the following article very easy to understand and clearly written.

Keyboard ghosting — 3D Printed Hand Wired 40% Keyboard – Ghosting 🙂

Wiring the diodes

We need to add a diode to each switch, we will be wiring to the top left of each switch (my pictures show the keyboard rotated 180 degrees as it was easier to work on).

The diode must be wired so the anode ( + ) is closest to the switch and the cathode ( – ) is furthest away, it is easy to work out which is which on a diode as the cathode has black bar on it.

To make life a little easier and as is recommanded in all the guides I read, you should create a small loop at the anode end and then pop this over the switch connector. The loop helps create a strong connection and makes positioning somewhat easier. You will want to point the tail of the cathode so it runs straight up away from the switch so that you can loop it around the joining row wire you will add later. For example;

3D Printed Hand Wired 40% Keyboard – Adding diodes

Once you have looped all your diodes around the switches make sure you solder and check their connections, also make sure you have soldered a diode to the rotary encoder as well, it needs to be added to the two pin side in the same way as the switches.

3D Printed Hand Wired 40% Keyboard - Ghosting :) — 3D Printed Hand Wired 40% Keyboard – All diodes soldered to the switches.

Adding the row wires

We now need to add the row wires, these are single wires that will run along each row and be soldered to the end of the diodes we just added.

I used insulated solid core wire for this and lined each wire up marking out where it would be in contact with the diode and cutting out the insulation at with a sharp craft knife.

Once you have your wire prepared you can then start soldering it to the diodes in each row, I recommend wrapping the tail wire of the diode around the row wire then soldering, once done you can trim any excess on each diode with wire cutters.

You should start to build up like this.

Partially wired row wires — 3D Printed Hand Wired 40% Keyboard – Partial row wiring.

Once you are done your rows should look like this.

3D Printed Hand Wired 40% Keyboard – Full row wiring.

Adding the column wires

This is a very similar process to adding the row wiring, we need to run wires down each column joining all second connectors on each switch in that column. For this I used old solid core network cable wires.

Once again measure and trim the insulation at the correct points and to aid with alignment I suggest you create a loop at one end and solder this to the first switch, then run down and solder to the remaining three in each column.

Once done it should look like this.

All rows and column wires added and soldered. — 3D Printed Hand Wired 40% Keyboard – Full row and column matrix

Wiring the microcontroller

The major wiring work is now over, all we need to now do is run a wire to each column and each row on the keyboard (plus three to the rotary encoder). These wires will go back to the microcontroller and later be configured in QMK to drive the keyboard.

I used ribbon cable and I highly recommend this, it is flat and easy to run. I did this in strips of four as that fitted nicely in the gaps between rows and columns.

For each row you need to solder a wire to the cathode side (black bar) of the diode (where it joins the row wire) in any one of those rows. For each column you need to solder a wire to any one of the switches (on the non diode connector) in that column. The following picture should make it a little clearer

3D Printed Hand Wired 40% Keyboard – Link wire routing

I ended up with a wiring diagram that links back the following Pro Micro microcontroller pins.

Pro Micro Pin	Row
C6	1 – Top row (QWER)
D4	2 – Second row (ASDF)
D0	3 – Third row (ZXCV)
D1	4 – Forth row (Ctl Alt)

3D Printed Hand Wired 40% Keyboard – Row wiring table

Pro Micro Pin	Column (Left To Right)
E6	1
D7	2
B5	3
B4	4
F6	5
F7	6
F4	7
F5	8
B1	9
B3	10
B2	11
B6	12

3D Printed Hand Wired 40% Keyboard – Column wiring table

Pro Micro Pin	Rotary Encoder Pin
D2	Right most pin of three
GND	Center pin of three
D3	Left most pin of three

3D Printed Hand Wired 40% Keyboard – Rotary encoder wiring table

One you have these all wired up I would recommend you do not fix the microcontroller in place and you do your programming and testing with a bare keyboard. Better to do it this way than assemble it all and then find a problem.

A 3D printed keyboard that has been hand wired with rainbow coloured wires and is open showing the wiring.

Configuring Firmware & Flashing QMK

I am not going to put a detailed guide on how to configure QMK here, you will need a QMK build environment. I suggest you follow this guide.

Once you have an environment together you can download the following files from my github page, these will need to be extracted into the qmk_firmware/keyboard/handwired directory. These files contain a fork of the code used by the Void40 by Victor Lucachi, this keyboard is not currently in the standard QMK base but I have reached out to Victor and it will soon be submitted (once it is live I will update this post to reflect it). The changes from the standard firmware are related to pin assignments and keymaps.

To build the firmware issue the following command

qmk compile -kb handwired/void40/ghostseven -km ghostseven

The resulting hex file should be flashed to the keyboard using QMK Toolbox. You will need to short the pins between RST and GND on the pro micro to put it in firmware update mode.

The keyboard will have the following layout if you used the above command.

Please ensure you test all the keys and make sure they work, if you have changed the wiring to the controller in any way you will need to edit the config.h file in the ghostseven folder and match this to your wiring layout.

#define MATRIX_ROW_PINS { C6, D4, D0, D1 }
#define MATRIX_COL_PINS { E6, D7, B5, B4, F6, F7, F4, F5, B1, B3, B2, B6 }

/*
 * Rotary Encoder Support
 */
#define ENCODERS_PAD_A { D2 }
#define ENCODERS_PAD_B { D3 }

Keycaps & Securing The Case

Once you are happy that your keyboard is working and that the wiring is correct you can clip the pro micro into position on the case bottom. You may require a little hot glue to hold it in place. Once you have the two halves of the case together secure the plate to the case bottom with 4 m3 screws. Once these are in place, flip the case over and use four more m3 screws in the corners to tighten the case up. Be careful to not over tighten and split the plastic.

Finally add your keycaps and get clacking.

NeoPixel LED Controller

16th August 202016th August 2020 blakeLeave a comment

Building a NeoPixel LED Controller with MQTT and HomeKit support. Expanding on my previous project to add LED lighting to my work area, I wanted to investigate a lower voltage and more customisable LED system. I had read about WS2812B or NeoPixel LEDs but had not built anything with them. I have since build a whole raft of lighting projects utilising these and even designed a simple PCB to use in my controllers. In this blog post I aim to go over the basics, take a peek at the software I have written and talk about the various projects I have used them in.

NeoPixel LED Controller – Short Demo – The Candles & Desk Strip Are Powered By This Controller

What Are NeoPixel LEDs?

NeoPixel is Adafruit’s brand name for individually-addressable RGB colour pixels and strips based on the WS2812, WS2811 and SK6812 LED/drivers, but it has become shorthand for any individually addressable LED drivers. The cool part about this is the fact that you can set properties on any LED in a whole strip or matrix, this allows us to play about with effects and fades and makes them a lot more versatile that the standard strips I used in my previous project (Build A HomeKit Enabled WiFi LED Strip). They also run on 5v rather than 12v so building a project with a microcontroller is far easier and need less components.

Required Hardware

The hardware you will require for this project is as follows

An existing MQTT server on your network, this is required for messaging,
If you wish to use HomeKit an existing Homebridge server on your network.
An ESP8266 board, something like a Wemos D1 Mini, you can use other boards but you will have to amend the code.
A length of WS2812B strip, something like this, 5 meters (60 LED) costs about £15.
(Optional) A barrel jack socket, to connect DC power to the board.
A suitably rated 5v power supply, the amperage will vary depending on how long your LED strip is. I used a 5v 4A supply I had already.
A suitable current smoothing capacitor to deal with sudden changes in the LED strip current draw. I used a 1000uF 16v capacitor.
Some perfboard to build the project on (or use my handy dandy Gerber files to have PCBs made, or even better get JLCPCB to fab and send it to you.).
(Optional) A screw terminal to attach the LED strip leads to your board.
Some patch wire to link the components on the board.
A suitable enclosure or access to a 3D printer (STL and OpenSCAD files are provided).
Soldering iron, snips etc.

The Circuit

The following shows how to connect the various components, there really is not a lot to it and you could go without any perfboard at all and simply solder the parts together.

NeoPixel LED Controller – Fritzing Circuit Diagram

I have used this circuit so frequently in projects that I have now designed a PCB so I can standardise the layout and case design. The Gerber files are freely available and if you wish you can visit my EasyEDA project page and get JCLPCB to manufacture batches of the board.

NeoPixel LED Controller – Naked Circuit Board

The Microcontroller Code

The code has been written using the Ardunio platform, although I prefer to to use PlatformIO inside Visual Studio Code rather than the Arduino editor.

All of the code files, fritizing diagram, Gerber and 3d printer files for the NeoPixel LED Controller can be found on my github.

The controller code is similar to my previous project (Build A HomeKit Enabled WiFi LED Strip) in so far as being able to send HSV values to set colours, but it also now allows you to run effects on the connected LEDs. You can even specify a favourite effect so you can easily toggle it via HomeKit. Some of the effects will use the currently selected colour as their base (with a default colour if none is selected) and other effects will run though pre-configured colours.

LED Effects

The current list of effects is as follows, they are taken from a great article on FastLED / NeoPixel LED effects by Tweaking4All.com. I have taken a selection I wished to use and adapted them for my purposes.

ID	Effect	Description	Video Link
1	RGB Loop	Fades colour in and out from red to green to blue.	Link
2	Running Lights	Chase light effect from red to white to blue.	Link
3	Colour Wipe	Wipe effect using the colour you have selected	Link
4	Rainbow Cycle	Rainbow cycle of colours, default effect on strip	Link
5	Theatre Chase	LEDs chase each other, like an old theatre, uses whatever colour you have selected	Link
6	Theatre Chase Rainbow	Rainbow effect version of theatre chase	Link
7	Fire	Burning fire effect	Link
8	Meteor Rain	Meteor shooting across the sky	Link
9	Cylon	By your command..	Link
10	Twinkle	Twinkle effect using selected colour	Link
11	Tinkle Random	Twinkle effect using random colours	Link
12	Sparkle	Variation of twinkle, white sparkle effect	Link
13	Snow Sparkle	Snow effect with occasional sparkle	Link
14	Breathing	Breath in out effect with selected colour.

NeoPixel LED Controller – Effects List

Configuring The Code

Firstly you must adjust and renamed the config file, I (now) use LittleFS uploaded config files for most of my projects as it makes my configuration easier for WiFi. MQTT and OTA. On the github page there is an example file that once checked out will need to be renamed to config,json (from config.EXAMPLE.json) and edited to fill in the SSID and password of your WiFI network. You will also need to complete your MQTT server details, I would pay special attention to the device_id and base_topic as they will end up setting the full topic for your MQTT commands, please set then to something sensible.

{
    "name": "Desk LED Strip",
    "device_id": "desk-led-strip",
    "wifi": {
      "ssid": "WIFI_SSID",
      "password": "WIFI_PASSWORD"
    },
    "mqtt": {
      "host": "xxx.xxx.xxx.xxx",
      "port": 1883,
      "base_topic": "basement/light/",
      "username": "MQTT_USERNAME",
      "password": "MQTT_PASSWORD",
      "retained": true
    },
    "effect_sw":{
      "effect_index": 4,
      "effect_seconds": 0
    }
  }

You can also see there is a section called effect_sw, this is designed to set the parameters for the effect you would like to be able to toggle on and off via HomeKit. The effect_index is a number from the above effects table, the effect_seconds is how long it should run with 0 being forever (this is best for a toggle switch, change if you configure a momentary one). By default it runs the Rainbow Cycle effect.

You will need to configure some settings in the main code, you will need to edit led.h. From here you can edit the pin that will send the control signals to the LED strip, by default it is D5 (LED_PIN). You will also need to set how many LEDs you have in your strip, otherwise they will not behave as expected (NUM_LEDS). Optionally you can set the voltage and amperage limits on the strip, thus limiting the power you will use (LED_STRIP_VOLTAGE, LED_STRIP_MILLIAMPS). I suggest leaving the voltage at 5v and adjusting the amperage to suit.

#define NUM_LEDS 73
#define LED_PIN D5
#define LED_STRIP_VOLTAGE 5
#define LED_STRIP_MILLIAMPS 4000

Over The Air Updates

The code is configured to allow over the air updates, the thought behind this is that once you have a light in place it may not be easy or practical to connect the device back to a computer to upgrade the firmware. The mDNS name will be in the form of <device_id>.local, for example, using the example config it would have a name of desk-led-strip.local. If you are using PlatformIO (which I highly recommend over the Arduino IDE) you simply need to change the upload_port in the ini file to the name of your mDNS entry.

I will not go through all the code files here as they are available on my github page. You will need to update and upload the config file before compiling and flashing the code to the device of your choice.

MQTT

Once you have the circuit built and the code flashed to your device, it is best to test that it can receive MQTT commands before you try and configure it to work on HomeKit.

For testing MQTT I use MQTT.fx on the Mac, and as it runs on Java this should work on all platforms. I am assuming you have not changed the base_topic and device_id, if you have you can update the tests to reflect this.

Basic Light

You can subscribe to “basement/light/desk-led-strip/hsv” and this will post back a comma delimited string with the HSV value that the light has been set to (for example 0,0,100). It will also retain messages so after a power loss the state is known.

If you send a message to “basement/light/desk-led-strip/hsv/set” with the payload of a comma delimited HSV value such as 0,0,100 it will set the strip to that colour and intensity, it will also then post back to “basement/light/desk-led-strip/hsv” with the HSV change.

Effects

You can set an effect and the duration for the effect should run for by sending a JSON payload to “basement/light/desk-led-strip/effect”. The payload should look like the following.

{effect_index:9, effect_seconds:20}

The above payload would run the Cylon effect for 20 seconds, it mirrors the parameters seen in config file for the effect_sw.

Effect Switch

If you wished to have a toggle-able effect mode without having to send a complex JSON payload (for example in HomeKit) you can define a switch effect in the config file. To turn the effect on or off you can simply send a “true” or “false” payload to “basement/light/desk-led-strip/effect_sw/set”. It will mirror back the state that has been set to “basement/light/desk-led-strip/effect_sw”.

Apple HomeKit via Homebridge

If you have a working Homebridge server you can easily add this device to it and be up and running in no time. You need to install the MQTTthing plugin if you do not have it already and then add the following to your config file, adjusting as required for your MQTT setup.

        {
            "accessory": "mqttthing",
            "type": "lightbulb",
            "name": "Desk LED",
            "url": "mqtt://localhost",
            "username": "USERNAME",
            "password": "PASSWORD",
            "topics": {
                "getHSV": "basement/light/desk-led-strip/hsv",
                "setHSV": "basement/light/desk-led-strip/hsv/set"
            }
        },

If you wanted to add an additional switch for turning on or off a the pre-configured effect mode then add the following to your config file, adjusting as required.

        {
            "accessory": "mqttthing",
            "type": "switch",
            "name": "Desk LED Effect",
            "url": "mqtt://localhost",
            "username": "USERNAME",
            "password": "PASSWORD",
            "topics": {
                "setOn": "basement/light/desk-led-strip/effectsw/set",
                "getOn": "basement/light/desk-led-strip/effectsw"
            }
        },

Once you have restarted Homebridge you will see a new light on your Home app.

3D Printed Case

I have produced a 3D printed case that fits my PCB, this will probably work for a custom build without the PCB but you will have to play around. I am not sure how well it will snap together without the PCB. The STL and OpenSCAD files are on my github under the folder 3d-printed-case.

NeoPixel LED Controller – 3D Printed Case

I hope you have found this guide useful, if you have any problems with the NeoPixel LED Controller or any suggestions, feel free to leave a comment or post on my github page.

Lighting Projects Using This Controller

Here are some photos of the lighting projects I have created using this controller, they are used extensively around my house; a display fireplace, a 3D printer running light, multiple desk lights and stair rail lights.

Build A HomeKit Enabled WiFi LED Strip

31st May 202016th August 2020 blake1 Comment

I have a work area that I wanted to provide some additional lighting for, and like everything else in my home I wanted it to work with Apple HomeKit. I did not want to spend a large amount of money buying something like a Phillips Hue Strip so I thought I would build my own. This will be a short guide to how I built a HomeKit Enabled WiFi LED Strip and the software I wrote to run it.

Before you start, if you are not comfortable building electronics projects or you are unsure on how to calculate the power requirements for your LED strips, please do not attempt this project. I have assumed a basic working knowledge of how to write code for Arduino devices and how to flash such code.

Required Hardware

A nice rule of thumb for the power usage (this is taken from the following Adafruit page) of 12v LED strips is as follows.

To find the total maximum current draw per meter, we would multiply 60mA x 10 (ten segments per meter for the 30/LED per meter strip) = 0.6 Amps per meter OR 60mA x 20 (twenty segments per meter for the 60/LED per meter strip) = 1.2 Amps per meter. Again, that’s assuming you would have all the LEDs on at once and that you are powering it from 12V.

The hardware you will require for the project is as follows.

An existing MQTT server on your network, this is required for messaging,
If you wish to use HomeKit an existing Homebridge server on your network.
An ESP8266 board, something like a Wemos D1 Mini, you can use other boards but you will have to amend the code.
A length of 5050 RGB LED strip, something like this, 5 meters costs about £6.
A suitably rated 12v power supply, the amperage will vary depending on how long your LED strip is. I used a 12v 4A supply I had already.
Three suitable MOSFETs I used IRFZ3NN N-channel ones, this should be good for long LED lengths but will require heat sinks if you run more than a few meters (Data Sheet).
A step down DC-DC power converter, this is to drop the 12v down to the 5v required to run the Wemos. I used a MP1584EN based one, you can get fixed 12v to 5v or variable. Please ensure you use a suitably rated one that can handle the amperage, again this will vary by LED strip length.
Some perfboard to build the project on.
Some patch wire to link the components on the board.
A suitable enclosure or access to a 3D printer (STL and OpenSCAD files are provided).
Soldering iron, snips etc.

The Circuit

The following circuit explains how to connect the various components, I will leave it to the reader on how they would like to arrange the board design and I will include a picture of my design. The IRFZ3NN MOSFETs have pin 1 as the GATE, pin 2 as the DRAIN and pin 3 as the SOURCE. If you use a different component please use this information as reference on how to rework the circuit.

12v WiFi LED Strip Circuit Diagram – Fritzing

The Microcontroller Code

The code has been written using the Ardunio platform, although I prefer to to use PlatformIO inside Visual Studio Code rather than the Arduino editor.

All of the code files, fritizing diagram and 3d printer files for HomeKit Enabled WiFi LED Strip can be found on github. LED RGB Strip Controller

Firstly you must adjust and renamed the config file, I use SPIFFS uploaded config files for most of my projects as it makes my configuration easier for WiFi an MQTT. On the github page there is an example file that once checked out will need to be renamed to config,json (from config.EXAMPLE.json) and edited to fill in the SSID and password of your WiFI network. You will also need to complete your MQTT server details, I would pay special attention to the device_id and base_topic as they will end up setting the full topic for your MQTT commands, please set then to something sensible.

{
    "name": "Workbench LED Strip",
    "device_id": "workbench-led-strip",
    "deep_sleep_interval": 600,
    "wifi": {
      "ssid": "WIFI_SSID",
      "password": "WIFI_PASSWORD"
    },
    "mqtt": {
      "host": "xxx.xxx.xxx.xxx",
      "port": 1883,
      "base_topic": "basement/light/",
      "username": "MQTT_USERNAME",
      "password": "MQTT_PASSWORD"
    }
  }

The main entry point to the project sets up the pins that are driving the colour channels, change redPin, greenPin and bluePin as required if you are using a different board or different pins.

int redPin = D8;
int greenPin = D7;
int bluePin = D6;

void setup() {
  Serial.begin(115200);
  analogWriteRange(255);
  
  // Initialize RGB Led strip pins
  pinMode(redPin, OUTPUT);
  pinMode(greenPin, OUTPUT);
  pinMode(bluePin, OUTPUT);

.........

I will not go through all the code files here as they are available on my github page, LED RGB Strip Controller. You will need to update and upload the config file before compiling and flashing the code to the device of your choice.

MQTT

Once you have the HomeKit Enabled WiFi LED Strip circuit built and the code flashed to your device, it is best to test that it can receive MQTT commands before you try and configure it to work on HomeKit.

You can subscribe to “basement/light/workbench-led-strip/hsv” and this will post back a comma delimited string with the HSV value that the light has been set to (for example 0,0,100). It will also retain messages so after a power loss the state is known.

If you send a message to “basement/light/workbench-led-strip/hsv/set” with the payload of a comma delimited HSV value such as 0,0,100 it will set the strip to that colour and intensity, it will also then post back to “basement/light/workbench-led-strip/hsv” with the HSV change.

Please be aware the HSV ranges are as follows H: 0-360, S: 0-100, V: 0-100.

Apple HomeKit via Homebridge

        {
            "accessory": "mqttthing",
            "type": "lightbulb",
            "name": "Workbench LED",
            "url": "mqtt://localhost",
            "username": "USERNAME",
            "password": "PASSWORD",
            "topics": {
                "getHSV": "basement/light/workbench-led-strip/hsv",
                "setHSV": "basement/light/workbench-led-strip/hsv/set"
            }
        },

Once you have restarted Homebridge you will see a new light on your Home app.

3D Printed Case

I have produced a very basic 3d printed case that suits the size of my circuit board, it is very simple and just pops together. The OpenSCAD and STL files are on the project page under the folder 3d-printed-case.

I hope you have found this guide useful, if you have any problems with HomeKit Enabled WiFi LED Strip or any suggestions, feel free to leave a comment or post on my github page.

Classic Mac Emulation On macOS

16th February 2018 blake1 Comment

Classic Mac Emulation On macOS, having just resurrected my 2008 Mac Pro from the doldrums, it has now become a permanent feature in the office / retro basement. Giving me the opportunity to play about with some emulation options without disturbing my main work Mac. I have been working on Classic Mac and Amiga emulation, with a slew of great guides and excellent free software. I will focus on Classic Mac emulation in this article as the Amiga side is a bit more involved and I am still learning the ropes on that (look out for a followup post later).

Classic Mac Emulation On macOS – Mac OS 9

This harps back to my introduction to Macs, when I was first fiddling about with them the only ones I could afford were second hand Performa 6300 or early Power Mac G4s (that I wish I still had now, glances at eBay watch list). So there is a nostalgia in running Mac OS 9 again and having easy (possibly not fully legally) access to a slew of old Mac software.

Having read around the subject of running OS 9 in an emulator I settled on using a free piece of software called SheepShaver this allows you to emulate up to OS 9.0.4 (anything above this will not run).

Classic Mac Emulation On macOS - Sheep Shaver Running OS 9.0.4 — Sheep Shaver running OS 9.0.4 Classic on High Sierra

I shall make an assumptions that anyone reading this post and looking to replicate this will be running (High) Sierra. With this assumption I can point out some relevant quirks with SheepShaver that could trip you up but are easily resolvable.

OSX 10.8 and later prevents mounting of physical CD-ROMs in SheepShaver but images created from CD-ROMs still work fine. You can create an image from a CD with Disk Utility. Make sure you choose either “read/write” (.dmg) or “DVD/CD Master” (.cdr) for the format. Compressed and read-only formats will not work. – Basically you need to make disc images or download disc images for OS 9 install or any other CDs you wish to use. It is not overly complex and should not be a barrier to use.
There is an issue with macOS 10.12 Sierra (in fact with an additional new security feature in Sierra) that prevents a newly installed SheepShaver to run. The procedure to get it running is simply to copy the program (only the SheepShaver application itself!) to the desktop, remove the old program in the SheepShaver folder and move the new copy from the desktop to the SheepShaver folder. – This is an odd resolution but does work, again an extra step but a simple fix.
With the above point in mind, when downloading SheepShaver you are going to grab the full package and the SDL patch, the SDL patch requires you to replace the main application and in doing so you may resolve the issue outlined in point 2.

Classic Mac Emulation On macOS – Installing SheepShaver

I will not go over the finer details of installing SheepShaver as there is already a very detailed guide done by emacualation.com, it is a great reference to getting everything setup. However I shall list some resources you will need to ease the process.

SheepShaver install files, this should always be the latest versions, with advisories of any post install patches (like the SDL patch).
Links to ROMs required for SheepShaver, I use the NewWorldRom
Mac OS 9.0.4 Bootable Install, support for all systems and languages.
Vintage Mac Software, this is a great jumping off point to various sites around the web where you can download games, apps and other Classic Mac curios. I am not sure of the legality of this, I imagine most if not all would be considered abandonware but please do some due diligence if you feel the need.

Classic Mac Emulation On macOS - Space Quest VI - OS 9 - Sheep Shaver — Space Quest VI running on OS 9.0.4 in Sheep Shaver emulator

I hope you get the chance to have a play with SheepShaver and enjoy experiencing the Classic Mac OS, it still has a lot to offer and is an excellent way to play with legacy software without having to buy and maintain older hardware (though that is more fun!).

Plus who would not want to play Space Quest 🙂

High Sierra On A Mac Pro 2008

12th February 201812th November 2019 blake1 Comment

High Sierra on a Mac Pro 2008, technically the last officially supported version of macOS for the Early 2008 Mac Pro is El Capitan. However this does appear to be a software cutoff point rather than an issue with the hardware required to run it.

There are a large group of older Macs that have fallen foul of this cutoff (most of them being released in and around 2008), thankfully a rather enterprising Mac Rumors user going by the name of dosdude1 has written a patching tool to bypass this limitation.

High Sierra On A Mac Pro 2008 – Patching Thoughts

I can attest to the patch install running without incident on an Early 2008 Mac Pro (3,1) and being relatively easy (ignoring any non Mac video card issues), 90% of it being the same as doing an in place upgrade using a usb stick.

However as you are going to be booting from a USB installer if you are running a Mac with a non Apple video card you will have to do this blind (as my Mac Pro 2008 rebuild article mentions regarding booting into recovery).

I did find this part rather tricky to the point where I went hunting again (in two different houses) for my original Mac Pro graphics card. In a flash of inspiration I checked an old server in my father’s loft and low and behold there was the card, a quick swap later and I had my Nvidia 8800 GT back and ready to go! Now if only I had remembered where it was when I was rebuilding the Mac Pro, that would have saved me a lot of time and made a fresh install easier.

Mac Nvidia 8800 GT — My long lost Mac Pro graphics card the 8800 GT

High Sierra On A Mac Pro 2008 – How To

I am not going to rehash the simple and clear guide that dosdude1 has written for building the patch installer as it would just be plagiarizing their work, you can find the guide here.

If you are looking for support for any troubleshooting or questions regarding the patching process or install a good place to start would be the Macrumors forum post dedicated to this topic, you can find it here.

If I can be of any help or if you have any question regarding this, feel free to drop a comment under this post.

Rebuilding my 2008 Mac Pro Desktop

11th February 201812th February 2018 blake2 Comments

Rebuilding my 2008 Mac Pro, it’s almost 10 years old and has languished for the last year hidden behind boxes, under powered and forgotten, it was time it had an upgrade and I fixed some of the destructive maintenance that had been done to it over the years.

But first a quick history of how and why I ended up purchasing this Mac back in 2008 (If you wish to skip to the rebuild, click here).

Switching from PC

After years of tinkering around PCs and having dipped my toe into Mac ownership via a selection of secondhand Pre G3 Power Macs (that ultimately ran plan9 in some strange cluster experiment) and then later a old G4 Power Mac. In 2006 I started my journey into switching from being a PC user to a Mac user and between then and 2008 I had several Macs in short succession.

First came a Early 2006 Mac Mini, a revolution for me as this was my first new, modern Mac and was not clunky, slow and secondhand, it reinforced my move from PC to Mac and I would not flip back for many years (lack of modern pro desktop did it in the end with hackintoshes bridging the gap till now).

Not long after the Mac Mini purchase I was itching for a more powerful Mac and just before Christmas I sold on the Mini and placed an order for a 20″ Late Core 2 Duo iMac, this and the subsequent refurbished Late 2006 MacBook that got lugged back an forth to work each day are still going strong, (the MacBook lacks a suitable battery but that is another future refurb job) and provided me with a brilliant ecosystem to work from. However I felt like they both lacked the professional and expandable setup I had been used to with home built PCs. It was time to spend the cash and move into the Mac Pro arena.

My First Professional Mac

In 2008 I finally bit the bullet and bought my first Mac that I truly considered a comparable and professional replacement to the home built computers I had used in the past. I scraped together enough to buy a single processor Early 2008 Mac Pro I could not quite afford to get the dual processor version (something I would regret and considered fixing with the rebuild) but did find the extra cash to add a third party ram upgrade to install a whopping 6 gigabytes.

For many years it was an excellent workstation but after several upgrades that kept it ticking over (new graphics card, SSD upgrade) it had reached a point where I felt that I could no longer use it as my day to day machine. This coupled with a pig headed decision on Apples part to abandon the Pro range for many years (leaving the Pro Mac user in the doldrums) I never ended up in a situation where I felt it was worth my money to buy a new replacement.

I begrudgingly moved back to the PC, the Mac Pro plodded on, repurposed as a server and occasional Mac specific software platform. It ended its life not even running MacOS but running Ubuntu as a XBMC media server / client and then got stored behind boxes in my basement after a house move.

I continued to use PCs but did make the shift (by a luck of hardware) to running a dual boot Hackingtosh (using tricks to install MacOS on a PC rather than a Mac) allowing me to enjoy the benefits of a Mac ecosystem without having to purchase a new Pro (they thankfully did release a new range, but have once again abandoned it, in all but name).

About a year ago I move back fully to a Mac, this time with my needs being significantly different I no longer require a desktop workstation and have found that the new Pro range of MacBooks are excellent. I am now rocking a MacBook Pro “Core i7″ 2.9 15” Touch/Late 2016 a beast of a laptop that more than fulfils my requirements and has scope for expansion via the Thunderbolt 3 ports (graphics cards, SSD drives and the like).

After this lengthy digression I best talk about the rebuild.

Rebuilding my 2008 Mac Pro

First thing to note, I took no pictures whilst cleaning and upgrading the Mac which in hindsight was stupid, all of the pictures are post resurrection, apologies for this.

The initial boot of the the Mac was exceptionally slow and to my surprise it was still running MacOS, I had been sure I had left it with Linux installed. The speed of the bootup and how excruciating long it took to give me a responsive and usable environment made me suspect that the hard drive was on the way out or there were other serious issues with the Mac (dead ram or SATA controller problems).

I managed to limp it to the About This Mac summary and confirm that all of the ram chips were working, it was running El Capitan and that there were no obvious hardware problems (other than how slow it was), it reported a functional SuperDrive so that should work for a reinstall, assuming the hard drive is the only problem.

The first step was to open the case and swap the drive out ready for a reinstall. I was greeted by dust, lots and lots of dust, this is the result of not remembering how many years ago you opened the case and actually cleaned it. Clean your computers people, they will thank you for it. I also forgot how damn heavy the case is, luging up stairs and outside for a clean was a pain.

A quick once over with the air duster cleaned most of the crap out (I dismantled the fan assemblies later and deep cleaned them along with the optical drive bay and rear fans) and it was ready for the drive swap.

Rebuilding my 2008 Mac Pro – Things you forget, things that are broken and stupid decisions

Removing the hard drive caddies reminded me of some seriously short sighted decisions I made years ago when I was lazy, stupid and wanted to fit an SSD drive to the mac.

In my haste and clearly not wanting to buy a proper caddy converter to change a 3.5 to a 2.5 drive (you could not use the standard drive bay adapters it required a full bay converter like an Ice Dock or similar) I had decided to (grimace) cut the SATA and power loom and reroute it to the gap behind the optical drives. So now there was a partially usable loom and cables strewn about and looking really quite awful, there was also missing mounting screws, resulting in only two of the four hard drive bays being usable.

A destroyed SATA and power loom, sometimes I make idiotic decisions

First item on the shopping list, a new loom, thankfully after a quick scout on the web and eBay I found a brilliant company called The Bookyard who had a loom for roughly £10 + VAT (Mac Pro Hard Drive Connection Cable) they even provided free mounting screws. However the knackered loom would not stop me from progressing just limit my options until a new one was installed.

In the years in between the loom cutting and now I had purchased a couple of bay converters that would allow me to easily install a SSD, I had a OCZ Trion 100 240GB drive sitting in an external caddy not being used so I repurposed this for the Mac Pro (it is not a great SSD and there are far better for modern computers but as the Mac Pro only has SATAII it would be perfectly suitable). With the drive fitted it was time to power up and do a clean install from a DVD.

The second boot was not quite as successful as the first, I was greated by the Mac chime, followed by no video and then grinding noises.

Troubleshooting these one by one I started with the grinding noises, this was caused by me trying to open the SuperDrive and it fowling on the case, in my view this was not that bad and likely could be solved by further cleaning or adjusting where the drive sits. For now I ignored this fault and moved on to the second issue no video.

This was actually a problem of my own making, the original graphics card in the Mac had long ago been replaced with a non Mac EFI Nvidia card that (again thanks Apple for being difficult) wont present any display until the graphical subsystem is initialized (so no hold option for boot choices etc). This presented some reasonably serious problems, whilst video may work in recovery mode on El Capitan (this may not work at all if it only currently works with custom Nvidia drivers) it’s certainly never going to work booting an install disc that originally came with the Mac.

At this stage I scratched the idea of doing a clean install from a DVD and attempted to get video output by blind booting into the currently installed El Capitan recovery mode. To achieve this I had to remove the SSD and reinstall the original hard drive, with this done and a blind boot using the recovery shortcuts (Command + Option + R) I was left with an excruciating wait but eventually recovery mode appeared. This was quite a relief as all progress would have had to stop until I had sourced a suitable video card had this not worked.

The SSD was refitted in the only other working bay and I restarted the recovery boot, after some faffing and erasing in disk utility I was able to begin the install of El Capitan onto the SSD. With this complete the original drive was removed and the SSD installed into bay one, powering back on it booted exceptionally quickly. This was excellent news and indicated that the issue had most likely been with the old drive being on its last legs, I suspect there were also configuration issues but hopefully not any underlying SATA problems.

Next item for the shopping list, was a recentish PCIe Mac EFI graphics card, it would be best if I could source one of these (even if it was not fitted unless rebuilding) as it would make booting / recovery easier. After some looking in the usual places, I came to the conclusion that they were a bit too expensive for the purpose of just having access to boot options, and given that blind booting works I could hold out on this for now.

Rebuilding my 2008 Mac Pro – DDR2 FB-DIMMS Are cheap now

Back when I first got the Mac, memory was very expensive as it was Fully Buffered, however in the proceeding 10 years this ram has become inexpensive. A quick search and £22 later I had 24 gigs of it on the way to me in matched 4 gig sticks, removing the original 2×1 gig sticks and leaving the aftermarket 2×4 gig ones will result in a healthy 28 gig of ram. Not bad for a 10 year old computer. Whilst I waited for the ram, I took the opportunity to work on the SuperDrive.

Two 1 Gig DDR2 FB-DIMMS — The removed 2 x 1 DDR2 FB-DIMMS

Rebuilding my 2008 Mac Pro – Ding Dong The Drive Is Dead

After dismantling the Mac, removing the front fan assembly and poping out the optical drive caddy it was clear that there was still vast quantities of built up dust and crap everywhere. I spent a good hour cleaning all of this with air dusters, cloths and cleaning fluid, and it did not surprise me at all that the SuperDrive had failed to open, the drop down doors on the case were totally caked in dust and very hard to move.

After freeing and cleaning the drive doors and a quick temporary reassembly the SuperDrive was now opening without fowling and no longer making grinding noises. However all was not well, any disc that was inserted failed to read and resulted in the familiar noises of a dead or dying optical drive. The result of years of dust and under use of the drive had killed it, it would need to be replaced.

A Dead 2008 SuperDrive — The old dead SuperDrive, optical drives hate dust!

The original Mac Pro 2008 SuperDrive is IDE, which is somewhat of a pain, on all subsequent models of the Mac Pro they moved to SATA (why they stuck with IDE on the 2008 is anyone’s guess as all the HDDs were SATA). On a quick trawl of eBay I located a second hand 2009 drive (SATA) with the full caddy for £10, a great purchase as the caddy is worth the £10 on its own.

Now the 2008 Mac does have a trick up its sleeve, under the front fan assembly are two hidden SATA ports (even more reason to wonder why they did not use these), which are perfectly capable of running the optical drives, these have frequently been used to add eSATA ports to the back of the mac as shown in this video.

Usefully there is enough room under the first HDD bay to route cables up to the optical drive, however you will need extra long SATA cables (as I found out to my mistake) and you will require a power converter to transfer from molex to SATA power.

I ended up using the following combination of cables, there is certainly a more efficient way of doing this but I had not initially anticipated how long the SATA data cables needed to be so I had to order some extenders. 1 x Sabrent SSD / SATA Hard Drive Connection Kit (£4.73) and 2 x Valueline VLCP73125V05 0.50m SATA 7 Pin and 15 Pin Male to SATA 7 Pin + 15 Pin Female SATA 22 Pin Extension Cable (£4.99) for a total of £14.71.

This gave me the ability to fit two SATA optical drives should I need and it made sense that if I was going to the trouble to route one set of cables I may as well do both even if I don’t immediately use them. I secured the cables to the inside of the case with electrical tape so they would not catch on the caddy and cause issues if I needed to add or remove drives.

Whilst I waited for the caddy and drive to arrive from eBay I repurposed an underused LiteON iHAS DVD burner, removed its front bezel and fitted it in place of the defunct SuperDrive. All of the cabling worked perfectly and the Mac could now read and write CDs and DVDs. The new SuperDrive when it arrives will be fitted as a secondary optical drive (assuming it works) and I will change to the new caddy as the original is bent and slightly buckled from previous manhandling.

Rebuilding my 2008 Mac Pro – Loom Swap And Ram Upgrade

By this time both the new ram and the replacement SATA loom had arrived, along with two replacement blanking plates for the back of the Mac (unsure where they had got to but The Bookyard had them in stock so I had ordered them at the same time as the loom, they were a little pricey but worth it).

Once again out came the fan assembly and four screws later the loom was out, it was a far less complicated process than I expected and hats of to Apple for making this range of Macs (unlike modern ones) incredibly user serviceable. With the loom replaced all four bays were now functional and ready for use. The ram cards were removed, cleaned (again, how does one computer trap so much dust) and repopulated with the new ram, taking the total up to a very decent 28 gigs.

Mac Pro 2008 Full Ram Card — A full ram card in the refurbished Mac Pro 2008

With the cards back in and the fan assembly refitted (hopefully for the last time) the Mac booted up and both the ram and optical drives were registering correctly.

Rebuilt MacPro 2008 System Overview — Rebuilt MacPro 2008 system overview showing upgraded ram and GTX 670 graphics

MacPro 2008 Storage Info — Rebuilt MacPro 2008 showing new SSD drive and replacement optical DVD drive.

Other than a final clean and the later addition of an extra optical drive the Mac Pro was now rebuilt and complete, lets hope it lasts for another 10 years!

Mac Pro 2008 Rebuilt — The rebuild Mac Pro 2008, or the dust monster as it should be called.

Rebuilding my 2008 Mac Pro – What Did It Cost?

Total spend was £71.36, which I think is quite reasonable based on what needed to be replaced. I am not taking into consideration the cost of the SSD, the caddy it went in or the DVD writer I had sitting around. If you needed to purchase all of these as well it would likely be more than double the cost of what I spent. Money could also have been saved if I had not been a complete idiot and cut through the SATA loom, or indeed if I had purchased less ram, I am not sure that I will see the immediate benefit of 28 gigs, but why not 🙂

Still it was a fun projected that has turned a forgotten and unusable workstation into something that I am now complimenting my setup with and I hope I will continue to use for some time to come.

I hope you enjoyed this article which was as much a trip up memory lane for my Mac ownership as it was a rebuild article.

Frustrating Tech – IPV6 Inbound KVM Issues

1st February 201810th February 2018 blakeLeave a comment

IPv6 inbound KVM issues caused some head scratching but ultimately lead to a solution, networking is tricky and often frustrating, but a little perseverance / angry googling can pay dividends.

Having some time ago built a general purpose server (from my old gaming pc and now running Ubuntu 16.04) that provides services to our home network (Plex server, download management, tv scheduling etc) I wished to expanded it to provide virtual machine hosting via KVM. The VMs were to initially provide UNMS for my Ubiquity gear and a homebridge server, for my Apple HomeKit automation.

As part of this expansion I wanted to provide physical interfaces for the small amount of VMs that would be spun up, so the logical choice was to install a multi-port network card. A quick trawl of eBay and I picked up a Intel PRO 1000 PT Quad Port PCIe card.

A not dissimilar picture of the Intel Pro 1000 PT Quad in my home server.

It installed fine and worked perfectly with the KVM setup (all managed and controlled by a Wok plugin called Kimchi), however when I configured IPv6 on the VMs I was getting very odd behaviour. IPv4 worked perfectly in and out and IPv6 worked perfectly out from the VM, however inbound IPv6 was very flakey or non existent, cue lots of head banging, configuration changes and firewall tinkering.

This went on for some time until I stumbled on a Redhat mailing list with someone having very similar behaviour to what I was experiencing, they had managed to manually resolve the issue by starting a tcpdump on the guest VM which then kicked the interfaced into receiving inbound IPv6 packets.

Very strange indeed, but thankfully a followup post detailing how to put the interfaces into promiscuous mode pushed me in the right direction and solved the issue. After any reboot or network interface initialisation, once the VMs have been started I have found putting the mactapv interfaces for the respective VMs into promiscuous mode resolves the issue.

Interface promiscuous mode can be set using the following command.

ip l set $dev promisc on

Where $dev is the name of the interface, in my case macvtap0 and macvtap1.

Hopefully this should prompt me to automate this on the VM startup and if anyone else if having similar issues offer a solution.