Hardware for mauveine

Last updated: 6 June 2024

System requirements

Minimum supported specs for running mauveine

  • Any model of Raspberry Pi (Raspberry Pi 2 or better required for interaction, including alarms)
  • 480x320 or better touchscreen display (SPI, DSI or HDMI)
  • 8GB or larger SD card
  • Speaker/hardware audio required for alarm functions
  • 512MB RAM
  • Raspberry Pi OS Lite 32 or 64 bit (bullseye) - 22 Sep 2022 or later

It may be possible to run mauveine in other configurations not meeting this specification, but it is not supported to do so.

This application is the work of a single developer working in her spare time.

  • “Supported” in this context means “issues will get looked into as and when time allows, and may not be prioritised”.
  • “Unsupported” means “you are absolutely on your own if this does not work”.
  • Raspberry Pi 4 or better
  • 800 x 480 5” capacitive touchscreen display (SPI, DSI or HDMI)
  • 8GB or larger SD card
  • Speaker/Hardware audio
  • 1GB RAM (4GB RAM for remote editing/debugging under VS Code)
  • Raspberry Pi OS Lite 64 bit (bookworm) - 5 Dec 2023 or later
  • Real time clock

Compatibility

Some hardware requires changes to the config.txt and/or cmdline.txt files. This are found in the first (boot) partition on the SD, which is automatically mounted when the SD card is inserted in a PC on Windows and on some graphical Linux OSes.

On a running Raspberry Pi, these files can be found in /boot for bullseye systems or /boot/firmware for bookworm and newer systems.

Raspberry Pi models

All Raspberry Pi models from the Raspberry Pi 2 onwards are compatible with mauveine.

Start up and button press responses may be slow on older models. Pi 1 models are unsupported, but may still be sufficiently functional, particularly as clocks in non-interactive mode

The following hardware has been tested and is known to be working with mauveine:

  • Raspberry Pi 2 model B
  • Raspberry Pi 3 model A+
  • Raspberry Pi 3 model B
  • Raspberry Pi 4 model B
  • Raspberry Pi Zero W
  • Raspberry Pi Zero 2 W
  • Raspberry Pi CM4 (Raspberry Pad 5 carrier)
  • Raspberry Pi 5

The following hardware has been tested, and mauveine is partially functional (and unsupported) on it.

  • Raspberry Pi 1 Model A+ - application launches, but GUI unusable

It has not been tested on, but should be able to run on the Pi CM3.

Displays

If it has no information, mauveine will attempt to guess your display size. It will get it wrong. This is not terrible, it just means that some on screen elements will be oddly sized until you set the display resolution.

The recommended display for use with mauveine is the Official Raspberry Pi 7” display. This will produce quite a large clock, but it is a reasonable quality display that is well supported by case vendors.

There is support for a number of generic display configurations based on commonly found specifications sold on the internet. These use DPI settings calculated using aspect ratio, size and resolution. They are likely to be a bit out, but probably not visibly so.

The following displays have been tested and have specific support within mauveine

screen_type Size Resolution Display Name
hyperpixel4sq 4” 720 x 720 Hyperpixel 4.0 Square display
mpi3051 3.5” 480 x 320 LC MPI3501 3.5 inch SPI screen
mpi7002 7” 1024 x 600 LC MPI7002 7 inch HDMI screen
pi7touch 7” 800 x 480 Official Raspberry Pi DSI screen
raspberrypad5 5” 800 x 480 CM4 carrier board with DSI screen
waveshare43dsi 4.3” 800 x 480 Waveshare 4.3 “ DSI screen
waveshare4rounddsi 4” 720 x 720 Waveshare 4” round DSI screen
waveshare5dsi 5” 800 x 480 Osoyoo / Waveshare 5” DSI screen
waveshare5oled 5” 960 x 544 Waveshare 5” HDMI AMOLED display
waveshare7zero 7” 1024 x 600 Waveshare 7” Pi Zero display

Notes:

  1. Although the clock displays on the MPI3051 screen I have not been able to get configuration dialogs to appear reliably. I do not recommend using this display except in non-interactive mode.

  2. Pixel burn in mitigation should be enabled when using an AMOLED display.

  3. Some displays like the HyperPixel 4 expose a hardware backlight interface with only two values, 0 and 1. On these displays, setting the hardware brightness to less than 100% will turn them off. In my opinion this is a bug in the display driver, and I will not therefore code around it in mauveine. It is possible, however, to set “disable_hw_brightness” in the “display” section of the config file to “True”. This will force software backlight control, which is really designed for OLED displays, but actually works reasonably well with the Hyperpixel displays as they have a very dark black for a non-OLED screen.

  4. The Osoyoo and Waveshare 5” displays may or may not be using the same panel (in fact they probably aren’t given that they seem to require different kernel drivers) but they are the same physical size and functionally identical for the purpose of configuring them within mauveine.

  5. The Raspberry Pad 5 reports a hardware backlight to the OS but does not appear to support hardware backlight control, possibly because it has physical buttons for this.

  6. The Waveshare 4.3” screen is interesting because it can be bought inside its own plastic case. This makes it a really good candidate for a standalone device. The default configuration of the OpenSCAD file for mauveine will print a stand for this case.

SPI, DSI and HDMI displays are all supported. If you can get a Pi to show its boot sequence on a display, then it will be usable. Displays like the Inky Impression which rely on custom graphics APIs to draw on them are not supported.

On the whole DSI displays seem to work best, and allow for brightness control in hardware. HDMI displays are reasonably plug and play, although they may require a special graphics mode set up in /boot/config.txt. SPI displays are variable, and usually require some playing around with drivers that assume you are using X to get them to work. They also tend to have performance issues due to having to push a lot of data over the GPIO interface.

While with appropriate settings, mauveine might be able to run on an e-ink display if it supports the standard Linux display drivers, current display refresh rates mean it is likely to be impractical to do this. In general e-ink displays do not support the Linux display driver and will not work with mauveine.

As part of its design, mauveine tries to size its GUI elements to a standard size to make them suitable for touch operation. By default, it makes an educated guess about how physically big your screen is based on its resolution. This may not work well on small screens that report a HD resolution and then downscale.

For this reason mauveine also contains a database of screen sizes for tested screen models, and the screen attached can be configured in the config file.

Screen rotation and touchscreens

Most users will be able to set the display rotation to their liking from within the mauveine interface using “display rotation” and/or “touchscreen rotation” in the advanced display settings menu, and need read no further in this section.

Screen rotation is complex, but the default eglfs graphics backend used by mauveine supports this, and configuration is integrated into the display database. Not all screens support eglfs (which requires the driver to support he linux Display Renderer Manager or DRM). Setting the display/force_fb config option to True will allow mauveine to work on such displays, but you would then have to configure the screen rotation outside of mauveine. The following information is provided for use with legacy drivers, and to enable those that need to to figure out how to configure their own display and touchscreen to rotate if they cannot get mauveine to do this for them.

Either way, mauveine fully supports portrait displays and you can make some nice looking clocks this way. Unfortunately if you are stuck without eglfs, then instructions for rotating your screen vary depending on your touchscreen and Pi model. It’s worth noting that the new kms Raspberry Pi graphics drivers have limited support for rotation. It’s sometimes possible to get things to work by using the old drivers, which may result in a loss of performance/power efficiency, but does work.

Rotating the screen often also requires rotating the touchscreen, which must be done separately. Most online tutorials suggest to use a program called xrandr. This program is for the the X11 graphical user interface and is not compatible with mauveine. Instead, touchscreen rotation can be set using udev. You need to find the name of the backlight device, which can usually be found in /sys/class/input/event0/device/name (or event1, event2 etc) but the evtest program may also be able to identify it for you if this does not work.

Create a file /etc/udev/rules.d/97-touchscreen-rotation.rules containing one of the following:

90 degree rotation
ATTRS{name}=="#name#", ENV{LIBINPUT_CALIBRATION_MATRIX}="0 -1 1 1 0 0 0 0 1"
180 degree rotation
ATTRS{name}=="#name#", ENV{LIBINPUT_CALIBRATION_MATRIX}="-1 0 1 0 -1 1 0 0 1"
270 degree clockwise rotation
ATTRS{name}=="#name#", ENV{LIBINPUT_CALIBRATION_MATRIX}="0 1 0 -1 0 1 0 0 1"

Replace #name# with the name of your touchscreen device, e.g. “EP0110M09”, “raspberrypi-ts”.

Example display configurations

Here are some sample display configurations.

Hyperpixel 4.0 Square (v2.0)

Why rotate a square display? The standard configuration has the power cable coming out of the bottom, which means it won’t stand up by itself. Putting the display upside down fixes this. The Hyperpixel 4.0 supports eglfs, and is supported out of the box by the display database, so it should not be necessary to configure rotation manually, but older display models may require something similar.

This display works in bookworm or bullseye. Some lines in config.txt (in /boot or /boot/firmware) are required.

Please ensure i2c and i2s support are disabled by commenting out these lines as below , as this display requires those pins and will not work with this enabled.

#dtparam=i2c_arm=on
#dtparam=i2s=on

Next, add a dtoverlay line to et up the display as follows (the kms-v3d line should already be there and needs to remain):

# Enable DRM VC4 V3D driver
dtoverlay=vc4-kms-v3d
dtoverlay=vc4-kms-dpi-hyperpixel4sq

Due to a limitation of this screen, it is likely to remain blank during the install process. Patience is advised.

For most users, this should be all that is needed. Touchscreen rotation will be automatically configured by mauveine when you select the correct display, and you need read no further.

If you do need to manually configure screen rotation, use the following line in config,.txt instead.

dtoverlay=vc4-kms-dpi-hyperpixel4sq,rotate=180

After it boots, log in to create /etc/udev/rules.d/97-touchscreen-rotation.rules as follows

ATTRS{name}=="EP0110M09", ENV{LIBINPUT_CALIBRATION_MATRIX}="-1 0 1 0 -1 1 0 0 1"

Then reboot and everything should now be the “right” way up.

LC MPI7002 7 inch HDMI screen in portrait mode

HDMI displays should generally be supported by mauveine out of the box, and this is true of the LC MP17002, but it may be that manual configuration could be necessary on older Pi models if a reversion to the linuxfb backend is required.

The setup below produces quite a good looking clock, but is not easy to get working. A 90 degree rotation is required here. Rotation will not work with the modern display drivers (unless you are using the eglfs backend). Ensure that there are no lines in /boot/config.txt matching the commented out lines. The other lines need adding

#dtoverlay=vc4-kms-v3d
#dtoverlay=vc4-fkms-v3d
display_hdmi_rotate=1
hdmi_cvt=1024 600 60 
hdmi_group=2
hdmi_mode=87
hdmi_drive=2

What this does is set up a custom display mode, which seems to be required to avoid the display driver thinking the display is 480x640 and stretching everything out. hdmi_drive=2 says to use the HDMI protocol (and send sound to the display). hdmi_group=2 tells the driver to use DMT (monitor) modes rather than CEA (TV) modes. Nearly all Pi compatible monitors use DMT. hdmi_cvt should be set to the display’s native (not rotated) resolution. Nearly all Pi displays use a 60Hz refresh.

Create /etc/udev/rules.d/97-touchscreen-rotation.rules as follows

ATTRS{name}=="wch.cn USB2IIC_CTP_CONTROL", ENV{LIBINPUT_CALIBRATION_MATRIX}="0 1 0 -1 0 1 0 0 1"

You might think that’s the figure for 270 degree rotation. You would be right. Different rotations may be required for display and touchscreen. There’s probably a really good reason for that, and experimentation may be required.

LC MPI3501 3.5” SPI/GPIO pin display

This is very much not a recommended configuration. It is a cheap display with poor touch sensitivity, you wil not be able to connect an audio HAT, and there is a considerable performance overhead to running a display over the GPIO pins. Touch response is so slow as to be unusable (although it may be better on a later Pi).

I use this on an original Raspberry Pi Model A (not a supported configuration) to test performance in a resource constrained environment.

In theory you will can run the install script that comes with the drivers to install the correct driver. In practice, that tries to install a whole bunch of GUI support stuff that will slow down your system to no actual benefit in this use case.

When logged in on the command line:

git clone https://github.com/goodtft/LCD-show.git

Then execute the following commands (extracted from the LCD35-show script)

sudo cp ./usr/tft35a-overlay.dtb /boot/firmware/overlays/
sudo cp ./usr/tft35a-overlay.dtb /boot/firmware/overlays/tft35a.dtbo

(Use /boot/overlays if using a Pi OS version older than bookworm.)

Then edit config.txt to comment out the following lines

# dtoverlay=vc4-kms-v3d
# dtparam=i2s=off

Then add the following to the bottom of your config.txt file

hdmi_force_hotplug=1
dtparam=i2c_arm=on
dtparam=spi=on
enable_uart=1
dtoverlay=tft35a:rotate=90
hdmi_group=2
hdmi_mode=1
hdmi_mode=87
hdmi_cvt 480 320 60 6 0 0 0
hdmi_drive=2

The display should be operational once a reboot is completed. Since you cannot configure mauveine via the GUI, it will be necessary to edit the config file (~mauveine/.config/mauveine/mauveine.conf) to change timezone/locale settings as necessary. You can also customize the GUI (see config.md for details), but it’s easier to use the gui/force_theme option to always load one of the standard themes. You will want to remove the setup section to allow the clock to start normally. (No PIN will be set if you do this.) I recommend adding

[display]
device=fb1
resolution=1024x600
size_mm=73x49

[gui]
disable_interface=True

The screen WILL remain blank unless device=fb1 is set in the config file.

Official Raspberry PI touchscreen

This should work out of the box without modification. Tested on a Raspberry Pi 5 running bookworm. This makes this display a strong recommendation for Linux/Raspberry Pi beginners.

Osoyoo 5” DSI touchscreen

The screen on this device works out of the box on bookworm, but without modification the touch screen no longer works. I have been able to get this device working in bookworm by adding the following line to config.txt in the boot folder.

dtoverlay=rpi-ft5406

This driver is not compatible with the kms driver (at the time of writing, it will appear to work but system crashes and graphical corruption will happen after a while), so you will also need to comment out

dtoverlay=vc4-kms-v3d

The modern kms display driver in bookworm does not support the touchscreen for this display.

I did not need to change this but you may or may not also need to set

  display_auto_detect=1

Note that the “official” method will use the unsupported legacy display drivers, which do not perform as well (not an issue in practice for mauveine although may result in higher CPU usage) and do not support screen rotation. This also hides the splash screen for most of the boot process. This ia a limitation of the legacy driver. If you want both touchscreen support and screen rotation with this screen, stick to the bullseye image for now.

Waveshare 4” round DSI touchscreen

This makes for a great looking clock, even if the mauveine interface is not really designed for round displays. The touchscreen does not seem to work, but it can be configured with a bit of effort by plugging in a mouse once the system has booted.

There is some information on the Waveshare Wiki but it does not appear to be linked from the main page. At the time of writing it is wrong.

For bookworm and later, once you have created an image, edit config.txt and add a line at the end of the file.

dtoverlay=vc4-kms-dsi-waveshare-panel,4_0_inchC

When running mauveine setup, be sure to select the round display preset so you will be able to see all of the menus. Using this with an analogue clock with all the decorations turned off produces a really nice looking result.

Waveshare 5” AMOLED display

This display does not work with the kms driver, which means that it is potentially slow and screen rotation may not work. In practice, it does not seem to cause performance issues on a Pi 4, however. It might be possible to generate a custom edid file and pass it as a kernel parameter, but i have not figured out how to do this.

This screen looks really good running mauveine and is great for low light environments too. Comment out the following line as follows

#dtoverlay=vc4-kms-v3d

Add the following lines to config.txt (in /boot/firmware or /boot).

hdmi_force_hotplug=1 
config_hdmi_boost=10
disable_overscan=1
hdmi_group=2
hdmi_mode=87
hdmi_timings=960 0 190 4 32 544 0 10 10 12 0 0 0 60 0 41000000 3

The standard kms kernel driver does not work with this display,

Burn in can be an issue on AMOLED screens and mauveine tries to reduce this risk, by changing the colour of each pixel every 20 minutes (by default). It will be enabled if you pick the presets for this display but otherwise, you can enable of disable it manually in the advanced display settings. It cannot be guaranteed that mauveine will not cause damage to your screen and you use it at your own risk, but I have been running one of these screens for over a year without any ill effect.

Waveshare 5” DSI touchscreen

Waveshare say you should add the following to your config.txt file after the “overlay=vc4-kms-v3d” line. I did not notice this making a difference.

dtoverlay=vc4-kms-dsi-7inch

Tested on a Raspberry Pi 2 on bookworm (32 bit) and bullseye (32 bit).

Waveshare 7” Pi Zero touchscreen

If you can live with the slightly slower speed of the Pi Zero 2 (which is fine for just running mauveine on its own, but struggles a little shell logins / running other stuff at the same time), this is an excellent platform for mauveine. Display and sound currently work “out of the box” from the SD card image without the need for further modification. (Text is slightly small until the correct display settings are configured.)

Audio

mauveine will support any custom sound hardware supported by ALSA, and will do its best to automatically detect sound devices which are present, but it’s possible that some sound devices that do things oddly won’t be detected. If this is the case, they will work with mauveine if you are able to configure ALSA to use them as the default device.

ALSA configuration is something of a black art. The standard asound.conf file used by mauveine looks like this, and this may be useful as a basis for writing a config file that works for your device (change soundcard for the name of your own device as reported by aplay -l):

pcm.!default {
    type asym
    playback.pcm {
        type plug
        slave.pcm "output"
    }
    capture.pcm {
        type plug
        slave.pcm "input"
    }
}

pcm.output {
    type hw
    card soundcard
}

ctl.!default {
    type hw
    card soundcard
}

To test for working sound, access the command line, either remotely or via the console. Stop mauveine if it is still running using

sudo systemctl stop mauveine.service

Once this is done, you can test sound using

speaker-test -c2 -t wav       (for stereo speakers)

or

speaker-test -c1 -t wav       (for mono speakers)

You can use aplay -L and aplay -l to list the sound devices that the system can see. You can also run mauveine’s own sound helper as root to see if it can set up your device for you. It usually lives in /usr/libexec/mauveine/mv-alsa-helper. Running it without parameters will give you some options to try.

Raspberry Pi audio support is frankly terrible and the removal of the aux port from the Pi 5 means that there isn’t even an easy fallback on modern Pis (although if your HDMI display supports audio over HDMI, this will work so long as the display is connected and on when mauveine boots).

Most of the changes you will need to make will be in config.txt. I suggest that you start by disabling anything that uses the GPIO pins other than i2c and i2s support, so if you are trying to get a sound HAT working, start with your config in this state - you can try adding other things back in once you have it working.

dtparam=i2c_arm=on                # i2s requires i2c support
dtparam=i2s=on                    # Most Pi sound devices use i2s
#dtparam=spi=on                   # SPI not used for sound - disabled
#dtparam=audio=on                 # Audio via the audio out jack 
                                  # often still works with sound cards
                                  # but disable while setting up to 
                                  # rule out a conflict

Setup for specific cards is below

Raspiaudio Ultra++

This a neat little board which is pretty unique in that it comes with build in speakers. They aren’t the loudest, but they get the job done. I could not get its own drivers to work though. It is based on a WM8960 chip. The best modern drivers for WM8960 boards seem to be the Waveshare ones. You will need command line access to install this board

git clone https://github.com/waveshare/WM8960-Audio-HAT
cd WM8960-Audio-HAT
sudo ./install.sh

After that is done and you have rebooted, you should be able to access the board from within mauveine. This was tested on a Pi 5 using bookworm.

Raspberry Pi Codec Zero / IQAudio Codec Zero

An “official” Audio solution in that Raspberry Pi bought up IQAudio. They both use the same drivers, but the IQAudio version of the care detects as “IQaudIOCODEC”. It may be just “Zero” for an official Raspberry Pi version.

If you have this version of the card, include in your config.txt (in /boot/ or /boot/firmware/)

dtoverlay=
dtoverlay=rpi-codeczero

The Codec Zero appears to require re-initialisation on every boot, although you may be able to avoid this by saving the configuration by running alsamixer as root. In any event the instructions for how to do this are available in the repository below.

The scripts to do this can be obtained using

git clone https://github.com/raspberrypi/Pi-Codec

Then you can run

sudo alsactl restore -f Pi-Codec/Codec_Zero_Playback_only.state

You may need to add that to /etc/rc.local (or write and install a systemd one-shot unit file) to run on every boot.

I have not been able to fully test this as a I appear to have fried my Codec Zero.

Adafruit speaker bonnet / Pimoroni pHAT DAC

This is a goof choice for Pis older than the Pi 5 because it has passthrough pins which you can attach a real time clock to, and can thus have sound and time sync without the network.

The instructions to install these sound devices are relatively complex, and require command line access. See the Adafruit website or the Pimoroni website for more details.

This card works completely differently from the standard solutions and requires its own custom asound.conf. It does not appear to support mixer controls.
If mauveine detects that this care is installed and has a kernel driver, it will try to set up asound.conf for you, so you don’t need to worry about that part of the install process.

Keyboard and mouse

Keyboard input in mauveine is not supported at this time, but some things work.

A mouse will work, but it is not really the intended use case as mauveine is designed for touch input. mauveine’s initialisation code hides the mouse cursor by default in some scenarios, but this can be configured.

Memory

512MB of RAM is sufficient to run mauveine, if no other applications are installed on the Pi. If you are using the Pi to provide additional functionality, then more RAM may be required.

In particular if you wish to use VS Code to remotely develop the mauveine code 2GB is recommended. 1GB will work, but increasing the swap file size to 512MB is recommended and slow downs may be experienced. It is not advisable to leave a debug session running while editing. A 512MB Pi is too slow to be useful for remote debugging even with swap enabled.

To increase the swap size, run the following commands while nothing is running.

sudo dphys-swapfile swapoff
sudo cp /etc/dphys-swapfile /etc/dphys-swapfile.bak
sudo sed -i "s/CONF_SWAPSIZE=.*/CONF_SWAPSIZE=512/" /etc/dphys-swapfile
sudo dphys-swapfile setup
sudo dphys-swapfile swapon

Storage

The default install of Raspberry Pi OS with all the necessary pre-requisites takes a little over 4GB storage space. You might get this below 4GB by installing less fonts, but you’d then be at risk of running out of space in daily usage, and it’s hard to find SD cards with less than 8GB capacity these days.

mauveine will run from SD card, but also from USB flash drives (tested on the Pi 4) and onboard MMC on the CM4. Disk performance is not really an issue for mauveine but booting from USB might increase durability. MMC boot gives a significant performance boost on the CM4.

Software

It is recommended to use the Lite version of Raspberry Pi OS, as a UNIX desktop environment is not compatible with running mauveine as a clock appliance.

Raspberry Pi 3 and above supports a 64 bit OS, and this is recommended, but mauveine has been tested and runs fine on 32 bit Raspberry Pi OS.

Versions of Raspberry Pi OS based on Debian versions later than bullseye should work. Versions based on Debian bookworm or later are recommended

Real time clock

A real time clock is not required for mauveine to work, as it is able to obtain time from the network, but it helpful if the clock loses power then cannot synchronise itself with a network clock.

There are a large number of real-time clock solutions for Raspberry Pi and it would be beyond the scope of this document to consider them all here. Once the RTC is configured to provide time to the dbus time sync service, mauveine will be aware of and monitor its status.

Raspberry Pi 5 realtime clock

If the correct battery is installed, this should work without the need for further changes. You can check that the check is working correctly from the “info” tab in the “About mauveine” dialog. If you can see “rtc-sync: yes” then yor RTC is working.

DS3231 based RTC

Include the following line in your config.txt file on your boot partition.

dtoverlay=i2c-rtc,ds3231

You may also need to uncomment the following line

dtparam=i2c_arm=on

BigTreeTech Raspberry Pad 5 CM4 carrier

Enable the RTC as follows in config.txt on your boot partition (/boot or /boot/firmware)

# BigTreeTech Raspberry Pad 5 RTC
dtparam=i2c_vc=on
dtoverlay=i2c-rtc,pcf8563,i2c_csi_dsi

Sample build

I have used the following kit to create a fully functional appliance with a polished aesthetic appearance. The prices given are approximate UK prices at the time of purchase.

Item Price
Raspberry Pi 4 Model B 1GB £40
Raspberry Pi Official 7” display £69
Raspberry Pi Power Supply £9
Kingston 32GB Select Plus micro SD card £5
SmartPi Touch Pro Case (large size) £30
Hobby components DS3231 RTC module £8
Mini Portable Rechargeable Travel Aux speaker 3.5mm jack £9
TOTAL £173

Build notes

1) I consider this to be a suitable project for someone with an interest in learning about computers and hardware. No soldering is required.

2) Obviously this is on the pricey side for an alarm clock, and Lenovo, for example, sell some off the shelf connected alarm clocks that do much of what mauveine does and feature a physical switch to turn off their microphone. (Microphone input is not supported in mauveine by design.) The advantage of a mauveine based system is that it is much more configurable and standalone, but mauveine cannot compete on price with the limited other connected clock options available, even though the software is free, because of economies of scale.

3) At the time of writing, it was very difficult to impossible to get a Pi at the advertised price. Hopefully this will improve soon.

4) If the screen cable is correctly plugged in, the screen will work without the need for any changes to the Raspberry Pi OS configuration.

5) The portable speaker is a bit of a hack. I have found it difficult to get custom Pi audio solutions to work satisfactorily. The speaker provides “good enough” amplified audio and fits in the back of the large SmartPi case, but it will not win any prizes for audio quality. To avoid light leakage its LED is covered internally. The speaker is powered from the USB A port on the back of the official screen, but it was necessary to use a rotary tool to shave some of the plastic off the USB A connector so the case would fit.

6) Starting the volume control in mauveine will play sound. If this does not work then to test whether the sound config is working, run the following command from the command line.

   speaker-test -t wav

If necessary you can identify the right device number using

   aplay -l
 
then

    speakertest -t wav- Dhw:<device-name>

7) The case comes with a fan, but it is not required for this project and I have not used it as I prefer silent operation.

8) I have connected the real time clock chip to Pins 1,3,5 and 7 of the Pi via the GPIO pins. Some useful resources for getting the RTC to work are

Many of the instructions for using an RTC available on the net are out of date to some extent, and I did not find it necessary to load custom kernel modules, or to disable fake-hwclock, which now seems to deal quite gracefully with having an RTC installed. The following lines in /boot/config.txt were adequate to get the clock working as expected for me.

   dtparam=i2c_arm=on
   dtoverlay=i2c-rtc,ds3231

This project has been made much easier by the existence of high quality independent specialist suppliers with a wide range of Raspberry Pi specific stock. In particular PiHut and Pimoroni have provided both speedy delivery and helpful and responsive customer service. Please consider supporting them when purchasing for your own projects.