Archive for category Photography & Images
Although the pair of Ortlieb Back-Roller packs on Mary’s bike make her look like a long-distance tourist, we’re actually on our way to her garden plot:
The left-side pack suddenly seemed unusually floppy:
One second later:
Another second and it’s visible under my right hand:
The view from her bike at about the same time:
I’m expecting to fall to my right, but it’d have been better if I hadn’t kicked the bag:
The pack went under the rear wheel and out the far side:
Where it came to rest in the middle of the trail:
Elapsed time from the first picture: just under 5 s.
Did you notice the other cyclist in the other pictures? She’s why I veered so hard to my right!
A pair of these latches hold the pack onto the rear rack:
When they’re properly engaged, they look like this:
When they’re not, they look like this:
Which is obvious in the picture and inconspicuous in real life.
The strap emerging from the top of the latch serves as both a carrying handle and latch release: pull upward to open the latches and release them from the bar, lift to remove the pack, and carry it away as you go. Installing the pack proceeds in reverse: lower the pack onto the rack bar, release the handle, and the latches engage.
Unless the pack is empty enough to not quite fully open the latches as you carry it, in which case the closed latches simply rest on the bar. We’ve both made that mistake and I generally give her packs a quick glance to ensure sure they’re latched. In this case, the plastic drawer atop the racks (carrying seedling pots on their way to the garden) completely concealed the pack latches.
Tree roots have been creasing the asphalt along that section of the rail trail: the bike finally bounced hard enough to lift the drawer and fall off the rack rod.
Memo to Self: In addition to the visual check, lift the packs using the strap across the middle holding the rolled-down top in place. Remember, don’t check by lifting the carrying handle, because it just releases the latches; another easy mistake to make.
Having tired of manually decoding UDEV’s essentially random device names produced for the various USB action cameras and card readers, I put the device UUIDs in
/etc/fstab and let the device names fall where they may:
UUID=B40C6DD40C6D9262 /mnt/video ntfs noauto,uid=ed 0 0 UUID=0FC4-01AB /mnt/Fly6 vfat noauto,nodiratime,uid=ed 0 0 UUID=0000-0001 /mnt/M20 vfat noauto,nodiratime,uid=ed 0 0 LABEL=AS30V /mnt/AS30V exfat noauto,nodiratime,uid=ed 0 0
You get those by plugging everything in, running
blkid, and sorting out the results.
The 64 GB MicroSD card from the Sony AS30V camera uses Microsoft’s proprietary
exfat file system, which apparently doesn’t associate a UUID/GUID with the entire device, so you must use a partition label. The Official SD Card Formatter doesn’t (let you) set one, so:
exfatlabel /dev/sdd1 AS30V
It turns out you can include spaces in the partition label, but there’s no way to escape them (that I know of) in
/etc/fstab, so being succinct counts for more than being explanatory.
One could name the partition in the Windows device properties pane, which would make sense if one knew it was necessary while the Token Windows Laptop was booted with the card in place.
I think this is easier then trying to persuade UDEV to create known device names based on the USB hardware characteristics, because those will depend on which USB card / device / reader I use. I can force the UUIDs to be whatever I want, because they’re just bits in the disk image.
With all that in place, you plug in All. The. Gadgets. and run the script (as seen below). The general idea is to verify the bulk video drive mounted OK, attempt to mount each memory card and fire off a corresponding
rsync copy, wait until they’re all done, tidy the target filenames, then delete all the source files to get ready for the next ride.
Funneling all three copies to a single USB hard drive probably isn’t the smartest thing, but the overall write ticks along at 18 MB/s, which is Good Enough for my simple needs. If the drive thrashes itself to death, I won’t do it again; I expect it won’t fail until well outside the 1 year limited warranty.
If any of the
rsync copies fail, then nothing gets deleted. I’m a little queasy about automagically deleting files, but it’s really just video with very little value. Should something horrible happen, I’d do the copies by hand, taking great care to not screw up.
After all, how many pictures like this do we need?
The Bash script as a GitHub Gist:
Repaving the driveway truncated the roots of a maple tree and, this year, produced a handsome pair of fungii:
Seen from the side, they’re even more complex:
They’re firm and perfectly healthy, but the tree is likely doomed.
A new Toshiba Canvio Basics 3 TB drive has two partitions:
sudo fdisk -l /dev/sdb Disk /dev/sdb: 2.7 TiB, 3000592979968 bytes, 5860533164 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: 575F7910-3F93-4FC5-B50F-7D1F05810EE6 Device Start End Sectors Size Type /dev/sdb1 34 262177 262144 128M Microsoft reserved /dev/sdb2 264192 5860532223 5860268032 2.7T Microsoft basic data Partition 1 does not start on physical sector boundary.
The “Microsoft reserved” partition is new to me. It’s apparently not a real partition, but a dumping ground for Windows disk management information.
The drive is a classic Black Box:
It comes with no specs, other than the tediously qualified “3 TB”, and the Toshiba web page shows only a 5 Gb/s = 625 MB/s “Max. transfer rate”.
A quick test slurping data from the Sandisk video-rated MicroSD card extracted from the Fly6 camera shows it can write data at a sustained 21 MB/s:
time rsync -ahu --progress /mnt/Fly6/ /mnt/part/test/ sending incremental file list ./ CONFIG.TXT 33 100% 0.00kB/s 0:00:00 (xfr#1, to-chk=29/31) FLY6.VER 14 100% 13.67kB/s 0:00:00 (xfr#2, to-chk=28/31) DCIM/ DCIM/15880604/ DCIM/15980609/ DCIM/15980609/09490001.AVI 499.32M 100% 21.61MB/s 0:00:22 (xfr#3, to-chk=21/31) DCIM/15980609/09590002.AVI 497.75M 100% 20.95MB/s 0:00:22 (xfr#4, to-chk=20/31) DCIM/15980609/10090003.AVI 499.06M 100% 21.31MB/s 0:00:22 (xfr#5, to-chk=19/31) DCIM/15980609/10190004.AVI 278.10M 100% 21.48MB/s 0:00:12 (xfr#6, to-chk=18/31) ... snippage ... real 6m26.272s user 0m55.900s sys 0m25.496s
That’s with the card jammed into an Anker USB 3.0 adapter and both devices plugged into the two USB 3.0 “Super Speed” ports in the front of my desktop box. Plugging them both into the adjacent USB 2.0 ports drops the data rate to 18 MB/s.
The Sandisk card claims read-write speeds of “up to” 20 MB/s, so it’s the limiting factor.
Getting reliable performance numbers is surprisingly difficult:
dd bs=4M count=1000 status=progress if=/dev/urandom of=/mnt/part/random.bin 4177526784 bytes (4.2 GB, 3.9 GiB) copied, 214.064 s, 19.5 MB/s 1000+0 records in 1000+0 records out 4194304000 bytes (4.2 GB, 3.9 GiB) copied, 214.922 s, 19.5 MB/s dd bs=4M count=1000 status=progress if=/dev/urandom of=/mnt/part/random2.bin 4194304000 bytes (4.2 GB, 3.9 GiB) copied, 217.08 s, 19.3 MB/s 1000+0 records in 1000+0 records out 4194304000 bytes (4.2 GB, 3.9 GiB) copied, 217.08 s, 19.3 MB/s
Obviously, prying bits out of the random number generator limits the overall write speed.
Zeros, however, are cheap and readily available:
dd bs=4M count=1000 status=progress if=/dev/zero of=/mnt/part/null.bin 4169138176 bytes (4.2 GB, 3.9 GiB) copied, 23.0091 s, 181 MB/s 1000+0 records in 1000+0 records out 4194304000 bytes (4.2 GB, 3.9 GiB) copied, 23.1775 s, 181 MB/s dd bs=4M count=1000 status=progress if=/dev/zero of=/mnt/part/null2.bin 4093640704 bytes (4.1 GB, 3.8 GiB) copied, 25.031 s, 164 MB/s 1000+0 records in 1000+0 records out 4194304000 bytes (4.2 GB, 3.9 GiB) copied, 25.7781 s, 163 MB/s
But the caches take a while to drain, even after the command returns:
time ( dd bs=4M count=1000 status=progress if=/dev/zero of=/mnt/part/null3.bin ; sync ) 4118806528 bytes (4.1 GB, 3.8 GiB) copied, 23.0004 s, 179 MB/s 1000+0 records in 1000+0 records out 4194304000 bytes (4.2 GB, 3.9 GiB) copied, 23.5305 s, 178 MB/s real 0m35.887s user 0m0.008s sys 0m4.824s
Dividing 4 GB / 35.9 s says the mechanical write speed is close to 110 MB/s.
Reading proceeds a bit faster, while also running up against the effect of the many caches between the spinning platter and the screen:
time ( cp /mnt/part/random.bin /dev/null ) real 0m36.565s user 0m0.048s sys 0m1.712s time ( cp /mnt/part/random.bin /dev/null ) real 0m29.157s user 0m0.036s sys 0m1.800s time ( cp /mnt/part/random.bin /dev/null ) real 0m10.265s user 0m0.028s sys 0m1.040s time ( cp /mnt/part/random.bin /dev/null ) real 0m0.608s user 0m0.004s sys 0m0.600s time ( cp /mnt/part/random.bin /dev/null ) real 0m0.590s user 0m0.008s sys 0m0.580s time ( cp /mnt/part/random2.bin /dev/null ) real 0m31.035s user 0m0.056s sys 0m1.816s time ( cp /mnt/part/random2.bin /dev/null ) real 0m31.024s user 0m0.052s sys 0m1.860s
Unsurprisingly, copying a brace of 4 GB files in parallel takes twice as long as each cold-buffer read, so disk’s raw read speed seems to be around 130 MB/s.
The drive’s write speed won’t be the limiting factor while saving camera video data!
On the Dutchess Rail Trail, just north of Page Industrial Park:
Ya gotta admire the confidence of anyone manipulating a kilobuck of slippery glass while looking backward over his shoulder. I’ll take a helmet camera any day, if only because it’s really conspicuous.
He’s leading a group of four riders, all on spendy carbon-fiber bikes:
Presumably they’re all smiling at the sight of a recumbent towing a trailer of garden tools topped with two bags of just-picked lettuce. I’m definitely the biggest clown in this particular parade!
I wonder how they would have reacted to a propane tank in the trailer?
We’re ticking along at 18 mph and, as it turned out, drafting a quintet of upright bikes is surprisingly easy. If I weren’t towing the trailer with Mary just out of sight ahead, I’d have had some fun until they decided they’d had enough.
It’s good to bring such happiness into the world …
We heard God’s Own Weedwhacker off to the right as we approached Jackson Drive on the way home:
The chopper followed the power lines, just over the treetops, with the downdraft thrashing the leaves:
Long ago, I attended a talk about using choppers for power line inspection and maintenance. Apparently, someone with nerves of ice can replace insulator supports and aeolian dampers on high-tension lines while perched on a chopper hovering very very close to the conductors. Pilots with experience getting troops into and out of hot LZs are in high demand.
I’m sure they give the E911 call center a heads-up before taking off …
A pair of Barred Owls set up housekeeping nearby and we’ve watched them swoop down on rodents in the yard. We hope they succeed in raising their owlets!
This one kept watch on us as we cleared out a dead holly bush near the garden:
I took another picture at +1 EV to show more of the owl’s face; while blowing out the highlights:
Go, owls, go!
Taken with the Sony DSC-H5 and 1.7× teleadapter, because the Pixel phone’s camera just doesn’t have enough moxie at full zoom.