Razer Hydra teardown.

[janoc]

We are trying to use the Hydra in a CAVE environment. Obviously we'd need a wireless version of the board eventually (we can wait though) but does anyone know if the device works if you extend the controller cable? Like 2.5m?

Cheers
Ben

If you mean to extend the USB cable, that works. But extending the cable to the two controllers will not - the device has only about 50-80cm range from the base station. After that it starts to be too noisy and finally fails to track completely. Basically you cannot even use the full range of the stock cables.

[MSat]

We are trying to use the Hydra in a CAVE environment. Obviously we'd need a wireless version of the board eventually (we can wait though) but does anyone know if the device works if you extend the controller cable? Like 2.5m?

Cheers
Ben

Without any further mods, I doubt it. Perhaps setting the OPamp gain higher might help, but that might increase the noise to unusable levels.

[WiredEarp]

Great news everyone. I received a PM from user ISUEE, who mentioned that they had managed to get janoc's Hydra resistor mod going, so I revisited it. Using the standard Hydra drivers does NOT work, however, I am happy to be able to confirm that it DOES work, and very well, using the VRPN drivers!

It turns out that I broke one side of my Hydra with my different mods, so that controller never works, but the other one returns perfectly valid data using the mod and the VRPN drivers. I haven't noticed any change in the accuracy etc, although I haven't done any serious testing yet. Also, even with the resistor mod in place, it seems you can still use the buttons/stick if you keep the flex cable connected.

This is awesome news for anyone who wishes to incorporate the Hydra into a game gun, or glove! Instead of needing to cut the board and extend the sensor (as PalmerTech did originally - my version that I did ages back is the green box in the attached picture), you can simply solder on this resistor, desolder and resolder the ground wire (to remove it from the controller), and you end up with a nice, lightweight board. Note I've left my board in the Hydra controller for now, to protect it (this is my half broken test Hydra, planning on doing a fresh mod on a new Hydra this weekend).

One thing that would be even better would be if there was some way to hack the official Hydra drivers, to bypass the initialization step. Its just a Windows application, so shouldn't be impossible (unless it depends on receiving a handshake from the microcontroller on the button board). I'm hoping that perhaps we could make it think we had simply pressed the buttons to initialize it, without needing to do so. Unless you move the controller to the other sensing hemisphere, I don't believe it would cause any problems. This would give us the advantage of being able to use the official driver and all its modes etc without needing to code fresh ones using VRPN.

Anyway, congratulations to janoc, it's some fine hardware hacking on his part IMHO. Also, thanks to ISUEE for heads up about it definitely working! I think this will open up doors for many people to develop all sorts of innovative homegrown gameguns and other controllers, based around this board.

[WiredEarp]

Oh, one other thing, does anyone have any idea as to where/how I could get/make a longer flex cable? The pitch is way too small for me to extend manually, and one side has pretty fine pins as well, so it wouldn't be easy to bridge the two boards with thin wires etc either. If we could get a flex cable of the right type that was, say, 3 inches long, it would greatly assist those who want to make gameguns etc. Currently, the one i'm building uses a PS2 joystick which is going to be interfaced manually, but if I had a long enough flex cable, I could simply use the Hydra joystick (and extend the buttons to where I want). This would give us the ability to use the standard drivers again, and the Hydra joystick is quite high quality. Currently, the cable is just not long enough, or robust enough, to do anything like this with. Its not so necessary with janoc's mod working, but would eliminate a fair bit of work and waste, if we could find a source for cables of this type.

[janoc]

Great news everyone. I received a PM from user ISUEE, who mentioned that they had managed to get janoc's Hydra resistor mod going, so I revisited it. Using the standard Hydra drivers does NOT work, however, I am happy to be able to confirm that it DOES work, and very well, using the VRPN drivers!

Cool, thanks for the confirmation again

One thing that would be even better would be if there was some way to hack the official Hydra drivers, to bypass the initialization step. Its just a Windows application, so shouldn't be impossible (unless it depends on receiving a handshake from the microcontroller on the button board). I'm hoping that perhaps we could make it think we had simply pressed the buttons to initialize it, without needing to do so. Unless you move the controller to the other sensing hemisphere, I don't believe it would cause any problems. This would give us the advantage of being able to use the official driver and all its modes etc without needing to code fresh ones using VRPN.

Personally I prefer to write code for VRPN than a proprietary SDK that may change or stop being supported at any moment. Also, VRPN is IMO a lot simpler to integrate than the Sixsense SDK which needs integration of a windows GUI dialog - hard to do if you are doing your own GUI rendering. Moreover, almost every VR-related software uses/supports VRPN, so you can swap the Hydra for a $150k tracker later without any changes to your code.

The only thing the VRPN driver doesn't have are the game profiles (no real need for them) and the gamepad mode. However, I doubt someone would actually want to use the Hydra as a gamepad.

Anyway, congratulations to janoc, it's some fine hardware hacking on his part IMHO.

Ah, you are welcome

Jan

[geekmaster]

... This is awesome news for anyone who wishes to incorporate the Hydra into a game gun, or glove! Instead of needing to cut the board and extend the sensor (as PalmerTech did originally - my version that I did ages back is the green box in the attached picture) ...

What material are those coil bobbins in the green box plastic made of? If ferrite (or other metal), they could restrict the range of the magnetic field somewhat. But pulling the field lines closer to the coils with a metallic core may also increase the accuracy, so perhaps a useful tradeoff if you need accuracy more than range.

[janoc]

What material are those coil bobbins in the green box plastic made of? If ferrite (or other metal), they could restrict the range of the magnetic field somewhat. But pulling the field lines closer to the coils with a metallic core may also increase the accuracy, so perhaps a useful tradeoff if you need accuracy more than range.

The coils in my Hydra seem to be bog standard, of the shelf, 18-20mH coils. These inductors look very much similar to what is in my Hydra: http://radiospares-fr.rs-online.com/web ... s/7380861/

I am not sure whether these have metal/ferrite cores or just plastic bobbin - it isn't visible from outside and the datasheet isn't mentioning a core.

The cores in the coils don't really restrict range - range depends on the strength of the magnetic field (transmitter power) and the sensitivity of the receiver that is directly proportional to the inductance of the coil. Which happens to be higher when there is a core. However, the cores increase a lot the non-linearity of the system, typically not something you would want in a tracker.

I have seen air coils in the Motion Star/Flock of Birds sensors, but those systems use also a much much stronger magnetic field - i.e. the CRT monitors in the adjacent room in my former lab would get strong interference when the system was in operation, cca 10m away. Hydra has no chance at doing that.

Regards,

Jan

[WiredEarp]

Personally I prefer to write code for VRPN than a proprietary SDK that may change or stop being supported at any moment. Also, VRPN is IMO a lot simpler to integrate than the Sixsense SDK which needs integration of a windows GUI dialog - hard to do if you are doing your own GUI rendering. Moreover, almost every VR-related software uses/supports VRPN, so you can swap the Hydra for a $150k tracker later without any changes to your code.

The only thing the VRPN driver doesn't have are the game profiles (no real need for them) and the gamepad mode. However, I doubt someone would actually want to use the Hydra as a gamepad.

Those are some good points Jan. I think I need to get out of the mode I've been in for some time, which is that of using conventional games (such as L4D) with VR gear and start thinking more about the new, VR specific games that will be coming out. I currently use the default Hydra drivers to play L4D, but thinking about it, it wont be at all hard to duplicate this functionality using VRPN, and probably will take me less time than stuffing around hacking drivers that will change next version anyway.

[janoc]

Those are some good points Jan. I think I need to get out of the mode I've been in for some time, which is that of using conventional games (such as L4D) with VR gear and start thinking more about the new,

I think that trying to use (and abuse) existing games into supporting VR hw is a hopeless battle without the publisher's support. Unless the game explicitly supports your device, you get at best some sort of mouse + keyboard emulation. That is what the Hydra profiles are actually for. However, that is hardly an ideal experience.

Some hw wouldn't even work at all, such as the upcoming Oculus Rift HMD, because they need explicit rendering support from the game.

[WiredEarp]

I think that trying to use (and abuse) existing games into supporting VR hw is a hopeless battle without the publisher's support. Unless the game explicitly supports your device, you get at best some sort of mouse + keyboard emulation. That is what the Hydra profiles are actually for. However, that is hardly an ideal experience.

Thats true if you are using mouse mode, but I've successfully hacked in absolute tracking for TrackIR in Comanche 4 and FarCry 3, and StreetRat has done so for some other games (Mass Effect and some others I cant remember) so its not an impossibility to make older games support absolute aiming. I'm planning on adding Hydra support to those two of mine in the next iteration (still have to release the FarCry3 one, just have a minor issue with the hangglider I need to fix first). This is one way to make older games work with VR gear (basically, just finding the pitch/yaw/?roll? coordinates the game uses and directly changing them). If the game is more open though, it's much better to do it the proper way by adding internal game code, as in the Half Life 2, Quake3, and other projects on this site which are adding VR support to these games.

Some hw wouldn't even work at all, such as the upcoming Oculus Rift HMD, because they need explicit rendering support from the game.

If you're referring to the warping required for Rifts etc, there is the Vireio Perception open source driver on this forum which does this already, and there is commercial software coming from Nthusim which also does this. So its not impossible to make old games compatible with our modern gear. However, the experience is never going to be anything like the experience with 'proper' VR games - ones with independent gun movement, and unlimited ducking/leaning etc. I tried to add leaning to FarCry3 but couldn't figure out the memory addresses

[geekmaster]

Personally I prefer to write code for VRPN than a proprietary SDK that may change or stop being supported at any moment. Also, VRPN is IMO a lot simpler to integrate than the Sixsense SDK which needs integration of a windows GUI dialog - hard to do if you are doing your own GUI rendering. Moreover, almost every VR-related software uses/supports VRPN, so you can swap the Hydra for a $150k tracker later without any changes to your code.

The only thing the VRPN driver doesn't have are the game profiles (no real need for them) and the gamepad mode. However, I doubt someone would actually want to use the Hydra as a gamepad.

And now, another reason to use VRPN support. In addition to the Hydra, we can have DAY-0 support for the Rift IMU without waiting for the Rift SDK, by using the "Unofficial Rift to VRPN Server" you can download here:

This VRPN Server executable is designed to transmit orientation data from the Oculus Rift’s sensors to a VRPN Client of your choice.

Compatibility: Windows ONLY
Author: Thai Phan
Instructions: Simply Download VRPN EXE file, Plug in Oculus Rift, then run VRPN EXE file.

[WiredEarp]

And now, another reason to use VRPN support. In addition to the Hydra, we can have DAY-0 support for the Rift IMU without waiting for the Rift SDK, by using the "Unofficial Rift to VRPN Server" you can download here:

Great link Geekmaster! That will make things easy for lots of people.

[janoc]

Thats true if you are using mouse mode, but I've successfully hacked in absolute tracking for TrackIR in Comanche 4 and FarCry 3, and StreetRat has done so for some other games (Mass Effect and some others I cant remember) so its not an impossibility to make older games support absolute aiming. I'm planning on adding Hydra support to those two of mine in the next iteration (still have to release the FarCry3 one, just have a minor issue with the hangglider I need to fix first). This is one way to make older games work with VR gear (basically, just finding the pitch/yaw/?roll? coordinates the game uses and directly changing them). If the game is more open though, it's much better to do it the proper way by adding internal game code, as in the Half Life 2, Quake3, and other projects on this site which are adding VR support to these games.

Well, cool if you can do this, but this is a really fragile way of doing things - it is likely to break the next time the company patches/updates the game. With the current trend of always on internet connection needed because of Steam/Origin and similar systems used to automatically patch your games (among other things), that would be a cat and mouse game.

Not to mention potential license/legal issues if you do this - most games explicitly forbid this sort of hacking in their license. Nobody reads that, but that doesn't mean you won't have problems because of it.

If you're referring to the warping required for Rifts etc, there is the Vireio Perception open source driver on this forum which does this already, and there is commercial software coming from Nthusim which also does this. So its not impossible to make old games compatible with our modern gear. However, the experience is never going to be anything like the experience with 'proper' VR games - ones with independent gun movement, and unlimited ducking/leaning etc. I tried to add leaning to FarCry3 but couldn't figure out the memory addresses

Sorry, but I don't consider hijacking of Direct3D dlls a solution. That's a horrible, Windows-only, Direct3D-only hack. Vuzix was doing this with their drivers for the VR920. They almost got me banned from World of Warcraft, because they silently replaced DLLs in the WoW installation, triggering the integrity check failure in their anti-cheating system. Of course, the patched Vuzix drivers didn't even work properly with the later releases of the games, because they weren't updated in years. This hack is of course better than nothing if you really really want to play a game with an HMD, but that is hardly something you can call "support". And it must not become the standard way of supporting these devices.

Furthermore, this type of hack still does nothing to issues such as the need to draw cursors and screen overlays properly in 3D so that they are not floating at the focal plane in front of you in stereo, UI and text size may need to be adapted for the lower resolution, different FOV, most FPS shooters keep your "head" glued to your shoulders (no independent looking and turning) etc.

[janoc]

And now, another reason to use VRPN support. In addition to the Hydra, we can have DAY-0 support for the Rift IMU without waiting for the Rift SDK, by using the "Unofficial Rift to VRPN Server" you can download here:

Great link Geekmaster! That will make things easy for lots of people.

Beware - I checked the link, it claims to support the Hilcrest tracker. That was the IMU Palmer considered for the Rift originally, but now they have their own, cheaper and better IMU. So it may not work with the actual Rift as shipped.

Moreover, it is Windows only, closed source, non-commercial use only - ergo, useless for me. If Oculus doesn't ship VRPN support out of the box, I will have to make my own once I have Rift on my desk.

[geekmaster]

Beware - I checked the link, it claims to support the Hilcrest tracker. That was the IMU Palmer considered for the Rift originally, but now they have their own, cheaper and better IMU. So it may not work with the actual Rift as shipped.

Moreover, it is Windows only, closed source, non-commercial use only - ergo, useless for me. If Oculus doesn't ship VRPN support out of the box, I will have to make my own once I have Rift on my desk.

They only just published the Rift VRPN server. Yes, the separate VRPN supports a lot of stuff including Hillcrest. But their Rift VRPN Server is in with all their brand new DIY Rift Mods. It seems unlikely that it would be any less. And in the main Rift thread, there are those who are reversing the server to extract the USB protocol for the Rift.

[WiredEarp]

Well, cool if you can do this, but this is a really fragile way of doing things - it is likely to break the next time the company patches/updates the game. With the current trend of always on internet connection needed because of Steam/Origin and similar systems used to automatically patch your games (among other things), that would be a cat and mouse game.
Not to mention potential license/legal issues if you do this - most games explicitly forbid this sort of hacking in their license. Nobody reads that, but that doesn't mean you won't have problems because of it.

Indeed, I've had to update my FarCry3 hack several times with each new patch. Its a bit of a PITA, but once the base code is there, it only takes me about 30 minutes to support the new version. However, many of the older games that people want to try, have reached their lifespan and are no longer being updated, so its not such an issue. I don't really care about the legal aspect, and I doubt the companies involved will care either about people modding/hacking older, singleplayer games. Those concerns are more important for multiplayer however, with cheat detection systems running etc.

Sorry, but I don't consider hijacking of Direct3D dlls a solution. That's a horrible, Windows-only, Direct3D-only hack. Vuzix was doing this with their drivers for the VR920. They almost got me banned from World of Warcraft, because they silently replaced DLLs in the WoW installation, triggering the integrity check failure in their anti-cheating system.

Thats the problem with multiplayer hacks! However, for single player stuff its not really a problem - you can't be banned just for playing games such as Mirrors Edge on your own PC. It is a concern for me however that people could play with these hacks online accidentally, and get banned then. However, if the companies don't wish to support different peripherals (such as FC3 not supporting TrackIR), then then only option people have is hacking the support in.

Furthermore, this type of hack still does nothing to issues such as the need to draw cursors and screen overlays properly in 3D so that they are not floating at the focal plane in front of you in stereo, UI and text size may need to be adapted for the lower resolution, different FOV, most FPS shooters keep your "head" glued to your shoulders (no independent looking and turning) etc.

Thats why I didn't bother hacking the main view in FC3. I didn't see the need, as there is no independent head turning etc. The Vireio Perception however does (I believe) allow people to do the independent head turning thing. Re the cursors and focal planes, this IS an issue, but its one also experienced by drivers such as Nvidias 3D Vision, so we can piggy back on mods made to support/fix that. For example, games such as Dishonored were terrible in S3D until a 'Helix mod' was released for it, which fixed all the 3D issues. I believe the way Helix mods work is using Nvidia 3D Vision extensions, so there is probably no problem with being banned for using them (anyone know more about this?). Also, the Nthusim driver which is coming out basically does the same thing as Vireio, but since they are an established company with lots of connections, and existing drivers that modify outgoing imagery, I wonder if they will be accepted for online play without worrying about banning?

that is hardly something you can call "support". And it must not become the standard way of supporting these devices.

Thats very true. I don't think theres really anything better we can do however to provide basic Rift compatibility for older, unsupported games. Hopefully, new games will all start to support the Rift etc natively, which would be the best solution for the future. That said, any game designed for desktop play, with Rift support added as an afterthought, will be way inferior to true VR games designed specifically for VR. I'm really looking forward to seeing what people come up with in terms of pure VR stuff now that cheap, wide FOV HMD's are going to be available to so many interested and talented people.

Beware - I checked the link, it claims to support the Hilcrest tracker. That was the IMU Palmer considered for the Rift originally, but now they have their own, cheaper and better IMU. So it may not work with the actual Rift as shipped. Moreover, it is Windows only, closed source, non-commercial use o

Bummer. Ah well, I doubt it will take at all long for a Rift->VRPN bridge to come out, and be open source, once the Rift and SDK is available to us.

[janoc]

Bummer. Ah well, I doubt it will take at all long for a Rift->VRPN bridge to come out, and be open source, once the Rift and SDK is available to us.

I will for sure write one for our own needs once the Rift is here, so if my boss is OK with it, I will send it to Russell Taylor to include it in the standard VRPN source, as my other drivers (SpacePoint, Gametrak, etc.) That comes with source and is licensed the same as VRPN, so you can use it even on Android, Mac or Linux.

AFAIK, the Rift tracker seems to talk to the PC as a normal USB HID device, so adding support for that should be fairly easy given the availability of the protocol doc. The only complication could be if they are doing the sensor fusion on the PC and not on the device itself, that would have to be re-implemented in order to avoid the dependency on the Rift SDK.

Regards,

Jan

[rupy]

How does the ball base look inside?

[janoc]

How does the ball base look inside?

There isn't that much interesting stuff in there. The ball has three crossed coils and a LED inside and the base contains a large PCB with a Blackfin DSP chip and some extra electronics. There are pictures of it elsewhere on this forum, I think.

Jan

[geekmaster]

... I notice that the dev kit from Sixense actually supports 4 sensors, not two. I wonder how much it would cost for one of those, or if it will be possible to buy or mod the Hydra to allow an extra 2 sensors (eg, if we could change the frequency, we could possibly run 2 hydra bases together). Long shot I know however, but 4 sensors would be extremely useful. I could then have one on the head, one on a glove, another on the gun, and the forth one as a hip sensor to measure turning, jumping, and crouching.

I might try and mod mine today. If so, I'll post some more stuff in this thread about it, to make it easier for others to find info re the mod.

It was reported in another thread that multiple Hydras will work in the same space if you disconnect the coils in all but one base unit. The position sensing is done in the handsets. The base sequentially activates each of the three coils, then none of them (for a sync signal). The handsets detect position and orientation from the relative strength of the three magnetic field signals. This testing was done with multiple Hydra base units plugged into different computers, but only one of them had its coils connected.

[janoc]

It was reported in another thread that multiple Hydras will work in the same space if you disconnect the coils in all but one base unit. The position sensing is done in the handsets. The base sequentially activates each of the three coils, then none of them (for a sync signal). The handsets detect position and orientation from the relative strength of the three magnetic field signals. This testing was done with multiple Hydra base units plugged into different computers, but only one of them had its coils connected.

Well, now this I seriously doubt for several reasons. If you disconnect the coils in the base, the DSP has no synchronization to the handset. If the handset is in range of the other Hydra, it will receive some random magnetic fields, but that's all - it will not be able to calculate anything useful from it, because it doesn't know which coil was activated when (necessary to calculate the orientation). The "space" following the 3 pulses is not sufficient to synchronize the two devices, because it has the same length as one signal pulse - thus you cannot reliably distinguish whether there is a "space" because the base isn't transmitting there or because the handset isn't receiving any signal in that time slot due to its orientation/position.

So if this was somehow working for someone, I think that they had the incredible luck that the Hydras started the sensing cycle in the same sequence and haven't drifted apart yet - which they inevitably will after a short while, because they aren't synchronized. The DSPs will drift apart due to temperature, noise, USB traffic, etc.

Regards,

Jan

[V8Griff]

Professional Magnetic trackers like Polhemus and Ascension use a frequency module inline with the source so I assume that it wouldn't be too difficult for the Hydra to use something similar to differentiate the pulses from different sources?

[janoc]

Professional Magnetic trackers like Polhemus and Ascension use a frequency module inline with the source so I assume that it wouldn't be too difficult for the Hydra to use something similar to differentiate the pulses from different sources?

You mean what they call the AC tracking system? That is actually not so much to avoid different magnetic sources (second tracker in the room would still interfere), but to eliminate things like fixed magnetic fields, influence of metal etc.

In theory Hydra could be adapted for something like this, but that would require quite a bit of re-engineering, including physically changing the circuitry in a significant manner (both the coil drivers and receivers would need replacing) and modifications to the firmware (the response of the coils is different if you are feeding a modulated signal into them compared to single pulses). If you want to go that far, you could probably design your own tracker as well - it would be likely simpler than to reverse engineer the Hydra to that level.

Jan

[V8Griff]

You mean what they call the AC tracking system?

Jan

No they actually have a separate box which is colour coded for simplicity to allow multiple sources as per the diagram below.

[janoc]

No they actually have a separate box which is colour coded for simplicity to allow multiple sources as per the diagram below.

Ah, I see. I had to actually find the Insidetrak documentation to look it up, that is a really ancient system. However, still the rest of my comment holds, you would have to replace a large part of the signal processing and coil driving electronics to be able to use a modulated signal. Also the firmware would likely need a modification. Considering that nobody has so far succeeded to reverse engineer the firmware (legal issues notwithstanding) and the complexity of the DSP math involved, I doubt that it is something worth doing.

BTW, I am not aware of Polhemus or Ascension using these "frequency modules". The primary function of the boxes between the main tracker and the emitter coils is to act as a power driver. Usually all the high power electronics is housed in that box, with a separate power supply, because it would be difficult to put that into the computer case that is the core of the system, with all the high currents and switching noise (you want to keep that away from the sensitive sensor receivers). Also, having the box separate allows for different emitter configs while keeping the same main box - e.g. the small close range emitters need different driver electronics, the Ascension trackers allow up to two emitters per driver box, etc. It saves costs, because the customer buys only the configuration they are going to use.

Regards,

Jan

[V8Griff]

BTW, I am not aware of Polhemus or Ascension using these "frequency modules". The primary function of the boxes between the main tracker and the emitter coils is to act as a power driver.

Sorry but that's incorrect. If you've looked up the InsideTrak manuals you'll see that that diagram is in there.

Usually all the high power electronics is housed in that box, with a separate power supply, because it would be difficult to put that into the computer case that is the core of the system, with all the high currents and switching noise (you want to keep that away from the sensitive sensor receivers). Also, having the box separate allows for different emitter configs while keeping the same main box - e.g. the small close range emitters need different driver electronics, the Ascension trackers allow up to two emitters per driver box, etc. It saves costs, because the customer buys only the configuration they are going to use.

The tracker electronics were all housed on a full length card in the PC and that box as shown merely sits inline, without any additional power and performs the function I have described. Configurations being selected by dip switches.

I have three complete InsideTrak systems, with all sources, frequency modules and receivers. Nothing else was required.

A similar product produced by Ascension at the same time called SpacePad allowed/required you to build your own source and supported up to four receivers.

Edited to add a picture of an InsideTrak card.

[geekmaster]

It was reported in another thread that multiple Hydras will work in the same space if you disconnect the coils in all but one base unit. The position sensing is done in the handsets. The base sequentially activates each of the three coils, then none of them (for a sync signal). The handsets detect position and orientation from the relative strength of the three magnetic field signals. This testing was done with multiple Hydra base units plugged into different computers, but only one of them had its coils connected.

Well, now this I seriously doubt for several reasons. If you disconnect the coils in the base, the DSP has no synchronization to the handset. If the handset is in range of the other Hydra, it will receive some random magnetic fields, but that's all - it will not be able to calculate anything useful from it, because it doesn't know which coil was activated when (necessary to calculate the orientation). The "space" following the 3 pulses is not sufficient to synchronize the two devices, because it has the same length as one signal pulse - thus you cannot reliably distinguish whether there is a "space" because the base isn't transmitting there or because the handset isn't receiving any signal in that time slot due to its orientation/position.

So if this was somehow working for someone, I think that they had the incredible luck that the Hydras started the sensing cycle in the same sequence and haven't drifted apart yet - which they inevitably will after a short while, because they aren't synchronized. The DSPs will drift apart due to temperature, noise, USB traffic, etc.

The sync pulse is magnetically broadcast as part of the magnetic "stream". Off (sync), then Coil 1, then Coil 2, then Coil 3, then Off again (another sync pulse). They all sync to the same sync pulse from the SINGLE set of magnetic fields (from the base with coils still connected). The other bases apparently just act as USB pass-through. It was reported to be working reliably. There are reports that you can even have multiple hydras on one computer IF you use VRPN. The stock hydra drivers have issues with that...

A small basestation has three small orthogonal coils that generate a weak magnetic field. Three smaller coils in each sensor detect this field. ... The system can handle any number of sensors because each performs its own analysis. ...
- BILL WONG, SIXENSE ENTERTAINMENT

The base DSP only drives the coils. The position calculations are independently done in the handheld controllers, and apparently only need that broadcast sync pulse (all base coils turned off).

They would drift out of sync IF multiple base units were broadcasting, because then there would periodically be no sync pulses (always SOME coil on from a base unit, for long periods of time) because of aliasing from multiple units. That is exactly why the extra base units need their coils disabled, so all the hydra controllers can always see the sync pulses from the single base unit.

EDIT: Those test results from cms need to be reproduced by others. It is still very much a "work in progress". @janoc you may be correct about drift, but it seems promising that the cms test results match what the Sixense guy said in the quote above. Here is where the "coil disabling" discussion begins:
http://www.mtbs3d.com/phpBB/viewtopic.p ... =0#p116713

[WiredEarp]

Nice summary Geekmaster. Glad you added the edit though, as much of that is just unconfirmed speculation ATM. However, it does look very promising. Just need someone else to disable the bulb and confirm...

[geekmaster]

... If the handset is in range of the other Hydra, it will receive some random magnetic fields, but that's all - it will not be able to calculate anything useful from it, because it doesn't know which coil was activated when (necessary to calculate the orientation). The "space" following the 3 pulses is not sufficient to synchronize the two devices, because it has the same length as one signal pulse - thus you cannot reliably distinguish whether there is a "space" because the base isn't transmitting there or because the handset isn't receiving any signal in that time slot due to its orientation/position.

Perhaps that is why the Hydra drivers want you to point the controllers at the base and press a button to start up, so they CAN synchronize. From then on, once they know where the sync pulse is supposed to be in the time sequence, they can distinguish a synch pulse from a null (missing pulse), because what pulse(s) they DO see at the expected timeslot helps them keep synchronization.

Also, they may use relative phase between coils in addition to relative amplitude. I suspect that is how they can determine 6 DOF instead of just 3 DOF.

[Krenzo]

Also, they may use relative phase between coils in addition to relative amplitude. I suspect that is how they can determine 6 DOF instead of just 3 DOF.

Magnetic tracking can do 6 DOF because a magnetic field has strength and direction. It's not just the distance from the coils but also the orientation of the coils that is used in the calculation. The base station sends out 3 separate fields, but the receiver generates 9 separate readings using the 3 coils which results in a 3x3 matrix.

[MSat]

The "space" following the 3 pulses is not sufficient to synchronize the two devices, because it has the same length as one signal pulse - thus you cannot reliably distinguish whether there is a "space" because the base isn't transmitting there or because the handset isn't receiving any signal in that time slot due to its orientation/position.

Keep in mind that all three receiving coils are being sampled, so under regular usage there shouldn't be any situation where none of those coils are detecting the "signal".


@geekmaster
The wireless version that Sixense developed may have had the processing done on the controller itself, but the Hydra controllers just have opamps, and send the analog signal down the wire to the base station to be converted to digital and processed by the DSP.

As for why the Hydra controllers need to be put on the base, my guess is so that it can determine which one will be used for the left and the right, to apply the appropriate control scheme.

This actually brings up something I realized last night that has been perplexing me - if the DSP doesn't directly modulate the signal, then the phase of the signal picked up by the receiving coils relative to what's transmitted can't be determined which would inherently create positional ambiguity in different regions of the sensing environment. Looking up various patents related to magnetic tracking shows that this is indeed an issue.

So either the Hydra's DSP directly modulates the signal (not too sure about this), or there's some other technique being used. If anyone has an O-scope and wants to probe the op amp outputs to get a close look at the waveform (probably need one with logging or capture and hold capability) we could see if there's anything useful embedded in the signal.

[MSat]

Also, they may use relative phase between coils in addition to relative amplitude. I suspect that is how they can determine 6 DOF instead of just 3 DOF.

Yep. The phase would need to be known. But how?

I've only used my hydra once, and I don't recall if a button had to be pushed on the controller. Does it? If so, then I suppose the difference in phase between the two controllers and knowing which one is used for the left and right could resolve ambiguity. Hmm...

[geekmaster]

If I get my controllers too close to the base, they sometimes swap, and then they move in the opposite direction onscreen, compared to how I moved them in RL... Getting them very close to the base again can swap them back like they should be...

[WiredEarp]

I'm pretty sure that the 'point trackers at the base' bit is just to determine what hemisphere they are operating in. The tracking tech returns equal results for both sides of the hemisphere, so it needs that calibration step in case people have moved a tracker into the other hemisphere. I don't think this has anything to do with detecting the synchronization (VRPN works fine without needing this step, just make sure the controllers are in the correct hemisphere when you start the drivers).

I think this step is also not required with the standard drivers if they are placed on the base when you start the drivers/application. I believe the metal bit in the handsets is detected (magnetically?) by the base, so it 'knows' which hemisphere they are in at that point, eliminating the need to do the detection check. Never thought it would change which is left and right, but I guess that would make sense.

[MSat]

Ok, this is interesting. Just checked the manual again, and it confirms what you guys say regarding initialization.

That's an interesting find, geekmaster. Does it only happen if both controllers are placed near the base? If so, then it sounds like the relative phase between each controller is used to prevent (but not eliminate) positional ambiguity, and that the DSP does not keep track of the generated waveform. But in that case, I can't figure out how setting the controllers on the base would be able to determine which one is left and right. There are no additional sensors in the base or controllers AFAIK.

So what about when using two Hydras? I'm guessing the controllers from the second unit would also need to be placed next to the base station that has its coils enabled. What kind of sucks about that is a modified controller to be used as a body tracker would need to also be initialized first before being worn.

[cms]

Ok, unfortunately it looks like I jumped the gun. My earlier experiment was me simply lucking out and getting aligned right. I've found that it isnt that unlikely to align with the base unit, but of course even when you do it does drift out of it (but can take minutes before it does).

Using vrpn I set it up so that I could press a button and reset the device easily. Unfortunately, it takes it a few seconds to come back and chances are higher that it wont be coming back aligned. You can repeat this a number of times until you do get aligned, but again, it will drift out of that within a few minutes. I've tried reseting them both as simultaneously as I can (through software at least) but that of course doesnt help. The devices report back a sequence number (unsigned char) where each represents ~16.67 (1000/60) ms. With that, it may be possible to confirm alignment, but taking a number of seconds each time to try for it makes this impractical. *sigh*

The sixense sdk has a number of interesting pieces not directly exposed (like "ApplyCoilOffsetFilter"). I want to poke around a bit more.

I'm particularly curious about these:
sixenseGetRawData
sixenseGetRawDataSingle
sixenseGetSignalQuality
sixenseGetSignalMatrix
sixenseSetTestMode
sixenseGetTestMode
sixenseSendTestCommand

These are the filters that are setup on initialization (sixenseInit):

SigMatFilter
ConvertCoordSysFromPolhemusFilter (Polhemus, interesting...)
CheckForDockedControllersFilter
TrackHemiFilter
DeSawtoothFilter
MovingAverageFilter
ComputeMatrixFromQuatFilter
NormalizeJoystickFilter
ControllerEnabledStatusFilter
ComputeStatsFilter
SetRangeLEDFilter
ApplyCoilOffsetFilter
SleepTimerFilter (this calls getTimeInMilliseconds from sixenseUtils, then sixenseSendTestCommand)

Hopefully there is some way I can force the sync through software.

[geekmaster]

Ok, unfortunately it looks like I jumped the gun. My earlier experiment was me simply lucking out and getting aligned right. I've found that it isnt that unlikely to align with the base unit, but of course even when you do it does drift out of it (but can take minutes before it does). ...

Can you genlock the clocks in the bases, forcing them to stay in sync? If so, your experiment may still work (but would require a clock timing connection between the multiple base units).

[MSat]

Ah, well that's too bad.

There are some interesting function in there. DeSawtoothFilter? Does that mean the base station coils are driven with a sawtooth wave?

[OzOnE2k10]

I'm trying to figure out the protocol between the handset and the base, and thought I might as well post the progress here...

It appears to be a fairly simple async protocol (as expected, only TX and RX wires).
The bit width (time between two of the narrow rising edges) is 16uS, so I guess that gives a baud rate of 62,500?

Here's a quick grab from the analyser.
I wouldn't take too much notice of the actual decoded data, as I don't think it's correct yet...
The "black" channel is TX from base to handset, the "brown" channel is the RX response.



The data looks a little bit like I2C (active low, with a possible address byte at the start).
I2C normally has a clock line and is bidirectional though, so it's probably just standard async serial but we don't know the number of bits etc.

I don't think the Hydra was actually tracking when this capture was taken, but it was pulsing the transmit coils etc.
If we could figure out this serial protocol, it would be simple enough to use a small AVR chip to spoof the joystick / buttons and make a smaller custom tracker module and allow the Windoze drivers / SDK to work.

Also, I've traced the pinouts of the handset / base connector(s)...

Base unit handset port pinout...

1. +3V3
2. RH TX (FROM handset)
3. RH RX (TO handset)
4. LH TX (FROM handset)
5. LH RX (TO handset)
6. RH /EN
7. LH /EN
8. RH coil sig
9. RH coil sig
10. RH coil sig
11. LH coil sig
12. LH coil sig
13. LH coil sig
14. GND

I haven't opened the the Left-hand handset yet, so it's /EN,TX,RX,coil pinouts are implied.
(Pins 11,12,13 are definitely the LH coil signals though.)

EDIT: Might as well list the Handset plug pinouts (long cable) separately for clarity...
NOTE: Ground / shield is connected inside the handsets with a separate wire.
Please be aware though that the wire colours in your Hydra may differ.

1. /EN (Green)
2. Coil sig (Blue)
3. Coil sig (Orange)
4. Coil sig (Purp)
5. TX (Brown, TO base)
6. RX (Yellow, FROM base)
7. +3V3 (Red)


The oscillator for the transmit coils in the base appears to be free running at ~18KHz.
As discussed previously, the osc is running all the time and is switched between the three transmit coils by the mux.

Anyway, plenty more fun to be had.
I might try some custom transmit coils soon.

[MSat]

UART, eh? A little surprised.

We're you able to capture the waveform generated by the free running osc?

Keep us posted with your reverse engineering