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.

Is it time to stop using Firefox because it is less secure?

Firefox has been my favourite web browser for a decade. Recently I started using Chrome in Linux because it performs better on most web pages, but there doesn't seem to be a Chrome performance advantage in Windows. Experiences with Chrome show that it is a good browser, but I prefer Firefox because I prefer Mozilla over Google.

Nowadays, Google is the Microsoft of the Internet. They own some of the most popular web sites plus the most popular web browser. Advertising is their main source of revenue, which makes them bad for privacy. Potentially giving so much of my information to Google does not seem good.

It seems like Firefox has lost its way recently. New unpopular features were added, while old features were removed, upsetting some loyal users. There doesn't seem to be much real progress. I hate how it won't be possible to disable extension signing, which means you will need to install a different build if you want to use an extension which wasn't signed via Mozilla. However, all of that was ultimately acceptable.

What really made me stop and think was when Pwn2Own announced that Firefox won't be attacked because it is too easy. Looking at comments on several sites, I didn't really see a valid defense of Firefox. Instead, some people expressed an irrational conviction that Firefox is safe and doesn't need security improvements. Then I looked at statistics on exploits, comparing Chrome to Firefox. In 2015, Chrome had 8 code execution vulnerabilities, and Firefox had 83. Previous years show a similar pattern.

Is using Firefox in Windows unwise because it is less secure? Running it in Linux probably gives you security through obscurity, but I'm already using Chrome in Linux.

Firefox will eventually get sandboxing via Electrolysis, but when? It seems like that has been "coming soon" for a long time. Is waiting for it to be released a good idea?

Don't use the Miranda NG Facebook plugin

Since Facebook disabled XMPP (Jabber), the options for connecting to Chat via a third party plugin are limited. Miranda NG, my favourite IM client, has a Facebook protocol which I was using. I had been getting captchas for sending or posting totally innocent links, like even Wikipedia or Slashdot, and even via the web interface. I didn't know what was causing this. Then I switched from the stable to the development Miranda NG version so I could use the SkypeWeb plugin. Soon after that, Miranda NG said my computer is infected and needs to be cleaned. After doing a bit of searching, I found that others had similar problems due to Miranda NG. Since then I intermittently can't send links at all.

It has been a few days since I stopped using the Miranda NG's Facebook protocol, the problem hasn't gotten better, and I'm annoyed. I don't want to use an instant messaging application which has the capability of blocking messages based on content. Much older IM protocols which allow direct connections between clients are so much better. I'm also not happy with their ability to block links in posts.

Basically, Facebook is a piece of shit which I use because others use it. Social networking should function via an Internet standard, not via proprietary web sites. It should be distributed, so you can select or run a server, instead of just logging in to one place.

I'm deactivating Facebook because it's too annoying now. Maybe eventually when I reactivate, it won''t annoy me with captchas and link blocking.

The purple-facebook plugin for Pidgin claims to use the protocol used by the Android Facebook Chat application. That could work better and not trigger captchas. Pidgin is worse than Miranda, lacking in features and flexibility. It's okay though, and I may start using in in Windows because of this.

Testing a 10X macro lens filter

The Olympus C-770 Ultra Zoom camera already has good macro capability, so there is no need for anything to help with that. However, experiments with a magnifying glass showed an interesting possibility for macro photography with zoom, and the 10X filter was very inexpensive at dx.com after the 2015 holiday $3 off $6 gift card.

Here's an nRF24L01+ module with C-770 super macro mode, without the macro lens filter. This is as close as I could get.

  

The 10x Macro lens filter allowed me to get a bit closer. It's a very slight improvement in macro capability, with a corresponding decrease in depth of field. Image quality degradation from the filter is minimal.

Using maximum zoom, it's possible to get even more magnification. There is significant image quality degradation, but you still get to see a lot more detail. You can see individual strokes of the laser engraving of the frequency on the crystal.

Taking these kinds of pictures required manual focus. Both the depth of field and the range of focus adjustment are very limited. It's easiest to set a specific focus, and then move the camera to optimize sharpness. The camera's focus adjustment would probably come in handy for focus stacking if it was mounted securely. 

For best magnification, I set the focus to the closest possible position. Due to the 10x macro lens filter, the actual camera distance is nice. It's not too close, allowing for good lighting, and not too far either.

I got the best sharpness at f/8. It seemed to minimize the hazy blurring seen in the above photos. It required good lighting to prevent blur from camera shake, but that's easy when the camera doesn't need to be too close to the subject.

With a more open aperture, there was an increase in blur when I half-pressed the shutter button, and f/8 decreased that. I nevertheless made my final focus adjustments with the shutter button half pressed.

This is a vacuum fluorescent display (VFD). You can see the cathode filaments which heat up and emit electrons, control grids used for multiplexing, and the anodes below them, which light up when electrons hit them.

This is an MC68705P3S microcontroller. The chip has a window because the program is stored in EPROM, which is erased by ultra-violet light.