My second (personal) iPhone app, C10CK, is now available in the App Store. It is a clock which displays time using binary notation – the same way everything is (eventually) stored in a digital computer. I’ve been using a binary clock since a staff member of ITP passed this past year and several alumni recalled stories of the binary clock she kept on her desk and would happily explain to anyone who asked. I now keep a binary clock on my desk and think of her when people ask me what it is. (more…)

Update 2: Before using the script, ensure that you can build tesseract for your host system normally. Also, I only tested the script with the v3 release of tesseract, not svn HEAD. If you get build errors, please try with rev 498.

Update: The script has been updated, thanks mostly to the prompting of fopen2003 in the comments below. I’ve successfully tested the resulting libs in both Simulator and an iPhone 4 (both at iOS4.x) using the PocketOCR project.

After many requests, I finally got around to looking into updating the build script to cross-compile tesseract ocr v3 for use with iPhone. Here’s the script. It seems to build the static, fat library without error. I haven’t tried to update my app to use it yet, so I really don’t know if it even works. Let me know in the comments if it actually does indeed work.

1. Check out the svn source of tesseract: http://code.google.com/p/tesseract-ocr/source/checkout
2. Copy this script into the source directory and run from there
3. Profit???

(more…)

I’ve been working sporadically on the app, trying to get the next release out the door.

Currently, the last feature holding up release is the post log upload…there are intermittent timeouts occurring and I’d like to determine if there is a lightweight way to mitigate them.

This upcoming release will likely change the “real-time” uploading to opt-in. There are two primary reasons: conserve significant battery life and to alleviate the server load from new data.

The battery savings are great…I’ve gone from close to 20% to less than 10% use over a 35 minute ride.

I’m getting low on space on the server, with about 550 hours of data logged – which is awesome – thanks to everyone who has shared their log data. However, I haven’t yet had an opportunity to visualize it and am feeling a bit overwhelmed by it. Hopefully this will throttle that a bit.

So, that’s the status…stay tuned!

Justin added a Twitter posting feature to Golden Cheetah a couple weeks ago. However, it used basic authentication, which Twitter has announced is going away in favor of OAuth only. So, after several more days of coding he did a bang up job of rolling in support using liboauth.

Now, getting liboauth and it’s prerequisites configured to play nicely with my Golden Cheetah dev environment has been another struggle. I have been making the OS X releases of Golden Cheetah for a while – and we package them as a universal binary (i386/ppc) with 10.4 support. I’ve had to custom compile Qt, QWT, srmio and all that stuff to enable this.

In brief, liboauth needed to be compiled against the same arch that GC and co. have been, and it really wanted to go native, eg x86_64 on my MacBook Pro. After a night and day of tinkering…here’s what worked. Thanks to Justin for getting this going.

Export config flags (just makes life easier on the command line):

export CFLAGS=-mmacosx-version-min=10.4
export CPPFLAGS=-mmacosx-version-min=10.4

openssl 1.0.0a:

./config -m32

liboauth 0.8.8 / curl 7.21.1:

./configure CC="gcc -arch i386" CXX="g++ -arch i386" -host i386

Golden Cheetah:

After getting linker errors for a while, I realized that I had to directly link to the static version of libcrypto that was installed alongside libssl in /usr/local/ssl.

Undefined symbols:
  "_EVP_MD_size", referenced from:
      _oauth_body_hash_file in liboauth.a(liboauth_la-hash.o)
      _oauth_body_hash_data in liboauth.a(liboauth_la-hash.o)
ld: symbol(s) not found

Here’s the relevant bit of src.pro:

!isEmpty( LIBOAUTH_INSTALL ) {
INCLUDEPATH += $${LIBOAUTH_INSTALL}/include
LIBS += /usr/local/ssl/lib/libcrypto.a
LIBS +=  $${LIBOAUTH_INSTALL}/lib/liboauth.a
LIBS += -lz
LIBS += -lcurl
DEFINES += GC_HAVE_LIBOAUTH
SOURCES += TwitterDialog.cpp
HEADERS += TwitterDialog.h
}

Rolling the extra logged sensor data into the GPX export took more effort that it should have…but I uncovered and fixed a latent bug in the export feature, so that’s a win right? Regardless, it’s was nice to use the new issue tracker at bugs.robertcarlsen.net for real(z) for the first time. I’m looking to get several other features implemented before the next released update…planning on a few weeks. Otherwise, code is available, as always, on github.

GPX export seems to be working, and imports fine into Google Earth. This is just a basic implementation of the essentials for a route; I’d really like to include other recorded sensors somehow into the track – maybe it could be a layer in Google Earth?

Looking at the ride data here reveals just how bad raw GPS data can be between tall buildings in NYC. Several data points often share the same GPS location. It seems that moving quickly with a clear path to the sky gives the best performance.

The app also quit midway though the ride – I have to look into that.

GPX export is available in the github repository.

Basic GPX export has been added to the github repo. That is all.

http://github.com/rcarlsen/Mobile-Logger/commit/9e1dc73304de562c30e64fa9a9b61840e69963c3

Golden Cheetah is about to release a new version. There have been extensive updates…some great, unique new features for analyzing cycling power training data. The full feature list will be announced with the official release. In brief:

• direct SRM download
• colorized power zones in plots
• altitude (from supported files)
• WKO file support (including bulk import)
• Critical Power (CP60) computation from aggregate CP data.
• weekly plot of time/distance and BikeScore/Intensity
• calendar view of workouts

There has also been significant work done under the hood in preparation for a pretty big announcement coming in the next few weeks. Exciting times.

Mac release candidate is available here. Linux and windows versions will be announced on the Golden Cheetah mailing list.

—

For posterity, I’ve upgraded my dev system to OS 10.6, Snow Leopard, and had to rebuild Qt and QWT. Since we want Golden Cheetah to continue to support PPC/Intel and 10.4+, here is the configure command I needed to use for building Qt 4.5.2.

./configure -static -prefix /usr/local/Qt4.5.2 -make libs -opensource -qt-sql-sqlite -LD="gcc -mmacosx-version-min=10.4" -confirm-license -universal -sdk /Developer/SDKs/MacOSX10.5.sdk

The BeachBall app has been submitted to the iPhone App Store. I’m pretty sure that I’ve crossed all the t’s and dotted the i’s throughout the application and am holding out hope for a smooth process. If all goes well it will be a great surprise just before the next semester kicks off.

Thanks to everyone who has been beta testing the (codename) Pinwheel app. I’ll be sure to give you all a copy of the final app when (if?) it’s approved.

In the meantime there are several other projects which need my attention. I’m committed to getting the in-progress work finished before moving on to new stuff…which is a strong motivator since I have a few things I’m really excited about working on. Onward…!

In preparation of submitting Pinwheel to the App Store I’ve gone and released a beta version via ad hoc distribution. Seems like it should be a straightforward prospect, however the various device provisioning, code signing profiles and entitlements made it a bit of a process for a first-timer.

iTunes also seems to be entirely unhelpful when something goes wrong with the “unknown error” message. What could it be? Code sign error? Unprovisioned device? Incorrect OS target? Mismatch in the app and mobileprovision file? It’s all a mystery in the iTunes universe.

Despite the inconvenience involved with having to generate a new ad hoc mobileprovision profile each time I add a new beta tester device, requiring a recompile of the beta app, it’s nice to finally get an app out to other non-development devices.

The ad hoc distribution process is documented well (enough) on Apple’s dev portal and on several other blogs, but my real stumbling block was navigating the Xcode interface to ensure that the proper code signing profile was being included in the binary (hint, look at the verbose build output for “embedded.mobileprovision” and ensure that the mobileprovision ID matches the correct version.)

I’ve also been getting trouble with Xcode not building using the correct provisioning, despite updating the target info and cleaning out the build folder. A restart of the program usually gets it sorted.

The next step will be to set up a Distribution build for the App Store submission. We’ll see how that goes in the end…