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.

Category: PC Tweakage

Remembering which tweaks worked

Presentation Video: Bring Enough Adapters

I plugged my trusty Dell Latitude E6410 into the VGA cable connected to a Viewsonic projector at TechShop Detroit to give the OpenSCAD Modeling presentation, but the display showed a surprising amount of ghosting; whether that was due to a bad cable or the usual presentation gremlins, I cannot say. Fortunately, although I didn’t have a VGA cable, I did have a fair assortment of adapters for the laptop’s DisplayPort output…

On the laptop end, DisplayPort to a DVI-D cable:

Latitude vs Viewsonic – DisplayPort to DVI-D

On the Viewsonic end, DVI-D to HDMI:

Latitude vs Viewsonic – DVI-D to HDMI

Worked like a champ!

The projector in the room for the Arduino Survival Guide presentation had a VGA cable, but had been losing sync and turning itself off, so I unplugged that, rebuilt the DisplayPort adapter string, and continued the mission.

I must add a known-good VGA cable and corresponding adapters to the assortment…

2015-06-29
No Affordance for Pulling

Well, I didn’t expect this:

Unsleeved USB memory

Turns out the only thing holding that case in place was a blob of hot-melt glue on the bottom of the PCB. Hot-melt glue doesn’t bond well to anodized aluminum, the RPi had been sitting outside on a winter day taking time-lapse bird feeder pictures, and the USB connector seemed a bit more snug than usual.

So I slobbered more hot-melt glue on the end of the PCB, jammed the case back in place, and that was that.

The PCB has two snap lines to accommodate shorter cases, with corresponding activity LED locations; it seems I got the long-case version.

2015-05-09
Rebooting a Dell U2711 Monitor
It turns out my fancy Dell U2711 landscape monitor doesn’t work well with Displayport video. I normally leave it in power-save mode, with the power LED slowly fading orange, but about once a week it won’t start up when I turn on the PC. It seems the only solution is a hard power cycle, so I plugged it into a remotely switched outlet to eliminate having to pull its plug.

Now that I know what to watch for, it’s easy to work around: if the power LED doesn’t turn blue when the PC power goes on, immediately turn off the PC power and power-cycle the U2711. If I let the PC continue in Xubuntu, the U2713 portrait monitor becomes the primary display and X helpfully rearranges the video configuration around the disabled U2711 until I manually un-wedge things. If I shut down the PC while it’s still displaying the BIOS intro screen, then click-click the remote power switch, the U2711 will be good for another week or so.

Every month or so, the U2711 won’t light up after going into power-save mode, even though the PC is still running just fine. I set Lightlocker (which replaces the classic screensaver on Xubuntu) to blank the screen after 10 minutes and turn off the display power after 11 minutes. When the U2711 doesn’t light up, some delicate xrandr surgery through the U2713 will bring the U2711 back to life.

The starting situation looks like this:
```
xrandr
Screen 0: minimum 8 x 8, current 1440 x 2560, maximum 16384 x 16384
DP-0 disconnected primary (normal left inverted right x axis y axis)
DP-1 disconnected (normal left inverted right x axis y axis)
DP-2 connected (normal left inverted right x axis y axis)
   2560x1440      60.0 +
   1920x1200      59.9  
   1920x1080      60.0     59.9     50.0     24.0     60.1     60.0     50.0  
   1680x1050      60.0  
   1600x1200      60.0  
   1280x1024      75.0     60.0  
   1280x800       59.8  
   1280x720       60.0     59.9     50.0  
   1152x864       75.0  
   1024x768       75.0     60.0  
   800x600        75.0     60.3  
   720x576        50.0     50.1  
   720x480        59.9     60.1  
   640x480        75.0     59.9     59.9  
DP-3 connected 1440x2560+0+0 left (normal left inverted right x axis y axis) 597mm x 336mm
   2560x1440      60.0*+
   1920x1200      59.9  
   1920x1080      60.0     59.9     50.0     24.0     60.1     60.0     50.0  
   1680x1050      60.0  
   1600x1200      60.0  
   1280x1024      75.0     60.0  
   1280x800       59.8  
   1280x720       60.0     59.9     50.0  
   1152x864       75.0  
   1024x768       75.0     60.0  
   800x600        75.0     60.3  
   720x576        50.0     50.1  
   720x480        59.9     60.1  
   640x480        75.0     59.9     59.9
```
Note that there’s no asterisk on DP-2’s 2650x1440 entry, which means it’s not active. In fact, it’s jammed in power-save mode and nothing other than a hard power cycle will wake it up.

The U2713 portrait monitor wakes up just fine, so X piles all the program windows into an untidy heap on that display, but, with enough Alt-Tab action, I can eventually resurface the console window and start typing:
```
xrandr --output DP-2 --off
xrandr --output DP-2 --auto
xrandr --output DP-3 --right-of DP-2
```
The DP-2 and DP-3 outputs correspond to what xrandr reported above.

Then I must rearrange all the windows on both monitors again, but that’s much easier than the hocus-pocus required to recover after rebooting the PC with the U2711 shut down.

The normal (or recovered) video situation looks like this:
```
xrandr
Screen 0: minimum 8 x 8, current 4000 x 2560, maximum 16384 x 16384
DP-0 disconnected primary (normal left inverted right x axis y axis)
DP-1 disconnected (normal left inverted right x axis y axis)
DP-2 connected 2560x1440+0+0 (normal left inverted right x axis y axis) 597mm x 336mm
   2560x1440      60.0*+
   1920x1200      59.9  
   1920x1080      60.0     59.9     50.0     24.0     60.1     60.0     50.0  
   1680x1050      60.0  
   1600x1200      60.0  
   1280x1024      75.0     60.0  
   1280x800       59.8  
   1280x720       60.0     59.9     50.0  
   1152x864       75.0  
   1024x768       75.0     60.0  
   800x600        75.0     60.3  
   720x576        50.0     50.1  
   720x480        59.9     60.1  
   640x480        75.0     59.9     59.9  
DP-3 connected 1440x2560+2560+0 left (normal left inverted right x axis y axis) 597mm x 336mm
   2560x1440      60.0*+
   1920x1200      59.9  
   1920x1080      60.0     59.9     50.0     24.0     60.1     60.0     50.0  
   1680x1050      60.0  
   1600x1200      60.0  
   1280x1024      75.0     60.0  
   1280x800       59.8  
   1280x720       60.0     59.9     50.0  
   1152x864       75.0  
   1024x768       75.0     60.0  
   800x600        75.0     60.3  
   720x576        50.0     50.1  
   720x480        59.9     60.1  
   640x480        75.0     59.9     59.9
```
Note that DP-2 now sports an asterisk.

The width of Screen 0 covers the U2711 in landscape and the U2713 in portrait: 4000 = 2560+1440. The height comes from the U2713 in portrait mode: 2560.

That this should not be necessary goes without saying. The U2711 run with firmware revision A09, which was supposed to fix the problem, but Dell basically walked away from it.

I’m pretty much forced to use Displayport video for both monitors, as a low-profile nVidia card with two dual-link DVI-D outputs doesn’t seem to exist. The Dell Optiplex 980 disables the system board video when it finds a PCI-E video card, so there’s no way to run the U2713 from the system board Displayport and the U2711 from a dual-link DVI PCI-E video card.
2015-05-06
HP 7475A Plotter: Serial Cable for Hardware Handshaking

The HP 7475A wakes up with hardware handshaking enabled: DTR starts high and goes low when the internal 1 KB buffer has less than 80 bytes remaining. The plotter also supports XON/XOFF handshaking, a sad software thing you’d use only if you had no other choice.

The Chiplotle doc provides a wiring diagram for a suitable 9-to-25 pin cable, so I printed one and doodled on it while pondering the Great Cable Stash:

HP7475A Plotter – Serial Cable

The color codes over on the left of the top diagram match a prebuilt cable I hoped to repurpose, but it had only five conductors, none of which were DSR or CTS. Pfui!

So I used a hank of gorgeous flexy 9-conductor cable (which came with premolded DE-9 ends of the wrong gender, now amputated into pigtails and back in the GCS), which supported the connections redrawn on the bottom in proper numeric order, used the obvious color sequence (Bn R O Y G Bl V W K), then soldered suitable connectors on each end:

HP 7475A Plotter – serial cable

And it worked the first time…

2015-05-04
RPi: Time-lapse Photos
The Raspberry Pi doc provides a recipe for the simplest possible time-lapse webcam: fire fswebcam once a minute from a cron job.

The crontab entry looks much like their example:
```
* * * * * /home/ed/bin/grabimg.sh 2>&1
```
I put all the camera details in the ~/.config/fswebcam.conf config file:
```
# Logitech C130 / C510 camera
device v4l2:/dev/video0
input 0
resolution 1280x720
set sharpness=128
jpeg 95
set "power line frequency"="60 hz"
#no-banner
```
That simplifies the ~/bin/grabimg.sh script:
```
#!/bin/bash
DATE=$(date +"%Y-%m-%d_%H.%M.%S")
fswebcam -c /home/ed/.config/fswebcam.conf /mnt/samba/webcam/$DATE.jpg
```
The output directory lives on a Samba-shared USB stick jammed in the back of the Asus router, so I need not putz with a Samba server on the RPi.

Manually mounting the share, which for the moment is the /testfolder/webcam directory on the USB stick:
```
sudo mount -t cifs -o user=ed //gateway/testfolder/webcam /mnt/samba
```
I’m pretty sure automagically mounting the share will require the same workarounds as on my desktop box, but this fstab entry is a start:
```
#-- ASUS router Samba share
//gateway/testfolder/webcam	/mnt/samba	cifs	auto,uid=ed,credentials=/root/.gateway-id 0 0
```
That requires a corresponding credentials file with all the secret info:
```
domain=WHATSMYNET
username=ed
password=pick-your-own
```
This is mostly a test to see how long it takes before something on the RPi goes toes-up enough to require a manual reboot. Disabling the WiFi link’s power saving mode seems to keep the RPi on the air all the time, which is a start.
2015-04-08
RPi: Logitech QuickCam for Notebook vs. fswebcam
Combining the camera data I collected a while ago with a few hours of screwing around with this old Logitech camera:

Logitech QuickCam for Notebook Plus – front

I’m convinced it’s the worst camera I’d be willing to use in any practical application.

The camera offers these controls:
```
fswebcam --list-controls
--- Opening /dev/video0...
Trying source module v4l2...
/dev/video0 opened.
No input was specified, using the first.
Available Controls Current Value Range
------------------ ------------- -----
Brightness 128 (50%) 0 - 255
Contrast 128 (50%) 0 - 255
Gamma 4 1 - 6
Exposure 2343 (8%) 781 - 18750
Gain, Automatic True True | False
Power Line Frequency Disabled Disabled | 50 Hz | 60 Hz
Sharpness 2 0 - 3
Adjusting resolution from 384x288 to 320x240.
```
Putting the non-changing setup data into a fswebcam configuration file:
```
cat ~/.config/fswebcam.conf
# Logitech QuickCam for Notebook Plus -- 046d:08d8
device v4l2:/dev/video0
input gspca_zc3xx
resolution 320x240
scale 640x480
set sharpness=1
#jpeg 95
set "power line frequency"="60 hz"
```
Trying to use 640×480 generally produces a Corrupt JPEG data: premature end of data segment error, which looks no better than this and generally much worse:

Logtech 08d8 – 640×480

The top of the picture looks pretty good, with great detail on those dust particles, but at some point the data transfer coughs and wrecks the rest of the image. I could crop the top half to the hipster 16:9 format of 640×360, but the transfer doesn’t always fail that far down the image.

The -R flag that specifies using direct reads instead of mmap, whatever that means, doesn’t help. In fact, the camera generally crashes hard enough to require a power cycle.

Delaying a second with -D1 and / or skipping a frame with -S1 don’t help, either.

The camera works perfectly at 640×480 using fswebcam under Xubuntu 14.04 on a Dell Latitude E6410 laptop, so I’m pretty sure this is a case of the Raspberry Pi being a bit underpowered for the job / the ARM driver taking too long / something totally obscure. A random comment somewhere observed that switching from Raspbian to Arch Linux (the ARM version) solved a similar video camera problem, so there’s surely room for improvement.

Dragorn of Kismet reports that the Raspberry Pi USB hardware doesn’t actually support USB 2.0 data rates, which also produces problems with Ethernet throughput. The comments in that slashdot thread provide enough details: the boat has many holes and it’s not a software problem.

For lack of anything more adventurous, the config file takes a 320×240 image and scales it up to 640×480, which looks about as crappy as you’d expect:

Logtech 08d8 – 320×240 scaled

Even that low resolution will occasionally drop a few bytes along the way, but much less often.

The picture seems a bit blown out, so set the exposure to the absolute minimum:
```
fswebcam -c ~/.config/fswebcam.conf --set exposure=781 "Logitech 08d8 - expose 781.jpg"
```
Which looks like this:

Logitech 08d8 – expose 781

Given that’s happening a foot under a desk lamp aimed well away from the scene, the other end of the exposure scale around 18000 produces a uselessly burned out image. I think a husky neutral-density filter would be in order for use with my M2’s under-gantry LED panels. The camera seems to be an early design targeting the poorly illuminated Youtube / video chat market segment (I love it when I can talk like that).

There’s probably a quick-and-dirty Imagemagick color correction technique, although Fred’s full-blown autocorrection scripts seem much too heavy-handed for a Raspberry Pi…
2015-04-06
RPi: Static WiFi Addressing
Having configured ssh on the Raspberry Pi for public keys, the next step is to cut the cord by configuring the USB WiFi dongle to automagically come up with a static IP.

[Update: As of 2017, set a static IP by tweaking /etc/dhcpcd.conf instead. Search the blog for that to find recent descriptions. ]

Make /etc/network/interfaces look like this:
```
auto lo

iface lo inet loopback

#iface eth0 inet dhcp

auto eth0
#iface eth0 inet static
iface eth0 inet manual
 address 192.168.1.209
 gateway 192.168.1.1
 netmask 255.255.255.0
 network 192.168.1.0
 broadcast 192.168.1.255

allow-hotplug wlan0

#iface wlan0 inet manual
iface wlan0 inet static
 address 192.168.1.9
 gateway 192.168.1.1
 netmask 255.255.255.0
 network 192.168.1.0
 broadcast 192.168.1.255

#wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

iface default inet dhcp
```
Then set up /etc/wpa_supplicant/wpa_supplicant.conf thusly:
```
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1

network={
	ssid="whatever it might be"
	psk="choose your own password"
}
```
You want different IP addresses for the eth0 and wlan0 devices, because you never know when you’ll be forced to use them at the same time.

Using wpa-conf rather than wpa-roam prevents the machinery from automagically doing things when you’re not watching.

The router can hand out IP addresses based on MACs, but that means bottling up all that configuration in a single device that might go toes up. Forcibly configuring each device to a static IP adds a bit of resilience to the network, right up to the point where you must change all of them at once.

Alas, the router seemed to lose track of the Pi after a day. Pinging from my desktop box reported Destination Host Unreachable, even though signing on through the USB keyboard showed the USB WiFi link (a netis WF2123) was still up. Signing on to the router and refreshing the DHCP list (even though the RPi has a static IP) knocked things loose: suddenly the RPi became pingable.

It seems the WiFi link turns itself off after a while, which can be averted by tweaking the options:
```
sudo nano /etc/modprobe.d/8192cu.conf
# Disable power saving
options 8192cu rtw_power_mgnt=0 rtw_enusbss=0
  
```
The WordPress sourcecode tag seems to turn underscores into blanks [Update: on the last line of a sourcecode block, which I’ve now forced to be a blank line] ; the options should read rtw_power_mgmt and rtw_enusbss, respectively.

Anyhow, the rtw_enusbss option prevents the USB interface from going down. It was already zero in the default configuration, but I presume there’s no harm in clearing it again.
2015-03-22