I’ve been pulling together the parts to build a VR headset for less than 100 quid. This isn’t as easy as you might think. In order to achieve it, I’m using a VR Box to provide the headset and lenses which isn’t bad. For the screen and accelerometers I managed to pick up a HTC One M8 for £60 which was an absolute bargain. With this set up, the google goggles demos run very well. The 1080p screen on the HTC One M8 is perfect for the display. The grill between pixels is minimal compared to the Oculus DK2. It’s still not as good as an oculus in terms of accelerometer lag and lens quality, but it is significantly cheaper.
I spent some time reading this instructables now I’m all set to try out Kinoni with the headset.
In order to extend it’s abilities I’m adding IR reflectors to the headset to allow head tracking with a camera. The tracking would have to be based on brightest spots with an IR source and scotchlite reflectors. I can only really get x/y working for head tracking on a single standard desktop HD cam. This is due to the distance between the reflective spots on the headset being too small to estimate depth. By adding a second camera it would be easier to calculate the headset’s relative 3D position in space. If you were going to add a second camera, would it make sense to use a Kinect instead?
If you’ve read any of my previous posts on the topic I’m trying to get OOK, FSK and potentially PPM (Differential Pulse Position Modulation) working in the Linux kernel with the HopeRF RFM12B adapter. This is mostly for ARM SBC/SoC type situations like the RaspberryPi or beaglebone.
The intention here is to allow you to easily intercept, and transmit consumer wireless signals on the 434/868 MHz bands. There are existing ways to do this. However they all appear to depend on the Jeenode or at least an atmega chip running JeeLib.
I want to remove the dependency on the atmega, and yet still exploit the RFM12B to provide OOK/FSK transmission. Right now I’m adapting the existing RFM12B-Linux module to allow sending and receiving OOK signals, I’m also adding in the code to interact with specific defined devices. So far my thoughts are that it shouldn’t be too hard to have drivers for multiple devices in the module.
I thought best to do a link dump of everything that is currently important to this endeavour;
After merging someone else’s OOK sending efforts. I’m not too sure that listening for OOK and FSK is really important. After all an SDR can happily listen across the frequencies and decode the signals.
I unfortunately get very little time to work on this, or other projects on this blog but try to keep it updated with my experiments from time to time. Once I have my Salus under control I plan to release the branch on github. Until then I get a little time here and there to experiment. My latest outcomes have been hampered by insufficient power to my Pi3. There have also been some issues with transmitting on the 868 band.