Razer Hydra HMD hack

Razer Hydra is a pretty decent 6DOF tracker (position + orientation) for the price, so a natural choice. However, the controllers do not lend themselves very well for tracking props or an HMD due to their size and shape and no different sensor is available from Razer. Some people have attempted to disassemble the controller and remove as much as possible, leaving only the sensing coils (it is a magnetic tracker). The disassembly procedure is well described here: http://www.mtbs3d.com/phpBB/viewtopic.php?f=120&t=14036 (registration required to see the images). However, a small mod is required for this to work properly.

What is inside

The controller contains two boards, one with the 3 sensing coils (about 20 mH each), two AD8656 dual opamps and an ADG794 electronic switch/mux with 4 channels. The smaller board contains all the buttons, the joystick and the trigger potentiometer, along with an LPC1111F microcontroller that senses the buttons and measures the potentiometers for the joystick and trigger. These data are then sent using a serial protocol to the base. The boards are connected by a flat flex cable with 8 wires.

The opamps amplify and buffer the signals from the sensing coils, the switch is controlled both by the base and the microcontroller on the joystick board, allowing to short the inputs of each of the opamps and disable the signal. Only the base seems to be controlling the /EN signal – holding it high (pull-up) keeps the Dx (x = 1-4) outputs floating (high-impedance state). When low, this pin activates the mux and connects the Dx pins to one of the SxA or SxB pins, depending on the state of the IN pin. When IN is low, Dx is connected to the SxA pin, when high, to the SxB pin.  The IN pin is controlled by the microcontroller.

The way the opamps are configured through the mux allows the micro to either short the opamp inputs through a 680R resistor (effectively disabling the coils) when IN is high or to allow normal functioning (bypassing the 680R resistor) when IN is low. What I have observed is that the base turns the /EN pin low when the device is opened (e.g. the vrpn_server is started) and the IN pin constantly low – the coil signals are enabled. When the device is closed, the /EN goes high, disabling the mux (but not the coils), effectively disconnecting the MCU from the board and connecting a 680R resistor in series with the inverting inputs of the opamps. The preliminary schematics below shows the circuit, hopefully making it clearer.

Tentative schematics with the unimportant parts left out (filter/decoupling caps, interface to the micro, 0R jumpers …)

I have never seen a transition on the IN line, but the VRPN driver uses very little functionality from the Hydra. Perhaps it is used in some undocumented mode (e.g. the gamepad mode? That one doesn’t use the coils.) or a left-over from the days when the SDK was wireless – maybe the micro was disabling the coils while it was transmitting info to the base, in order to not cause spurious data being received because of the voltages induced by transmission in the sensing coils. Who knows. Any suggestions on this are welcome.

The description above holds for the 3 switches in the mux, the 4th one is used only as a pass-through for one of the opamps because of the way the board is routed – essentially a “wire” jumper.

Detour to magnetic tracking

The following three images are captures from my oscilloscope measuring the signals on the opamp outputs – the amplified coil signals. It is quite obvious how the magnetic tracker works. There are three pulses, each 2ms long, followed by a pause of 2ms again, giving about 125Hz refresh rate. The three pulses correspond to each of the three crossed coils in the base – they are pulsed in series. The receiver coils in the controller receive each of the pulses with different amplitudes, depending on the relative orientation of the receiving and transmitting coils. If their axes are aligned, the corresponding signal is strong. If they are not aligned, the signal is weaker, being weakest when the axes are perpendicular. Changing the distance of the controller from the base changes the amplitude of all three signals in the same way. From this information the DSP in the base can determine the orientation and position of the controller using some complicated math.

The mod

Disclaimer: The following hack was tested on my Linux machine with the VRPN driver. It did work (the tracking is working), but I haven’t tested the accuracy of the modified Hydra or any other adverse effects – caveat emptor.  This hack could ruin your device and will most certainly void your warranty. Don’t blame me if that happens.

The obvious solution how to make the controller smaller and more amenable to e.g. an HMD installation is to remove the joystick board by disconnecting the flat flex cable. Some people were supposedly successful, however most often the Hydra stops tracking (sends random data). The problem seems to stem from the fact that the base unit will not power up the controller properly, resulting in garbage being sent to the CPU in the base.

The sensor board

The sensor board with the relevant components marked. The yellow pin labels on the chips were added by me for reference, they are *not* present on the real chips 🙂

One way to do this is to solder a 10k resistor between the positions of the unpopulated diode D24 and the unpopulated R97 resistor. That will make the base power the board properly and the device will work. I strongly suggest putting a strip of insulating tape over the resistor or a drop of hot-melt glue to hold it down against the PCB, in order to avoid snagging it on something or floating around and putting stress on the thin traces. Otherwise the traces could lift off/break and ruin the board.

10k resistor soldered between the positive power rail and the serial line.

Detail – 10k resistor soldered between the positive power rail and the serial line.

With this mod I am able to use the controller with the VRPN driver even without the joystick board and everything is working. I haven’t tested it with the official drivers/SDK – I am interested in hearing any success/failure reports if someone decides to try this hack. I am also interested in hearing any hypotheses/info on why is the power to the controller board behaving in such a weird way and what could be the reason for the multiplexer on the board, as it doesn’t seem to be really used for anything.

Update 1

I have confirmation from Jane Peters from the Iowa State University in the US and from Justin Scaniglia that they have been able to reproduce the mod. However, it seems to work only with VRPN, not the standard Windows SDK.

Update 2

A very nice music composition/performance project by Byron Mallett (aka @Mystfit) using this hack:

 

11 Comments

  • MSat commented on September 16, 2012 Reply

    Interesting find!

    Quick question: Is d24 connected to c99? Also, have you completely verified that all the axis still function properly?

    • admin commented on September 16, 2012 Reply

      On my Hydra the cap and the diode footprint don’t seem to be connected. Strange, it looks like a decoupling cap, but I am not getting a low resistance indication there using my ohmmeter.

      And yes, all axes work – both in position and orientation, at least using the VRPN driver.

  • MSat commented on September 16, 2012 Reply

    I have a feeling the mcu strobes the enable pin for a reason. Possibly using it as the second control bit for a 3:1 mux. If not that, then what is the purpose of the mux? I find the design to be quite fascinating.

  • admin commented on September 16, 2012 Reply

    That is what I thought too – I have hooked up my scope on both IN and /EN pins and there is nothing whatsoever going on. Both are held high during normal operation (when /EN is high, the outputs of the mux are in high-z state and IN doesn’t matter).

    There are more such bizarre things – e.g. the fourth opamp has all parts populated, even though it is not used (there are only 3 coils there). There are plenty of unpopulated footprints. The routing of some of the signals is a bit weird too. E.g. the D24 diode is marked in reverse – that was obviously either a zener or reverse voltage protection diode. If it was a zener, then the controllers were likely meant to work at higher voltage (5V?). Reverse protection diode would make sense if it was battery powered. My guess is that this is a left-over from the original wireless version and the functionality is not really used in the consumer one.

    There is also a JTAG/SWD footprint on the joystick board, so I may try to see if I can pull out the firmware from the micro. However, it is most likely protected.

  • admin commented on September 16, 2012 Reply

    One more thing – the mux is actually 2:1 only, not a 3:1. The IN pin normally controls which set of inputs (S1 vs S2) gets connected to the D output. It has 4 channels. The /EN pin turns off all of the switches at once when held high. However, the way it is configured, it seems that they use it only to ground the opamp inputs, not really as a true mux.

  • MSat commented on September 17, 2012 Reply

    I don’t get it at all, then. If both the IN and EN pins are held high the whole time, why would they even have the mux populated on the board? I know the part was a 4-ch 2:1 – I just figured they somehow rigged it up to use it as a 3:1. Hmmm..

    You said ” It seems that the pull-up line is somehow tied to the serial output of the microcontroller and will distort the transmitted data.”, so how come this isn’t affecting the EN pin?

    • admin commented on September 17, 2012 Reply

      As I said, I suspect that the mux is only used in some special mode or perhaps not at all with the current setup. Maybe it was something left from the wireless version, where disabling the coils could save power or something like that. And they re-used the PCB – it is cheaper to reuse than to re-engineer the entire thing. Hard to say, really.

      Re the serial line – there are some caps along the way, if you trace the EN line to the flat flex connector, effectively filtering the fluctuations out. However, that should affect the serial signal quality, unless the caps are small values and the serial is at low speed (which it seems to be). When I have the jumper in place, the serial signal is heavily distorted, I am getting only shallow dips from the full Vcc – the micro is obviously trying to pull the line down, but doesn’t succeed because it cannot sink enough current (there is a 1.2k resistor there right next to the micro, limiting the current to about 2.2mA max). If the jumper is disconnected, I am getting full swing digital signal, with some 8 or 9 bits per character (I didn’t try to analyze it). It is hard to properly trace this on the joystick board, because the traces are obscured by the silkscreen and many parts on that board.

      If you want to play with this, I think I have seen the serial signal on the via right under the unpopulated D23 diode, above the via that has the 3.3V. That seems to pass through the C99 cap (not sure whether it is connected or only passing under it) and to the flat flex connector. The QFN package of the micro has the UART on pins 31 (RX) and 32 (TX). I think that these are connected to the two large square pads next the JP3 marking (test pads?). It seems to go to the pins 6 and 7 of the flex. I don’t see anything obvious that could cause the problems with the jumper being connected there, but there are some connections under the connectors too that I don’t see too well. Also my eyesight isn’t best, this is really a job for a microscope. If you manage to figure out why is it affecting the EN line, I am all ears.

  • MSat commented on September 17, 2012 Reply

    Heh. Sorry for all the questions, I don’t have my own _yet_, so I’ve been trying to get all my info from other. I’ve been interested in the design ever since some tear-down pics have been posted on the MTBS3D forum. 🙂

    I can see if the mux was some remnant of the wireless design, but if EN is held high the whole time, keeping all the lines HI-Z, wouldn’t it be completely pointless for the part to even be populated on the board?

  • admin commented on September 17, 2012 Reply

    Well, if you want to build your own magnetic tracker, better be prepared for some serious math :-p

    Re the mux – yes, essentially removing it should not affect the functioning of the board for tracking. On the other hand, we don’t really know what is the thing doing – perhaps it is required for some functionality that wasn’t reverse engineered yet. Also the connections around the mux and the opamps are rather convoluted, so I would be careful about jumping to conclusions.

  • MSat commented on September 17, 2012 Reply

    >>Well, if you want to build your own magnetic tracker, better be prepared for some serious math :-p

    Hehe. I realized that when I seen under the hood of a couple different ones!

    I had tried doing a partial trace based on some images that had been posted elsewhere. Even the little bit that I could see left me completely perplexed. If the IN and EN pins aren’t being strobed, then I’m completely at a loss. Initially, I was thinking it was used as a sort of 3:1 mux where it only sends the signals from one coil at a time (maybe so it can detect common-mode noise on the lines?). Either that, or perhaps it shorts and opens the coils quickly to implement some sort of filter?

  • admin commented on September 17, 2012 Reply

    No, not at all. All three coils are sent at the same time as analog signals down the wire to the base. Each has its own wire, they are not multiplexed – that would even not make much sense, because you need to capture the voltages on the 3 coils at the same time. Otherwise the controller could move while you are switching the coils around, leading to errors.

    You can clearly see those three signal lines coming from the left side from the opamps to the connector.

Leave a Reply

Your email address will not be published. Required fields are marked *