Archive for category Amateur Radio
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:
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.
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:
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:
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:
But it works well enough for now …
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
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…
Seven days and 300 miles of pedal pushing:
We rode north to the start of the Cycling the Hudson Valley ride in (wait for it) Hudson, rode south while crossing the Hudson six times, then I rode north from Da Bronx while the other 100 riders proceeded south to the tip of Manhattan and the finish line in Brooklyn. Mary, alas, drove the last few days to avoid aggravating a tender tendon.
While everybody else had a touristing day in Hyde Park, we slept in our own beds for two nights.
Everything you need to know about modern bicycle touring:
The straight line along the right side of the map, from just below the New Croton Reservoir to Hopewell Junction, represents data loss from riding in a valley, plus knocking the coaxial power plug out of the battery pack where the South County Trail becomes one with Rt 100 / Saw Mill River Road for a few miles.
That last day had plenty of hillclimbing, even on the rail trail, but with a rewarding section of Rt 52 that drops 500 feet in a mile; I hit 41 mph while passing under I-84.
A good time was had by all!
Based on having to seal the rear vent hole of the previous earbud, I did the same for the new one:
The audio quality was terrible, so I tried another bud with a foam windscreen over the hole and a hole punched in the middle of the double-sided white foam tape:
The audio remained unintelligible, so I tried an upscale (but still cheap, because surplus) Koss earbud, first without blocking the vents and then with snippets of Kapton tape:
The earphone has three slits on each side, but only the middle slit has a hole penetrating the case; it must be a stylin’ thing.
That sounded better, so I’ll roll with it. There’s supposed to be a foam cover over the housing, but those things always get grody and fall off; there’s not much point.
As nearly as I can tell, contemporary earbud designs optimize for volume (dBm/mV) and thumpin’ bass, all to the detriment of actual audio quality. Based on numerous samples over the years, there is zero correlation between price (admittedly, on the low end) and audio quality (admittedly, with my crappy hearing).
I own a pair of very nice (and thoroughly obsolete) Shure E2c sound-isolating ear beetles that sound great (even with my crappy hearing), but I’m unwilling to chop them up for the bike headset …
After building the mic mount, another dab of epoxy mounted the length of AWG 10 wire I said I wouldn’t use:
The whole point of the complex mount is to expose the two noise cancelling holes on the back of the electret element:
Add heatstink tubing over the entire length of the boom wire, use more black cable ties, shape another foam ball:
And it worked on the first try, not that there’s much to it.
Yeah, that’s the HDR-AS30V camera mount up top: dork mode in full effect.
The last time around, this involved silver soldering the boom wire directly to the mic housing. This time, I filed a fishmouth in the smaller tube and epoxied it to the tube that’ll hold the mic capsule:
The smaller tube is a loose slip fit for #10 copper wire, but that’s really too heavy for the boom. I’ll probably nestle #12 wire inside another tube and epoxy that whole affair in place.
The mic capsule tube needs a rounded notch filed in one end to accommodate the wire.