mharsch

Recent versions of the Raspberry Pi Imager Tool allow customization using cloud-init config and netplan files that are seeded on the boot partition of the sd card as part of writing the image. These files can be edited before booting the pi for the first time, with customizations that will run automatically at first boot.

To automatically pre-configure the pi SD card image for use with the ConnectedIO CM4NA modem, and tailscale do the following:

Prerequisites:

• Generate an auth key from the Tailscale Admin Console (Settings -> Keys -> Generate auth key) copy and save for later
• Plug in the CM4NA Modem (both data and power) to the Pi. Mode should be AT#USBCFG=0 (default from factory)

Use the latest version of Raspberry Pi Imager tool (ver 2.03 as of this writing)

mharsch

#!/bin/bash

# Script for wiping old plot directories and prepping drives for new plots
# Pause between steps in case something goes wrong (Ctrl-C to bail out)
RANGE=sdb[g-j]

DEVS=/dev/$RANGE
DEVS_SCHED=/sys/block/${RANGE}/queue/scheduler
PARTS=/dev/${RANGE}1
OLD_DIRS=/plots/${RANGE}1

mharsch

This will save you from going down a rather deep documentation rabbit hole:


1.) enable pcspkr driver by removing blacklist entry for pcspkr in /etc/modprobe.d/blacklist.conf
2.) create user group 'beep' for controlling permissions to speaker
	sudo addgroup --system beep
3.) Add your user account to the new beep group (logout and log back in after this step)
	sudo usermod -aG beep $USER
4.) change default permissions on speaker device to allow members of group 'beep' to access speaker.
    Comment out previous entry and add the following line to /usr/lib/udev/rules.d/70-pcspkr-beep.rules

mharsch

Uses this container to scrape power data from the reverse-engineered kasa API running on the smart plugs (e.g. HS100).

Docker compose example

compose.yml

version: '3.8'

mharsch

Most online instructions for Linux watchdog refer to the 'watchdog' package which is best described here

The watchdog configuration described here uses systemd, and the two methods are mutually exclusive, so if you've previously setup the above watchdog, you must first uninstall it.

sudo apt remove watchdog

Our goal is to add a systemd service that continuously pings a known host (or IP address)

mharsch

/**
 * V. Hunter Adams
 * DDS of sine wave on MCP4822 DAC w/ ISR
 *
 * Modified example code from Raspberry Pi
 * Copyright (c) 2020 Raspberry Pi (Trading) Ltd.
 *
 * SPDX-License-Identifier: BSD-3-Clause
 *
   GPIO 8 (pico pin 11) MCP4725 SDA

mharsch

RTX 3080 Ti System:
===================
OS="Ubuntu 22.04.2 LTS 5.15.0-70-generic"
SystemVendor/Model="Gigabyte Technology Co., Ltd. B550 AORUS MASTER"
CPU="1x AMD Ryzen 9 5950X 16-Core Processor (C:16|T:32)"
GPU="NVIDIA GeForce RTX 3080 Ti"
GPUSKU="Ampere"
GPUArch="N/A"
DriverVersion="530.30.02"
PCIeLink="PCIe 4x16"

mharsch

#include <math.h>

// connected to 'D+' pin on mini USB
const int input_pin = 11;
// connected to 'D-' pin on mini USB
const int output_pin = 12;

void setup() {
  // put your setup code here, to run once:
  Serial.begin(9600);

mharsch

Deprecated

I no longer recommend the below method. For my updated recommendation, see this gist

Setup Linux to reboot if it loses access to a certain host by hostname (not IP)

The linux watchdog service can be configured to run certain 'liveness' tests periodically, and then take some action (such as reboot) if a test fails (and doesn't recover) for some period of time.

There is a built-in test for pinging an IP address (i.e. 'ping' directive), but you may instead need to test access to a hostname

mharsch

If you have a failure mode that can be diagnosed by a high rate of messages flooding the system log,
you can use the script below in conjunction with the watchdog service to detect the condition
and reboot if it persists.  This is a pretty big hammer, but potentially better than just rebooting on
loss of network or some other arbitrary liveness test.

add a 'test-binary' line to /etc/watchdog.conf pointing to this script (will be treated as V0 test script
with no corresponding repair script).  Also, set 'interval' to something like 20 seconds (at least greater than
the sample period in the script).

You can convince yourself it's working (once the watchdog service has been restarted with the above config)