Jeff Epler's blog

LG Optimus S on ting MVNO

I finally talked Ingrid into switching from Sprint to ting. After deliberation, she decided to go with the cheapest Android phone, the LG Optimus S (LG-LS670). My good experience with my HTC Detail must have helped her decide to give ting a try.

Her old phone was an LG Remarq (feature phone with slider keyboard), but the service on Sprint was costing her $82 a month, and she was starting to want smartphone features like decent access to Google calendars and her e-mail. Well, she can have it all, and for only about $30 a month on ting!

If this article helps you decide to switch to ting, please consider using my referral code to get $25 off your phone (and $25 off a monthy bill for me!)

Hosting Troubles

My shared hosting server apparently burned down, fell over, and then sank into the swamp. It looks like my main blog is back, but images and css are still missing. Ugh. Hopefully in another day or two everything will be back to normal.

dusub: Subtract two 'du'-style listings

Life is a constant war against the limited size of backup media. Here is my next weapon in the fight: dusub. Save a du listing today, then find out tomorrow or next week what's been growing:

dusub olddu newdu

Positive numbers in the output represent an item that grew since olddu; negative numbers represent a decrease in size since olddu.

Presently, dusub only knows how to deal with plain du, not 'du -h'.

Files currently attached to this page:

dusub.py

1.4kB

Google Literal Search for Firefox

Click here to add "google literal search" to your list of search engines in firefox. This is about like the original google search engine that ships with most versions of firefox, except that it specifies the tbs=li:1 parameter so that the search is literal.

If you'd like to look directly at the .xml file that specifies the search provider, it's google-literal-search.xml.

Concept: Using rolling shutter for digital IS

Rolling shutter image of propeller blades (from Wikipedia)

I make no claim that this idea is original, but I wanted to write it down anyway.

Take an ordinary CMOS digital camera sensor with a rolling shutter and since it only costs a few cents, add accelerometers and gyros.

Now, instead of merely capturing each row from the sensor into a finished image, record each row from the sensor separately, along with its location on the sensor and the time the capture started and ended; record this and the accelerometer and gyroscope data.

When you've got enough processing power available (in the camera if you have it, on a general-purpose computer if you don't), use [the integral of] the accelerometer and gyro data to estimate the orientation and position of each row within a larger image, refine it by using any overlap between rows to align them. Once all rows have an initial placement, refine the placements repeatedly until the best fit is achieved. Paint all the rows onto a larger canvas, trim the result down and interpolate at any spots you didn't cover. ALE and hugin have some excellent algorithms for these steps, though there are probably some additional tricks and wrinkles when all the input images are 1d.

You can even incorporate multiple complete scans of the sensor in this way, adding information without increasing smearing due to motion of the camera. This information can either be used to reduce sensor noise or increase output resolution using ALE algorithms.

You could also do your best without having accelerometers and gyros: use any simple motion estimate (such as zero between the first and second rows, and the previous alignment-based estimate from row N-1..N for row N..N+1) as input to the alignment step.

Finally, an altered CMOS sensor that reads out in an interlaced fashion (or other "non-linear" fashion) would be even better, because the first few rows read out would be spread over the sensor, "pinning down" rows that are read later. For instance, if the initial stride is 16 rows on a 1024-row sensor and the full exposure time is 1/8s then the basic geometry of the scene is captured in just 2ms (relatively little motion being possible in this time) and subsequent rows read will have the opportunity for overlap with both rows "above" and "below" during the initial alignment phase.

Cancellation error

I was recently reminded of the importance of choosing numeric algorithms that don't behave catastrophically for certain inputs. One example is the calculation of 1-cos(θ) for small θ. In this case, cos(θ) is very close to 1, leading to a large cancellation error in the subtraction step.

WWVB CRT mock-up

The plan is to be able to watch the leap second on some manner of wwvb-controlled clock of my own making.

To that end, Chris gifted me with a compact B&W CRT from Goodwill, and I picked up a TellyMate, which can display 38x25 text on a TV.

Ignoring for the moment the difficulty of receiving the WWVB signal when all the interference from a CRT TV is right nearby, I've created a mock-up of what the display will look like (except that the font won't be nearly so good looking as this):


         0123456789
   0.. 9 M01100000M  Minute  = 30
  10..19 000000111M  Hour    = 07
  20..29 000000110M  YDay    = 66
  30..39 011000010M  DUT1    = +0.3
  40..49 001100000M  Year    = 2008
  50..59 100001000M_ nols LY nodst
   
  Local time:
  1:31:00.0 AM

  Thu Mar 6 2008
  UTC-0600 (CST)

At the top, the WWVB data is displayed, along with its interpretation. The previous minute and the current minute are mixed, with the cursor indicating the most recently read second of data. Whatever piece of data is currently being read or will next be read will be blanked out until all bits are received (for instance, during seconds 0..8, "minute" will be blank; from 9..18, "hour" will be blanked).

Most of the time the "_" shown after second 59 will be blank. During a leap minute it will be "_" and during the leap second it will read "M".

Below, in larger lettering, the local time will be displayed. I think I can achieve 10 updates per second, so I'll show tenths but not hundredths (or, say, thirtieths). The UTC offsets for standard and daylight saving time will be hardcoded (so if I move to Colorado to be closer to WWVB I'll have to fix my firmware).

The WWVB receiver and decoder is written and passes my tests. I have yet to write the display code (and optimize it--I can transmit fewer than 500 characters and control codes per 1/10 second to the tellymate), and I also have to work out how to get enough reception that having the WWVB display is not a big old waste of time. (or maybe I'll just display a simulated WWVB signal instead—with a disclaimer, of course. stop looking at me like that.)

Every once in a while, ssh is too slow

I'm using my OLPC XO-1 as a music server which allows anyone in the household the ability to play, stop, pause, adjust volume, and so on. This was first done by 'ssh olpc ...', but there's a substantial delay between issuing the action and its effect. So I wrote a simple web service that does the same thing. It turns out that most of the time is ssh overhead that's not present in a http connection.

$ time ssh olpc /home/olpc/bin/cmus-playpause
real  0m0.522s
$ time wget -O /dev/null http://olpc:8000/playpause
real  0m0.066s

It's nothing like the 384x speedup I got the last time I was complaining about the olpc's performance, but it's still nothing to sneeze at.