Pebble watch programming to extend battery life.

These are my observations to date on battery life with the Pebble classic watch. I figure the data will be of interest to other watch face developers.

For my own Pebble watchface I wanted:

• Simple digital display with seconds counter.
• Show current date.
• Large characters to be readable in poor light conditions.

Once it was running, I wanted to measure and optimize battery life. The watch reports battery state in 10% increments, so I track the level changes as a function of time.
Pebble has some hints online at developer.getpebble.com/guides/best-practices/battery-perform-guide/ . Basically, they say to do as little as possible when servicing the timer ticks, and minimize the portion of the screen that's updated.
The plot here was obtained with the watchface shown in my previous post: blog.sensicomm.com/2015/09/pebble-watch-programming.html . The green lines are the first version: I call the routines to update everything on the screen every second. For the blue line, I update the seconds display every second, but the rest of the display only updates every minute. For the red line, I update the seconds every second (obviously), the hour and minute update when the minute changes, and the day updates every hour. The short magenta line is like red, except I turn the backlight off (instead of auto) and turn the watch off at night. Bluetooth was off in all cases.
Observations:

• The time from end-of-charging to 90% battery level varies widely, from a few minutes to many hours. My guess is that the battery keeps trickle charging even after the display shows charge is complete: the shortest times to 90% were when I took the watch off charge immediately, and the longest were when it was connected for an hour or so after the indicated completion of charge.

• That said, minimizing unnecessary screen updates appears to make a significant difference in power use: an additional day or so before the battery drops to 40% remaining power.

• I probably won't bother keeping the backlight off or turning the watch off at night: the savings don't seem that great and the inconvenience is significant.

• The screen backlight was in auto mode: it comes on for a few seconds when the watch shakes. It did occasionally come on during all tests (except magenta). No sure how much difference it made.

Again, this is for the Pebble Classic; no idea how it works on other Pebbles.

Pebble watch programming.

Time for a new watch. I chose the Pebble classic because I like the idea of a daylight-readable (e-paper) display and multi-day battery life between charges. The fact that several were available on ebay at good prices didn't hurt either.
Yes, I do love the display. It's a crisp and clear monochrome, easily readable in sunlight. In the photo, you may notice a bit of "rainbow" effect to the left of the time and date. That seems to be a polarization effect: it's noticeable when wearing polarized sunglasses or with indirect illumination from a clear sky. In direct sunlight or artificial light the rainbows go away.

Programming

The watch has an ARM chip in it, so of course I have to develop my own watch face. Pebble has an online development platform, but I decided to install the SDK on my Debian PC. I got the SDK from developer.getpebble.com/sdk/ and installed it per the instructions, which includes installing several libraries and python packages. A couple of notes:

• The "pip install -r requirements.txt" command takes a long time to run -- several minutes.
• I did not install the Pebble-supplied ARM compiler: it requires a later version of glibc than I have installed. I already had a compiler installed (blog.sensicomm.com/2014/02/stm32-on-linux-again.html), and it seems to work fine.
• To tell the SDK where the existing compiler is:
• cd $HOME/pebble-dev/PebbleSDK-3.3/
• ln -s  /opt/gcc-arm-none-eabi arm-cs-tools

And it works. I was able to compile a sample program using the "pebble build" command and install it using Bluetooth and an Android phone.

HDMI-VGA adapter for Raspberry Pi

This year Santa left an HDMI to VGA adapter under the christmas tree. I have an old LCD monitor with only a VGA input while the Raspberry Pi and Beagleboard/Beaglebone boards only have HDMI outputs.
The specific adapter is under $10 from seeedstudio.com, although I see a bunch of others on ebay and other sites that look similar.
Setup on the Raspberry Pi was pretty easy - only one Google search. Had to edit the /boot/config.txt file to force the Pi to use the HDMI output and to set the screen resolution (both VGA and HDMI can report screen resolution back to the host, but it doesn't seem to happen with this setup).
Configuration info was found at www.raspberrypi.org/forums/viewtopic.php?p=269212.
Internally the adapter is just a Chrontel CH7101A chip to do the HDMI-VGA conversion, and an Everest Semiconductor ES7144LV audio output chip. My unit pulls about 180 milliAmps from the +5 volt output of the HDMI connector. That's way more than the 50 mA maximum (according to Wikipedia), but the Pi is driving it without any problems. I haven't tried the adapter with Beagles yet, but research so far indicates that they require an externally powered adapter because they can't supply enough current via HDMI.
Caution: poking around inside will most likely void the warranty and might smoke the adapter and/or the Beagleboard. You're on your own if you try something like this:
Interestingly, there's space on the lower right corner of the PCB for a USB connector as an alternate +5 input. I took out the zero-ohm resistor (R1, just to the left of the USB connector footprint), and brought out 3 wires: Ground, HDMI +5 out, and +5 power in. Now I can just connect the +5's together for the Pi and should be able to use external power for the Beagles.

Debian on BeagleBoard classic.

I have one of the original beagleboards with the omap3 processor, which is ARM+DSP coprocessor. Originally it used the Angstrom Linux distribution, which uses bitbake to build the kernel and all related software tools. I saw recently that Debian is now supported on this device; I like to run Debian on everything including my PC's, BeagleBone Black, and Raspberry Pi (raspbian - almost Debian), so why not on the beagleboard as well?
My hardware setup is a USB-serial adapter from a Linux (Debian, of course) host to the serial port of the Beagleboard. I also have a Sabrent USB-Ethernet adapter on the Beagleboard.
The "official" instructions seem to be at elinux.org/BeagleBoardDebian, which I found from beagleboard.org/project/debian. Per those instructions, I downloaded the netinstall package from github.com/RobertCNelson/netinstall (using git of course), and put it on a 16GB SD card using the command:

sudo ./mk_mmc.sh --mmc $SDCARD --dtb omap3-beagle --distro wheezy-armhf --firmware --serial-mode

On my PC I have SDCARD=/dev/sdb, because that's where the memory card shows up when it's plugged in. MAKE SURE you get this right, because you could wipe out a disk on the PC if you get it wrong. I decided to uses the --serial-mode option to work from the serial port and avoid any HDMI display issues.
Moved the SD card from the PC to Beagleboard, powered up, and got a typical Debian install menu on the serial port! I used

minicom -D /dev/usb/prolific2303 -b 115200 -o

to connect to the USB-serial port. The Beagleboard serial port does not use the modem control lines, so had to turn off the "Hardware Flow Control" and "Modem has DCD" options in minicom.
The netinstall process was just like installing Debian on a PC: select some options and wait for it to download a bunch of packages. It found the Sabrent ethernet and used it with no problem; device usb0 shows up as a network device as well, so it should be possible to install by using a USB connection to the PC host, but I didn't try that.
Finished the install, rebooted the Beagleboard, aaaannnd - nothing happened!!! Load process just stopped in uboot. After a few hours of screaming, hair-pulling, and spelunking in uboot macros, I found the problem:
I had set up /boot as a separate partition.
The uboot macros look for  /boot/uEnv.txt on each partition and then boot Linux using that partition as the root partition. Made /boot a normal directory instead of a mount point, patched up /etc/fstab, and uboot brought up Debian with no problem.
Did my usual Debian tweaks (sensicomm.blogspot.com/2013/01/my-debian-tweaks.html) and everything seems to be working as expected.

Goats and Coffee

OK, this post is way off normal topics. Last month my wife and I were part of a team that visited a non-government organization working on economic development in Guatemala. The project related to raising goats and fighting the coffee rust fungus that's been causing so many problems in Central America.
I put together a writeup that gives more background on the problem and how it's being approached: www.rothweiler.us/guatemala-2014 .
It's outside my area of expertise, but looks like an interesting approach that makes good use of local resources. Comments (positive or negative) from folks with more experience are welcome.

Parallel port jtag

I've been using a homebrew version of the Xilinx DLC5 parallel port jtag adapter for programming my fpga boards. The DLC5 is no longer supported by Xilinx, but some Linux jtag programmers still support it.
Recently I moved to a new PC, and my DLC5 hack no longer works with that parallel port. I can see on the scope that the right pins are moving, but the chip won't program. I suspect that either the rise and fall times are too slow, or there's noise on the signal lines.
Anyway, I had a sample of the SiLabs si8663 digital isolator, so I decided it's time to build a new interface. The Si8663 is a hex isolator (3 signals each direction), that's spec'ed to operate up to 150 Mbps bit rate (WAY more than needed for this app). Another neat feature is that the drivers on each side work from 2.5 to 5.5 volts, providing a level shifter at no extra charge.
Board is available on OshPark (www.oshpark.com) for anyone interested. Project name is "isopartag 140513". Circuit's simple: chip + 4 bypass caps on the bottom. The design includes resistors to tap power from unused pins of the parallel port, but they haven't been added yet, to that feature is untested. For now I just tap 5 volts from an unused keyboard or mouse port.
Caution:The Si8663 comes in two versions: a wide body for safety isolation, and a narrow body intended more for electrical noise isolation. I'm using the narrow version, and the board is not designed with wide separation between the input and output sides. In other words, this design is for low voltages only, don't use it where safety is an issue.

via-rhine in Debian Wheezy

This blog post is only of interest to a small handful of people,  but since you found it, it might be you :). As always with system changes, there's a chance of damage or data loss. So check your backups first.

I have an old Averatec notebook that I use for travel and when I don't want to take risks with my main PC. I'm planning a trip so it's time to update to the latest debian distribution. After the update, everything seems to work, except the via-rhine wired ethernet.
The symptoms appear similar to Debian bug report 708757 . After a lot of hacking and experimenting, I finally upgraded to the latest kernel in wheezy-backports and the problem went away.

Details:

lspci shows the device as:
00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74)

It does work with Debian kernel packages:
 linux-image-2.6.32-5-686  # Old, from previous Debian distribution.
 linux-image-3.14-0.bpo.1-686-pae # Very latest, bleeding edge.

And does not work with
linux-image-3.2.0-4-686-pae # debian stable kernel for my system.

Fix:

To get the very latest kernel, you need the backports repository. Best instructions I found were:
scottlinux.com/2013/11/23/how-to-install-newer-kernel-from-debian-wheezy-backports
 Basically,
1) add wheezy-backports to /etc/apt/sources.list
2) apt-get update
3) apt-get -t wheezy-backports install linux-image-3.14-0.bpo.1-686-pae
4) done. reboot to use the new kernel.

Cleanup:

One side effect of the bug is that it returns a wrong and somewhat random MAC address for the ethernet controller. Recent versions of Debian try to ensure that each MAC address is always associated with a consistent eth* number. So each random mac address gets assigned to a new eth* number. If this is happening the output of dmesg will show messages like:

udev: renamed network interface eth0 to eth7

Every time udev sees a new MAC address it adds it to /etc/udev/rules.d/70-persistent-net.rules,
so the fix is to edit that file and remove all the junk MAC addresses.