Detecting a wireless door bell on Arduino & Raspberry Pi

My front door is an enclosed PVC 5 bolt super secure door with reinforced frame.  To get a doorbell on this door I chose to employ a wireless solution, rather than drill through all of that.  The bell button is pretty simple and it is stuck to the frame with a bit of sticky velcro.

Out of interest, I recently decided to rig up a system to record the number of times the door bell is rung during the day; when there is no-one at home.  Especially useful, if the postman says he’s called but I really don’t think he has.  It can also send me an email so that if I’m not far away I can pop back to see who is waiting for me.  A bit of If This Then That communication to my phone.


RF Receiver Module

First thing I did, was buy an RF Receiver (and Transmitter).  The receiver I got has  XY-MK-5V written on the back of it. It is a RF receiver that can cope with 433Mhz.  This is written on the inside of the bell button, so I knew the transmitter in the bell ought to be compatible.


Arduino & Raspberry Pi

Connecting the receiver to an Arduino or Raspberry Pi simply requires the data line to be connected to an input on either device and setting up some code which will read data from that line.  The output from the receiver is a high frequency data stream that must be read quickly.


rc-switch

https://code.google.com/p/rc-switch/wiki/HowTo_Send

On Arduino and the Raspberry Pi there is a library available for detecting the incoming data stream.  All reports suggested to me that it would ‘work-out-the-box’ but I spent a few fruitless hours trying to get it to work.  In the end, I stepped back through all the code and compared the data that I was getting.

For the module I have, XY-MK-5V, the longest unchanging stream of data was 4800 microseconds.  The code for rc-switch, expects the longest stream to be greater than 5000 microseconds; after which it will start parsing the stream of data to get a code.

So on both the Raspberry Pi and the Arduino; the code for rc-switch would never hit the point where it would start decoding.  Thus it would never give me a response.

By altering the two instances of ‘5000’ inside RCSwitch::handleInterrupt() to read ‘4500’, I got the whole system to work.

I hope this helps other people that have had similar problems to me getting rc-switch, arduino and a 433Mhz receiver to work.

I still need to complete the rest of my doorbell project, but after hours of trying to detect the button being pressed, I’ll do that tomorrow!


Alternative using Analogue

http://arduinobasics.blogspot.co.uk/2014/06/433-mhz-rf-module-with-arduino-tutorial.html

Flappy Wormy

For the BackSpace workshop, I’ve created another worksheet which is slightly easier (I think) than the Gem Gem worksheet. It simply reuses the Wormy game, to produce a Flappy Bird style game in python.

Here is a link to the worksheet.

Gem Gem Saga

I’m giving a workshop at the Royal Leamington Spa Backspace event on Sunday 26th October. So that the attendees have something to try out I’ve created a worksheet which will turn Al Sweigart’s Gem Gem game into the much more exciting Gem Gem Saga !

Here is a link to that worksheet if you’d like to give it a go.

Drop me a comment if you find any mistakes with the worksheet and I’ll correct them.

Mobile Device Screen Sizes (Aspect Ratio and Resolution)

If you’ve ever tried to develop a product for a mobile device, now or way in the past, you should have come across a very common problem.  I have also come across this problem and I still find that I don’t have a very good solution.  While this is the case I thought I’d try to gather together useful posts from others that can help you to find your own solution.

So what is the problem?  Every screen that you try to draw stuff on will have a physical size and shape (usually rectangular), and a grid of coloured dots (pixels) that fill that space to give an image.  I’m ignoring orientation of said screen; and the colour depth of each pixel.

The physical size is measured in physical distances like centimeters (or inches), and the shape is given as a ratio (aspect ratio).

The number of pixels that fill that shape are simply counted along the long and short edges.

So to properly understand how big the screen is that you reading this blog on; you will need to know the physical size (21″ monitor), that is has a 16:9 aspect ratio with 1440 pixels along one side and 900 pixels along the other.  You could even measure the physical size of the screen as factor of the pixel density.  For example, you could say there are 72 pixels per inch.

Armed with this information and a selection of mobile phones you will find that there is no consistent numbers.

http://v-play.net/doc/vplay-different-screen-sizes/

V-Play’s blog post on how to cope with the different screen sizes shows more about this problem.

At the end of that blog, there are some very useful links to other solutions.

 

Jobs, old and new

I’ve not posted on here for almost a year. Lots has happened in the year. During my time at Blitz Games Studios I worked on Paper Titans for the iOS, which launched in May. Did okay for a few days! After that I worked on the tablet version of Ace of Spades for Jagex and that was pretty much ready to launch. However, Blitz Games Studios closed its doors after 20+ years and we were all (175) made redundant.

A lot of us managed to find work within a few weeks, and a lot are still looking. From the sound of it, staying in the industry and staying in Leamington has been difficult but I’d say 75-ish are still working close to Leamington. Many have had to move to Leeds, Newcastle, Cambridge, London, but many are working in neighbouring towns such as Warwick, Banbury, Coventry, and some as far as Oxford and Birmingham.

I was torn between technical management and technical development (programming) but I decided to focus on management from here on. Luckily I have managed to find a brilliant role with an old boss of mine, David Darling, in his mobile dev. company; Kwalee. There is plenty for me to do and I have made a big impact on the teams there. The feedback I’m getting is very positive and several iOS & Android games will be launching soon.

That’s it..

Danceionette using Unity Free

Danceionette – Yuletide Edition

My iPhone/iPad app has launched just in time for Christmas.
https://itunes.apple.com/gb/app/danceionette-yuletide-edition/id585033621?ls=1&mt=8

It’s also available for Android! https://play.google.com/store/apps/details?id=uk.co.everytale.danceionette_ye

I’m excited because this means I’m now officially famous! It was either that, or putting the game up in the post office window. I’m sure I’ll get about as many hits!

===

My dad came up with the idea of dancing marionettes after looking at the ragdoll physics with me in Unity. Then I tied it to a rhythm matching game with a Christmas theme. The whole thing is written using C# scripts in the Free version of Unity 3.5. Last March, Unity had an offer to get a free license for the mobile (iPad/Android) versions and I also had that.

Why a snowman, rather than Santa Claus? Well, I didn’t have time to create a lovely character in a 3D modelling package and a snowman is basically made of spheres.

Vector Graphics source at FreeGamer

Just stumbled upon this whilst reviewing some links for the Raspberry Pi user manual.

http://freegamer.blogspot.co.uk/2008/06/hex-tower-defence-and-java-vector-tools.html

I’ve not had time to delve deeper but looks interesting; if in Java!

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: