Cold brewing coffee by agitating all night

Making coffee with boiling or near boiling water vapourizes a lot of the nice smelling volatile compounds (so the room smells nice but you don't get to enjoy them from your cup) and changes other compounds. Overnight in the refrigerator makes very weak coffee (doesn't extract much), but has promising taste. One could probably compensate by using a lot more coffee, but I don't like the inefficiency. So, I tried to extract more by agitating all night.

That is simply a geared electric motor slowly spinning a water bottle with some water and ground coffee inside. The 24V motor is powered by 3V from an adjustable wall wart. It's all put together in a temporary way because this is an experiment. I made it extra rigid because I don't want anything to shake apart as the water sloshes around. The plastic tub underneath is just in case something breaks or leaks.

In terms of darkness and caffeine, the coffee is similar to normal coffee made with hot water. It is less bitter, but it also lacks some other elements of flavour. I guess some aren't very soluble in cold water, and some are probably oils and not water soluble at all. The result isn't bad, but it's not better than my normal way of making coffee in a French press.

I wonder about using other liquids in this setup. Would milk extract more? What about extracting with oil? I wouldn't want to drink that, and it probably wouldn't extract caffeine because it is a water soluble alkaloid, but it might produce strongly coffee flavoured oil which is useful for cooking.

Kodi in Raspbian

Raspbian seemed to be the obvious choice for Raspberry Pi 2 Model B operating system. It's customized for running on the Raspberry Pi, contains all the proprietary GPU stuff, is basically Debian, and receives regular updates. Its packages are compiled for earlier versions of the Raspberry Pi and don't take full advantage of ARMv8, but according to most benchmarks that's not a big deal. I installed Raspbian Jessie.

Kodi (formerly known as XBMC) is available as a package in Raspbian and easy to install. However, my first impressions after running it from the X desktop weren't very good. The menus would sometimes get messed up, with the mouse leaving trails. Quitting would often leave me with a black screen. Sometimes it would be possible to switch into a text virtual terminal and back into X, but other times that would be impossible and a reboot would be necessary.

I mostly used the Pi as a low power always on PC. Now I'm giving Kodi another try, for using the Pi as a media player. This time I'm auto-starting it at boot time, without running X. Using the graphical Raspberry Pi configuration utility, I set it to boot to text mode and not auto-login the pi user. Automatic startup of Kodi can be enabled by editing /etc/default/kodi. The kodi user that it defaults to using is created when Kodi is installed.

Unfortunately, this runs into a big problem: after rebooting Kodi ran but couldn't be controlled by the keyboard or mouse. It's a simple problem and there's a simple solution. The kodi user doesn't have access to input devices, and needs to be added to the input group via "sudo addgroup kodi input". However, that's very inconvenient to accomplish once Kodi is starting automatically and you can't control it, so make sure you do it before rebooting.

The other big problem was that most HD videos didn't play. There was no error message, though ENOSPC errors could be seen in the log. I guessed this was due to insufficient memory allocated to the GPU. The default is 64 MB, and Kodi recommends 128 MB for the Raspberry Pi 1 and 256 MB for the Raspberry Pi 2. After adding gpu_mem=256 to /boot/config.txt that was fixed.

Kodi now seems to work fine in Raspbian, with no need to install a Kodi centric distribution.

Update: Another problem was the lack of a shutdown option in the Kodi power button dialog. I fixed that by changing PolicyKit settings using instructions from this page:

cat <<EOF | sudo tee /etc/polkit-1/localauthority/50-local.d/custom-actions.pkla
[Actions for kodi user]
Identity=unix-user:kodi
Action=org.freedesktop.upower.*;org.freedesktop.consolekit.system.*;org.freedesktop.udisks.*;org.freedesktop.login1.*
ResultAny=yes
ResultInactive=yes
ResultActive=yes
EOF

A firmware upgrade fixed Linux USB 3 suspend problems

I recently got a NEC/Renesas uPD720201 based USB 3 card. It worked perfectly in Windows 7 with the 3.0.23.0 driver. It also worked when I booted Ubuntu 15.10 Wily Werewolf, but sometimes failed after suspend to ram (sleep) and sometimes prevented sleep. Upgrading to the latest development version, Ubuntu 16.04 LTS Xenial Xerus, did not fix the problem. Here is what the kernel logged when sleep failed:

xhci_hcd 0000:03:00.0: WARN: xHC save state timeout
suspend_common(): xhci_pci_suspend+0x0/0x70 returns -110
pci_pm_suspend(): hcd_pci_suspend+0x0/0x30 returns -110
dpm_run_callback(): pci_pm_suspend+0x0/0x140 returns -110
PM: Device 0000:03:00.0 failed to suspend async: error -110
PM: Some devices failed to suspend, or early wake event detected

Once this happened all subsequent attempts to suspend failed the same way, and only rebooting might allow suspend to work again.

According to Device Manager in Windows, the USB controller firmware version was 2020. Renesas doesn't offer any official downloads, but 2024 and 2026 are available for download elsewhere. Upgrading to 2026 (sometimes shown as 2.0.2.6) via k2026fwup1.exe (SHA1: 44184f1379c061067ac23ac30055a2b04ddf3940) seems to have fixed the problem. I haven't had any problems with suspend or resume, and the USB 3 ports remain functional after many suspend and resume cycles.

This probably also affects uPD720202, which is the same chip but with only two USB ports. The Renesas uPD720200 chip uses different firmware.

Some people reported problems with the 2026 upgrade procedure. Here someone recommends a 2024 downgrade followed by another 2026 upgrade if there are problems. I uninstalled the USB 3 driver in Windows 7 before the upgrade, thinking stuff that the driver does might interfere. The upgrade was quick and problem-free for me, and after rebooting I re-installed the driver.

BTW Here's a photo of the card:

Partitions can make whole drives inaccessible, as if they failed

After setting up some partitions via fdisk in Linux and rebooting, the GA-P35-DS3R F13 BIOS hung while detecting the SSD. The Dell Inspiron 6400 laptop didn't hang, but it reported an error when I put in that SSD. It seemed as if the drive failed. Then I booted Linux with the SATA cable unplugged, and plugged in the cable while Linux was running. The drive was detected and it worked perfectly. Overwriting the partitions in the MBR with zeroes caused it to be detected by the BIOS. Of course that's not a solution because I need that partition.

The solution was overwriting the CHS addresses with FE FF FF bytes. That is the same value used for CHS addresses beyond the 8GB limit, where only LBA can be used. Modern software should always be using LBA anyways, so the CHS shouldn't need to be correct.

This is probably a bug Intel ICH9R BIOS.

Here is the partition which triggered the bug: 80 41 02 00 07 00 33 0D 00 10 00 00 00 20 03 00

Fixing Prolific PL2303 code 31 error

The code 31 error seems to happen when a PL2303 device tries to create a COM port which already exists. For example, it happens if you already have COM8 and you plug in a PL2303 device which tries to also configure itself to COM8.

COM port numbers are usually defined based on the USB port, so the simplest solution is to plug the device into a different port, and hope it will get a different COM port number.

The other solution is to reassign the port number. You can do this via Device Manager. Go into the Ports (COM & LPT) section, right click on the port you want to change, select Properties, go into the Port Settings tab, and click on the Advanced button. In the bottom of the Advanced Settings dialog you can change the COM port number. The list helpfully shows what numbers have been assigned to other devices, including devices which are not currently plugged in. If this cannot be done due to the code 31 error, either change the conflicting device's port, or unplug the conflicting device, plug in the new device and then change the new device's port.

I don't trust Windows with rare operations like this, because they probably haven't been tested enough. A port may fail to work or you might get a bluescreen. So, I recommend rebooting. Everything should be fine afterwards.