The Smell of Molten Projects in the Morning

Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.

Tag: Rants

And kvetching, too

  • Canon SX-230HS: Wasabi NB-5L Batteries

    Based on my good experience with the Wasabi NP-BX1 batteries, I also bought three Wasabi NB-5L batteries for my Canon SX-230HS pocket camera:

    Canon NB-5L - OEM Wasabi Misc - 2014-10-04
    Canon NB-5L – OEM Wasabi Misc – 2014-10-04

    Well, that’s not what I expected: the “new” Wasabi batteries perform worse than the three year old Canon OEM battery and no better than the crap batteries from eBay.

    Just to be sure, I ran two tests on each of the three new batteries. Unlike the NP-BX1 batteries, these deliver a lower voltage than the Canon OEM battery and have a much lower capacity. The camera cuts off at 3.5 V, so the new batteries deliver 2/3 the run time of the old OEM battery

    Sheesh…

    Tech support at Blue Nook (I am not making that up) says they’ll send me a couple of batteries from their next shipment to see if something’s wrong with this batch; all the batteries have date code BNF27.

  • Bank Website Cookies

    Seeing as how we live in The Internet Age, I must fetch my statements from Big Bank’s website, rather than extract quaint sheets of paper from an envelope. Seeing as how the start of the Internet Age is over, I run a fairly well armored version of Firefox that ruthlessly suppresses ads (have you ever bought anything as a result of an Internet ad?), crushes cookies, rejects malware, and generally defends my interests.

    Big Bank’s website doesn’t work without adjusting the armor and, equally unsurprisingly, those adjustments seem to depend on both their website’s current revisions and my browser / plugin / extension versions. It seems mildly odd that Big Bank would depend on the same techniques that identify advertisers and scammers and malware purveyors, but so it goes.

    My most recent attempts to retrieve an account statement produced an indefinite “busy” loop instead of a PDF file, which usually means something got blocked. Big Bank outsources its statements and I’ve already whitelisted internet-estatements.com and allowed its popups, so it must be something else.

    A bit of rummaging in the sump revealed cookies from several domains that didn’t get set whenever I tried to access my statement:

    • adsrvr.org
    • bigbankcardus.com
    • casalemedia.com
    • doubleclick.net
    • mookie1.com
    • serving-sys.com

    Pop Quiz: which domains in that list would you trust without question?

    Bonus: Explain why “mookie1.com” isn’t funny in this context.

    Double Bonus: Why is a banking website dealing with doubleclick?

    It seems the missing cookies came from bigbankcardus.com, as the statement PDF appeared after I whitelisted that domain and reloaded everything.

    I could understand (if not enthusiastically approve of) getting advertising cookies from Big Bank’s main page, but there should be exactly none of that crap when I access my statements.

    There is no point in complaining: it’s like that, and that’s the way it is.

    At least they don’t require Internet Explorer…

  • Patient Sign-In App: Human Factors FAIL

    It used to be we “signed in” at the dentist by exchanging pleasantries with the folks behind the desk, but that was so 20th Century. Now we’re confronted with an iPad sporting a form:

    Patient Sign-in Tablet Form
    Patient Sign-in Tablet Form

    Pop Quiz: Assuming you filled in your birthdate and remembered how their files have recorded your name, where do you tap to proceed onward?

    Reasoning by analogy from my Kindle Fire’s keyboard, I assumed the conspicuous bright blue Go button would do the trick.

    Nope. That’s not it.

    After a bit of fumbling around, it turns out to be the dark blue Next button (on the non-contrasting light gray title bar) at the right edge of the title bar.

    I betcha I could have fun with some of those little icons…

    In fact, the next time we showed up, the iDingus sported a popup asking if I wanted to update the firmware (or some such). Of course, I gave the receptionist an evil grin and tapped “Hit me!”

    Word: this app nonsense isn’t ready for prime time.

  • NYS DOT Patch Quality

    After years of neglect, an NYS DOT crew started a really nice repair job on the inside edge of the curve just north of our house. They milled out the deteriorated road surface, cleaned out the debris, and laid in a patch flush with the road surface. That’s quite unlike their usual shovel-some-cold-patch / hand-tamp / drive-over-it process, made familiar everywhere else around here.

    Unfortunately, for unknown reasons, they didn’t fill in the last two feet of the milled-out trench, leaving a tooth-shattering pair of perpendicular edges exactly where you’d least expect them:

    Rt 376 north of Heathbrook - unfinished patch
    Rt 376 north of Heathbrook – unfinished patch

    Ran out of asphalt? Lunch break? Called off to another emergency? We’ll never know.

    I sent a note, with that picture, to the NYS DOT Bicycle & Pedestrian Coordinator, asking what happened; perhaps they planned another layer atop the whole curve to seal the rest of the cracked pavement?

    The next day a crew filled in the hole, which I find far more than coincidental.

    Although it’s better than it was, there’s now a joint that will deteriorate more rapidly than the uniform asphalt layer they should have created.

    We’ll take what we get…

  • Invisible Asterisk: Except Cops

    The signs at every Dutchess Rail Trail grade crossing and access point seem unambiguous:

    DCRT - No Motor Vehicles
    DCRT – No Motor Vehicles

    More specific signs appear at random intervals along the trail:

    DCRT - All Terrain Vehicles Prohibited
    DCRT – All Terrain Vehicles Prohibited

    You can’t see it, but every sign includes an invisible asterisk introducing the invisible clause “Except Cops”:

    DCRT - Sheriff ATV Convoy
    DCRT – Sheriff ATV Convoy

    Back when the Dutchess County deputy sheriffs rode huge ATVs that occupied nearly the entire paved trail and bulldozed everybody out of their way, I had the temerity to ask why they weren’t riding bikes. The deputy sheriff told me, rather condescendingly, that they had to be prepared for anything and that there had already been incidents.

    These little ATVs aren’t quite so imposing and, more likely, also fit on the new bridges and between the bollards, which may explain everything.

    I’ve seen what might be their best use case, although ambulances can attract your attention without an ATV escort:

    DCRT - Sheriff ATV Leading Ambulance
    DCRT – Sheriff ATV Leading Ambulance

    Straight up, I have no objection to police patrols on the rail trail.

    I do object to the official mindset that simply adds an invisible exception to any inconvenient rule.

    As I see it, the root cause of the militarized police and extralegal government activities we’ve seen across the country in recent years boils down to “That law / regulation / rule does not apply to us, because we are the government.”

    I can ride the length of the DCRT and back in about two hours, averaging 12 mph, without getting particularly sweaty in the process; the track in that link shows a three hour ride that includes the HVRT and a Walkway scrum, plus the ride from and to home. A police ATV can’t go much faster than that on the trail, even with lights and sirens, because oblivious pedestrians keep getting in the way.

    If an officer on a bike can’t keep up with me, then something has gone badly wrong with the job requirements for becoming a deputy sheriff.

    As far as “being prepared for anything” goes, the cargo capacity of those little ATVs rules out a bunch of hardware that fit in the big ones: anything seems an elastic concept. A bike can carry enough equipment for many incidents; my tool kit weighs more than some bike frames, the packs have plenty of room to spare, and there’s always the trailer option. I doubt genuine Mil-Spec assault rifles would come in handy on the rail trail.

    It’s also not clear why an officer on a bike can’t call for the same backup as an officer on an ATV: those buggies lack fancy VHF antennas, so they’re using a hand-held radio or phone. The 5 W amateur radio on my bike, through a mobile VHF antenna on a crappy ground system, can easily reach local amateur radio repeaters and APRS nodes. Many pedestrians seem absorbed with their phones, so getting microwaves into and out of the trail doesn’t pose much of a problem.

    Cops-on-bikes present a much less aggressive aspect than cops-on-ATVs who ignore the rules that apply to the rest of us.

    They could do it differently, as the department has both bikes and ATVs.

  • When the Phone Don’t Ring, We Know It’s Carmen

    A few weeks ago we ported our landline number to Ooma’s VOIP service, turned on their Community Blacklist, blacklisted a few pests that crept through, and … the scam calls vanished. For the first week, the only calls we received came from people we know.

    Most of the Caller ID numbers seem faked, so one side effect of blocking them will be to prevent calls from real persons or businesses eventually assigned those numbers. In particular, I’ve set up a blacklist filter that kills calls from numbers that differ from ours in only the last few digits: at least one scammer combined the first several digits of the called number with some random digits at the end.

    Obviously, it’s impossible to kill all the faked numbers. The filters work surprisingly well, though.

    Killing nearly all the scam calls is worth ten bucks a month right there, even though it seems odd to pay a private party to prevent illegal action by somebody else. Used to be the government put our tax dollars to work and dealt with people who performed illegal actions, but … that was then, this is now.

    As an aside, I wonder how the NSA handles all those scam calls. Given that the Feds regard anybody within three or four hops of a Person Of Interest to be a Person of Interest, not only should all the scammers have terrorist tags (they call everybody all the time, right?), we ordinary folks picking up the phones are now within a few hops of a known terrorist affiliate.

    Conversely, if the NSA discards scam calls, then I know precisely how to set up the perfect terrorist communications network.

    Verizon refunded $3.11 from our last bill and didn’t try to convince us to retain our landline service. They’d recently “upgraded” our copper line to fiber, so the basement has a nice Optical Network Terminal that I just unplugged; they don’t seem to want it back. Maybe I’ll harvest the 12 V 8 Ah (!) SLA battery for a project.

    We’re not interested in the FiOS “Triple Play” special offers that hover around $90/month for two years, plus unknown equipment charges, plus a regional sports network surcharge, plus unknown taxes and fees, with or without a $250 gift card kickback, with or without a discounted tablet. The cable company recently boosted what we pay for 15/3 cable to $60/month, so we’re definitely trapped by a duopoly.

    Some things (all, some, or none of which may be true) I learned while chatting with various contestants:

    • Overtalking them with “You may hang up at any time if you agree that you’re a scammer” produces either an immediate hangup (they agree!) or a very interesting discussion.
    • Starting with “You have sixty seconds to prove you’re not a scammer. Go!” generally produces an immediate hangup.
    • Setting up a call center “the size of your garage” costs about 85 kilobucks and provides seats for about a dozen “agents”.
    • It’s the best job you’ve had, if you’ve been unemployed for three years, because it’s minimum wage plus a bonus for every prospect you “qualify”, all without having to work in a retail environment. I was unable to discover when the bonus kicks in, but likely after the Level 2 closer sucks actual money out of the victim’s credit card account.
    • Some contestants sincerely believe they’re doing a Good Thing: helping people get lower interest rates on their credit card debt. Pointing out that I’ve asked my credit card issuer whether that works and getting a firm “No!” in reply doesn’t change their belief in the least.

    It’s sad that getting a dead-end job in a scamming company might be the best thing that’s happened to some of those folks in a long time. Makes me almost regret having some of them break down and cry under interrogation…

  • 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…