Headlamps

The Zebralight H54Fc N is great. The Nichia 519A emitter is as good as the legend says with the neutral tone, beautiful color rendering... just a smooth and even beam (in the Fc version), perfect for close-range work. Something else I've noticed recently is that the older H53 I have was significantly brighter with a lithium primary (the Energizer silver ones, not the Li-ion rechargeable 14500) than with a fully charged high-discharge Eneloop, indicating that the driver is not optimized for the 1.2 V Ni-MH. No such problem with the H54; the light is just as bright with Lithium primary or Ni-MH. Every few years Zebralight comes out with a revised version of their AA headlamps. The H5x series remains the king of single-AA headlamps. Now I'm curious about the SC65c HI with the Nichia 719A emitter... yes I do miss the 18650 brightness and endurance, but those unprotected lithium cells are annoying to deal with - need special chargers, cannot buy online and ship by air, more and more restriction about lithium cells with air travels.

Enabling UART on the Beaglebone Black

To enable the UARTs with the recent console Debian image for the Beaglebone Black, add these lines to sudo nano /boot/uEnv.txt

uboot_overlay_addr0=/lib/firmware/BB-UART1-00A0.dtbo
uboot_overlay_addr1=/lib/firmware/BB-UART2-00A0.dtbo
uboot_overlay_addr2=/lib/firmware/BB-UART4-00A0.dtbo
uboot_overlay_addr3=/lib/firmware/BB-UART5-00A0.dtbo
disable_uboot_overlay_video=1
disable_uboot_overlay_audio=1
enable_uboot_cape_universal=1

Also run this if you're running the bone off an SD card, AND the eMMC does not have an up-to-date uboot.

sudo dd if=/dev/zero of=/dev/mmcblk1 count=1 seek=1 bs=128k

It seems that some recent changes to uboot have made these obsolete:

cape_disable=bone_capemgr.disable_partno=... cape_enable=bone_capemgr.enable_partno=...

They used to work before 4.4.x came about. Just bits and pieces gathered from forums plus a lot of trial and error.

Restore MySQL database from dump file

When restoring a MySQL db from a .sql file (such as an SQL dump file created by mysqldump), the login credentials on the target (including root) may be overwritten by the source .sql file if the .sql file was created with the --all-databases option.

RabbitMQ TLS

After copying the ca cert and key files, specify their locations in RabbitMQ's config file (/etc/rabbitmq/rabbitmq.config). Make sure the user "rabbitmq" can read them, especially the key file. Otherwise TLS connection attempts would just get stuck with no error message showing up in server nor client.

Cloning a Raspberry Pi SD card

The goal is to clone the SD card of a Raspberry Pi after setup and installation, perhaps for backup or to make more copies of the same setup. Copying the SD card as an image file (.img) onto a regular machine is simple - just install Win32DiskImager (Windows) or Etcher (Windows/Mac) and click through the prompt. The tricky part is writing the .img file back into other SD cards.

All SD cards are not made equal. Not for cards that claim to have the same capacity. Not even for cards of the same stated capacity that come from the same Amazon order. Off by one byte and Win32DiskImager / Etcher would complain about the card being too small to hold the image. The simple solution is to use a bigger card. Card sizes grow by a factor of two, so you'd need a 32GB card to hold the image of a 16GB card (pretty much the smallest size you can find in Q4 2017). It works, but how'd you backup your 32GB card?

Another way to get around this is to resize the .img file. Usually very little space is actually used on a newly prepared Pi (a 2017 Raspbian Lite image with RabbitMQ, pika, numpy, etc. all installed for both Python 2 and 3 takes only 1.6GB of space), so most of the card is actually empty and can be trimmed from the image file. The process goes roughly as follow: boot a machine using a GParted / Ubuntu Live image, mount the storage device (e.g. USB stick) holding the .img file, mount the .img file as a loopback device, resize the file system using GParted, unmount the loopback device, then truncate the .img file.

First boot into the live image (if you are using the Ubuntu Live image, make sure you don't accidentally install it). You will also need to mess with the boot order of your machine at least temporarily. There's extensive resource elsewhere for this. Once in, mount the USB drive holding the .img file (if it isn't automatically mounted; use lsblk to find out what the device name is). The partition on my USB drive shows up as /dev/sdb1. My .img file is named node-080.img):

sudo mkdir /media/usb0
sudo mount /dev/sdb1 /media/usb0

Now mount the .img file as loopback device:

sudo losetup -f (take note of its output; mine is /dev/loop1)
sudo losetup -P /dev/loop1 /media/usb0/node-080.img

Launch GParted:

sudo gparted /dev/loop1

Resize the second partition (the first one is the /boot partition, which is tiny) to the content, leaving ~200MB of empty space at the end. Commit and exit.

Unmount the loopback device:

sudo -d /dev/loop1

Now truncate it, but first find out where the last sector of the partition is:

sudo fdisk -lu /media/usb0/node-080.img

Take note the sector size (512 bytes for me) and End sector. Then truncate:

truncate --size=$[(END_SECTOR+1)*512] /media/usb0/node-080.img

Verify:

ls -al