Oculus VR, makers of the very cool Oculus Rift VR display, are making their first steps towards open hardware. Their first project is a latency tester, meant to precisely measure the latency of a VR setup or application. This is true open hardware with everything – the firmware, schematics, and mechanical parts all available on GitHub
Inside this neat bit of hardware is a STM32F102 microcontroller and a TCS3414 color sensor. The firmware is designed to measure changes in color and send that data back to a computer with a timestamp.
Not only are the schematics and board files available, there are also a few links to buy the PCBs at OSH Park: for about $24, you can get three copies of the main PCB and sensor board delivered to your door. If you have a 3D printer, Oculus has provided the .STL files to print out the enclosure for this device.
While this is a fairly niche product, we’re amazed at how well the Oculus folk have put together this open source hardware project. Everything you need to replicate this product, from board files, mechanical design, firmware, and instructions on how to build everything is just right there, sitting it a GitHub. Wonderful work.
18 thoughts on “Oculus Releases Open Source Hardware”
Looks like the processor is and stm32f102
perfect example of how companies can use open source.
this thing has no sale value for them. it’s not their product, but a tool to test the real product. so it has use value, but no sale value.
open sourcing it means they get feedback and patches form the open source community, lowering their maintenance cost and increasing stability + the positive PR.
this is straight out of esr’s bazaar.
well done oculus.
I hate STM32s with passion. Awful library, broken compilers, hardware bugs. No thanks, I will stick with my good old (and proven) ATmega 8.
same here, many problems i have had with the STM32s. Maybe it was just a bad bach but i also switched. I stick to the 18f4550 now.
That’s like complaining that more things can go wrong with a Ferrari than a push bike.
Is GCC for ARM broken?
Support for and implementation of peripherals is the big difference between the different manufacturers of parts containing the same ARM core, and those are the most important factors for a successful design.
No, it’s not broken. “broken compiler” is what you hear when people are groping for a rational explanation for their unsolved issues. There are thousands of products out there with working STM32 guts. This is what happens when you try to push the envelope but you are too cheap to pay for the engineering assistance that your project deserves.
So F, are you per chance a F35 JSF engineer?
ST sells to professional organizations that have substantial financial resources at their disposal. Their support and documentation is designed for paying corporate customers, not individuals working on pet projects. Frankly ST is not interested in the hobbyist market, and they have no problems leaving you to twist in the wind if you are not willing to pay for premium support. They have plenty of customers that are willing to play their way, you can look at ST’s financials to see that this style of business is working out well for them.
If you can get your STM32 design to work without their help, bully for you, but you are not doing it the right way, and there is no guarantee that your design will continue to work unless you are “in the loop” with their engineers.
Sounds like a good enough reason to not use them if you ask me. Especially when there are plenty of other players out there with more open support and tools.
I’ve ported long ago my own OS (Miosix: http://miosix.org) to the stm32, and it’s been working for years on many different chips (stm32f1, f2, f4) without any help from their engineers.
The peripherals are more versatile and thus more complex to configure than those found on AVR and PICs, so if you’re coming from that world there is a learning curve, but it’s well worth it.
Also, don’t use their “peripheral library”. It’s meant to save your time but in the end you’ll spend more time with respect to accessing the peripherla registers directly. The datasheets are well written, much more than the documentation for their peripheral library.
fede.tft: Interesting, will have to check that out.
I’ve been using libopencm3 with the STM32s in a limited way, and no complaints. Never bothered with ST’s peripheral library, heard lots of comments it was rubbish, and libopencm3 looked pretty clean to me.
I also don’t mind ST’s documentation. Definitely a little more hairy than Atmel’s, but it’s a much hairier chip.
What other Cortex M3 chips with such good peripheral sets are available, but have better documentation? I’d be interested in any suggestions.
So basically, what F is saying is that their documentation is so crap and their hardware so quirky that you’re a fool to try and use STM32 hardware unless you’re paying them enough to have dedicated support from their engineers to explain how the hardware actually works, and that any design created without having one of their engineers in the loop at all times is at risk of failing spectacularly in the field. Sounds like a good reason to go with one of their competitors then; I’ll bear that in mind.
F, it’s kind of retarded to say that ST doesn’t care about the hobbyist market when they’ve done more than any other uC manufacturer to make their products available to hobbyists.
Remember their $2 dev boards?
Who else makes an ARM prototyping platform like the STM32F4Discovery for less than the price of an Arduino?
Not having previously really bothering to research much about the Oculus hardware, I ended up reading a 312 *page* thread about adapting MIPI-DSI LCDs to accept HDMI input for use in a Rift, and I learned *alot* about the Rift. I was actually researching the interface they were discussing, because such an interface could be used to convert an HDMI signal into a MIPI-CSI signal that could be connected to the camera input interface on a Raspi, allowing the Raspi to hardware compress an HDMI signal.
They did end up developing a working hardware interface that, having been programmed with the right parameters, should work perfectly to allow a Raspi to capture or stream .264 HD content from an HDMI source…
I researched the same subject few monts ago :o :)
HDMI is a clock master
mipi-dsi display driving source (video out on a cellphone pcb for example) is also the clock master
mipi-dsi camera sink is ALSO the clock master = camera interface on the Rasppi is clocking the camera, not the other way around
You end up with hdmi source that has its own clock, and camera in interface that also has its own clock, Rasppi is all blackbox when it comes to DSI, broadcom doenst let you tweak clocks = you will end up with clock jitter at the very best, clock missmatch at the worse
you could buffer one full frame on the fpga in between, but with clock missmatch (rasppi clocking camera at 59Hz for example) you will end up with dropped frames and crap all around
I really liked the idea of turning rasppi into cheapest hardware h.264 HDMI capture interface, but it wont work without low level access to DSI side of things, and that wont happen with broadcom at the helm :(
BUT accepts ONLY useless long broken RC4 crypto and RSA!!!, they dont even support Diffiehelman, basically they redirect you to UNSECURED “secured” version for show and PCI compliance.
whats fascinating is
supports ALL current secure AES/diffiehelman implementations
WTF? were they compromised and some hacked reconfigured part of the website dealing with financial information to weaken security to the point of easily broken?
How much does the whole thing cost once put together?
Is there any reason to build one when you can simply buy consumer level 1000fps Casio camera
you put a LED in front of the camera facing the display, you blink that led same moment new frame starts, you capture at 1000fps. No need for custom hardware.
This is how a dude at blurbusters does it
Please be kind and respectful to help make the comments section excellent. (Comment Policy)