Archive for category PC Tweakage
Optiplex 9010: Xsetwacom vs. Dual Monitors
Posted by Ed in PC Tweakage, Software on 2017-07-31
Having replaced the Dell Optiplex 980 (running from an eBay NOS power supply) with an off-lease Optiplex 9010, I was mildly surprised to find two Displayport outputs from the built-in Intel graphics chipset. Not being a gamer, I don’t care much about graphic performance, but plugging two 2560×1440 monitors into the jacks and having them Just Work was delightful. Indeed, Dell even managed to fix work around the error in the U2711 firmware requiring me to power-cycle the damned thing before booting the PC; now I can just turn the PC on and It Just Works.
Mysteriously, the incantation required to limit the Wacom tablet to the left-hand landscape monitor now uses DP1 instead of HEAD-0:
xsetwacom --verbose set "Wacom Graphire3 6x8 stylus" MapToOutput "DP1" xsetwacom --verbose set "Wacom Graphire3 6x8 eraser" MapToOutput "DP1" #xsetwacom --verbose set "Wacom Graphire3 6x8 Pen stylus" MapToOutput "HEAD-0" #xsetwacom --verbose set "Wacom Graphire3 6x8 Pen eraser" MapToOutput "HEAD-0"
I’ll leave the “HEAD-0 incantations as comments, so as to have a hint the next time …
Optiplex 980 Power Supply: Capacitor FAIL
Posted by Ed in Electronics Workbench, PC Tweakage on 2017-07-12
Came up from the Basement Laboratory to find my Dell Optiplex 980 PC had failed, with the power button and diagnostic 1 + 3 LEDs blinking amber. They built it back in June 2010, so section 3 of the Dell reference applies, the power supply status LED on the back panel was off, and, going straight to the heart of matter, I popped the top, disconnected the internal power supply cables, and poked the power supply test button:
Optiplex 980 Power Supply – rear panel test button
… and it’s dead.
Inside, the system board sports a Mini-ATX power supply connector:
Optiplex 980 – Mini-ATX power connector
I originally hoped to swap a supply from an Optiplex 755 (also in a Small Form Factor case) residing on the recycle heap, but it has an ordinary ATX connector:
Optiplex 755 – ATX power connector
So I moved the 980’s SSD and dual-Displayport video card into the 755, fired that devil up, and … it worked!
With my desktop back in action, albeit somewhat slower, I popped the dead supply’s case by violating the Warranty Void If This Label Removed sticker to unscrew the last screw:
Optiplex 980 Power Supply – overview
Notice anything?
The electrolytic capacitors over on the left look like this:
Optiplex 980 – Good capacitor
The cluster of caps on the upper right have bulged pressure-relief lids, like this:
Optiplex 980 – Bulging capacitor 1
And this:
Optiplex 980 – Bulging capacitor 2
And this:
Optiplex 980 – Bulging capacitor 3
None had ruptured, but they’re obviously feeling a bit nauseous.
Given the 980’s mid-2010 manufacturing date, this probably isn’t capacitor plague, just simple overheating from operating in a dead-air zone amid all those heatsinks and wires. Some of the Usual Unnamed Sources suggest overheating the capacitors is how manufacturers ensure their hardware doesn’t last forever, without being obvious about planned obsolescence; I’m loathe to ascribe to malice what can be explained by design desperation.
A Genuine Dell replacement supply from eBay ($25 delivered) came from yet another “small form factor” Dell chassis, so it isn’t quite the same size, lacks a supply test button / LED status light, and doesn’t quite fit:
Optiplex 980 – replacement supply misfit
Nothing a sheet metal nibbling tool can’t fix, though, given I haven’t developed a deep emotional attachment to the chassis. I gnawed off the left side of the frame and squared up the rim around the lower screw, after which the opening fit the supply pretty well, although the latching tab bent up from the bottom of the chassis didn’t quite engage the far end of the supply. No big deal: it’s not in a high-vibration environment.
The new-to-me supply also carries an ATX connector, but the eBay seller included a Mini-ATX adapter. Jamming the adapter + wires into the space available required concerted muttering, assisted by tucking the SSD under the DVD-RW drive. No pictures, as it’s a classic seven pounds in a five pound box situation.
And then It Just Worked again.
Canon LiDE 120 Scanner vs. SANE
Posted by Ed in PC Tweakage on 2017-07-04
I just replaced a cheap old Canon LiDE 30 flatbed scanner with a cheap new LiDE 120, only to get flat-black scans. The machinery worked (yes, I released the travel lock), everything seemed fine, the images were the proper size, but they were dead black.
Of course, the scanner worked OK on the Token Windows Box, but wow what crappy software they include.
Turns out the LiDE 120 requires the latest-and-greatest version 1.0.27 of the various SANE programs & libraries. Mercifully, getting those didn’t require compiling from source, just setting up the maintainer’s PPA of the most recent stable release:
sudo add-apt-repository ppa:rolfbensch/sane-release sudo apt-get update sudo apt-get upgrade
Which introduced circular dependencies with the distro-installed version 1.0.25 files, which I solved by ripping the entire SANE Thing out by the root(s) and reinstalling it to (re)synchronize All The Things:
sudo apt-get remove libsane:i386 sane sane-utils xsane libsane-common ia32-libs libsane sudo apt-get install libsane:i386 sane sane-utils xsane libsane-common ia32-libs libsane
And then It Just Worked:
C-Note – detail
Of course, you must keep this WARNING in mind:
Canon LiDE 120 – Legal Issues Warning
Franklin didn’t know about scanners or color laser printers when he observed:
Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety
Of course, there’s more to the story, but one should:
Raspberry Pi Boot vs. Avahi vs. DHCP
Posted by Ed in PC Tweakage, Software on 2017-02-22
Sometimes, one of our homebrew streaming media players will emerge from reset without starting up properly. The system board LEDs blink more-or-less normally, but the WiFi activity monitor seems … odd. This post documents the results of some exploratory surgery hinting at a possible solution.
I set the router’s DHCP server to assign a fixed IP address to each of our homebrew streaming media players based on its MAC address. That seemed less horrible than setting a static IP address in each player’s configuration, although I could see advantages to either approach. For streamer1, the player discussed here, the IP address is 192.168.1.101; that’s a non-routable address used only on our network behind the router.
During the Raspberry Pi’s boot, the default /etc/rc.local script finds and displays its IP address:
_IP=$(hostname -I) || true if [ "$_IP" ]; then printf "My IP address is %s\n" "$_IP" fi
The /var/log/boot log showed this after one boot:
--- snippage ---
Starting LSB: Raise network interfaces....
---
[ OK ] Started LSB: Raise network interfaces..
Starting ifup for wlan0...
[ OK ] Started ifup for wlan0.
[ OK ] Reached target System Initialization.
[ OK ] Listening on Avahi mDNS/DNS-SD Stack Activation Socket.
---
[ OK ] Reached target Sockets.
---
[ OK ] Reached target Basic System.
Starting Avahi mDNS/DNS-SD Stack...
Starting Regular background program processing daemon...
[ OK ] Started Regular background program processing daemon.
Starting dhcpcd on all interfaces...
---
[ OK ] Started Avahi mDNS/DNS-SD Stack.
---
[ OK ] Started dhcpcd on all interfaces.
[ OK ] Reached target Network.
---
Starting /etc/rc.local Compatibility...
Starting Permit User Sessions...
[ OK ] Reached target Network is Online.
Starting LSB: Start NTP daemon...
My IP address is 169.254.14.12
[ OK ] Started Permit User Sessions.
connect: Network is unreachable
[ OK ] Started /etc/rc.local Compatibility.
Starting Terminate Plymouth Boot Screen...
Starting Hold until boot process finishes up...
That mysterious IP address is a Link-local address, about which Wikipedia says: “If a host on an IEEE 802 (Ethernet) network cannot obtain a network address via DHCP, an address from 169.254.1.0 to 169.254.254.255 may be assigned pseudorandomly.”
So, having the router hand out IP addresses doesn’t quite work the way I expected. The Pi awards itself a link-local IP address before getting one from the DHCP server, presumably because the vast Linux startup Pachinko machine has a race condition. Alas, the pseudorandom LL address doesn’t fit in the 192.168.0.0/16 network handled by the router: the Pi can’t connect to the network.
My code in /etc/rc.local starts the streaming player immediately after the default code displaying the IP address, thus joining the race condition: if the player starts up before the DCHP server assigns the proper IP address, it can’t connect to the music server out on the Interwebs. My code includes a retry loop with a five second delay which eventually connects, at least most of the time, but sometimes gets wedged.
The most reasonable fix seems to involve forcing a static address on each Raspberry Pi, so it can immediately connect to the network, without any negotiation, and get on with the business at hand.
Rather than configuring that in /etc/network/interfaces as before, the New Hotness adds a stanza to /etc/dhcpcd.conf:
interface wlan0 static ip_address=192.168.1.101/8 static routers=192.168.1.1 static domain_name_servers=192.168.1.1
En passant, I killed off IPV6 with this line in /etc/sysctl.conf:
net.ipv6.conf.all.disable_ipv6=1
The router doesn’t support IPV6 and there’s no point in using it. Bonus: less log clutter. Double Bonus: startup happens faster!
All of which may help the NTP client update the system clock sooner, perhaps preventing time jumps like this:
2017-02-14 08:42:24,183 INFO: Player setup for: BR1 2017-02-14 08:42:24,184 INFO: Volume control knob: /dev/input/volume 2017-02-14 08:42:24,225 INFO: Starting mplayer on Ambient -> http://185.32.125.42:7331/maschinengeist.org.mp3 2017-02-14 08:42:27,175 INFO: Track name: [Arcticology - Nocturnal Sounds] 2017-02-14 08:42:27,194 INFO: Track unmuted 2017-02-15 04:25:00,386 INFO: Track name: [Oöphoi - Suspended Matter] 2017-02-15 04:25:00,413 INFO: Track unmuted
The timestamps in the first five lines date back to the previous shutdown. The Pi remains plugged in and powered while it’s reset, which apparently preserves the system clock variables, albeit without a hardware clock ticking along: time stands still between shutdown and restart.
In this case, the IP address situation worked itself out before the player started, but the NTP clock reset on the sixth line happened at least three seconds after the log began.
This chunk of /var/log/syslog has more detail:
highlight="1,5,6,7,8,15,21"] Feb 14 08:42:24 streamer1 dhcpcd[693]: wlan0: leased 192.168.1.101 for 86400 seconds Feb 14 08:42:24 streamer1 dhcpcd[693]: wlan0: adding route to 192.168.1.0/24 Feb 14 08:42:24 streamer1 dhcpcd[693]: wlan0: adding default route via 192.168.1.1 Feb 14 08:42:24 streamer1 avahi-daemon[387]: Registering new address record for 192.168.1.101 on wlan0.IPv4. Feb 14 08:42:24 streamer1 dhcpcd[693]: wlan0: deleting route to 169.254.0.0/16 Feb 14 08:42:24 streamer1 avahi-daemon[387]: Withdrawing address record for 169.254.14.12 on wlan0. Feb 14 08:42:24 streamer1 avahi-daemon[387]: Leaving mDNS multicast group on interface wlan0.IPv4 with address 169.254.14.12. Feb 14 08:42:24 streamer1 avahi-daemon[387]: Joining mDNS multicast group on interface wlan0.IPv4 with address 192.168.1.101. Feb 14 08:42:25 streamer1 dhcpcd[693]: wlan0: no IPv6 Routers available Feb 14 08:42:25 streamer1 ntpd_intres[728]: DNS 0.debian.pool.ntp.org -> 206.71.252.18 Feb 14 08:42:25 streamer1 ntpd_intres[728]: DNS 1.debian.pool.ntp.org -> 45.33.13.54 Feb 14 08:42:25 streamer1 ntpd_intres[728]: DNS 2.debian.pool.ntp.org -> 204.9.54.119 Feb 14 08:42:25 streamer1 ntpd_intres[728]: DNS 3.debian.pool.ntp.org -> 216.229.4.66 Feb 14 08:42:26 streamer1 ntpd[720]: Listen normally on 6 wlan0 192.168.1.101 UDP 123 Feb 14 08:42:26 streamer1 ntpd[720]: Deleting interface #3 wlan0, 169.254.14.12#123, interface stats: received=0, sent=0, dropped=4, active_time=3 secs Feb 14 08:42:26 streamer1 ntpd[720]: 216.229.4.66 interface 169.254.14.12 -> (none) Feb 14 08:42:26 streamer1 ntpd[720]: 204.9.54.119 interface 169.254.14.12 -> (none) Feb 14 08:42:26 streamer1 ntpd[720]: 45.33.13.54 interface 169.254.14.12 -> (none) Feb 14 08:42:26 streamer1 ntpd[720]: 206.71.252.18 interface 169.254.14.12 -> (none) Feb 14 08:42:26 streamer1 ntpd[720]: peers refreshed Feb 15 04:20:10 streamer1 systemd[1]: Time has been changed [/sourcecode]
Given the timestamp resolution, NTP (or systemd) apparently resets the clock three seconds after the IP address changes. That may be as good as it gets, if only because the NTP daemon must find its servers, evaluate their status, then whack the local clock.
After forcing the static address, things look better, but it’s too soon to be sure. Many things can clobber streaming, not all of which happen on this side of our router.
Unicode Keyboard Flameout and Workaround
Posted by Ed in PC Tweakage, Software on 2017-01-26
For unknown reasons, probably having to do with the unmitigated disaster of trying to get an SDRPlay radio working with GNU Radio (about which, more later), Unicode keyboard input stopped working. This is not to be tolerated, because engineering notation requires a lot of Greek letters.
Unicode support seems to be baked into the lowest levels of the Linux operating system, although it’s not clear to me whether it’s in X, QT, GTK, or somewhere else. Googling the obvious keywords was unavailing; evidently this feature never ever fails or, more likely, very few people use it to any extent.
Note that I already have the Compose key set up, but Compose sequences don’t include Greek letters.
After considerable flailing, I added the Simple Greek keyboard layout and defined the (otherwised unused) Menu key as the keyboard layout switcher. That’s a pretty big hammer for a rather small problem; I devoutly hope Unicode mysteriously starts working again.
For reference, the Greek keyboard layout looks like this:
Greek keyboard layout
I’d have put Ω on the W key, rather than V, but that’s just because so many fonts do exactly that.
Raspberry Pi vs. Avahi
Posted by Ed in Electronics Workbench, PC Tweakage, Software on 2017-01-18
It turns out that the various Avahi daemons performing the magick between whatever.local names and dotted-quad 192.168.1.101 addresses for Raspberry Pi descend into gibbering madness when confronted with:
- One name corresponding to multiple IP addresses
- One IP address used for multiple MAC addresses
- Multiple names for one IP address
- Multiple names for one MAC address
- Multiple IP addresses for one MAC address
- Multiple MAC addresses for one IP address
- Any and all combinations of the above at various times
The least of the confusion involved an incorrect IP address linked to a familiar name pulled from deep history by a baffled daemon doing the best it can with what it thinks it knows. Despite what I concluded, rather early in the process, there’s no real error, other than my performing what amounted to a self-inflicted fast-flux nameserver attack.
Anyhow, I devoted the better part of an afternoon to sorting out the mess, which involved labeling all the streaming radio players with their MAC addresses and rebooting them one-by-one to allow all the daemons time to recognize the current situation:
Raspberry Pi 3 – WiFi MAC address
That label corresponds to the Pi 3’s on-board WiFi adapter.
For Pi 2 boxen, the MAC address travels with the WiFi adapter jammed into a USB port:
SunFounder WiFi Adapter – MAC address
I didn’t label the (unused) Ethernet jacks, figuring I’d solve that problem after it trips me up.
Raspberry Pi WiFi Adapters
Posted by Ed in Electronics Workbench, PC Tweakage on 2017-01-11
One might be forgiven for thinking these two USB Wifi adapters are essentially identical:
USB Wifi adapters
Turns out the SunFounder RT5370 (on the top, with the stylin’ curved case) has better performance than the Wifi With Antenna (on the bottom, with full-frontal chunk goin’ on), by a not inconsiderable 5 to 10 dB. Boosting the received power level in the fringe areas of our house from -70 dBm to -63 dBm makes all the difference between not working and steady streaming.
The built-in WiFi antenna on a Raspberry Pi 3 ticks along 10 dB lower, with -80 dBm (10 pW!) at the receiver making for poor communication: a Pi 3 works perfectly within reasonable line-of-sight of the router (even through our wood floor) and wakes up blind in fringe areas. Hacking an external antenna probably helps, but definitely isn’t a net win compared to ten bucks worth of USB adapter.
The wavemon utility (it’s in the Raspbian repo) comes in handy for figuring that sort of thing.
There is, of course, no way to determine anything important about the adapters from their product descriptions, which are essentially identical, right down to the price. Neither have any product identification on their cases. The back of the package for the SunFounder gadget gives some specs, none of which may mean anything (clicky for more dots):
SunFounder RT5370 USB WiFi Adapter Specs
I ordered another SunFounder adapter, Just In Case it comes in handy, with the hope that both behave the same way.
-
You are currently browsing the archives for the PC Tweakage category.
Blowback