Close

One step forward, two steps back

A project log for STFDock

Turning a Griffin MultiDock 2 into a self-contained OpenSTF device lab

paul-nichollsPaul Nicholls 05/07/2017 at 04:510 Comments

Starting on boot

Starting from a basic template, I created a couple of init scripts: one for the ADB server, and one for STF itself. RethinkDB comes with an init script - just follow the instructions (copy the sample config file into /etc/rethinkdb/instances.d and edit as desired). These init scripts worked, but at the same time I was writing them, I was also experimenting with various USB hubs (including the MultiDock's), and at one point ended up with a USB hub which I was sure had previously worked perfectly no longer playing ball with several devices. After much poking around, I discovered that the ADB server needed to be running as root in order to see and talk to all of the devices - even with the relevan udev rules (per the Android developer docs). I adjusted my init script accordingly, and didn't really think much more of it.


Ubuntu rebuild

Even after "caffeination", the Compute Stick wasn't anywhere near stable enough. The SUSPEND_METHODS="none" fix definitely put a stop to the auto-suspend after a short period of "inactivity", but after a while (anywhere from an hour or two to the better part of a day) it was still falling off the network for no apparent reason. I restored the Compute Stick to its factory state using the recovery partition (just as well I hadn't got around to removing it yet) and started fresh; a different project with another Compute Stick had revealed that the default Unity environment isn't as much of a hog as I'd initially thought (after tuning, at least), so this time I've stuck with that. Removing as much unneeded software as possible and tuning what I can (including installing compizconfig-settings-manager and disabling a bunch of plugins etc which I didn't want/need) has resulted in a pretty lean system which is happy to run STF on an ongoing basis.

USB hubs, revisited

Having ordered and now received the Plugable USB hub recommended by the STF documentation, it was time to figure out which combination of hubs made sense to use. I unboxed the Plugable hub to start testing, only to find that it had two problems: just like the Orico, it has a momentary power button, making it difficult to mount inside the MultiDock; and the two oldest devices (Galaxy Nexus and Galaxy S Wifi 4.0, both 6-7 years old) aren't detected at all by the computer when plugged into it. The power button turns out to be something of a non-issue, as it'll happily power up and work just fine with the button held in - so I can either short it out or simply mount it such that the button is permanently held in. The compatibility issue, however, is a bit trickier to deal with. A quick peek at the hub's innards reveal it to use FE1.1s [pdf datasheet] hub controllers, with no obvious way to change its behaviour (I suspect that it's the Battery Charging 1.2 support which causes the problem, as the devices in question charge happily but don't appear as USB devices). I then suddenly remembered that the compatibility issues I saw with the MultiDock matched those that I experienced with other hubs when the ADB server wasn't running as root, which made me wonder if I'd tested the MultiDock at the wrong time; I've now reassembled the MultiDock's innards, and sure enough, most of the devices work on it! Unfortunately, the old devices aren't supported (as per the Plugable hub), but plugging the MultiDock into the Orico hub gives a good balance - newer devices can be plugged directly into the MultiDock, while the older ones can be plugged into the Orico hub. Subsequent testing of the Orico hub has revealed that it also powers up without issue if the power button is simply held in permanently, so it's a viable option for legacy device support.

The revised plan

In light of the above, my revised plan is something along these lines:

This should result in a self-contained box which takes in a singe mains power feed, has an external power switch (which the MultiDock already has), and supports all of the devices which I'd like to be part of the farm. If it proves too difficult to fit the Orico hub's innards into the MultiDock, I could also revert to the previous plan of replacing the MultiDock's guts with the Plugable hub (plus the Orico).

Discussions