Numeric Keypad Repair

Having set up a cheap wireless numeric keypad as a simple macro pad at my left hand, I eventually knocked it off the desk, whereupon the screw compressing the back of the case against the membrane switches ripped through the plastic:

Numeric Keypad - compression screw pullout
Numeric Keypad – compression screw pullout

The symptoms came down to erratic operation of a few keys that became worse as I continued tapping on the thing. Finally, with nothing to lose, I took it apart and, upon seeing the hole in the case, realized I didn’t have to cut the usual label to find the hidden screw.

Slathering the little donut with acetone and clamping things together might work for a while, but I’m sure the keypad will hit the floor again with similar results.

Instead, recruit some candidates from the Box o’ Random Screws:

Numeric Keypad - screw selection
Numeric Keypad – screw selection

Pick the screw big enough to grip the undamaged boss on the front of the case, yet short enough to compress the back again, add a small washer spanning the hole, and it’s all good again:

Numeric Keypad - screw installed
Numeric Keypad – screw installed

This only works because the keypad sits at enough of an angle to hold the screw off the desk.

That was easy …

Epson ET-3830 Refilling

Although the blurb for the Epson ET-3830 All-In-One scanner / printer says “up to 2 years of ink in the box”, the black ink hit the bottom line of the tank near the end of August:

Epson ET-3830 - refilling black ink
Epson ET-3830 – refilling black ink

Refilling is totally without drama, which is worth a couple of bucks right there.

Being that type of guy, I keep track of ink vs. time:

Epson ET-3830 - ink status
Epson ET-3830 – ink status

In round numbers, it looks like we use nearly all of a 127 ml bottle of black ink and a bit more than half of an 70 ml bottle of color ink every eight months.

I find it much easier to read long articles and tech documents while slumped in the Power Chair than to scroll through them on big or little screens, so we go through much more ink and paper than most folks.

Manjaro Linux: TOTP PSA

I set up my pobox.com account set up with two-factor authentication through my Yubikey, so logging in requires my user ID, password, and a Time-based One-time Password generated through the Yubikey Authenticator program. A few weeks ago, pobox occasionally rejected the TOTP and it eventually became a hard failure. Oddly, other sites I’ve set up with TOTP 2FA continued to work fine.

My initial trouble report:

The last couple of times I’ve tried to sign in, the usual TOTP copy-n-paste from my Yubikey authenticator has failed.

Up to that point, it worked flawlessly.

Manually typing the TOTP also fails.

I have reset my (complex!) password to no avail; I use Firefox’s password manager to fill it in.

I do have a set of lockout codes, but they’re a solution to a different problem.

Given the constant updates to Firefox (102.0.3), it’s almost certain the hole is in my end of the boat. I have disabled all the usual ad blocking for pobox.com, although there may be other domains I’ve overlooked.

Other than that, my email seems to be working just fine …

Any suggestions on how to proceed? (Obviously, I’m not going to be able to sign on to look at the ticket.)

Thanks …

This is the fastest I’ve ever reached Tier 2:

We’re happy to help you with this. I’ve escalated your ticket to our Tier 2 agents, as they are best suited to assist with this issue.

There is nothing like a good new problem to take your mind off all your old problems:

I’ve had a chat with our Tier 2 agents about this and they’ve suggested I escalate it to our developers to have a look at.

Somewhat later:

I am afraid to say that our developers were unable to find any clear reason as to why your Yubikey failed.

Yubikey devices verify by connecting with Yubikey’s server, and it is possible that this connection failed.

Can you please try using the Yubikey again to see if the issue is still occurring?

If it’s still failing, can you please try adding a new Yubikey device to see if it works?

Of course, the problem didn’t magically Go Away, but I did more experimentation and figured out where the hole was in my end of the boat:

Ah-HA! It’s a PEBKAC error!

For unknown reasons, this PC was not set for automatic NTP time updates(*). Its time had drifted (presumably since I installed it back in June 2021) and was now 58 seconds behind real time, exceeding pobox’s tolerance.

Other websites apparently allow a few more seconds of slop before disallowing a TOTP, so I had not yet run afoul of their limit.

Some lesser-used sites threw me out, however, but I had not looked beyond the most common sites.

The default TOTP interval is 30 seconds, so perhaps pobox allows only ±1 interval and the other sites allow ±2? Frankly, I think pobox has it right: everybody else prioritizes customer sat over security.

Got the clock set correctly and, gosh, TOTP works fine.

Mark it solved, but definitely add “Soooo, is your PC’s clock set for automatic updates?” to the debugging protocol.

Thanks …

(*) I’ve installed all of the boxen here and would not ever have picked “Yeah, sure, I want to dink with the clock.”

The solution looks like this:

Manjaro Time and Date Settings - Auto Set
Manjaro Time and Date Settings – Auto Set

Which was unchecked on this PC.

Of course, systemd has long since subsumed NTP, making everything I thought I once knew obsolete: now it’s handled by timesyncd.

How you make sure time synchronization is enabled goes like this:

$ systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Network Time Synchronization
     Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled; preset: enabled)
     Active: active (running) since Thu 2022-08-25 06:49:31 EDT; 10h ago
       Docs: man:systemd-timesyncd.service(8)
   Main PID: 355 (systemd-timesyn)
     Status: "Contacted time server 23.157.160.168:123 (2.manjaro.pool.ntp.org)."
      Tasks: 2 (limit: 19063)
     Memory: 2.2M
        CPU: 188ms
     CGroup: /system.slice/systemd-timesyncd.service
             └─355 /usr/lib/systemd/systemd-timesyncd

Aug 25 06:49:31 shiitake systemd[1]: Starting Network Time Synchronization...
Aug 25 06:49:31 shiitake systemd[1]: Started Network Time Synchronization.
Aug 25 06:50:12 shiitake systemd-timesyncd[355]: Timed out waiting for reply from 162.159.200.123:123 (2.manjaro.pool.ntp.org).
Aug 25 06:50:12 shiitake systemd-timesyncd[355]: Contacted time server 23.157.160.168:123 (2.manjaro.pool.ntp.org).
Aug 25 06:50:12 shiitake systemd-timesyncd[355]: Initial clock synchronization to Thu 2022-08-25 06:50:12.850444 EDT.

If it’s enabled and running, then it’s all good.

Whereupon all my TOTP passwords began working again.

I checked two other Manjaro systems: one had auto updates enabled, one didn’t. I have no explanation.

Kensington Expert Mouse Scroll Ring: More Data Points

A note from Alan adds more data about troubleshooting problems with the classic Kensington Expert Mouse trackball scroll ring:

I have two comments and a question: first I made the mistake of purchasing 4 used expert mice on ebay etc and each had a different problem but 3 of 4 also had faulty scroll rings. 2nd: one of them was dated 2020 (a wireless version). so they definitely haven’t fixed this issue and it’s very wide spread (or maybe why shady sellers decide to part ways with their trackballs).

question: from reading across your quotes it’s not clear but it seems like there is no real consistent fix to this issue nor a really strong conclusion as to what causes it? My futzing with a couple of these does seem to suggest that alignment of the ring makes a difference but not a lasting one.

As far as the alignment non-fix goes, tweaking the detector position just changes the amount of light passing through the wrong side of the reversed IC, without solving the problem. That’s what we’ve all done, with essentially the same results: feels good, doesn’t last.

Kensington (whoever they are these days) may have fixed the problem with a different quadrature detector oriented in the proper direction, but that’s not something we civilians can accomplish.

It should be possible to unsolder the reversed detector (if, indeed, it is), aim the lens (if that’s what it is) at the emitter, then somehow resolder the leads to the same pads. Perhaps flip it to put the leads on the top, away from the PCB, secure it with a generous blob of hot-melt glue, and connect jumpers from pads to leads?

So far, the two new-ish units on my desks continue to work well, depriving me of sufficient motivation to dig into my junkers.

If anybody is willing to hack their defunct trackball, please let us all know what happened!

Because you may be reading this in our future, comments on this particular post will probably have been disabled to reduce the attack surface for spammers. Send me an email / use the comment form (linky over on the right), or comment on the post of the day and I’ll sort it out. Thanks!

CR2032 Lithium Cell Lifetime

The Dell Optiplex 9010 acting as a file server woke up dead after I plugged it in after returning from a road trip. Its ID sticker shows a manufacturing date almost exactly nine years ago and the problem was exactly what you might expect:

Optiplex CR2032
Optiplex CR2032

I’d never measured 100 mV on a CR2032 before.

Because the Optiplex runs headless in the basement, diagnosis required hauling it upstairs, booting it with a display & keyboard, whacking the date into the current decade, then resetting a few other vital bits.

The electrolytic caps looked to be in fine shape, though.

Huion Tablet USB Cable Realignment

The Huion tablet on my desk has its USB cable sticking straight out of the left side, whereupon it must loop around to burrow under the shelf under my monitor on its way to the port on the back of the PC case. The loop snagged on all the clutter atop the desk and I finally got around to Fixing That Problem:

Huion tablet - rerouted USB cable
Huion tablet – rerouted USB cable

Of course, it wasn’t quite that simple.

Right angle USB Mini-B connectors are still a thing:

Huion tablet - USB angle adapters
Huion tablet – USB angle adapters

Which is a “left angle” adapter and which is a “right angle” adapter depends on which supplier you ask and how much you trust their descriptions / product photos, so you should get a set containing both: it’s the only way to be sure.

The one on the right (a “right angle”) shows a bit of carving, which came after the completely unsurprising discovery that the stylin’ curves on the side of the tablet collided with the rectangular adapter:

Huion tablet - misfit adapter
Huion tablet – misfit adapter

Some diligent X-Acto knife work carved away enough of both the adapter and the tablet case to snugly join them:

Huion tablet - plastic surgery
Huion tablet – plastic surgery

The hackery over on the far right fits around the USB cable’s molded connector. I simply cut away any parts that touched until the adapter seated firmly in the USB socket and the cable exited parallel to the edge.

Part of this involved not carving deeply enough into the adapter or cable connector to expose the internal wiring. I assumed the tablet didn’t have anything vital immediately inside that fancy curve, so that’s where I dug deepest.

Stick adapter + cable to the tablet with good-quality electrical tape and now the cable points directly to where it should go.

Declare victory and move on!

Raspberry Pi: WLAN to Wired Network

The CNC-3018XL and MPCNC machines each have a Raspberry Pi feeding G-Code into an Arduino clone controlling the stepper motors. The former grew a USB WiFi interface in place of its internal WiFi hardware when it seemed to have difficulty connecting to the house router, while the latter pretty much worked. Of late, however, I’ve been trying to reduce the number of WiFi devices cluttering the airwaves, with the result of wiring both machines to an old Ethernet switch from the Box o’ Network Stuff:

LinkSys Switch for CNC machines
LinkSys Switch for CNC machines

The blue puck is the KVM button to select one of the machines for the keyboard / mouse / monitor on the bench.

One key point I generally screw up: the WiFi IP address cannot become the wired IP address without rebooting everything else on the network. Instead, just change the IP addresses and be done with it.

Collecting all the pieces in one place:

Disable the both internal WiFi hardware and Bluetooth in /boot/config.txt, thereby eliminating the need to force the WiFi down in /etc/rc.local:

dtoverlay=pi3-disable-wifi
dtoverlay=pi3-disable-bt

Define the static IP address in /etc/dhcpcd.conf:

interface eth0
static ip_address=192.168.1.34/24
static routers=192.168.1.1
static domain_name_servers=192.168.1.2

Kill IPV6 activity in /etc/sysctl.conf:

net.ipv6.conf.all.disable_ipv6=1

I very much doubt this information is either complete or correct, but it serves the purpose as of early 2022.