Raspberry Pi B+ launched

In stock now at CPC / Farnell / RS

Cases from Pimoroni.

I already have both on order.  For me the advantages are

  • 4 USB ports – no need for a USB hub for keyboard, mouse, WiFi dongle + A.N.Other
  • reduced power usage
  • all GPIO pins now exposed
  • Better audio quality and 4-point jack for compsite video
  • Better connector layout
  • micro-SD card, so no sticky-outy bits

First thing I’ll be doing is replacing my GeneralPi and disposing of the USB hub – a much tidier desktop with fewer wires.


Scary Mug Shot

Scary Mug Shot

I went to the Raspberry Pi Jam in Cambridge yesterday, and really enjoyed it.  Lots of interesting presentations, lots of kit for sale, interesting projects to chat with people about and a nice relaxed atmosphere.  If you have a Jam near you and haven’t been to one yet, go along and have a look.  I really enjoyed it!

If you were there, and didn’t spot me, here’s a scary mug shot for next time!


Happy New Year to one and all

Just a little thanks to all you tolerant readers out there.

In September 2012, this site had 3 unique visitors, using 28MB bandwidth – and one of those would have been me!

In December 2013, this site has 6666 unique visitors, using a 4.97GB bandwidth.

That’s not far off a 200 times increase in traffic across the year since I started the site and the projects.  From that, I take it there must be something useful here that you like or have benefited from, which pleases me greatly – thank you all!

Off topic: blog housekeeping

Just in case any of you are tracking the dronepi category, or the old SkySpy name for Phoebe, I’m doing some tidying up.  A drone is a generic name for any autonomous vehicle, but the terminology has been more focussed recently being used commonly for autonomous flying machines for spying or bombing; a drone covers so much more than that.  Phoebe is cute and innocent and shouldn’t be tarred with that brush.

At the project conception, I had that in mind, and called it SkySpy, but that was just too generic, and prone to typos.

I’d considered using QuadcopterPi in the past also, but it’s too long; others agree as they are generally referred to as QCs.  So as of now, I’m tidying up the blog to use QCPi as the project category, and as best I can, I’ll bring the wording in the text in line.

That also then allows a short name for the Quadcopter Remote / Radio Control project: QCRCPi.

I know, it’s a bit OCD, but that’s part of being a geek!

Super duper WiFi dongles

I have a range of WiFi dongles I use with my various RPi projects, which I thought I’d share as my choices have evolved as my requirements got more refined.

First off is the Edimax Nano dongle – an absolute cracker – tiny, yet supports soft AP (WAP).  The only reason I moved on from here is the drone needs 360 degrees line of sight meaning I wanted a dongle with antenna to achieve better reach and signal strength.

That led me to these Edimax EW-7612UAn V2 dongles.  They support soft AP (WAP) although I didn’t have that requirement yet.  They worked great, until I realized that when in flight, even with the antenna, the signal would be poor due to its position on the drone blocking line of sight to the controller.  It also suffered during the couple of gravel crashes the drone took.  So I needed a detachable antenna that I could attach between the drones legs.

Which brought me to the EDUP range – my first purchase was the EP-MS150N.  A cracking dongle with a small body, small USB connector, 150m range and detatchable antenna allowing for a separate wired antenna.  Lovely jubbly – except they seemed to vanish from Amazon and ebay shortly after I found them (partly my fault), and they don’t support soft AP / WAP.  So when I came to setting up my test WAP, these didn’t work.

On the plus side that did lead me to the EDUP site and to the EP-MS15003 – a cracking dongle – like the MS150N but double the range and with soft AP support.  But unavailable outside of China / HongKong – shame.

Which finally led me to the EDUP EP-MS1537 – also 300m range, soft AP support, and available on ebay (from HongKong), so I ordered a couple and they’re on there way now  from China.

But I’m impatient, and liked the white colouring of the EP-MS15003, it’s smaller size and cropped USB plug, so carried on grubbing around on google and found these guys in Hong Kong stocking the EP-MS15003, and offering DHL delivery at a sensible price meaning delivery within a week rather than a month.  Sorted!

One week later, it’s arrived and installed and running the drone WAP like a dream.

P.S. All the above dongles use the Realtek chipset, so, where soft AP is supported, can be used as a WAP using these instructions if you need a bridge to the internet, or mine, if you want your WAP to be in a completely isolated secure network like I want for the drone.

Blog membership disabled…

Just a quick note to the few of you who are genuine members of this site that the majority of the 130 members are scammers.  Rather than spending a few minutes mocking and then deleting their attempt to post something pointless on my site, I’m just going to delete them all.

My apologies in advance if I accidentally delete you as a valid and valued member – please let me know if I do.

This should in no way affect anyone’s ability to post comments which I will continue to moderate.

No Hesitation, Repetition or Deviation

Although neither the drone nor alarm pi projects are even phase 1 complete (phase 1 for the drone is safe automaton takeoff, hover and land, and for the alarm is independent alarm control), I’m strongly considering moving from the RPi.GPIO library to the RPIO library for a number of reasons:

  • RPIO interrupts can be used to wake socket.select() calls, whereas RPi.GPIO runs a separate thread which can only wake a socket.select() on the make thread by sending a SIGINT – functional but ugly
  • RPIO supports hardware PWM across any GPIO port whereas currently, I use I2C to connect to a PWN breakout chipset

While using the RPi.GPIO works fine, RPIO just feels better. So once phase 1 of both projects are complete, I’m going to add phase 1.5 which is the switchover to RPIO (or perhaps merge the best of both).

In passing, I’m also considering moving over to PiPi once it’s available in the Wheezy distro – the drone is running full speed currently with no sleeps. Moving to PiPi means I can start introducing time.sleep() as the precursor to TCP socket inputs via socket.select(). Currently the space in the CPU cycles from using interpreted Python is feeling a bit small to stably introduce remote control.