Sharpley.org.uk

KWakeOnLan 0.2 !

Wed, 16 Dec 2009 22:59:13 EST

Today I got a patch for a piece of software I released almost a year back and had totally forgotten about

The patch adds support for setting the broadcast address in KWakeOnLan so that it is possible to make it work over a VPN or potentially any internet connection.

It's the first time I've had someone submit a patch for a piece of software that I'd written exclusively till that point, and it feels really good - it shows people are using your software enough to want to edit it

So thanks to Sebastian Kloska I present KWakeOnLan 0.2 + (a few interface tweaks by me)

Hooking up a Microcontroller to HomeEasy home automation devices.

Tue, 24 Nov 2009 00:07:01 EST

...and making an awesome alarm clock

Rencently I bought two wireless light bulb switches. The package consists of a bulb holder and a seperate switch. The switch sends a low power signal over the radio waves to turn the light on and off. It allows me to have an extra lightswitch in my room without my landlord going 'mental.

However, having a simple switch is quite dull...

By hooking up a microcontroller on my Arduino to communicate on the same radio waves, suddenly the possibilites are a bit more interesting. Below is a circuit diagram, and a photo of the prototype setup on a breadboard.

Parts

An Arduino (a prototype board featuring an ATMega328 microcontroller
A 433.92 Mhz transmitter (and receiver for reverse engineering the protocol in the first place)

The photo on the right looks more complicated because it also shows the receiver connected

Code

There was existing work in the Arduino commmunity playground here. with a demo transmitter. I tidied up the code and have re-released it as a re-usable class for various projects. My new class is available in the wiki.

If anyone wants a full description of how the protocol works, drop me an email.

The project I built

Using the microcontroller to control the light bulb I decided I would two two things:

Make an alarm clock
Add a web front-end

The plan for the alarm clock was to make a device to turn my main light on a few minutes before the conventional alarm on my phone wakes me up. Waking up to a pre-lit room is considerably less miserable in the winter months.

The latter was a result of my bizarre desire to add a web front end to any electrical device I see, it also serves as a convenient mechanism to set the clock and times for the alarm. Without this I would have had to spend ages connected buttons, an LCD and the whole thing would take up more space.

The web frontend comes in two parts. Some code that sits on my PC hosting pretty images and CSS, and a very small web server written in C on the Arduino which performs all the actions.

The web server code is pretty lightweight, and has a pretty robust platform for parsing the requested URL. Is a good reference if you are building your own web projects.

Downloads

The Arduino code, PHP front end proxy, and a small python script to sync the alarm clock to PC time.

Future

The next immediate plan is to rebuild the entire circuit from scratch on some stripboard, using a bare ATMega328 and get my Arduino back for more development.

Make use of interrupts, and sleep the processor to save power

Move all the webserver code onto the microcontroller.

I would also like to make the alarm slighlty more complicated - and perhaps parse a vcal feed to know when to turn on...which in 1K of RAM will be a challenge.

Add in some kind of photoresitor to the mix.

Building a high resolution digital oscilliscope with an Arduino

Tue, 03 Nov 2009 00:00:00 EST

About

A common task in most home electrical engineering projects is to reverse engineer a signal from a device. This could be an IR receiver, a serial connection or in my case a radio receiver. What is needed is a way to record this signal and send the data to a computer so it can be analysed for patterns and eventually decoded.

Whilst specialised hardware does exist, or obscure hacks using the soundcard for input, I didn't fancy doing that.

In essence what is required is the following:

loop
{
  wait for pin to change
  {}
  send the time of this event to the serial port
}

The problem with this is that sending data to the serial port is a very slow operation, the RF signals I was trying to capture were alternating high and low with gaps of around 200 microseconds. The processor will take a while to send data out to the serial port and osciallations get missed.

The solution I found was to buffer the data, and then send the data and then send this data to the serial port once a reasnoble sample had been collected. This provided enough data to analyse without missing any gaps. The ATMega has a data storage area of 1Kb, given an int takes two bytes we can have an array of the pulse length of 450 of these oscillations. The output is a list of the time the processor with the pin low, followed by the time the pin was high, then back to low and so forth.

Another problem that had to be avoided was noise. Particularly dealing with AM radio signals small blips would appear in my data. Whilst most engineers would solve this was clever hardware, I'm a code hacker and decided to filter this into my code. Any pulse of data under 20 microseconds is treated as noise. That pulse is thrown away and it acts as though the previous pulse never ended.

Code

Without further waffling, here is the code I used:

boolean currentState = LOW;
unsigned long timeStart;   
unsigned int times[450];   
unsigned int index = 0;    

void setup() // run once, when the sketch starts
{                                                                  
     pinMode(12, INPUT);                                           
     Serial.begin(9600);                                           
     timeStart = micros();                                         
}                                                                  

void loop() // run over and over again
{                                     
  while(digitalRead(12) == currentState) //wait for state change
  {}                                                            
                                                                                                                              
  //make it wait for the next type of state change next run     
  if (currentState)                                             
  {                                                             
    currentState = LOW;                                         
  }                                                             
  else                                                          
  {
     currentState = HIGH;
  }

  unsigned long duration = micros() - timeStart;

  if ( duration > 20 || index == 0)
  {
    times[index] = duration;
    timeStart = micros();
    index++;
  }
  else
  {
    //the last pulse was really tiny, probably just noise. That means we should just revert the add we did last time, and pretend it never happened
    //next pulse change replaces the last recorded entry (entry before this one)
    index--;
    //set timeStart back to the time the pulse without noise started
    timeStart = micros() - times[index] - duration;
  }

  //if we're out of storage space send all the data. 
  if(index >=450)
  {
     printResult();
  }
}

void printResult(void)
{
  for(unsigned int i = 0 ; i < index ; i++)
  {
    Serial.println(times[i]);
  }
  index = 0;
}

Proposed new KDE toolbar configuration

Thu, 10 Sep 2009 22:13:12 EST

The current tool bar system in KDE is a bit dated, the window is filled with lots of buttons, and reordering items isn't all that intuitive. It's not all that 'user friendly'.

The existing toolbar configuration

My suggestion

I've made a working prototype of a new click and drag solution. Essentially it's a very similar toolbar configuration scheme to that of Firefox. A lot of the code required already existed in KToolBar, it just wasn't being used. This demo only really has changed to the toolbar editing dialog. If this is accepted by kde-usability people, I'll try tidying it all up, ready to be a patch to show to the kdelibs guys.

Below is a screencast showing my prototype mockup:

Ogg vorbis video

Source code

Combined KDE Title bars and menu bars - an implementation

Tue, 25 Aug 2009 20:53:00 EST

There has a been a few suggestions (and one of the highest ratest KDE brainstorm ideas) of merging the window decorations and the window title into a single bar. The current system that we are used to has a lot of unnecessary white space particularly vertical pixels which is a problem for tiny factor notebooks.

Below is a mockup from someone on the KDE forums

The proplem that exists is that the window decorations are drawn by the window manager KWin, wheras the menu bar is drawn by the owning application.

The proposed solution:

Application exports the menu to kwin via DBUS
Kwin renders the menu
When the user clicks a menu, it sends a DBUS call back to the application
The application then renders the drop down menu in the appropriate position on screen

This is clearly very messy, and sucks. A lot.

The alternative

There is another approach, which I've not seen anyone else discuss:

The application draws both the menu and window decorations itself
Application forwards movement of title to window manager

To me this seems a much cleaner solution, the idea of window managers needing to draw the coloured bar at the top of an application seems to be a very legacy decision and there doesn't seem to be any reason for it. It's a bit controversial, but I think it's a step in a good direction. It even allows the user to use a different window manager and keep the combined window titles.

My code

Anyway, I drafted up up a bodge to one of the KDE tutorial windows to show the idea in action. It allows people to see if combined menu and toolbars is good from a usability point of view and to try to overcome some of the UI problems it poses (such as where to now put the window title!) however the idea gets implemented in the future, if people decide it is a good idea.

My implementation has a few issues:

It looks very fugly, though there's no reason why it wouldn't look identical to the existing oxygen theme if I spent some time on it and shared the same rendering code
There are no window frames.. because I forgot about them. This is actually more of an issue.
I can't decide where to put the window title, this is more of an issue with the concept of combining the two bars rather than an implementation issue.
There is also talk of people wanting tabs combined with the window title..we can't put all 3 there!

A real version of this technique would involve changing KMainWindow so all applications inherit this ability without further code changes.

It also would only take a minor modification and we can copy a feature I've seen whilst running spotify under Wine of allowing the user to move a window by dragging from any whitespace in the toolbar.

Without further ado. Here is a screenshot, and a link to the source. No modifications to KWin are needed!

Source tarball

Disabling screensaver in DragonPlayer

Fri, 21 Aug 2009 07:34:31 EST

After getting a whopping 100 votes on KDE brainstorm I finally got round to sorting the screensaver disabling in Dragon Player.

The patch is now in backports so should make it to the next KDE4.3 release

Package Kio now in PPA

Sun, 16 Aug 2009 07:36:06 EST

After following a tutorial on #kubuntu-devel I finally got round to packaging my first piece of software instead of just uploading a source tarball and making users do all the work. ;-)

My PPA is available at ppa.launchpad.net/david.edmundson/ppa/

Start of a blog

Fri, 14 Aug 2009 16:34:42 EST

I finally got round to keeping a blog, and actually listing some of the work on KDE I'm doing. I tend to just come up with my own set of patches and applications which sit on my desktop gathering metaphorical dust.

I've been encouraged to start a blog and actually share some of this stuff with people who might be interested and to try and make stuff more available, by making debian packages instead of just releasing source dumps.