Advertisements

Posts Tagged Improvements

Ortlieb Backroller Pack Drop

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:

AS30V-0285

AS30V-0285

The left-side pack suddenly seemed unusually floppy:

AS30V-0300

AS30V-0300

One second later:

AS30V-0360

AS30V-0360

Another second and it’s visible under my right hand:

AS30V-0420

AS30V-0420

The view from her bike at about the same time:

Ortlieb-0158

Ortlieb-0158

I’m expecting to fall to my right, but it’d have been better if I hadn’t kicked the bag:

Ortlieb-0169

Ortlieb-0169

The pack went under the rear wheel and out the far side:

Ortlieb-0185

Ortlieb-0185

Where it came to rest in the middle of the trail:

Ortlib pack drop - aftermath

Ortlib pack drop – aftermath

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:

Ortlieb pack drop - QL latch detail

Ortlieb pack drop – QL latch detail

When they’re properly engaged, they look like this:

Ortlieb pack drop - QL latch - secure

Ortlieb pack drop – QL latch – secure

When they’re not, they look like this:

Ortlieb pack drop - QL latch - whoopsie

Ortlieb pack drop – QL latch – whoopsie

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.

Whew!

Advertisements

,

1 Comment

Copying Action Camera Video: Now With UUIDs

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?

Ed signalling on Raymond

Ed signalling on Raymond

The Bash script as a GitHub Gist:

3 Comments

Siglent SDS2304X Oscilloscope: Homebrew Front Cover

Both my Tek 2215A and HP 54602 oscilloscopes came with snap-on front covers to protect all those delicate knobs and connectors. Not so the Siglent SDS2304X, which is basically a flat shoebox with a handle: the case has no features for a cover to snap onto, Siglent doesn’t offer a padded carrying case, and it’s too thick big for any of the laptop bags around here.

I’ve been lugging it to Squidwrench meetings and can easily visualize a gash across the LCD panel or a knob rammed against a door frame.

So I trimmed a pair of foam angles, punched holes to fit around the knobs along the right edge, cut up a cardboard tray from the heap, and duct-taped the whole mess together:

Siglent SDS2304X Oscilloscope - crude front cover - interior

Siglent SDS2304X Oscilloscope – crude front cover – interior

The cover is equally ugly from the outside:

Siglent SDS2304X Oscilloscope - crude front cover - installed

Siglent SDS2304X Oscilloscope – crude front cover – installed

A Velcro bellyband around the whole affair / through the handle holds it together.

I considered 3D printing a set of corners and screwing them to a flat plastic plate, but came to my senses just in time.

6 Comments

Bypass Lopper

Some surreptitious brush clearing called for a tool larger than our wonderful Fiskars PowerGear pruner, so I unearthed a long-disused bypass lopper in the garage (it may have Come With The House). Alas, the pivot bolt lost its jam nut long ago:

Bypass loppers - OEM 10 mm bolt

Bypass loppers – OEM 10 mm bolt

That’s an M10x1.5 bolt, for which I lack a corresponding nut.

But 3/8-16 is approximately M10x1.5, for small values of thread engagement, and I do have an assortment of inch-sized stainless steel fasteners:

Bypass loppers - 0.375 inch bolt

Bypass loppers – 0.375 inch bolt

The nylon lock nut jams the bolt against the left blade, with the split washer applying pressure to the tapered blade. Slobbering oil in the sliding joints restored it to perfect working order.

The weird round dingus on the far side of the pivot, up against the handles, is a bumper cushioning the fully closed position. It’s a nice touch and might work better if its rubber pad hadn’t aged out over the decades spent in the garage waiting for this very day.

It’s my kind of yard work: “What do you need killed next?”

,

Leave a comment

Toshiba 3 TB Drive Format & Speed

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:

Toshiba 3 TB USB drive

Toshiba 3 TB USB drive

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!

4 Comments

Monthly Science: Calibrated Bottle

Mary used to mix up her oil-and-vinegar dressing using a measuring cup, then she drew markings on the bottle, then I added tidy labels:

Calibrated Oil-and-Vinegar bottle

Calibrated Oil-and-Vinegar bottle

The labels align with her process: she adds ½ C oil first, then ¼ C vinegar, then various other ingredients. The liquids swirl around, sort themselves out, and it’s all good.

Surprisingly, the labels survived uncounted dishwasher adventures.

2 Comments

Digital Tattoo Power Supply: Polarity Doesn’t Matter

When I rewired the guts of the digital tattoo power supply to eliminate the series foot switch, I kept the original wiring polarity, with the black wire to the sleeve and the red wire to the tip:

Tattoo Digital Power Supply - internal view

Tattoo Digital Power Supply – internal view

It’s the same color code I (strongly) recommend in the Squidwrench Electronics Workshops: use any color for the ground / common wire as long as it’s black, then, if you have a red wire, use it for the positive supply. You can use yellow for the higher supply voltage, but stop being clever.

I put suitably colored Powerpoles on the far end of the cable to replace the standard tattoo machine spring clip connector, so I can attach clip leads, battery test fixtures, and so forth and so on.

We wired the supply into a clip-leaded diode measurement setup with a current limiting resistor and a pair of multimeters to measure the diode current and forward voltage, whereupon we noticed all the meters displayed negative voltages and currents.

After a frenzy of wire-checking verified their setup was all good, I forced the simplest possible test, herein recreated on my bench:

Tattoo Digital Power Supply - polarity test

Tattoo Digital Power Supply – polarity test

Which produced this display:

Tattoo Digital Supply - reverse polarity

Tattoo Digital Supply – reverse polarity

Huh.

After a brief exploration of “Trust, but verify” territory, we swapped the clip leads from the power supply and continued the mission.

Back on my bench, I pulled the supply apart and measured the voltage at the jack terminals:

Tattoo Digital Power Supply - jack wiring

Tattoo Digital Power Supply – jack wiring

Still negative. Huh.

The bottom of the power supply PCB shows exactly what you should expect by now:

Tattoo Digital Power Supply - reversed color code

Tattoo Digital Power Supply – reversed color code

The red wire near the top of the board is, indeed, soldered to the trace labeled GND and goes to the jack’s tip terminal; the adjacent black wire goes to the front-panel LED. Similarly, the black wire just below it, soldered to the same trace as the yellow wire, goes to the jack’s sleeve terminal; that trace also connects to a resistor leading to the trace labeled LED+ and the LED’s red wire.

Although tattoo machines run from DC supplies, their motors or vibrators don’t depend on any particular polarity and will run fine with a backwards supply.

Resoldering the red and black wires where they should go produces the expected sign at the jack:

Tattoo Digital Supply - meter leads

Tattoo Digital Supply – meter leads

Although measuring and plotting diode voltages and currents may seem tedious, actually wiring stuff together and taking data reveals how difficult the real world can be.

I trusted the supply’s internal color code and, although I’m certain I tested the Powerpoles, I obviously didn’t notice the meter’s sign.

Memo to self: Sheesh.

, ,

1 Comment