Personal Video Recorder
The Requirement
TiVo revolutionised video-recording. The video-tapes & the error-prone spinning video-head were replaced by a hard-disk, & the increasingly wide TV-schedule was available as dial-up (this is before broadband) service; they had invented the PVR. Regrettably, TiVo's UK-debut in with the Thomson PVR10UK, failed after an advertising campaign which focussed solely on the ability to pause live TV, & the ≈2007 migration from terrestrial analogue broadcasting to DVB was the final nail in the coffin. Though over a decade has passed since TiVo's fall (except as offered by Virgin Media), other PVRs haven't reproduced the user-experience. In my experience, they're typically:
- so slow that the video & audio desynchronise when the CPU has to work to correct signal-errors or to render a fast-changing scene, & too slow to exit from the highest available fast-forward to make this facility useful.
-
inexplicably inflexible, e.g.:
- missing fast-forward speeds.
- prohibiting deletion of a recording until completion.
- unsophisticated program-search; based merely on a plain text match (rather than regular expression) with either title or description, & not on e.g. channel, duration, genre, start-time …
- unsophisticated program-timer attributes.
- at the cheaper end, they lack network-access.
- peppered with obvious errors (e.g. glaring spelling-errors in the UI), suggesting scant regard for quality-control.
- unlikely to receive s/w-updates for more than a token period after the model's debut, & therefore can't be trusted on your LAN.
- closed-source, making it hard to trust with one's data.
- lack of (RAID)-storage.
The Solution
Software
There are a variety of open-source s/w-projects based on GNU/Linux & kodi (formerly XBMC), which provide not only PVR-functionality but can double as a media-player:
Hardware
In the Raspberry Pi became available. The model 3B provides:
- a 4-core processor,
- USB-2.0 ports,
- Ethernet & WiFi,
- hardware-accelerated h.264-decoding.
This is sufficiently powerful to run kodi, & is quite inexpensive. Many people have pioneered such solutions, but I've detailed my specific solution & conclusions.


Component | Type | # | Size | |
---|---|---|---|---|
Case
|
Acrylic sheet | Transparent | 1 | A3 × 3 mm |
A4 × 5 mm | ||||
Tube | Aluminium | 4 | (72 × 12 × 1) mm | |
(75 × 12 × 1) mm | ||||
Foot | Rubber | 15 mm | ||
Threaded rod | Stainless steel | M3 × 30 cm | ||
Acorn Nut | M3 | |||
Nut | 8 | M3 | ||
Washer | Penny | 20 | M3 × 12 mm | |
8 | M3 × 9 mm | |||
Computer
|
Raspberry Pi | Model 3B | 1 | |
µSD-card | Class-10 | ≥ 8 GB | ||
WiFi-adapter | LB-link (Realtek RTL8188CUS) 802.11n | |||
Real-time Clock | Battery-backed, DS1307 | |||
Standoff | Male-female | 4 | M2.5 | |
Bolt | ||||
Nut | ||||
Cable | HDMI | 1 | Standard Type-A | |
RF
|
Tuner | USB 2.0 DVB-T2 | 2 | |
RF-adapter | Male F-connector to male Belling-Lee | |||
Cable | Male-female USB | Type-A, 25 cm | ||
Acrylic bar | Square-section | 1 | 4 cm × 5 mm2 | |
Solvent | Tensol 12 | |||
Cable-tie | Black | 20 cm × 2.5 mm | ||
RF-splitter | 2-way inductive. With 3 female F-connectors | 1 | ||
Bolt | Hex socket | 2 | M3 × 8 mm | |
Nut | M3 | |||
F-connector | 90° male-male | 1 | ||
Female-female | ||||
Cable | Male-male F-connector | |||
Cable-clamp | U-bolt | |||
Storage
|
Hard-disk drive | SATA | 2 | 2.5", 500 GB |
Adapter | SATA 3 to USB 3.0 | Standard, Type-A | ||
Bolt | Hex socket | 8 | M3 × 8 mm | |
Grommet | Rubber | 10 mm × 3 mm | ||
Flash-drive | USB | 1 | Standard, Type-A | |
USB-hub
|
USB-hub | USB 3.0 | 1 | 4-port, 15 W |
Cable-tie | Black | 2 | 20 cm × 2.5 mm | |
Status-LEDs
|
Strip-board | 1 | 64 mm × 25 mm | |
Operational amplifier | LM324 | Quad | ||
Standoff | Male-female | 2 | M2.5 | |
Bolt | ||||
Nut | ||||
LED | Red | 4 | 5 mm | |
Potentiometer | Multi-turn cermet | 100 kΩ | ||
Resistor | 0.25 W | 47 Ω | ||
Jump-wire | 6 | 10 cm | ||
Power-supply | Switch-mode, with UPS-monitor | 1 | 60 W, 230±10 V AC to 12 V DC | |
DC-DC Buck-converter |
| 10 A | ||
Battery | VRLA | 12 V, 2.1 Ah | ||
Barrel-connector | Right-angle | 2 A, 1.35 mm × 3.5 mm | ||
µUSB lead | Power only | 35 cm, 18 AWG | ||
Mains-cable | 3-core, PVC-insulated | 0.75 mm2 | ||
Mains-plug | 3-pin | 3 A fuse | ||
Switch |
| 3 | 10 A | |
Wire | Multi-strand | Red & Black | 16 AWG, 26-strand | |
Crimp-connector |
| 11 | M3 | |
| 14 | 6.3 mm | ||
Insulating boot | For female crimp spade-terminal | |||
Cable-tie | Black | 2 | 25 cm × 3 mm | |
Bolt | Hex socket | 2 | M3 × 8 mm | |
Nut | M3 |
From a glance at the list of parts, this is likely to be more expensive than the average commercial PVR, but then they're not exactly the same product. Whereas a commercial PVR will probably give you a nose-bleed when you discover that it promised long & delivering short, this solution is:
- networked; one can connect over ssh, or HTTP.
- flexible; there are many s/w add-ons to enhance functionality.
- open-source; so you can in principle, inspect the code to see how your data is being used.
- supported; the update-frequency depends on the selected distribution.
- repairable.
- many of the parts are re-usable in other projects, or may previously have been purchased for abandoned projects.
-
it looks better; OK, that's subjective, since I think it looks like Port Talbot at night, & other people think Port Talbot looks worse.
If you're unconvinced by these merits, you could (in decreasing order of preference) reduce the cost by:
- replacing the UPS with two wall-warts
-
- reducing the power-on sequence to a process of inserting wall-warts sequentially into a distribution-board.
- leaving the PVR vulnerable to brown-outs (which may be infrequent anyway).
- the cost of a high quality power-supply for the Raspberry Pi (the USB-hub was presumably supplied with one) reduces the saving.
- omitting the USB WiFi-adapter
- requiring one to use the weak internal WiFi-adapter.
- omitting the status-LEDs
- requiring one to manually confirm that the HDDs & DVB-tuners are available after booting.
- downgrading to just one HDD / SATA-USB adapter
- increasing the chance that video-files will be lost on failure.
- downgrading to merely one tuner (& also potentially remove the RF splitter & three gender-changers)
- preventing simultaneous recording.
- downgrading from DVB-T2 to the older DVB-T standard
- limiting one to tuning into standard-definition broadcasts.
- downgrading to a Raspberry Pi Zero W
-
- only one CPU; slower but adequate.
- only a mini HDMI-port.
- only one µUSB data-port.
- removing the battery-backed real-time clock
- the internet must be available when booting to permit synchronisation with an NTP-server, & prior to receiving this time-signal, all times will be incorrect.





Case
The case is built from acrylic.
- This typically comes covered by protective plastic, which shouldn't be removed until completion. 3 mm was selected so that the grommets used to mount the HDDs could threaded through the width.
- The A3 acrylic sheet is scored & snapped over a straight edge (which takes considerable force), into two A4 halves; one could merely buy A4 sheets (which I did for the bottom layer), but that's slightly more expensive. The sheets can then be clamped together to reduce the effort of subsequent processing & to force alignment of those holes they share.
- The corners are hack-sawed & then ground to a radius of ≈1 cm; large washers can be clamped either side, to form a guide for the file. This is largely aesthetic, though my sheet of acrylic arrived by post with one corner pre-mashed.
-
Various holes were drilled using HSS twist-drill bits.
- For accuracy a drill-stand was used, after piloting each hole by hand using a pin-vice & a 1 mm drill-bit (which easily bites into the relatively soft protective plastic).
- Acrylic tends to ride up the thread of a twist drill-bit, & since it's brittle, the consequences are typically catastrophic, so each hole was progressively enlarged 1 mm at a time.
- Excess heat can melt & discolour the acrylic, so a low drill speed was used & also peck-drilling for wider holes.
- To reduce chipping, wood was placed beneath the acrylic to support the perimeter of the exit-hole as the drill-bit emerges from the far side.
- A square-section acrylic bar is bonded to the lower side of the top acrylic sheet, between two holes from which both DVB-tuners are suspended using a cable-tie.
The horizontal acrylic sheets are connected to form two tiers, by vertical aluminium tubes at each corner, through each of which a threaded rod is inserted coaxially. Penny-washers are used to spread the load from the tightened threaded rods, to avoid cracking the acrylic. The aluminium tubes don't reliably centre around the threaded rod (as can be observed in the photos), which was partially resolved by inserting M3 × 9 mm washers into the base of each. The length of the tubes separating the upper tier, plus twice the thickness of a penny-washer, should equal the 70 mm width of the HDD plus the thickness of the grommets. The length of the tubes separating the lower tier is less critical, but must exceed the combined height of the battery & crimp spade-sockets (the descending spade-terminals from the battery-switch above are offset from the battery). In either case a pipe-cutter is used to achieve perpendicular ends; using a hack-saw & file is considerably more laborious.
The threaded rods are capped by acorn nuts to shield the sharp ends; these were added after the photographs were taken. Rubber feet must be threaded onto the lower end of the threaded rods, since otherwise various protruding bolt-heads & cable-ties would prevent the case from sitting horizontally.
Computer
Because the Raspberry Pi's WiFi-antenna is very short (& there's no provision for an external antenna), network-connectivity was unreliable, despite:
- having only two plaster-board walls between the WiFi access-point & the Raspberry Pi,
- using the 2.4 GHz spectrum (which penetrates obstacles better than the newer 5 GHz spectrum),
- orientating the Raspberry Pi within the case so as to maximise exposure of the WiFi-antenna (located between the µSD-socket & the GPIO-pins).
So the integrated WiFi-adapter was replaced by a device with a better antenna, & of sufficiently low power to permit direct connection to the Raspberry Pi's USB (rather than via the fully populated 4-port USB-hub). The integrated WiFi-adapter can then be disabled using the following commands.
cat >>/storage/.config/modprobe.d/blacklist.conf <<-EOF # Disable RPi's weak internal WiFi.
blacklist brcmfmac
blacklist brcmutil
EOF
The Raspberry Pi is attached above the middle acrylic sheet using 12 mm long standoffs to enable subsequent extraction of the µSD-card using one's fingers rather than tweezers. The upper end of the standoff must be female since there's insufficient space to tighten a nut; the lower end can be either gender.
There was apparently no need to attach a heat-sink to the Broadcom BCM2837 SoC. While recording two high-definition channels & watching a standard-definition recording, the temperature rose from a quiescent 39 C, to 57 C; well below the 80 C at which throttling occurs.
Though the Raspberry Pi has 4 USB-2.0 ports, it only has a single bus, limiting the data-rate to a theoretical 480 Mb/s. In the UK, each DVB-t2 tuner requires about 40 Mb/s. Though each HDD has a SATA 6 Gb/s interface, it won't be required to write any faster than both DVB-t2 tuners can simultaneously receive. So if recording two HD channels while watching a third, the total requirement (200 Mb/s) is still within what might be expected from the USB-2.0 specification, provided that the Ethernet-interface (implemented on USB) isn't being hammered for any unrelated reason.
The battery-backed real-time clock is connected to the GPIO-pins. Conveniently, the selected model passes the pins through for connection to other devices, but is only based on a DS1307 rather than the more accurate DS3231. To modify LibreELEC so that the kernel recognises it, ssh into the Raspberry Pi & issue the commands:
mount -o 'remount,rw' /flash; # This file-system is normally mounted read-only. echo 'dtoverlay=i2c-rtc,ds3231 # For realtime clock.' >>/flash/config.txt; # Append a line to the config-file. reboot; hwclock -r # Confirm the time.
Storage
The selected distribution is read from a µSD-card; I used a 32 GB (though 8 GB would have been sufficient) Samsung Pro Endurance, its read-speed easily exceeds the 25 MB/s speed of the card-reader (minimising boot-time), & claims significantly higher write-endurance. For installation, either follow "these instructions", or install NOOBS & select the required distribution.
Video files are recorded onto a RAID 1 built from a pair of HDDs formatted with BTRFS. To regularly maintain this filesystem, navigate down LibreELEC's TV-interface:
Settings → Add-ons → Install from respository → LibreELEC Add-ons → Program add-ons → BTRFS Tools → install Settings → LibreELEC → Services → cron → Enable cron
Then ssh into the Raspberry Pi, & as the user "root" edit "$HOME/.cache/cron/crontabs/root" by issuing the command:
crontab -e # Edit root's crontab.
0 2 1,16 * * $HOME/.kodi/addons/tools.btrfs-progs/bin/btrfs scrub start /var/media/Video
If this dumps you into an unfamiliar editor, then repeat after issuing the shell-commands:
echo 'export EDITOR=vi' >>~/.profile; # Specify your favourite editor. . ~/.profile # Source the new profile.
These HDDs are connected to the USB-hub via SATA-USB adapters, & by rubber grommets to reduce transmission of vibrations & amplification by the case. The thickness of the acrylic from which the upper layers are composed, is limited to 3 mm to permit these grommets to be threaded all the way through.
Since kodi is not just a PVR, but a media-player, any audio files can be read from a USB flash drive. To avoid corruption of the file-system on power-loss (especially if you don't opt to build the UPS), ssh into the Raspberry Pi & issue the command:
echo "mount -o 'remount,ro' device" >>/storage/.config/autostart.sh # Remount the file-system read-only.
RF
Two DVB-tuners were used, to permit simultaneous recording. I used a Geniatech MyGica T230 & a PCTV Systems tripleStick 292e, both of which worked seamlessly. DVB-T (Freeview in the UK) was piped to them via an RF-splitter. Initially I used a cheap four-way splitter, which at best quarters the signal-power available to each output, resulting in a signal that was unacceptably weak, so I replaced it with a higher quality two-way inductive splitter.
The assembly of RF-components was hung beneath the top acrylic sheet of the case, taking care to distance them from the GPIO-pins rising from the Raspberry Pi; connecting the 3.3 V pin to the 5 V pin, or shorting either to ground, is a great way to blow the Raspberry Pi.
USB-hub
The 7200 RPM Hitachi Z7K500s selected for storage of video files, require only ≈2 W each, but can draw a rather high 5.5 W on start-up (the 5400 RPM version is little better).
The power-requirements of both the HDDs & two 0.5 A DVB-tuners, exceed that which can be delivered from the USB-ports of the Raspberry Pi, so they're connected to a four-port powered USB-hub; I selected a hub which conforms to USB 3.0, not because of its speed (since the Raspberry Pi to which it is connected only supports USB 2.0), but because it makes 0.9 A available to each device, which is necessary for the HDDs.
I selected a 15 W Atolla 204u3. Input-power at 5 V is delivered via a barrel-connector, allowing both this & the Raspberry Pi to be powered using one buck-converter. The various USB-cables can be merely USB 2.0, though one might want to confirm that their power-wires are of adequate capacity; I just used USB 3.0 ones. The orientation of the USB-ports avoided the need to twist thick the SATA-USB cables through 90°.
Having allocated all of the ports of the USB-hub to high-power devices, I connected the USB flash-drive containing the audio files directly to the Raspberry Pi; this is tolerable, since its power-requirement is only 0.2 A. If one decided to replace the Raspberry Pi's WiFi with a higher-power adapter, then a seven-port USB-hub would be a better choice (though they typically require a 12 V power-supply).
Back-powering the Raspberry Pi from the USB-hub also, bypasses protection & is generally deprecated, so it retains its own independent power-supply.
UPS
Though the maximum operational power-requirement is only ≈20 W, the mains-plug has a 3 A fuse to account for the higher current on start-up.
The 230±10 V AC mains is converted to 12 V DC. Since the selected PSU is rated at 60 W output but never exceeds 20 W, it only reaches 38 C, & since it doesn't have any cooling-holes beneath, it is mounted directly on the base acrylic sheet with two M3 hex socket bolts.
This is used to charge a sealed lead-acid battery, which returns the charge should the mains voltage be disconnected for any reason. Since the PVR typically takes ≈18 W, the 2.1 Ah 12 V battery can last for almost 1.5 h. This battery is positioned to ensure that its terminals are in no danger of contact with the bolts for the HDD above.
This intermediate DC voltage is then stepped-down to supply both the Raspberry Pi & the USB-hub; both of which can tolerate 5±0.25 V. Since the selected buck-converter is rated at 10 A but seldom reaches a quarter of that, its heat-sink doesn't get very hot, but the supplied standoffs were sufficient to separate it from the acrylic base to increase air-flow. CAVEAT: I added insulating washers to these standoffs, which were otherwise uncomfortably close to circuit-traces. This module's voltage should be calibrated before use (which involves holding down a button before powering-on), after which it can be configured to display both i/o voltage & output current.
The buck-converter was set to the maximum voltage tolerable according to the USB-standard, 5.25 V. The measured voltage had dropped to 5.2 V @ the exit to the switch before the Raspberry Pi, at the maximum expected load, having lost a little over crimp-connectors, 16 AWG wires & one switch. Then there's the Raspberry Pi's µB USB power-connector which was constructed from a short fast-charge (no data) USB-cable, with one end removed & the two exposed 18 AWG power-wires (the thickest I could find) terminated with crimp spade-sockets. The voltage-reduction resulting from a series of shonky connections is dependent on the current demanded, resulting in sporadic Low voltage errors from the OS (typically when the HDD were activated); so I increasing it to 5.5 V.
The selected buck-converter also permits one to define a current-limit, & 4 A (calibrated by shorting the output into a 0.5 Ω 50 W resistor) was found to be adequate to avoid activation in normal circumstances. This prevents excessive loading (& consequently heating) of either the PSU or buck-converter, should a short-circuit occur (CAVEAT: it won't prevent disaster if a nut drops from the standoffs above, through the cooling-vents in the top of the PSU, since this is upstream from the buck-converter).
Switches have been used to independently isolate the three power-connections. This facilitates sequential application of power to the USB-hub & then to the Raspberry Pi, so that the HDDs are available to mount when the latter is booting. The battery is also connected via a switch, because removing the crimp-terminal (for whatever reason) is annoyingly hard. The minimum requirement is satisfied by SPST switches, but the greater functionality of DPDT switches (which cost little extra) may facilitate re-use in a different project. Each switch requires a 12 mm cut-out, which exceeds the diameter which can safely be achieved using a twist-drill bit without cracking the acrylic; I used a step drill-bit.
User-interface
The Raspberry Pi is connected to a TV using HDMI. Since the TV's tuner isn't required, one might be tempted to replace it with a simple monitor, but monitors typically lack any audio-amplifier (see below), & the primary input-device is the TV's remote-control & infra-red receiver, which via HDMI-CEC can relay commands to the Raspberry Pi, avoiding any requirement for a dedicated infra-red receiver. CAVEAT: the HDMI-support on older TVs may not include CEC, or may need it to be enabled, & the manufacturer may refer to it using some fatuous brand-name (typically called "something-(link|sync)").
Audio
Perhaps just when playing music, or also when watching a film, the output from the TV's internal speakers doesn't quite cut it. Your new TV may have a greater pixel-density than the human (& owl) eye, but the sound is probably no better than from an old cathode-ray model; it's probably worse since the internal speakers typically face either backwards or downwards, to permit a oooh-so-stylish narrow front bezel.
One can connect an audio amplifier (& Hi-Fi speakers) to the TV's audio output (typically RCA sockets) rather than directly to the Raspberry Pi. The TV will probably have an item buried in its menu to manually redirect the audio signal, though mine switches automatically on sensing the presence of the connected audio amplifier. One could alternatively take the audio signal from the headphone-jack on the Raspberry Pi.

Status-LEDs
The depicted circuit is powered from the Raspberry Pi's 5 V GPIO-pin, & can supply a constant current (irrespective of the LED's colour) to any of four LEDs, each according to the state of a dedicated GPIO-pin. Individual trimmer-potentiometers are available to fine-tune the brightness.
A daemon "show_status.py", governs the state of the connected GPIO-pins. To start this at boot-time, ssh into the Raspberry Pi & issue the shell-command:
echo 'nohup /storage/.config/show_status.py --poll --period=15 &' >>/storage/.config/autostart.sh # Poll the h/w periodically.
This daemon could be used to continuously indicate arbitrary attributes of the PVR, but has been used to monitor the availability of the required h/w. CAVEAT: this script must be tailored to reference your specific hardware.
- Both HDDs
- References the file-system label.
- USB flash-drive
- References the file-system label.
- PCTV Systems tripleStick 292e DVB-tuner
- References the vendor & product.
- Geniatech MyGica T230 DVB-tuner
- References the vendor & product.
N.B. Failure to find some of this h/w might result from booting the whole system simultaneously. A more reliable procedure is to boot the USB-hub first (from which the above h/w is powered), & then the Raspberry Pi.
The Solution Revisited
Computer-aided Design
The design is unpleasantly Heath Robinson, & could benefit from the replacement of various generic parts with dedicated 3D-printed alternatives, replacing those I've greyed-out in the parts-list. To this end the design (originally sketched with the 2D drawing-package in Libre Office) was re-modelled more precisely in 3D using FreeCAD, from which several STL files were exported to upload to a 3D-printing service. The triangulated surface described in the STL-file is converted by the printing-service to the G-code required to drive the motors of their specific printer. FreeCAD is an impressive product, but requires an equally impressive effort to grok; don't abandon hope, since the rewards will extend beyond this project.
3D-printing

FFF was used to print the parts in PLA … because these are the cheapest options. This influences the design because; unlike the more expensive SLS & SLA processes, FFF can't tolerate unsupported spans (anything nearer horizontal than 45°); this combination of material & process produce mechanically weak parts, so the part must derive strength from its shape. If you opt for a 3D-printing service rather than owning your own printer, then there's always the option to upgrade these choices. The service I used printed the parts to a quality that exceeded my expectations, using a Prusa i3 Mk3
-
Ferrules 16 ferrules were used to constrain the 8 aluminium tubes into coaxial alignment around the 4 threaded rods. They replace 8 M3 × 9 mm washers, dropped into each tube, which unsatisfactorily only vaguely centred the lower end of each tube. These are very small & the details are at the limits of FFF.
CAVEAT: in the lower edges where the surface breaks from horizontal, 45° chamfers have been used in preference to rounded fillets.
-
Battery-brackets Two brackets were used to secure the battery, replacing the cable-ties which failed to constrain sideways motion. These have to leave room for the battery's spade-connectors.
CAVEAT: material has been saved by introducing holes in the flanks, but because of the limitations of FFF, they are irregular hexagons (with 90° top & bottom angles & the remainder 135°) rather than round.
-
WiFi-adapter Bracket A bracket was used to secure the WiFi-adapter, which was used to replace the one integrated into the Raspberry Pi, & to orientate its longer antenna. Clearly this part is dedicated to precisely the selected WiFi-adapter, & a completely different design would be required for any other; this one has an indicator-light, for which a view-port has been included in the 3D-printed bracket. The interior void has a vaulted ceiling which is at the limits of FFF, & required a small amount of filing to smooth the ragged edge at which the ceiling breaks upwards from horizontal towards the vertical tower used to constrain the antenna.
CAVEAT: the chosen WiFi-adapter/driver combination proven unreliable. The reason is unknown, but may be related to power-delivery, since it was connected to the Raspberry Pi's USB (the 4-port USB-hub being fully populated).
-
DVB-tuner Bracket A bracket for the two DVB-tuners was used to replace the combination of cable-ties & square-section acrylic bar. The honey-combed upper span permits the activity-light on the PCTV Systems tripleStick 292e to be seen.
CAVEAT: FFF can't cope with the unsupported span in this part, so during construction, it must be orientated to lie on its flat trapezoidal side.

Conclusions
My impression is largely positive, but …
Operational Issues
- The user-defined status-LEDs should have been socketed rather than directly soldered to the PCB, since the circuit will supply the same current regardless of the colour, & the Python-script can easily be changed to represent a different aspect of the runtime-state. These additional user-defined status-LEDs are regrettably neither self-explanatory nor particularly informative; a small LCD might be better.
- The Python-script above, polls for faults rather than reacting immediately.
- If the whole system is powered-on simultaneously, then the hard-drives may not be visible to the Raspberry Pi as it boots.
- The antenna on the integrated WiFi-adapter proved inadequate & was therefore disabled. It was replaced by a low-power USB alternative, which proved unreliable. Better (but more expensive) solutions might be to either use a second WiFi access-point configured as a repeater, or invest in a WiFi 6 mesh.
-
The Raspberry Pi's integrated red power-LED was so bright that it was distracting when watching TV,
so was disabled:
echo 'echo 0 >>/sys/devices/platform/leds/leds/led1/brightness # Disable the red PWR led.' >>/storage/.config/autostart.sh
Physical Issues
- The inflection of each SATA-USB adapter's cable, imparts a significant lateral force on the SATA-plug of the corresponding HDD, which may be need to be reseated after toggling the battery-switch (suspect this if the above fault occurs repeatedly). Fortunately the USB-plugs on the hub have the same vertical orientation as the SATA-plug, so that they don't also need to be twisted by 90°.
- The snapped edge of the acrylic isn't as precise as hoped; perhaps it can be smoothed with a blow-torch, or one could just buy A4 sheets in the first place.
- The battery-switch is inconveniently located, & clumsy use may unseat the SATA-plugs.
- Access to the adjustment-screws of the cermet potentiometers on the buck-converter, is too restricted, necessitating disassembly before changing either the voltage or the current-limit. This can be remedied by drilling access-ports above these screws in the middle tier of the case, through which a slim screw-driver can be inserted.
- The wires supplying DC current to the USB-hub, merely loop around the edge of the middle tier of the case, & could be routed through a dedicated hole protected by a grommet.