Archive for category Recumbent Bicycling

Eroded PTT Cable

While installing new underseat packs (about which, more later) on my Tour Easy, I discovered a bight of PTT cable had been touching the top of the chain:

Eroded PTT cable - Tour Easy

Eroded PTT cable – Tour Easy

The gentle ripples to the right of the worn-through section seem particularly nice; you couldn’t do that deliberately if you had to.

This section of cable should have been taped to the upper frame bars. It’s hidden under the seat, just in front of the rear fender, and between the under-seat packs, so it’s basically invisible from any angle.

Soooo, that probably explains a bit of the intermittent trouble I’d been having with the PTT switch, although most of it came from the corroded switch contacts.

Rather than replace the whole cable, I cut out the eroded section, spliced the conductors, and taped it firmly back on the tubes.

About these ads


Hudson River Eagle Sightings

A pocket camera can’t do justice to the Bald Eagles, just before dusk and halfway across the Hudson River from our river cruise yacht:

Bald Eagles at dusk - Hudson River near Hudson NY

Bald Eagles at dusk – Hudson River near Hudson NY

We got a closer look at the pair of eagles who once graced the original Grand Central Station and are now standing guard at St Basil Academy in Garrison.

This one glanced away from the entrance, perhaps to keep an eye on us:

Eagle at St Basils Academy - entrance

Eagle at St Basils Academy – entrance

Another watches over an interior road:

Eagle at St Basils Academy - cliff

Eagle at St Basils Academy – cliff

They’re two tons of cast iron apiece and, should any of you want a restoration project, I’m sure the good folks at St Basil’s could work something out.

We saw those during the Cycling the Hudson Valley tour: riding during the day, camping and touristing in the evening.

Several years ago we encountered a Penn Station eagle at the Washington Zoo:

Karen on Penn Station eagle

Karen on Penn Station eagle

Fly away, young Valkyrie, fly away …


Dutchess Rail Trail: Bee Crossing

It had to happen:

DCRT - Bee Crossing

DCRT – Bee Crossing

Given that the Sony HDR-AS30V has a 170° FOV (probably diagonally corner-to-corner), the honeybee must be an inch or two from the lens. Subsequent frames show it circling around in front of the fairing and continuing about its business.


Sony HDR-AS30V GPS Time vs. File Timestamps

Faced with the utter confusion caused by trying to figure out the interactions of the Sony HDR-AS30V time settings, I set it to local time, Time Zone GMT+0, DST off, enabled the GPS receiver, disabled the auto-off battery saver, and parked it outside with a nice view of the sky.

About ten minutes later it achieved GPS lock, which suggested the time wasn’t terribly wrong. After locking, the camera set itself to the current local time +1 hr, TZ = GMT-5, DST off; it apparently runs an embedded Linux distro, so it can convert from geographic location to time zone easily enough. It cannot know about DST, so I set DST on, the time jumped -1 hr, and it’s now set to local time, TZ = GMT-5, DST on.

A short movie produces this metadata:

exiftool MAH00046.MP4 | grep -i date
File Modification Date/Time     : 2014:09:02 17:58:49-04:00
File Access Date/Time           : 2014:09:02 16:59:51-04:00
File Inode Change Date/Time     : 2014:09:02 16:59:51-04:00
Create Date                     : 2014:09:02 20:58:41
Modify Date                     : 2014:09:02 20:58:48
Track Create Date               : 2014:09:02 20:58:41
Track Modify Date               : 2014:09:02 20:58:48
Media Create Date               : 2014:09:02 20:58:41
Media Modify Date               : 2014:09:02 20:58:48

exiftool MAH00046.MP4 | grep -i zone
Time Zone                       : -04:00

ll MAH00046.*
-rwxr-xr-x 1 ed ed 18M 2014-09-02 17:58 MAH00046.MP4
-rwxr-xr-x 1 ed ed 11K 2014-09-02 17:58 MAH00046.THM

ll -c MAH00046.*
-rwxr-xr-x 1 ed ed 18M 2014-09-02 16:59 MAH00046.MP4
-rwxr-xr-x 1 ed ed 11K 2014-09-02 16:59 MAH00046.THM

ll -u MAH00046.*
-rwxr-xr-x 1 ed ed 18M 2014-09-02 16:59 MAH00046.MP4
-rwxr-xr-x 1 ed ed 11K 2014-09-02 16:59 MAH00046.THM

Tue Sep  2 17:13:44 EDT 2014

date -u
Tue Sep  2 21:13:47 UTC 2014

The camera quickly achieves GPS lock with DST on (so it’s still able to use its recent GPS ephemeris data) and doesn’t change any of the current time, Time Zone, or DST values (so it’s happy with all that).

Based on that short experiment:

  • Internal Exif timestamp values are UTC
  • Time Zone Exif value is (Actual Time Zone + DST)
  • File modification is (local ending time +1 hour)

Some poking about shows that I misunderstood the “create” time, which actually holds the time when the file metadata changed, meaning there’s no way to tell when the file was created. I did know that the “access” time tracks the last time the file was opened: reading the Exif data will update the access time.

The +1 hr offset in the modification timestamp will (probably) vanish when DST goes off in the fall.

The Exif data contains the correct UTC times for the video’s Create and Modify dates, as well as the net Time Zone offset, which means I (well, a script using exiftool) can calculate the (UTC or local) time corresponding to the beginning & end of the video file. Indeed, exiftool can whack the file’s modification time directly from the Exif data:

exiftool '-FileModifyDate<ModifyDate' MAH00046.MP4
1 image files updated

Extracting still images proceeds from a time relative to the start, so the number of frames plus the calculated start time gives the actual time for that frame, modulo converting frames into hh:mm:ss.ff format and getting the addition correct.

Perhaps it makes more sense to set the modification time to the starting time of the video, thus simplifying the calculations:

exiftool '-FileModifyDate<CreateDate' MAH00046.MP4
1 image files updated

Both of those times are the UTC values, so a further adjustment based on the time zone would be in order. It’s not clear whether exiftool can perform that calculation internally or if it must be a two-step process.

A cheat may be in order: the thumbnail file modification timestamp matches the starting time of the corresponding video file. The script can base its calculations on the thumbnail timestamp. Of course, both of those are subject to the FAT-vs-DST problem.

More pondering is obviously in order.

For what it’s worth, the raw GPS log data from the camera lives in the PRIVATE/SONY/GPS/ directory, with a YYMMDDnn.LOG file name. It relentlessly accumulates two records every second:


The battery life is so terrible with the GPS on that I don’t plan to use it much at all, but at least now I know how to set the clock’s time…


Tour Easy: Push-to-Talk Switch Rework

The handlebar-mounted PTT button for the amateur radio on my bike once again went toes-up, most like due to the accumlation of road dust and rainwater over the years. Rather than replace the switch, which would require peeling off a massive glob of hot melt glue and resoldering the wires, I just carved the tops off the rivets holding the cover in place, pried off the cover, and removed the button to reveal the top of the switch dome:

Handlebar PTT switch - corroded dome

Handlebar PTT switch – corroded dome


The dome flexes outward to contact the (rather crusty) terminals on either side, so all the action happens under the dome.

A lineup of the plastic button, the inverted dome, and the cover plate:

Handlebar PTT switch - components

Handlebar PTT switch – components

The top and bottom of the dome show some grit: that’s where it contacted the switch terminals.

Wiping the crud out of the switch body, scrubulating everything with contact cleaner, and putting it all back together restored the switch to working order. There’s (once again) a snippet of Kapton tape over the cover holding it in place, but I don’t expect this to last very long:

Handlebar PTT switch - kapton cover

Handlebar PTT switch – kapton cover

But it works well enough for now …


Sony HDR-AS30V vs. ExFAT vs. Ext2 Times: Total Bafflement

I’d like to overlay a timestamp on still images extracted from Sony HDR-AS30V camera videos, ideally including the frame number, to record exactly when the incident occurred. Movie players use relative time, with 00:00:00 at the beginning of the file, so we’ll need either the file timestamp or the timestamp recorded in the image’s Exif data, plus the frame number modulo 60 (or, shudder, 59.94 for NTSC).

The ExFAT format used on 64 GB MicroSD cards stores the file’s creation time, its modification time (writing data), and the most recent access time (reading data). That’s similar to the Linux ext2/3/4 filesystem time and unlike plain old FAT, which omits the access time.

The various FAT formats store local time, with no regard for time zones, Daylight Saving Time, or anything else. Linux stores times as UTC and converts to local time on the fly. This has catastrophic consequences for getting any of this right.

It helps to have alias ls='ls -h --color=auto --time-style=long-iso' in your .bashrc file.

The HDR-AS30V has a year-month-day calendar, a 24-hour clock, a Time Zone value, and a separate DST on/off setting.

Turning DST on adds 1 hr to the Time Zone value, turning it off subtracts 1 hr. That has the side effect of changing the clock time: not what I expected. You must, therefore, set the TZ first, then DST, then the clock, which does not follow the menu’s natural order of things.

The camera sets file timestamps as it creates the files, but Linux also meddles with the values while displaying them. Some doc suggests that Linux regards FAT file timestamps as UTC and applies DST correction, which seems to match what I see. There’s a mount option (-o tz=UTC) that seems to have no effect, as well as an undocumented time offset (-o time_offset=60) that also has no effect.

Setting the TZ to GMT+0 (Sony uses GMT, not UTC) for simplicity, setting the clock to the correct local time, and twiddling DST shows that:

  • Rebooting (remove /insert battery) doesn’t change anything
  • Metadata in file = clock setting – DST setting (-1 on, +0 off)
  • MP4 / THM file create / modify times = always clock +1 hour
  • MP4 / THM file access times = as create / modify until next Linux access

Under those conditions, with the clock set to (locally accurate) 1908, UTC+1, and DST off, then the Exif timestamp metadata for a movie created at that time look like this:

exiftool /mnt/part/MP_ROOT/100ANV01/MAH00036.MP4 | grep -i date
File Modification Date/Time     : 2014:09:01 20:08:09-04:00
File Access Date/Time           : 2014:09:01 19:10:14-04:00
File Inode Change Date/Time     : 2014:09:01 20:08:09-04:00
Create Date                     : 2014:09:01 19:08:03
Modify Date                     : 2014:09:01 19:08:08
Track Create Date               : 2014:09:01 19:08:03
Track Modify Date               : 2014:09:01 19:08:08
Media Create Date               : 2014:09:01 19:08:03
Media Modify Date               : 2014:09:01 19:08:08

The corresponding filesystem values:

ll /mnt/part/MP_ROOT/100ANV01/
total 146M
... snippage ...
-rwxr-xr-x 1 ed root  14M 2014-09-01 20:08 MAH00036.MP4
-rwxr-xr-x 1 ed root 8.5K 2014-09-01 20:08 MAH00036.THM

ll -c /mnt/part/MP_ROOT/100ANV01/
total 146M
... snippage ...
-rwxr-xr-x 1 ed root  14M 2014-09-01 20:08 MAH00036.MP4
-rwxr-xr-x 1 ed root 8.5K 2014-09-01 20:08 MAH00036.THM

ll -u /mnt/part/MP_ROOT/100ANV01/
total 146M
... snippage ...
-rwxr-xr-x 1 ed root  14M 2014-09-01 19:10 MAH00036.MP4
-rwxr-xr-x 1 ed root 8.5K 2014-09-01 20:08 MAH00036.THM

The THM file contains a 160×120 pixel JPG thumbnail image taken from the first frame of the corresponding MP4 file. For longer movies, it’s more obvious that the MP4 file creation date is the start of the movie and its modification date is the end. The maximum 4 GB file size of corresponds to exactly 22:43 of 1920×1080 movie @ 60 frame/sec (the metadata says 59.94).

The +1 hour offset in the file create / modify times comes from the FAT timestamp being (incorrectly) adjusted by the Linux DST setting. When exiftool reads the MP4 file, that resets its access time to the actual time as seen by Linux, thereby crushing the bogus FAT time.

Doing the seemingly sensible thing of setting the camera to have the correct local time (roughly 1930), the correct time zone, and the correct DST setting produces this jumble:

exiftool /mnt/part/MP_ROOT/100ANV01/MAH00037.MP4 | grep -i date
File Modification Date/Time     : 2014:09:01 20:33:15-04:00
File Access Date/Time           : 2014:09:01 20:33:14-04:00
File Inode Change Date/Time     : 2014:09:01 20:33:15-04:00
Create Date                     : 2014:09:01 23:33:11
Modify Date                     : 2014:09:01 23:33:14
Track Create Date               : 2014:09:01 23:33:11
Track Modify Date               : 2014:09:01 23:33:14
Media Create Date               : 2014:09:01 23:33:11
Media Modify Date               : 2014:09:01 23:33:14

ll /mnt/part/MP_ROOT/100ANV01/MAH00037*
-rwxr-xr-x 1 ed root  11M 2014-09-01 20:33 /mnt/part/MP_ROOT/100ANV01/MAH00037.MP4
-rwxr-xr-x 1 ed root 8.2K 2014-09-01 20:33 /mnt/part/MP_ROOT/100ANV01/MAH00037.THM

ll -c /mnt/part/MP_ROOT/100ANV01/MAH00037*
-rwxr-xr-x 1 ed root  11M 2014-09-01 20:33 /mnt/part/MP_ROOT/100ANV01/MAH00037.MP4
-rwxr-xr-x 1 ed root 8.2K 2014-09-01 20:33 /mnt/part/MP_ROOT/100ANV01/MAH00037.THM

ll -u /mnt/part/MP_ROOT/100ANV01/MAH00037*
-rwxr-xr-x 1 ed root  11M 2014-09-01 19:34 /mnt/part/MP_ROOT/100ANV01/MAH00037.MP4
-rwxr-xr-x 1 ed root 8.2K 2014-09-01 20:33 /mnt/part/MP_ROOT/100ANV01/MAH00037.THM

The only correct time in that mess is in the next-to-last line: the access time for the MP4 file. Every other timestamp comes out wrong, with the internal metadata values being off by +4 hours; that suggests the camera sets the internal timestamps to UTC.

As nearly as I can figure, the only way to make this work requires setting the clock to the local time, TZ to UTC+0, and DST off. That will screw up the filesystem timestamps, but at least the Exif metadata will be correct, for some value of correct.

The camera’s GPS receiver depends on the clock for its initial synchronization. I don’t know how the TZ and DST settings affect the clock’s correctness for that purpose.

I do not know if / how / when the displayed times have been altered by the programs that display them.

I think exiftool can extract the times from the internal metadata and fix up the filesystem times, but that’ll take more tinkering.

Sheesh & similar remarks…


Real Estate Sale Signage

Real Estate Agencies used to post property marker signs like this:



Even far off to the side, a bright background color catches your eye:



The signs sported primary colors, reasonably large type, and simple words, making them almost readable in those pictures and definitely legible from the driver’s seat. While not particularly handsome or stylin’, they got the message across: this house is for sale.

Then a strange thing happened.

Berkshire Hathaway somehow got into the real estate business and Borged several of the local agencies. BH being a Name Brand with a connotation of wealth & taste, their branding imposed a subtle touch on the new signage:



No, you can’t quite read that in real life, either, although the agent’s name and number on the header come close to the old standard.

One day, a old-school sign appeared along one of our usual routes:



Although white and green don’t pop out of the background, the sign has enough contrast that you can read what’s needed.

Then they became affiliated with Christie’s, the Big Name in the realm of high-end auctions. I have no idea what Christie’s has to do with real estate, but if Berkshire Hathaway can do it, it seems Christie’s thinks they can do it even better.

In any event, the Christie’s Corporate Standard evidently calls for very, very subtle signage:


That sign might mark a high-end bed and breakfast, but certainly does not tell me that the place is for sale: none of the text approaches readability from the street, certainly not at normal travel speeds, and nothing about it even suggests that I should take action.

A few weeks later, two hang tags added a COMMERCIAL note (the property evidently has potential to become an office or retail space) and the agent’s name and phone number in minuscule type:



After a while, a very bright red do-it-yourself HOUSE FOR SALE placard suggested the property owner wasn’t entirely satisfied with the results to date:



The high-contrast black-on-white FOR SALE header definitely doesn’t match the rest of the sign, but its more legible information might motivate you to pause and puzzle out the rest. The red placard vanished a few days after the header appeared, leaving us with this peculiar mix:



None of the (numerous) Christie’s signs in the area have a header, so this may be a case of a squeaky wheel getting greased. I won’t be surprised to see a corporate image change, including larger type, as these fancy signs weather away.

Perhaps the correct conclusion to be drawn is that, in this Internet age, nobody buys a house based on the quaint custom of driving by a house-with-sign, thinking “Hey, that’s perfect for me!”, and calling the agent, so there’s no need for anything more than a pro-forma marker identifying a property that will be selected by filters applied to MLS / Zillow databases.

The most recent change simplifies the sign to the bare minimum:



Perhaps we’ve witnessed a falling-out over typography?

This began as a test of the Sony HDR-AS30V camera’s resolution, with the obvious conclusion it wasn’t intended as a camera suitable for recording text.