Archive for January, 2018
An SJCAM M20 action camera includes the date and time in its file names, but the directory entries appear with the wrong timestamp:
sudo mount -o uid=ed /dev/sdc1 /mnt/part ll -tr /mnt/part/DCIM/Photo/ | head total 4.8G drwxr-xr-x 4 ed root 16K Apr 8 2016 ../ drwxr-xr-x 2 ed root 144K Jan 25 18:52 ./ -rwxr-xr-x 1 ed root 3.8M Jan 26 05:08 2018_0126_100825_001.JPG* -rwxr-xr-x 1 ed root 3.8M Jan 26 05:08 2018_0126_100830_002.JPG*
I’m in the Eastern US time zone, -5 hr from UTC.
By definition, FAT directory entries contain the “local time” when the file was created / changed. Because it cannot know which “local time” applies, the Linux VFAT filesystem treats the timestamp as UTC and adjusts it by -5 hr.
So the camera writes the directory timestamps properly. When mounted, Linux correctly (for a reasonable definition of correctly) regards them as UTC, knocks off five hours to match this time zone, and displays the result.
Alas, disabling the VFAT timestamp conversion has no effect:
sudo mount -o uid=ed,tz=UTC /dev/sdc1 /mnt/part ll -tr /mnt/part/DCIM/Photo/ | head total 4.8G drwxr-xr-x 4 ed root 16K Apr 8 2016 ../ drwxr-xr-x 2 ed root 144K Jan 25 18:52 ./ -rwxr-xr-x 1 ed root 3.8M Jan 26 05:08 2018_0126_100825_001.JPG* -rwxr-xr-x 1 ed root 3.8M Jan 26 05:08 2018_0126_100830_002.JPG*
I’m not sure why that doesn’t do anything; it doesn’t generate any error messages.
Although it seems like a reasonable thing, one cannot force a specific time zone with, say,
tz=UTC8 or whatever.
You can specify an offset in minutes:
sudo mount -o uid=ed,time_offset=$((-5*60)) /dev/sdc1 /mnt/part ll -tr /mnt/part/DCIM/Photo/ | head total 4.8G drwxr-xr-x 4 ed root 16K Apr 8 2016 ../ drwxr-xr-x 2 ed root 144K Jan 25 23:52 ./ -rwxr-xr-x 1 ed root 3.8M Jan 26 10:08 2018_0126_100825_001.JPG* -rwxr-xr-x 1 ed root 3.8M Jan 26 10:08 2018_0126_100830_002.JPG*
time_offset value is subtracted from the directory timestamp, which means you’re feeding in the actual time offset from UTC, including whatever Daylight Saving Time offset may be in order.
So Linux takes the FAT timestamp, adds (subtracts a negative) 5 hr, and displays the result as my (now correct) local time.
I suppose I could set the camera to UTC, but then the camera’s on-screen and in-video timestamps would be off by four or five hours, depending on the season. So it goes.
PLA isn’t particularly strong, especially in small sections under high stress:
I tried solvent-bonding + clamping the break, didn’t expect much, and wasn’t disappointed.
It adds a festive touch when done up in orange PETG:
The attentive reader will note the missing head of the screw anchoring the mount to the left Z rail. Apparently a #32 drill was a bit too small to let the randomly chosen self-tapping screws thread themselves into EMT; they probably anchored a PCB to the plastic case of a long-forgotten lump of consumer electronics.
It should last long enough for something else to let go …
Two more umbrella struts snapped and required the same repair, but, having drained all the suitable snippets from the Box o’ Brass Cutoffs, some lathe work was in order:
I used the carbide insert in the mistaken belief it’d be less grabby, then applied the cutoff tool.
Break the edges, slide splints over the ribs, slobber epoxy on the struts, slide splints into place, apply masking tape for a bit of compression & alignment, and let it cure:
Three down, five to go …
Having run out of dead CR123A lithium cells, I soldered up another holder to work through a handful of dead AA alkalines:
It’s amazing how much light comes from a single wearable LED powered by a dead battery in a dark room!
Stipulated: I should have 3D printed a CR123A cell adapter. Maybe next time …
A light overnight snowfall revealed an early morning drama:
I think a hawk stooped on a squirrel, perhaps launching from the utility pole by the garden, scuffled across the driveway to the right, and hauled breakfast off to a nearby tree:
The driveway always shows many tracks, but the ones entering from the center-right don’t continue out the left:
A pair of squirrel pups appeared in the last week. They’d make a good, easily carried hawk breakfast.
Go, hawk, go!
A plot of the back EMF for an Automation Technology KL17H248-15-4A stepper motor looks like I’m making stuff up again:
Maybe the only questions I ask are ones with linear solutions?
Anyhow, the data comes from the Z-axis motor in the lathe:
Scary-looking, but reasonably safe. The chuck holds the motor shaft so it’s not going anywhere, the boring bar prevents any rotation, and the motor bearings do exactly what they’re supposed to. Shorting the motor leads would definitely put a hurt on the PLA frame, so I didn’t do that.
The scope sat on the floor beside the lathe, capturing waveforms and doing calculations:
Some waveforms look bent:
I asked the scope to measure the RMS voltage, rather than the peak, because it’s less sensitive to distortions.
Each winding produces one electrical cycle across four mechanical full steps, with the windings in quadrature. One shaft revolution thus produces 200 / 4 = 50 electrical cycles, so converting from shaft RPM into electrical cycles/s goes a little something like this:
Electrical cycles/s = (shaft rev/min) * (50 cycles/rev) / 60 (s/min)
Which works out to a tidy 0.833 Hz/RPM, basically spot on the last data point’s 839 Hz at 1000 RPM.
The motivation for this comes from the third column in the scribbles: back EMF = 22.7 mVrms/RPM = 32 mVpk/RPM.
A rapid move at 12 k mm/min = 200 mm/s shows the motor current collapsing to the ragged edge of not working:
Converting motor speed to shaft RPM:
RPM = (axis mm/s) / (32 mm/rev) * (60 s/min)
RPM = (axis mm/min) / (32 mm/rev)
So the shaft turns at 375 RPM when the X axis moves at 12 k mm/min, with each motor generating 8.5 Vrms = 12 Vpk of back EMF.
The MPCNC wires the two motors on each axis in series, so the 24 V power supply faces 24 V of back EMF (!) from both motors, leaving exactly nothing to push the winding current around. Because the highest EMF occurs at the zero crossing points of the (normal) winding current, I think the current peaks now occur there, with the driver completely unable to properly shape the current waveform.
What you see in the scope shot is what actually happens: the current stabilizes at a ragged square-ish wave at maybe 300 mA (plus those nasty spikes). More study is needed.
Two readers recently complained of auto-playing, non-mute-able video advertisements on these pages. As I mention over in the right column, down near the bottom, WordPress controls the number of ads, their placement, and (somewhat) their content. They call it the “WordAds” program, which is distinct from Google’s “Adwords” program, and I have opted into the WordAds program to get a cut of the revenue.
Here’s what my advertising revenue amounted to over the last six years:
|Period||Earnings||Ad Impr||$ / 1k|
[Edit: Update headings, get decimals right.]
To save you the trouble, the second column adds up to $2200: I’ve been raking in $1/day.
In recent years and very round numbers, this blog gets 650 visitors and 1000 page views per day, for about 1.6 page views/visitor and 30 k views/month.
You can clearly see the collapse of online advertising starting in early 2016, where the revenue fell off a cliff.
Until the last few months, the eyeballometric average of 15 k “ad impressions” / month amounts to either half an ad per page view or half of the visitors running ad blockers. I strongly doubt the latter, so maybe WordPress showed ads only on the first page view. The month-to-month variations suggest WP tinkered with the ad quantities and placement; I have no visibility into nor control over any of those machinations.
Early last year, WP apparently began pushing video ads, because the revenue per ad doubled, tripled, then jumped to nearly 30¢/impression, all from the same number of impressions.
September seems to be when WP went from one ad per view to three, with at least one of them being an aggressive video ad. The per-ad revenue dropped by a factor of two, though, suggesting the additional (non-video?) ads have no value, video ads aren’t as hot as they used to be, or creative rearrangement of WP’s (unknown) revenue sharing ratio.
So I had a brief exchange with the WP Happiness Engineers on the subject (edited for conciseness, with additional commentary):
> Can you provide a little more detail, please?
In recent weeks, two readers have posted disturbing comments:
Is there a secret to avoiding the auto-play video ad that ignores the “mute button” and refuses to let you scroll away?
I really enjoy your blog posts … but the hijacking by the video causes me to not view as often as I used to …
They obviously didn’t (and surely can’t) give me the URLs for those video ads, but they’re obviously not isolated events.
My rule of thumb says one person reporting a problem means ten had a similar problem and another hundred just walked away.
1) I can pay WP to suppress all the ads. That feels a lot like blackmail from this side of the exchange, particularly with aggressive video ads.
2) I can turn off WordAds and forego the ad revenue. That neither reduces the ad load nor improves their quality. It seems to only give WP even more incentive to monetize my IP.
I’ve suggested to all my readers that they should be running an ad blocker, because the next step after WP presenting crappy video ads from sketchy ad brokers will be shoveling malware from outright thugs. If malware can happen to ads from, say, the NY Times, it can definitely happen with WP.
Kill the scummy ads!
This would be nice:
I’ve asked our team if we can disable the video ads on your site. I’ll get back to you as soon as I hear from them.
Apparently they can’t kill all the video ads.
I find it frustrating when successive help-desk contestants don’t read the actual trouble reports and ask for information I obviously can’t provide:
I wanted to get a bit of clarification from you on the ads which are causing trouble on your site so we can pinpoint them and help to remove them.
There are two different types of video ads, can you let me know which of these two you are referring to?
Standalone video ads in a big placement below posts.
In-banner video. This is your standard banner ad placement and type except that there’s some video auction in the banner.
Having already told them everything I know, there’s little more I can add:
Two readers took the time to comment about them and I must assume the ads have pissed off many more people, but I have no further information on the ads.
Frankly, if you can’t identify the ads from this description:
1) “the auto-play video ad that ignores the “mute button” and refuses to let you scroll away”
2) “hijacking by the video”
Then WP definitely has lost control over the WordAds program.
Ads like that cheapen the WP brand. Why would WP want their blogging platform associated with aggressive crap?
It seems WP has definitely lost control:
We certainly don’t want ads that hijack the browser to show up in our network, any more than you do.
Unfortunately, bad-acting advertisers manage to submit ads to our network that violate our policy on this. We do our best to block them, but no filter we can put in place is fool-proof, and they submit new ads as quickly as we can block them.
This is a problem that advertising networks are facing industry-wide, not just on WordPress.com.
There are tens of thousands of ads in our network at any given time, so in order to identify which advertiser is placing the ads, we need more information to look them up in our logs:
Your device’s browser and operating system.
Your IP address (you can go to whatismyip.com to find this)
The exact URL of the page/blog post where the ad was shown.
The URL of the page that the ad takes you to.
If possible, a screenshot of the ad that hijacked the browser.
If you’re getting reports from site visitors, they can also send us that information by filling out this form:
But I’ll say it again anyway:
> they can also send us that information
That’s expecting entirely too much effort from people, so it’ll never happen.
I’m mildly surprised anybody bothered posting a comment, but I suspect it’s because they think I’m responsible for the crappy ads.
Of course, I can pay WP to not run ads.
> a problem that advertising networks are facing industry-wide
Which is precisely why I recommend using an ad blocker.
Basically, WP has outsourced both of our reputations to untrustworthy companies. We then say we have no responsibility for any problems, because those thugs over there did it, not us.
I understand why it happens and share some of the blame: I’m using a “free” blogging service and expecting it should Just Work.
Question: would paying WP to “Remove WordPress.com Ads” eliminate all ads from my blog?
The wording of “Allow your visitors to visit and read your website without seeing any WordPress.com advertising” suggests WP can show ads from other sources, so I’d like to be sure.
Which turns out to be the case:
To clarify, that means that the advertisements that WordPress.com places on your site (including ads from other sources) will be hidden if you upgrade to a Personal, Premium, or Business plan.
Spinning up a VM somewhere, setting up a WordPress instance, adding a comment spam suppression system, keeping everything updated with the latest patches, repairing the inevitable breakage, and maintaining the infrastructure isn’t anything I want to do. Basically, all I want is a place for my shop notes and doodles, not an unpaid sysadmin job.
The least awful alternative seems to be paying WP a few bucks a month to suppress all the ads, have them (continue to) do all the maintenance, and eat the costs.
From what I read, Patreon (et. al.) funding programs don’t actually produce any revenue, so the subscription model won’t be worth the effort.