VR headset for under a hundred quid

geeek-vr-box-virtual-reality-glasses-3d-brilI’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?

RFM12B Linux Kernel Module development

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.RFM12B

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.

 

Ennio Wifi Doorbell: The saga continues.

ennio cameraI managed to get around to playing with the Ennio wifi doorbell a little more, trying to figure out how all of it works. It seems I have to learn a few things about UDP, however with a quick and dirty tcpdump on my openwrt router (which I was hacking in other ways earlier) to an NFS share on my RAID I managed to collect a chunk of worthwhile data while my phone interacted with the camera.

Capture results

As far as I can tell without capturing all of the data of all of the interactions it goes something like this:

  • Phone sends a broadcast request of some kind and the doorbell responds with a packet with it’s name to the UDP port specified by the initial contact.
  • The phone logs into the device using the username and password provided by doing by sending a hex encoded ASCII string, with some preamble bytes:

Continue reading →

Ennio Doorbell internal teardown

Here are the results of taking apart the Ennio wifi doorbell. I haven’t had a chance to dump the memory from this device yet, but I received a request to take some photos of the internals. Here are those photos;
Ennio memory chip Ennio camera module Ennio main board reverse side Ennio SoC module Ennio SoC module reverse side. Ennio internals unhooked

 

 

 

 

 

 

 

 

 

 

The SoC is a RaLink RT5350, the data sheet for the chip can be found here. I guess some of the pins on the wide connector are for programming the memory chip (JTAG). I just need to work out which ones.

I’m looking for memory dump options, at first I wanted to mount my NFS server onto the device and dump to a file there, however that won’t work due to NFS being missing from the device. The other option is to dump it to telnet using base64 encoding, then decode it on the other side… This would be less than ideal but still possible. I need to boot the device up again to figure out what to do next.

Setting up a cross compile toolchain to build new binaries might be the best option for getting what I need out of this thing. Although I doubt the source code for the IPCam will be available to me.

The most important thing for me to do is to disable the wifi hardware. Once disabled it’s safe to actually put the hardware on the wall outside. I will likely need to take it down at some point, if I intend to flash the memory. I still wouldn’t recommend buying an Ennio wifi doorbell, or any of the variations out there. The failure point is the OS which is a black box of obscurity over security. I would love to have the time to develop a better open-source OS to run on these things which would work on foscam, wansview and others too. Like OpenWRT but for IPCams.

Hacking the Ennio Wifi Doorbell

ennio cameraI recently purchased a Ennio Wifi Doorbell in order to have a doorbell, and also have an outdoor front of house security camera. It seemed like pretty much the only option available.

The camera is fairly easy to set up in the way it was intended. Install an app from the app store, and pair it (with magic, or zeroconf/bonjour) with your phone.

When the button is pushed a push notification arrives on your phone, I’m not quite sure how this happens yet but I’ll dig further. The camera sends a photo with the push notification and also allows streaming of video from the camera.

As far as I can tell both of these things work over 3G as well as Wifi flawlessly with a horrifying app UI.

First things first, is it secure?

With this thing going on the front of my house I want to know if it’s possible to break into it or in some other way use it to break into my network.

The short answer, this device is about as secure as a wet paper bag with a block of gold in it. This, although a major downside from a consumer perspective, leaves many open opportunities for the hardware hacker. Continue reading →

io_export_diffmap & MetaMorph: Resurrecting a dead project.

It seems that the original author of io_export_diffmap for Blender and MetaMorph for Unity has killed the original website and various scant ramblings on forums have led me to discover that it is essentially an orphaned project now. I’ve decided to take it on, update it to blender 2.74 and start work on porting the javascript to C# for Unity5. My work is stored over at github as usual. Continue reading →

Update: ESP8266 WiFi server complete (enough)…

Photo 01-05-2015 16 19 46So a new Arduino arrived today after the connectors gave out on my older ones. It’s a cheap UNO clone and will be followed by a selection of Nano’s for various coming projects. I added support to my ESP8266 project for lightsOn, lightsOff, and setting a value for the lights on. Which can be found in the github repo. The server responds with a simple JSON string explaining the current state of the light, and can be adjusted by sending particular HTTP requests. Continue reading →

Kernel hacking for the RFM12B

RFM12BI’ve been busying myself with fixing up and adapting the RFM12B Linux driver. My first thought was simply to give people support for sending and listening for OOK signals as an extension, then taking the device support in the rtl_433 decoder to extend RFM12B driver to include lots of OOK device support for things like weather stations and energy monitors.

JeeLib already does most of this work on Arduino so for the most part this is simply a matter of joining lots and lots of code together from different places and making sure it sits right. I’ve decided that in order to do this it would probably be better to re-write the driver while trying to fix some of the original driver’s TODO list along the way.

The driver will loosely allow :-

  • Compatibility with the original RFM12B driver & original JeeLib compatibility.
  • Send OOK, FSK messages to devices.
  • Listen for OOK, FSK messages from devices.
  • Set tuning to a specific frequency.

Continue reading →

Fitted Salus RT800RF

Fitted the Salus RT500RF today, this wasn’t such a difficult job but I did blow two fuses following bad advice. The wiring of my Vaillant Turbomax doesn’t require bridging the COM and Live as suggested in many online videos, nor do I need to add a LOAD resistor between pins 4 and 5 on the boiler.

RT500RF to VaillantHere’s a simple diagram to demonstrate how to connect the Salus RT500RF to a Vaillant. Now simply when pins 3 & 4 of the Vaillant are bridged they will start the boiler up. An optional pipe thermostat to switch the boiler off if the pipe overheats can be inserted in between pins 3 on the Vaillant and N/O on the Salus RT500RF.

Now I’m getting ready to start sniffing the airwaves with my SDR and my RFM12B to see what I can do. All I really want is to set/get the current state of the boiler.

[auction-affiliate tool=”lister”]

Upgrades… Salus RT500RF 868MHz wireless boiler control

RT500RFI’ve just received a Salus RT500RF in the post. I’m pretty much all prepared to hack this thing, at first I’ll sniff the airwaves with the RTL-SDR and try and get a handle on how it works. There’s been at least one blog article regarding this unit so I’ll also have a dig around them and see what they can tell me too. The idea is to get the Raspberry Pi with the 868MHz RFM12B to send a signal to turn the heating system on/off, and if possible, interrogate the current state of the boiler.

This will be the first stage in smartening up the house. The OWL CM160 and the Salus RT500RF are the first devices that I’m going to mess with as they’re the most useful to me right away. Next I’ll be turning my hand to Oregon Scientific weather sensors, Wireless door bells and other hardware on the 433/868 bands. These bands of course are used in Europe and some other locations, the equivalent is 315/915 for the US. So if you’re following my work then make sure you pick up the right bands for your location. It’s always best to buy radio transmitters and receivers in your own country because the likelihood of anything being on sale which isn’t allowed is reduced.

[auction-affiliate tool=”lister”]