bloovis.com

03/25/2010 (5:31 am)

The impoverished state of Android Apps

Filed under: android, centro, nexus one, ruby, software, treo ::

One of the reasons why I decided to buy an Android device was to investigate the possibility of writing applications for that platform. After spending a couple of days with Android, it’s pretty clear there are huge voids in the app space waiting to be filled. The transition from Palm OS is going to be painful because the following apps have no equivalent on Android:

  • Adarian Money. This is lovely little financial app that I’ve used for several years to track every penny I spend. The Android checkbook apps do not come close; the best-selling one doesn’t even track expense accounts, let alone support double-entry accounting. Clearly, a lightweight version of GnuCash is needed here.
  • DateBk. I’ve used this program for nearly ten years in its various incarnations, from DateBk+ on a Handspring Visor, to DateBk5 on a Centro. It’s the king of calendar apps and nothing on the iPhone or Android comes close. The Google Calendar app does sync with the web version, but is otherwise very minimal. It also has a serious bug: its ringtone reminders do not work when the screen is turned off, so you’ll miss appointments and meetings constantly. Pimlico has hinted that they might be porting DateBk to other platforms, but who knows when or if Android will ever be supported.
  • ListPro. This is a checklist app on steroids, almost a mini-database. I use this for packing lists, lists of items lent out to other people, notes on things to look up when I get home, to-do lists, etc. The Android apps are the usual mix: either seriously broken or only supporting a tiny subset of ListPro’s features.

If I didn’t have a full-time job, I’d start working on filling these gaps myself. I may do that anyway as a rainy-day weekend hobby. The prospect of writing in Java is not pleasant, so I may start working on the algorithms and data structures (or Models and Controllers, in newspeak) in Ruby, and hope that Duby is usable on Android by the time I need to start thinking about the UI (or View in newspeak).

03/22/2010 (7:06 pm)

Moving contacts from Palm OS to Android

Filed under: android, centro, nexus one, treo ::

After nearly ten years of using Palm OS PDAs and cell phones, I’m moving to an Android phone. I didn’t want to enter over 100 contacts manually on the new device. Some Google searching turned up ways to migrate the contact list, but most of them involved running Palm Desktop software on Windows. It turns out there is a non-obvious, Windows-free method, described here. In case that forum posting goes away, here’s a repeat of this method (slightly modified):

  1. On the Palm device, run the Phone app, then select Contacts.
  2. Choose the category to display; I chose All.
  3. Press MENU button and choose Send Category.
  4. Choose Email; this will send your contacts as an attachment file called All.vcf, and will bring up the email app to send it.
  5. In a web browser on your desktop computer, open your Gmail account.
  6. Find the message containing the attachment All.vcf. Click on the download link for the attachment and save it somewhere on your computer.
  7. In Gmail, select Contacts, then Import, and locate the file you saved in the previous step. Gmail will merge the contacts contained in that file into your existing Gmail contacts. Your Android device will find those contacts when it syncs.

03/19/2010 (5:25 am)

Solving pilot-xfer sync problem on Ubuntu Jaunty / Linux Mint 7

Filed under: centro, linux, linux mint, software, treo, ubuntu ::

I use pilot-xfer (part of the pilot-link package) to back up the data on my Palm Centro, and occasionally to install files on the Centro. It’s always worked fine on Linux Mint 6. The only thing I needed to do before running pilot-xfer was load the visor kernel module using this command:

sudo modprobe visor

But when I switched to a different laptop running Linux Mint 7, pilot-xfer never seemed to be able to connect with the Centro for the second and subsequent attempts after a reboot. Some poking around revealed that the problem is apparently due to the visor module setting up an incorrect symbolic link for the device /dev/pilot. Normally, after you connect the Centro to the computer with a USB cable and press the hotsync button, /dev/pilot should become a symlink that points to ttyUSB1. But I was seeing it point to ttyUSB0, which is the wrong device file for the Centro.

I couldn’t find an elegant way to fix the problem, so I was forced to come up with a brute force method: before connecting the Centro with the USB cable, remove the visor module and the device symlink:

sudo rmmod visor
sudo rm /dev/pilot

Then after connecting the Centro, load the visor module again:

sudo modprobe visor

Note 1: Immediately after you load the visor module, /dev/pilot will point to ttyUSB0. That’s OK. After you press the hotsync button, the visor module should change the symlink to point to ttyUSB1. If it doesn’t, you’ll have to use the brute force “unplug and unload” method I described above.

Note 2: You should always press the hotsync button on the Centro before running pilot-xfer.

Note 3: You can eliminate the need to use the -p option with pilot-xfer by setting the environment variable PILOTPORT to /dev/pilot. Putting this line in your ~/.bashrc (if your shell is bash) will do the trick:

export PILOTPORT=/dev/pilot

09/14/2008 (10:16 am)

Using a Treo 700P as a USB modem on SLED

Filed under: linux, suse, thinkpad, treo ::

During my frequent trips to Vermont over the last four years, I’ve discovered that most airports do not offer free WiFi access (Burlington VT and JetBlue at JFK are notable exceptions). In preparation for an upcoming trip to Vermont and the need to do some telecommuting en route, I figured out how to use my Sprint Treo 700p as an EVDO modem on SLED (SUSE Linux Enterprise Desktop) SP2 on a ThinkPad R61. I was aided in this by a couple of blog postings: Treo 700p Tether with Linux and Dialup Networking via Treo 700p and Ubuntu. Rather than list only the things I did differently, here is a complete procedure.

Installation:

As an ordinary user on Linux:

  • Create the directory usbmodem somewhere (e.g. in ~/tmp or ~/Desktop). Make it the current directory.
  • Download the USB Modem zip file. If you purchased the official version, it’ll have a name like usbmodem_retail_1_60.zip .
  • Unpack the zipfile using unzip usbmodem_retail_1_60.zip
  • Install USBModem.prc on the Treo; you’ll find this file in the current directory. I did this by uploading the file to my web site, and then selecting it in the Treo’s web browser.

As the root user on Linux:

  • From the usbmodem directory created earlier, run this command:
    cp drivers/linux/ppp-script-evdo-template /etc/ppp/peers/ppp-script-treo
  • Edit /etc/ppp/peers/ppp-script-treo. Change the “connect” line to:
    connect '/usr/sbin/chat -s -v "" AT OK ATD#777 CONNECT'
    Change the “user” line to:
    user USERNAME
    where USERNAME is your Treo’s user name, as determined from the main phone app, Options / Phone Info, UserName.
  • Edit /etc/ppp/pap-secrets, and add this line:
    USERNAME@sprintpcs.com *
    where USERNAME is the phone’s user name as determined in the previous step, and where there is a single tab between USERNAME@sprintpcs.com and the asterisk, not spaces.

Making a Connection:

  • Turn on the Treo, and connect it to the Linux machine with the USB sync cable.
  • Wait a few seconds and verify that the visor kernel module has been loaded with lsmod | egrep visor.
  • On the Treo, start the USB Modem program and press the “Enable Modem Mode” button.
  • Back on Linux, perform the following steps as root.
  • Bring down all other networks using ifdown eth0 or ifdown eth1 as necessary.
  • Verify that the USB modem driver and device are present using ls -l /dev/ttyACM0
  • Connect to the EVDO network using:
    pppd /dev/ttyACM0 call ppp-script-treo
    You should see messages about the connection being established. If you see a message about default route not being overridden, you forgot to bring down all your existing net connections earlier.
  • Verify the connection using route -n. You should see two entries for ppp0. To make really sure the connection is working, try ping -c3 www.google.com
  • End the connection by pressing the “Disable Modem Mode” button in the USB Modem program on the Treo. This should automatically bring down the ppp0 connection on Linux.

It should be possible to use KPPP (the KDE dialup connection application) instead of the various command line tools described above, but I have not tried this.

The irony in all this is we can finally do something with our cell phones that we were doing with Ricochet 13 years ago.

05/24/2008 (8:09 am)

Treo 700p field test mode

Filed under: treo ::

I recently moved to a rural location where cell phone signal strength is weaker. The signal strength indicator (the “bars” icon) on the Treo 700p isn’t terribly useful in finding the strongest signal in and around the house. A more accurate method of determining signal strength is to put the phone into field test mode. You do this in the main phone app by dialing ##33284, or ##DEBUG, and pressing Dial. (This is for Sprint Treos; for other carriers, see this page.) This brings up a continuously updated “Debug Parameters” display. The signal string is the “RSSI Value” on the top line.

At my home the RSSI values ranged from -95 to -102 depending on where I was standing, with the larger (less negative) numbers indicating stronger signal. According to this posting on HowardForums, -105 is the “no service” point. This will come in handy in determining where to mount the external panel antenna when it arrives.

02/22/2008 (9:26 pm)

Free music formats

Filed under: ipod, linux, music, ruby, software, treo ::

Playing music directly from CDs is, like, so last millennium. I don’t even own a CD player any more, unless a laptop with a CD drive counts. I do all my listening now via a 4th-generation iPod and a Treo 700p.

The problem is that most popular music file formats, particularly MP3, are encumbered by patents. The owners of these patents require license fees if you use files in these formats for commercial purposes, or make them available for downloading via the internet, or copy them to a physical medium like a CD — essentially, you have to pay protection money for any purpose except private use in the home.

Because the legality of patented file formats is questionable for Linux users, I decided to stop using these formats altogether. Fortunately, there are free formats that work just fine: FLAC (a lossless format), and Ogg Vorbis (a lossy format conceptually similar to MP3). My fourth generation iPod didn’t support these formats, but replacing the iPod’s firmware with Rockbox fixed that problem. The commercial Pocket Tunes software for the Treo also plays Ogg Vorbis files.

So now the interesting technical problem was to convert my CD collection to digital files for use on the computer and my two playback devices. My first two attempts at this were failures because I mistakenly chose to rip the CDs initially to Ogg Vorbis and MP3. This was a mistake because these formats are lossy, and some audio fidelity is lost in the conversion process. I could hear the loss in fidelity when comparing a CD of the Brahms First Symphony with an Ogg Vorbis file created with -q3 (equivalent to MP3 at 128Kbps). The opening bars of this symphony are very thick, and the Vorbis file sounded muddy compared with the CD. Increasing the Ogg Vorbis quality level to -q6 cleared up the muddiness, but I realized that I need to start from scratch with the ripping process.

Now my strategy is to first rip CDs to FLAC files. FLAC is a lossless format, so these files are, in essence, an exact copy of the music on the CD. FLAC is quite bulky, anywhere from three to six times the size of an Ogg Vorbis -q6 file of the same recording. But the FLAC files only need to live on the ThinkPad, not on the iPod or the Treo. When the ThinkPad disk fills up, I back up the FLAC files to an external USB disk, then delete them from the ThinkPad disk. I’m not too worried about the lack of redundancy here because the CDs act as the ultimate backup.

Once I have the FLAC files, I then transcode them to whatever lossy format I need for playback, typically Ogg Vorbis. As mentioned earlier, I use quality level -q6 for this step, because I find it produces results that, to my ears, are nearly indistinguishable from the original CD.

The workflow for these steps (ripping, tagging, transcoding, syncing) was not so easy at first. I was using GUI tools like grip, but as with nearly all GUIs, these tools required a large amount of manual labor: filling out forms, clicking buttons, and so forth. The problem was particularly annoying when I had ripped several albums and wanted to convert them all at once to Ogg Vorbis.

To make the process of ripping and tagging more automatic, I invented an album description file format, and wrote some Ruby scripts that use these “album files”, as I call them. Album files are simple text files that contain the artist, album title, genre, date, and track names. Here’s a hypothetical album file:

Artist=Brahms
Album=Piano Works - Radu Lupu
Genre=Classical
Date=1970
Rhapsody in B minor Op. 79 #1
Rhapsody in G minor Op. 79 #2
Intermezzo in E flat Op. 117 #1
...

The first step in ripping a CD is to create an album file for it. There are several online databases of track information that can be used; I use freedb.org. The script cdmakealbum reads the track data from a CD, queries freedb.org for a matching record, and writes a corresponding album file to standard output. I usually hand-edit the resulting album files to correct mistakes or to suit my aesthetic and organizational preferences.

The second step is to rip the CD to FLAC files and tag them based on the information in the album file. The script ripalbum does this. It keeps the files separate by using a two-level directory hierarchy (artist name, album name).

The third step is to trancode the FLAC files to Ogg Vorbis. The script flac2ogg recursively walks the FLAC directory tree and creates Ogg Vorbis files in a separate Ogg directory. The script is smart enough to skip files that have already been converted.

The final step is to copy the converted Ogg Vorbis files to the iPod. Because the iPod runs Rockbox, it’s a simple matter of using rsync to copy a directory on the laptop to a directory on the iPod. The script syncipod does this, after first running flac2ogg (thus eliminating the need for the separate transcoding step described in the previous paragraph).

While this might seem like an awful amount of work, it’s actually quite fast. The lengthiest part of the process is hand-editing the album files; once that’s done, the scripts can run unattended.

Another advantage of the scripts is that some of them take an optional parameter that tells them to pause when the CPU temperature exceeds a certain level. This prevents my flaky ThinkPad T40 from crashing when it gets too hot (which it can do during the very CPU-intensive transcoding process).