• Compute Stick caffeination

    Paul Nicholls5 days ago 0 comments

    After the software tweaking mentioned in the previous post, I was pretty happy with how it was running. A BIOS update got headless mode working with no other changes required; before the update, the Stick wouldn't boot without a display attached - just sitting there with the power LED lit but not doing anything useful.

    I decided to leave it running for a while so that I could monitor for any memory leaks etc, and was rather puzzled to find that it seemed to die after sitting for about 5-10 minutes without any keyboard/mouse input (even if I was connected via SSH). The power LED stayed lit, but it didn't respond to any kind of input. I tried plugging the display, keyboard and mouse back in and booting back into the GUI, and found that it did the same thing. It seemed to be going to sleep / suspending itself, but I couldn't convince it to wake up - and no options I changed within the GUI seemed to change this behaviour.

    I tried a few options found around the web (i.e. Ask Ubuntu), and eventually found one which works: set SUSPEND_METHODS="none" in /etc/default/acpi-support (and restart acpid). So far, so good!

  • Compute Stick tweaking

    Paul Nicholls6 days ago 0 comments

    The Intel Compute Stick comes with Ubuntu 14.04 LTS preloaded, running the full-fat Unity interface. In an effort to minimise RAM usage (to keep as much available for STF as possible), I've replaced Unity with lubuntu-desktop (LXDE) and removed a whole bunch of default packages which aren't relevant. If you choose to replace Unity with something lighter (such as Lubuntu/LXDE), it's probably a good idea to run `sudo apt-get clean` (and/or remove some unwanted packages) after installing lubuntu-desktop but before logging out of your Unity session, so that there's some storage space free; my Compute Stick ran out (a decent chunk of the already tiny 8GB is taken up by a recovery partition, which I may back up and then remove), resulting in neither Unity nor Lubuntu/LXDE wanting to start - both just showed the wallpaper after login, with no other UI, and wouldn't respond to anything. If you do get stuck in that state, try dropping to a console (ctrl+alt+F1) and running `sudo apt-get clean` in order to free up some space before you log in.

  • MultiDock hacking?

    Paul Nicholls6 days ago 0 comments

    Closer inspection of the MultiDock's daughter boards reveals that the USB hub is connected to port 1 on the TS3USB221A. Per the datasheet, we should be able to tie the switch pin low in order to lock it to port 1. As the TS3USB221A is in a 10-Pin µQFN package, soldering directly to it would be a massive pain in the posterior. Luckily, the trace was reasonably easy to follow - a via right next to the pin drops it through to the back of the board, where it runs up to another via right next to pin 6 on the PIC. Each of the PIC's pins is almost as big as the entirety of the TS3USB221A, making it a much friendlier target for modding - and luckily, there's an ICSP header right next to the PIC, with a ground pin within easy reach.

    Lifting the PIC's pin 6 from the board and soldering a jumper wire in its place, connected to the ICSP ground pin, does appear to have locked the TS3USB221A to port 1 - and one phone which didn't work with the unmodded MultiDock now happily works when plugged into the Orico hub via a modded daughter board. Unfortunately, that's not all that's needed; some devices seem to cause the PIC to switch something on the power rails (understandable, since it's trying to switch the port over to a dedicate charging port controller), resulting in the device's USB connection 'bouncing' continuously.

    It's possible that the MultiDock's hub and/or daughter boards are broken, as I picked the MultiDock up second hand (well below full retail price) - and I've noticed a red LED blinking constantly on the MultiDock's main board, just beside the first USB2514B hub controller IC. With this in mind, and the lack of apparently quick-and-easy hack to make it work how I'd like it to, it's back to my original plan of removing the original electronics and replacing the whole lot.

  • MultiDock exploration

    Paul Nicholls04/20/2017 at 09:57 0 comments

    Since the MultiDock's USB hub doesn't seem to be suitable for this project, it'll have to come out. I've done a bit of exploratory rummaging around inside it. As long as you have a T20 "security" torx bit (with a hole in the middle), the MultiDock is very easy to get into. Simply unscrew the back plate, then remove three screws and slide out the device tray, and the electronics are exposed. (Photos will be added soon - I need more light!)

    The internal construction consists of a metal-cased power supply, a large flat PCB which holds the USB hub controllers (3x SMSC/Microchip USB2514B) and a few other components, and a series of 10 vertically-mounted boards with the USB sockets and status LEDs on them.

    Each of the 10 vertical boards is connected to the main board by a short USB mini-B male to mini-B male contains a surprising amount of circuitry, including:

    I haven't reverse engineered the whole thing yet (far from it), but so far I've been able to determine that the TS3USB221A is used to switch the USB port between the USB2514B hub and the TPS2511 dedicated charging port (DCP) controller. I'm guessing that the PIC is deciding whether to switch it to the hub or DCP controller, and that my compatibility issues are being caused by it connecting most of my devices to the DCP rather than the hub. I'm not currently sure how it decides - but may be able to figure it out from a closer inspection and/or a bit of probing. A minor hardware hack to tie the TS3USB221A's port selection pin either high or low (depending on which port is which) may also be an option, if I can find a safe/easy connection point. If I can force the ports to hub mode, it'll still remain to be seen whether that allows the devices to draw sufficient current to charge (or at least maintain, rather than draining the battery).

  • MultiDock testing

    Paul Nicholls04/20/2017 at 09:18 0 comments

    While I wait for the Compute Stick to arrive, I have OpenSTF deployed on my old ThinkPad T430. Plugging the MultiDock into the ThinkPad, it was recognised as three four-port USB hubs (two of them are connected to ports on the third, providing a total of 10 usable ports for devices - 4 on each of two hubs, plus two on the third hub). This seemed like a good start, but of the four devices which currently make up my OpenSTF device lab:

    • One works - hooray!
    • One is detected, but ADB lists it as "no permissions" so OpenSTF can't use it
    • Two aren't detected at all

    It doesn't seem to matter which port(s) I use on the MultiDock - each device behaves the same, no matter which port (and thus which internal hub) it's connected to. This means that the MultiDock's original electronics are going to be useless for this project, but that's not a big deal as I've already got an Orico 7-port powered hub on the way which should hopefully work.