my 4 layer corne split keyboard layout (germany)

I’ve been using my corne split keyboard for about 3 weeks now and during that time I’ve made a couple of changes to the layout.

Right now I am quite happy with the content I am typing these days but I guess over time I am still going to optimize further.

Nevertheless I want to document my layout here, in a picture and with the json file that can be used with the QMK configurator.

building a corne split keyboard

It’s been a while since during a Hack-the-Planet episode I was gifted two PCBs of a corne keyboard by PH_0x17 of Nerdbude and ClickClackHack fame.

Since a picture says more than a thousand words, I give you the result first:

my crkbd based keyboard

This keyboard design is made from the ground up as open source and naturally is fully available as a GIT repository containing everything you need to start: PCB schematics, drawing, documentation and firmware source code.

It took me a couple of months to get all the required parts ordered and delivered. Many small envelopes with parts that seemlingly are only produced by a handful of manufacturers. But anyways: After everything had arrived and was checked for completeness my wife took the hardware parts into her hands and started soldering and assembling the keyboard.

And so this project naturally is split up between my wife and me in the most natural (to us) way: My wife did all the hardware parts – whilst I did the software and interfacing portion. (Admittedly there only was to be figured out how to get the firmware compiled and altered to my specific needs)


So make the jump over to the blog of my wife and enjoy the hardware portion over there. Come back for the software portion. I will only leave some pictures of the process here:


After putting the hardware together it was time to get the firmware sorted as well. This keyboard design is based upon the open source QMK (Quantum Mechanical Keyboard) firmware.

Conveniently QMK comes with it’s own build tools – so you will be up and running in no time. Since I had purchased Arduino ProMicro controllers I was good with the most basic setup you can imagine. As the base requirements for the toolchain where minimal I went with the machine that I had in front of me – a Raspberry Pi 4 with the standard Raspberry Pi OS.

These where the steps to get going:

  • get Python 3 and the qmk tool installed – I’ve chosen not to use the tool setup procedure but instead go with a separate clone of the QMK firmware repository.
python3 -m pip install --user qmk
  • clone the QMK firmware repository and get the QMK tool running (in the /bin folder of the firmware repository – it’s actually just a python script)
git clone
cd qmk_firmware
git submodule sync --recursive
git submodule update --init --recursive --progress
make crkbd:default
  • create your own keymap to work with. You gotta use the crkbd firmware options as a default for this keyboard. The command below will generate a subfolder with the name of your keymap in the keyboards/crkbd/keymaps folder with the default settings of the crkbd keyboard firmware.
qmk new-keymap -kb crkbd
  • build your first firmware by running the command below (note: btk-corne is the name of my keymap)
qmk compile --clean -kb crkbd/rev1/legacy -km btk-corne
success! The first firmware is compiled
  • now you can flash the firmware to both ProMicro controllers. The most straight forward way for me was using avrdude on the commandline. In my case the device is added as /dev/ttyACM0 and the compiled firmware named crkbd_rev1_legacy_btk-corne.hex.

    When you got all this information you need to plug in the ProMicro and trigger a reset by bridging Ground and the Reset Pin. If you added, like we did, a button for reset you can use this. After hitting reset the ProMicro bootloader will enter the state where it’s possible to be flashed. Reset it and THEN run the avrdude commandline.

    The full commandline is:
avrdude -p atmega32u4 -P /dev/ttyACM0 -c avr109  -e -U flash:w:crkbd_rev1_legacy_btk-corne.hex
  • (alternatively) you can also use QMK Toolbox to flash the firmware. Also works.

So now you know how to get the firmware compiled and running (if not, look here further). But most probably you are not happy with some aspects of your keymap or firmware.

By now you might ask yourself: Hey, I’ve got two ProMicros on one keyboard. Both are flashed with the same firmware. Into which of the two do I plug in the USB cable that then is plugged into the computer?

The answer is: by default QMK assumes that you are plugging into the left half of the keyboard making the left half the master. If you prefer to use the right half you can change this behaviour in the config.h file in the firmware:

You have to plug in both of them anyway at times when you want to flash a new firmware to them as you adjust and make changes to your keymap.

Thankfully QMK comes with loads of options and even a very useful configurator tool. I used this tool to adjust the keymap to my requirements. The process there is straightforward again. Open up the configurator and select the correct keyboard type. In my case that is crkbd/legacy. The basic difference between legacy and common is a different communication protocol between the two halves. This really only is important when features are used that require some sort of sync between the two haves – like some RGB LED effects. Since I did not add any LEDs to the build I go with legacy for now. Maybe I need some features later that require me to go with common.

The configurator allows you to set up the whole keymap and upload/download it as a .json file.

That .json file can easily be converted into the C code that you need to alter in the actual keymap.c file. Assuming that the .json file you got is named btk-corne.json the full commandline is:

qmk json2c btk-corne.json

Then simply take this output and replace the stuff in the keymap.c with it:

Now you compile and flash again. And if all went right you’ve got the new keymap and firmware on your keyboard and it’ll work just like that :)

Hack-the-Planet Podcast: Episode 25

Diesmal gehen wir der Frage nach, wie viel Speicherplatz ein 5 Meter PNG File benötigt, das Daniel für seinen DIY Arcarde Automaten gebaut hat, wundern uns über LED-Leuchten an, die wie echter Himmel aussehen sollen und freuen uns über den “Digitalen Alltag als Experiment”.


ASIO4All –
Corne Keyboard –
Prusa Mini –
Andreas YouTube Kanal:
Forschungsgemeinschaft elektronische Medien e.V. TU-Ilmenau:
Overpass Turbo –
Overpass API –
Openstreetmap –
Resilio Sync –
Buch Alltag als Experiment –
Bürowabe von Panasonic –
Selbstgebautes Ambilight –
Misola LED Tageslichtpanel –
Mandalorian Making Of –
Farbwiedergabeindex CRI –
Retrogames e.V. –
Retropie –
Bubble Bobble Bartop Arcade built –
LEGO Star Wars 75253 BOOST Droide –
Ikea Bygglek –
Arpanet auf ESP32 –
PH_0x17 baut Arpanet auf ESP32 –

Hack-the-Planet Podcast: Episode 24

Wir haben uns wieder zusammengefunden – diesmal mit unserem Gast Philipp von – und haben über Tastaturen, Github Arctic Vault, OCRmyPDF und einen selbstgebauten Arcade Automat gesprochen.

Wie schon bei der letzten Folge 23 haben wir zusätzlich zur Tonspure eine Videospur aufgezeichnet – allerdings nicht als “Talking-Heads” Episode sondern während wir über die Themen sprechen versuchen wir die Themen mit zusätzlichem Inhalt zu unterfüttern – Links und Bilder eben.

Link zu YouTube

Apple Watch repair attempt

After years of use the display of my trusty Apple Watch popped off. It seems the glue had given in and failed.

As there was nothing wrong with the watch otherwise I am attempting a repair.

I’ve got the new adhesive seal, a new force touch sensor and a new battery while I am at it.

Add opening and disassembling was an adventure in itself I had to give up for now as I am missing an exotic Y000 screwdriver.

While I wait for this to arrive – here is the screw I had to stop at:

multi-Protocol to MQTT tool

When you are dealing with IoT protocols, especially at hobby-level, you probably came across the MQTT protocol and the challenge to have all those different devices that are supposed to be connected actually get connected – preferably using the MQTT protocol.

Recently this little project came to my attention:

OpenMQTTGateway project goal is to concentrate in one gateway different technologies, decreasing by the way the number of proprietary gateways needed, and hiding the different technologies singularity behind a simple & wide spread communication protocol: MQTT.


OpenMQTTGateway support very mature technologies like basic 433mhz/315mhz protocols & infrared (IR) so as to make your old dumb devices “smart” and avoid you to throw then away. These devices have also the advantages of having a lower cost compared to Zwave or more sophisticated protocols. OMG support also up to date technologies like Bluetooth Low Energy (BLE) or LORA.

Of course, there is a compatible device list…

Hack-The-Planet Podcast: Episode 17

Hack-The-Planet Podcast: Episode 16


Linux mac80211 compatible full-stack Wi-Fi design based on SDR

In a tweet we were given an early christmas present – open-sdr released an open source software Wi-Fi stack that utilizes software-defined-radio technology to implement actual working Wi-Fi.


  • 802.11a/g; 802.11n MCS 0~7; 20MHz
  • Mode tested: Ad-hoc; Station; AP
  • DCF (CSMA/CA) low MAC layer in FPGA
  • Configurable channel access priority parameters:
    • duration of RTS/CTS, CTS-to-self
    • SIFS/DIFS/xIFS/slot-time/CW/etc
  • Time slicing based on MAC address
  • Easy to change bandwidth and frequency:
    • 2MHz for 802.11ah in sub-GHz
    • 10MHz for 802.11p/vehicle in 5.9GHz
  • On roadmap: 802.11ax

See this demonstration:

TESLA PowerWall 2 Security Shenanigans


  • GUI wide open.
  • Default password on WiFi and management interface
  • Attacker can cause financial damage to consumer
  • Attacker can dump entire PW Load into the grid at once
  • Attacker can oscilate between CHARGING and DUMPING (microseconds, the poor sub-station!)
  • Attacker can change grid codes.

More here. At least somebody looked into the security and attack potential of these things.

DIRECTIVE 2009/24/EC – Article 6 – Decompilation

Article 6

  1. The authorisation of the rightholder shall not be required
    where reproduction of the code and translation of its form
    within the meaning of points (a) and (b) of Article 4(1) are
    indispensable to obtain the information necessary to achieve
    the interoperability of an independently created computer
    program with other programs, provided that the following
    conditions are met:

    (a) those acts are performed by the licensee or by another
    person having a right to use a copy of a program, or on
    their behalf by a person authorised to do so;

    (b) the information necessary to achieve interoperability has not
    previously been readily available to the persons referred to
    in point (a); and

    (c) those acts are confined to the parts of the original program
    which are necessary in order to achieve interoperability.
  2. The provisions of paragraph 1 shall not permit the information obtained through its application:

    (a) to be used for goals other than to achieve the interoperability of the independently created computer program;

    (b) to be given to others, except when necessary for the interoperability of the independently created computer program;

    (c) to be used for the development, production or marketing of
    a computer program substantially similar in its expression,
    or for any other act which infringes copyright.
  3. In accordance with the provisions of the Berne
    Convention for the protection of Literary and Artistic Works,
    the provisions of this Article may not be interpreted in such a
    way as to allow its application to be used in a manner which
    unreasonably prejudices the rightholder’s legitimate interests or
    conflicts with a normal exploitation of the computer program.

Original in english and german.

turn an Xbox 360 HD-DVD drive into an Fluorescent Scanning Thermal Microscope (FSTM)

Curtesy of Sam Zeloof I came around the fact that I’ve got a good part of a FSTM in a cupboard here.

Apparently my choice of purchasing the HD-DVD drive for the Xbox 360 will ultimately pay off!! As we all know Bluray won that format war back in the days.

But now it seems that this below would be useable for something:

Over the life of nuclear fuel, inhomogeneous structures develop, negatively impacting thermal properties. New fuels are under development, but require more accurate knowledge of how the properties change to model performance and determine safe operational conditions.

Measurement systems capable of small–scale, pointwise thermal property measurements and low cost are necessary to measure these properties and integrate into hot cells where electronics are likely to fail during fuel investigation. This project develops a cheaper, smaller, and easily replaceable Fluorescent Scanning Thermal Microscope (FSTM) using the blue laser and focusing circuitry from an Xbox HD-DVD player.

The Design, Construction, and Thermal Diffusivity Measurements of the Fluorescent Scanning Thermal Microscope (FSTM)

As mentioned, Sam Zeloof shows off the actual chip in more detail:

Xbox 360 HD DVD player photodiode chip reverse engineering, includes 49 bits of antifuse trimming from the factory

Hack-The-Planet Podcast: Episode 10


Odometer for the HUD

Since I am back at developing the Head-Up-Display app I was writing about in February (yeah, mornings got darker again!) I want to leave this nice looking Odometer Javascript library here:

Odometer is a Javascript and CSS library for smoothly transitioning numbers. See the demo page for some examples.

Odometer’s animations are handled entirely in CSS using transforms making them extremely performant, with automatic fallback on older browsers.


Hack-The-Planet Podcast: Episode 009

Hertzian Landscapes

I played with SDR – Software Defined Radio – back in 2013. I’ve still got the equipment around.

Now that I am thinking about it – there is a practical use-case that I will look into in the coming months for sure for it. And just to mention this use case here: With SDR I could create a more versatile 443/886 Mhz receiver.

Anyhow. SDR hardware allows you to access a whole spectrum of radiosignals at once. And a common way to visualize the spectrum is to draw the amplitudes in a line add each new measurement as a new line – color/brightness coded.

What you get is some sort of waterfall diagram that looks like this:

Hertzian Landscapes (2019) is a live visualization of the radio spectrum. Unlike visible light, waves in the radio spectrum cannot be perceived by us directly yet this space is teeming with human activity. Hertzian Landscapes employs a digital receiver to scan large swaths of radio spectrum in near real-time and visualizes thousands of signals into a panoramic electromagnetic landscape. Users can zoom in to specific frequencies by positioning themselves in front of the panorama as if controlling a radio tuner with their body, giving them a sense of walking through the spectrum.
From radio broadcasts to weather satellites and from medical implants to aeronautical navigation, the radio spectrum is divided into hundreds of designated slices each tied to a specific application. Based on a localized frequency database that describes these slices, signals are annotated to provide information about their theoretical type and application.

C# PlayStation emulation

After looking into the NES emulation written entirely in C# I came across a similar approach using C# to emulate a full and much more complex PlayStation 1.

Scott Hanselman wrote:

I then stumbled on this very early version of a PSX Emulator in C#.

Now, if you were to theoretically have a Playtation SCPH1001.BIN BIOS and then physically owned a Playstation (as I do) and then created a BIN file from your physical copy of Crash Bandicoot, you could happily run it as you can see in the screenshot below.

Hack-the-Planet Podcast: Episode 006

Episode 006: “Monitoring Release Pipeline” ist fertig und steht bald zum Download und zeit-sourveränem anhören bereit.

Auf der Homepage, im Feed und auf YouTube:

Diesmal unterhält Andreas sich mit mir über:

QuickCharge 3 (QC3) enable your Arduino project

You might have asked yourself how it is that some phones charge up faster than others. Maybe the same phone charges at different speed when you’re using a different cable or power supply. It even might not charge at all.

There is some very complicated trickery in place to make those cables and power supplies do things in combination with the active devices like phones. Many of this is implemented by standards like “Quick Charge”:

Quick Charge is a technology found in QualcommSoCs, used in devices such as mobile phones, for managing power delivered over USB. It offers more power and thus charges batteries in devices faster than standard USB rates allow. Quick Charge 2 onwards technology is primarily used for wall adaptors, but it is also implemented in car chargers and powerbanks (For both input and output power delivery).

Wikipedia: Quick Charge

So in a nutshell: If you are able to speak the quick charge protocol, and with the right cable and power supply, you are able to get anything between 3.6 and 20V out of such a combination by just telling the power supply to do so.

This is great for maker projects in need of more power. There’s lots of things to consider and be cautious about.

“Speaking” the protocol just got easier though. You can take this open source library and “power up your project”:

The above mentioned usage-code will give you 12V output from the power supply. Of course you can also do…:

Be aware that your project needs to be aware of the (higher) voltage. It’s really not something you should just try. But you knew that.

More on Quick Charge also here.

smart arduino fish pond feeder: TurtleFeeder

We’ve got several quite big fish tanks in our house. Mainly used by freshwater turtles.

say Hi! to Wilma.

These turtles need to be fed every once in a while. And while this is not an issue normally it’s an issue if you leave the house for travel for an extended period of time.

Of course there are humans checking on everything in the house regularly but as much as can be automated should and will be automated in our household. So the requirement wa to have the turtle feeding automated.

To achieve this is would be necessary to have a fixed amount of turtle food be dispensed into the tanks on a plan and with some checks in the background (like water quality and such).

It’s been quite a hassle to come up with a plan how the hardware should look like and work. And ultimately i’ve settled on retrofitting an off-the-shelf fish pond feeder to become controllable through MQTT.

The pond feeder I’ve found and used is this one:

It’s not really worth linking to a specific product detail page as this sort of feeder is available under hundreds of different names. It always looks the same and is priced right around the same.

If you want to build this yourself, you want one that looks like the above. I’ve bought 3 of them and they all seem to come out of the same factory somewhere in China.

Anyway. If you got one you can easily open it up and start modifying it.


the wheel is turned by a DC motor and the switch is triggered by the wheels fins
I’ve added a connector to the switch and the motor cables for quick connect

The functional principle of the feeder is rather simple:

  1. turn the feeder wheel
  2. take the micro-switch status in account – when it’s pressed down the wheel must be pushing against it
  3. turn it until the micro-switch is not pressed anymore
  4. turn some more until it’s pressed again

Simple. Since the switch-status is not known on power loss / reboot a calibration run is necessary (even with the factory electronics) every time it boots up.

After opening the feeder I’ve cut the two cables going to the motor as well as the micro-switch cables. I’ve added a 4-Pin JST-XH connector to both ends. So I can reconnect it to original state if desired.

These are all the parts needed:

I am using a Wemos D1 Mini and a couple of additional components apart from the prototype board:

A PN2222 NPN transistor, a rectifier diode 1N4007 and a 220 Ohm resistor.

I’ve connected everything according to this schematic I’ve drawn with Fritzing:

I’ve then prototyped away and put everything on the PCB. Of course with very limited solderig skill:

As you can see the JST-XH connector on Motor+Switch can now be connected easily to the PCB with all the parts.

Make sure you check polarity and that you did correctly hook up the motor and switch.

When done correctly the PCB (I’ve used 40mm x 60mm prototype pcb) and all cables will fit into the case. There’s plenty of room and I’ve put it to the side of it. I’ve also directly connected an USB cable to the USB port of the Wemos D1 Mini. As long as you put at least 1A into it it will all work.


Since the Wemos D1 Mini sports an ESP8266 and is well supported by Arduino it was clear to me to use Arduino IDE for the software portion of this project.

Of course everything, from schematics to the sourcecode is available as open source.

To get everything running you need to modify the .ino file in the src folder like so:


What you need to configure:

  • the output pins you have chosen – D1+D2 are pre-configured
  • WiFi SSID + PASS
  • MQTT Server (IP(+Username+PW))
  • MQTT Topic prefix

Commands that can be sent through mqtt to the /feed topic.

MQTT topics and control

There are overall two MQTT topics:

  • $prefix/feeder-$chipid/state
    This topic will hold the current state of the feeder. It will show a number starting from 0 up. When the feeder is ready it will be 0. When it’s currently feeding it will be 1 and up – counting down for every successfull turn done. There is an safety cut-off for the motor. If the motor is longer active than configured in the MaximumMotorRuntime variable it will shut-off by itself and set the state to -1.
  • $prefix/feeder-$chipid/feed
    This topic acts as the command topic to start / control the feeding process. If you want to start the process you would send the number of turns you want to happen. So 1 to 5 seems reasonable. The feeder will show the progress in the /state topic. You can update the amount any time to shorten / lengthen the process. On the very first feed request after initial power-up / reboot the feeder will do a calibration run. This is to make sure that all the wheels are in the right position to work flawlessly.

So if you want to make it start feeding 3 times:

mosquitto_pub -t house/stappenbach/feeder/feeder-00F3B839/feed -m 3

And if you want to see the state of the feeder:

mosquitto_sub -v -t house/stappenbach/feeder/feeder-00F3B839/state

All in all there are 3 of these going to be running in our household and the feeding is going to be controlled either by Alexa voice commands or through Node-Red automation.