Category Archives: Electronics

Posts about electronics. Usually meaning electrical gadgets smaller than a proper computer.

TP-Link Archer C7 with OpenWRT

I bought myself a TP-Link Archer C7 because the 2.4Ghz congestion in my apartment has become so terrible that my good old TP-Link WR1043ND (no 5Ghz radios) is no longer adequate, and the C7 was very well spoken of among reasonably-priced 802.11ac routers. It also has some nice perks like two on-board USB ports, so I can use it as a print server (with p910nd) and have USB storage for logs (vnstat & co.) and such attached without a separate hub. I wasn’t feeling quite motivated enough to buy and set up one of the NUC-like cheap SFF Intel boxes as a router like Ars Technica and Jeff Atwood have recently noted is an increasingly good plan, based largely on the dearth of ac WiFi cards that work reliably in host mode.

Some notes that may be of use to others, particularly about firmware replacement on recent models and throughput:
Continue reading

Posted in Computers, Electronics, General, Objects | 14 Comments

Breaking In to your Own Devices

I gave an informal talk for the IEEE student branch about breaking in to your own devices this evening. I did the low-postable-content notes with live examples and links thing, but at least one person wanted to watch the video links, so here are the notes. There is something delightful about giving talks that require legal disclaimers. I don’t think there is anything in here that will get me in trouble…

Continue reading

Posted in Computers, DIY, Electronics, Entertainment, General, School | Leave a comment

Clevo P650SE/NP8651

P650SET510Flat_web

My 5-year-old T510 has been showing its age, mostly by falling apart (speakers died, parts held on with gaffers tape, occasional probably-thermal GPU lockups, etc.) and I decided it was time for a replacement. Unfortunately, the laptop market right now has absolutely nothing appealing (clickpads everywhere!) so I gave up and bought a closest-match Clevo P650SE chassis that I could kit out myself. There are a couple annoyances, but overall it’s a nice machine. Really long detail notes including a bunch of Linux tweaking below.

Continue reading

Posted in Computers, Electronics, General, Objects | Tagged , , | 5 Comments

RFID Exploration

I recently picked up a USB RFID reader/writer pod to play with, partly to learn enough to be dangerous about the tech, and partly hoping to tamper with the RFIDs in the current university ID cards. I’m pretty sure I failed on the latter point, but am succeeding at the former in the process.

RFIDKit

Notes from the first round of fiddling with it follow.

Continue reading

Posted in Computers, DIY, Electronics, General, Objects | Tagged , | 18 Comments

Galaxy S5

MyTouch 4G Slide vs. SGS5, flat dimensions.

MyTouch 4G Slide vs. SGS5, flat dimensions.

I got a Samsung Galaxy S5 (The T-Mobile flavor, SM-900T) a week ago. I’m pretty pleased with it overall, but many of the impressions worth sharing are not positive, particularly of the small-but-stupid variety. Much of the animus (and credit) is really for Google, not Samsung.
Continue reading

Posted in Computers, Electronics, General, Objects | Tagged , | Leave a comment

New Chorder

I’ve been playing with chorded input devices for years, and got the itch again recently.

CNChorder
Continue reading

Posted in Computers, DIY, Electronics, General, Objects | Tagged | Leave a comment

3D Printing KC Talk

I gave a quick primer on 3D printing as a Keeping Current (CS departmental) seminar yesterday.

It’s not a great standalone deck but posted (in reduced quality, gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dPDFSETTINGS=/ebook -dNOPAUSE -dQUIET -dBATCH -sOutputFile=/path/to/output.pdf /path/to/input.pdf is good magic).

It seemed to be well-received, printed objects were played with, thoughtful questions were asked, I think this is the first time I’ve given a 3D printing primer to a wider group and not been asked the “guns” question.

Posted in Computers, DIY, Electronics, General, Objects, School | Leave a comment

WNR3500L Repair

Some years ago the KAOS lab bought a number of Netgear WNR3500L routers to use as network glue. A pair of them have been in constant service since 2011 in the lab and machine room, and both of those died in the last two weeks. I’ve finally satisfactorily tracked down the culprit, and figure it’s worth a quick write up.

The WNR3500L is a bit of a false-promise machine; it was sold as an “open router” with excellent community firmware support, but it has some pretty extensive blobs that mean it really only runs versions of DD or Tomato with a small range of 2.6 kernels.

I initially just swapped the first one to die out for a spare (which happened to be flashed with Tomato instead of DD, it was an experiment when they were first set up), and reloaded most of the settings by hand (we failed to save or document many of the settings elsewhere. Our fault.) until I had time to investigate. When the second one died, it became urgent.

WNR3500LScrew

Conveniently, the WNR3500L has a 3.3V RS-232-like serial port (115200/8/n/1) under an easily removed panel, retained by one small torx screw/pin thing (Both are out in the picture while I was figuring out which side was which).

WNR3500LBP

This leads to another victory for the Bus Pirate. Any 3.3V compatible UART adapter would work, but the bus pirate has much nicer cables for this sort of thing. In retrospect, those headers are correctly sized to just plug the female harness ends directly, but I used clips out of habit.

It turns out they were booting right up with only warnings, but the configuration was sufficiently garbled that neither the WLAN nor the Ethernet ports were coming up. I blew the first one’s settings away (note: at least on the old version these were running, reboot TWICE after clearing the NVRAM to get back to a consistent state: the first time it writes default values, the second time it boots cleanly). With the software-only nature of the problem established, I took more time to investigate the second one, at which point…

nvram show
[1310 lines excluded]
size: 32782 bytes (-14 left)

Well, There’s Your Problem.

Turns out the tiny little log fields for monthly traffic statistics filled up the nvram and were causing configuration corruption, and thus failures.

There are some forum threads and bug reports on the matter, and it was fixed about two years ago with a test to prevent writing past the end of the file, a default setting to automatically delete traff logs after 12 months, and various other enhancements. Now that we’re up and running again it isn’t desperate, but it looks like there is a DD release from mid-2013 with the fixes applied that still supports these things, and they are probably due to be re-flashed to keep this from happening again.

Lessons:

  • My home OpenWRT on a TP-Link 1043ND uses a connected USB key for logging and such. This is a much better behavior (like most things in OpenWRT: DD-WRT appears to be kind of an unmaintainble mess).
  • Keep an eye on appliances like routers, they’re still just computers.
  • Back up your damn configurations, or at least retain copies of the information required to regenerate them. Regenerating settings, especially when it involves manual tasks like MAC address hunting, sucks.

Other notes:

  • These things’ bootloaders appear to always look at 192.168.1.2 through the non-WAN ports for a tftp payload named vmlinuz. There may be a way to disable that, but I think I’d prefer to leave it on, since it only enables local attacks and provides a rescue mechanism.
  • The WNR3500L has a documented weakness about WAN-LAN throughput with various firmwares. Our uplink is actually good enough for it to matter, so perhaps one of the newer versions will improve that.
Posted in Computers, DIY, Electronics, General, Objects, School | Tagged , , , | Leave a comment

chdk-ptp PKGBUILD

In another episode of fixing things for the Cameras as Computing Systems class I’m taking, I made a PKGBUILD that apparently correctly builds and installs chdk-ptp on Archlinux systems. Chdk-ptp is a tethered-control application for Canon cameras running CHDK, that hooks a variety of custom extensions to the ptp protocol. Their build system is a little lackluster, is missing things like an install rule, and requires a helper script be installed to do some path munging before running the binary, but the documentation is good enough to sort it out, and the program itself seems to work. My package depends on iup-all-bin from the AUR which also provides the cd dependency (not marked in its provides array, though there isn’t an official package to conflict with). I tried to use the built-from-source AUR packages for cd (Seriously, who thought that was a good name for a piece of software?) and iup, but iup was giving me a hassle and the chdk-ptp documentation suggests the binary distribution will be less trouble anyway.

The PKGBUILD format has changed a bit since I was last making my own- I like most of the changes in terms of clarity and modularity, but it does require a bit of re-learning. It also means I have a couple of pet packages that probably need attention.

The build is a little janky so despite it passing through namcap with only one expected warning, I don’t want to put it in the AUR until I’ve tested it enough to be reasonably sure it works as intended. I expect I will get around to that eventually.

Posted in Computers, DIY, Electronics, General, Objects, School | Tagged , , , , , , | Leave a comment

Makergear M2 Heated Bed Issue

There was a problem with the Lab’s Makergear M2 recently that is worth writing up.

Last weekend, we had it off site for a demo event for a group of highschoolers interested in engineering and medicine, which included assembling samples of these printable articulated hands that Dr. Dietz designed. (Semi-related: I’ve watched him do it, and continue to be mystified how he does things like this in OpenSCAD). We printed some models live, but on the last print of the trip it made a burning plastic smell. Not the usual, pleasing corn-syurp-y PLA-at-work smell, but acrid recently-deceased-electronics smell. We couldn’t locate the problem, and everything was working, so we assumed filament impurity and moved on.

M2RAMBO39530Melted

The next day, the bed stopped heating. Probing around with a DMM indicated the board was fine but the wire harness was not (A thank you to the Ultimachine folks for putting proper test points on the outputs). A bit of googling turned up this thread implicating the quick release screw terminal block that connects the bed leads to the board. Sure enough, upon yanking the connector free, the removable wire-side portion was a melted mass.

39530Melt

The existing connector is a Molex 39533-2002 rear-entry, two lead “Eurostyle” connector. Interestingly, Makergear and/or Ultimachine (Makergear buys and installs RAMBO Boards) used straight-through 5.08mm (200mil, but usually talked about in metric) quick release connectors – screws on the top, wires enter from the right – for the other MOSFET outputs, but a rear-entry (screws on the left, wires enter from the top) for the bed heat. This seemed odd since the side of the little laser-cut enclosure the RAMBO board lives in obscures the screw heads, but the reasoning will become clear. When I was poking at it to see if I could figure out what went wrong, I noticed the threads on the melted side were all but stripped out, but I don’t know if that was a cause or a symptom.

M2RAMBO39533

Since it is a standard connector, the (apparently intact) board side will mate with any two-position 3953x part. We found an ebay listing for five 39533-2002 for about $8 shipped, which are compatible and straight-through. Sadly, ebay is usually cheaper and faster than dealing with an electronics vendor if you only need one thing. The replacement seems to work fine, but clearly the original was a rear-entry model to keep the wires from being pressed against the side of the case. The M2’s wire harness is definitely its weak point; two of three serious intervention-requiring stoppages have been related to the bundle headed up to the bed/Y assembly.

The general lesson is to keep an eye on your screw terminals, especially if they are carrying current. I recall replacing the (non-quick-release) bed heater screw terminals on Collexion’s Makerbot ToM after a meltdown not long ago, so there is clearly a general issue with running that much current through screw terminals (several of the common crimped connectors would likely be superior in most ways). Since it came up (and since it is intuition-defying and I’ve heard a lot of people who should know better get it wrong) I’ll close with a reminder that you should not tin your wires before placing them in screw connectors – I know I’ve read this in a standard, research-backed source from ISO or NASA or somesuch, but I can’t find it right now.

ADDENDUM: It cooked two more of the same connector, then we discovered that the SD card connector was a little lose, and apparently causing a ground problem. It hasn’t cooked another connector since, and the bed heats faster than it was, so strong evidence that that was the root cause.

Posted in DIY, Electronics, General, Objects | Tagged , , | 3 Comments