On the bottom you see the aluminum enclosure, on top you see the sensor cables/clips. You can use those to easily clamp onto anywhere in an electronics circuit.
There’s not a lot more to tell about the enclosure itself, there’s a micro USB connector to connect the device to your computer.. and that’s it. Here’s a picture of the PCB:

Some specifications of this logic analyzer (taken from manufacturers website):

• open source hardware and software
• low cost
• supports existing softwares like the Salae, USBee and Sigrok
• small
• easy to customize

Let’s hook it up!
I am testing the Saleae logic analyzer software, because it looks like the nicest analyzer software of the three supported software products.
You can’t use the Saleae software from the Saleae website because they prevented the use of cloned logic analyzers. Robomotic provides a local copy of the software.

Saleae claims the cloned logic analyzers are counterfeit, I totally disagree. It’s just a hardware design based on a certain micro controller.
There’s no way Saleae has the exclusive right to this hardware. I do agree that they have the right to protect their software though, and that’s what they are doing right now.

The software installation is pretty easy, it’s basically a next->next->finish job. Please note that .NET framework 3.5 is required.
After the you start the software the logic analyzer is immediately recognized by the Saleae software. Now I had to hook it up to something, I choose the serial console port from the Belkin home base.. remember that one from previous posts ? :-)
A logic analyzer is a very nice device to analyze asynchronous serial communication. I hooked up these three pins: RX (input 2), TX (input 1) and ground (input 3).
Here’s a picture of my setup:

Do you notice the little analyzer clips on the board?
In the Saleae software you have to pick a sample rate and sample frequency. I chose the following, which are more then enough for the boot log of the Belkin home base:

And here’s the result:

Input 1 shows the TX pin of the Belkin home base, the boot messages. Works like a charm!

Conclusion
The BugLogic is a very good value for money (around €40,- including shipping!) logic analyzer. It utilizes a lot of existing logic analyzing software around.
Furthermore it’s very compact in size. There’s just two minor points of improvement if you ask me:

• The cable clips are a bit cheap quality, some were actually broken on arrival. There’s 10 clips so more then enough anyway.
• Pin 1 is not clearly marked on the enclosure so I had to open it to figure out.

This concludes this product review. Would you like a professional review of your product as well? Please contact me using my contact form.

Please note that flashing custom firmware’s can wreck your device! I am pretty confident of doing this, I have done it several times in the past with other devices. Another reason which makes me just do it, is that I have serial console access. So, there must be some way to unbrick this device.

After looking around in the firmware structure I found a startup file (in preinstall/etc/rc.d/rc.S) with the following content:

# serial login
DEBUGMODE=`sxromconf -c GET_DEBUG`
if [ "${DEBUGMODE}" = "on" ]; then
  /sbin/getty -L ttyS0 115200 vt100 &
else
  echo "Serial login always is disabled by DEBUGMODE setting!"
fi

Aha! Now that looks familiar, it’s the code preventing us to login to the console.
I changed the code to the following:

/sbin/getty -L ttyS0 115200 vt100 &

After that I compiled the new firmware, and restarted the device. Does it work?

Belkin Home Base serial login

Success! Now we can continue to find the RX pin, just connect a test wire to the USB-BUB TX pin and randomly test the pins. After a few attempts I found out that pin 3 is the RX pin.
Now let’s try to login, and check our privileges:

Belkin Home Base root privileges

So there you have it! Full root access on the Belkin Home Base. Time to celebrate, cheers!

Let’s continue with the scope option though. Here’s a picture of my setup:

DSO Nano connected to the Home Base.

The ground clip from my scope is connected to another ground point I found using the continuity tester function, remember last post? The test clip from my scope is connected to one of the pins on the header. Hey, what are those waves on the scope display ?!

Houston, we’ve got signal!

The waves we got is serial communication from the Belkin Home Base right to our scope! It actually took me 5 restarts of the Home Base. Pin 5 is our TX pin.
To locate our last pin (RX) we will first have to connect our Belkin Home Base to our PC. I use a USB-BUB for this. Any other FTDI cable will most likely be ok, i’ve also seen people use old telephone data cables for this purpose.

Here’s the USB-BUB with the Belkin Home Base TX pin connected to the BUB’s RX pin:

Great, so does it work? After fiddling around a bit with the baudrate/parity settings etc. I came up with the following settings:

Baudrate: 115200
Data bits: 8
Stop bits: 1
Partiy: Off

Here’s the result:

After it finished booting, I noticed the following:

Crap! It doesn’t allow us to login, so there is no way to test for the RX pin :-(
Normally I would just connect it to random pins and check if I can “type” to the serial console, unfortunately that’s not an option for this device.
To be continued…

- RX pin, the receiving pin as seen by the device (in this case the data the Belkin receives from the PC)
- TX pin, the transmitting pin as seen by the device (in this case the data send from the Belkin to the PC)
- GND pin, the ground connection between the device and the PC.
- 3.3V/5V pin, a constant power supply.. in most cases this is not needed. But you could use it to power a MAX232 chip.

The first step is to visually look at the board, most serial connection headers are 4-6 pins. Do you remember the 6 pin header I described in the previous blog post?

So, this is going to be our target. The second step in the process is to find the ground (GND) connection of the serial port header. To do this I prefer to use a multimeter (with continuity tester functionality), the continuity test function looks like this:

Continuity tester

The test will beep and/or visually indicate whether two electrical connections are connected to one another. Knowing that the continuity tester function can do this, it’s rather easy to find the ground connection. You need a reference pin for the ground connection (I used the dc-jack ground connection) and then test each pins of the header on at the time.

Searching for ground!

Aha! Pin 6 is the ground connection.

Now that we found the ground connection we can proceed to the next step, which is finding the VCC (+) connection. Usually this is 3.3v or 5v. For this step we use the multimeter once again, but now on the dc-voltage setting. Something in the range of 5-20v should be good:

Multimeter for dc voltage measurement

Leave the ground clip connected to the same reference point as we used in the previous step. Now touch each of the pins on the header to check for a voltage, looks like I found something:

Found the 3.3v (+) connection!

So pin 1 is the 3.3v connection. This post will continue later on for the sake of readability. In that future post we will figure out the TX (Transmit) and RX (Receive) pins.

After playing around a bit with (works just fine!) I decided to open it.. why? Just because I can :-)
Opening this things was a piece of cake, just mind that there is a Torx T7 screw in the right bottom corner. It’s hidden underneath the information label:

Here are some pictures of the board itself:

Frontside of the Home Base PCB.

Backside of the Home Base PCB.

There are two interesting headers on the board (1×6 pin and 1x2x7 pin), I will play around with them a bit later on (in fact, I already did.. I’ll just save that for a later blog post..):

To be continued..

This means node 1 and 2 are in use, another example:

0000 1011

This would indicate node 4, 2 and 1 being used. So, how do we figure this out from code? This is where bitwise AND comes into play. A bitwise AND takes two binary representations of equal length and performs the logical AND operation on each pair of corresponding bits. In each pair, the result is 1 if the first bit is 1 AND the second bit is 1. Otherwise, the result is 0.
We can use this from our python code in the following matter:

    length = ord(response[7]) - 1
    index = 1

    for i in range(0, length):
        buffer_index = response[8+i]
        num = 1
        j = 0

        while j <= 7:
            if (ord(buffer_index) & num > 0):
                print "node exists!", index
            else:
                print "node does not exist", index

            index = index+1

            if j < 7:
                num = num * 2 

            j = j+1

And does it work?

Looks fine!

After playing around a bit with a demo Homeseer license to test whether the stick and module worked (setup was really easy), I quickly switched over to my ‘bits and bytes view’..
Here’s a log of the Aeon-Labs stick initializing:

The yellow text is the command that get’s transmitted from the PC to the controller. This article will focus just on the sending command (my first starting point with python and z-wave)
So let’s have a look at the basics, these are the 5 bytes that get send to the controller: #01#03#00#02#FE
Let’s translate these bytes to bits (a lot of people still seem to have trouble to distinct between the two of them):

01 = 0000 0001
03 = 0000 0011
00 = 0000 0000
02 = 0000 0010
FE = 1111 1110

From some z-wave documentation publicly available, I figured out that the checksum is the last byte of the command. In most documents they referred to the checksum as a CRC checksum, I actually think it’s an LRC (Longitudinal Redundancy Check). A LRC is computed by XOR all the byte values of the packet together. XOR stands for a bitwise eXclusive OR. A bitwise exclusive or takes two bit patterns of equal length and performs the logical XOR operation on each pair of corresponding bits. The result in each position is 1 if the two bits are different, and 0 if they are the same. For example:

    0101
XOR 0011
  = 0110

So how does our calculation look at bit level? (remember that we skip the first byte):

00000011 (03) XOR 00000000 (00) = 00000011 (03) (Nothing happens on this operation)
00000011 (03) XOR 00000010 (02) = 00000001 (01) (See how one + one is 0 here?)

So the outcome is 01.. hmm, not quite the LRC value we’d expected. We expected ‘FE’ (last byte in our command). This is because the LRC calculation z-wave uses starts with a starter value, which is “FF” or 1111 1111. So let’s try our calculation again, now with three steps:

11111111 (FF) XOR 00000011 (03) = 11111100 (FC) (Note the last two bits as a result of our XOR operation)
11111100 (FC) XOR 00000000 (00) = 11111100 (FC) (Nothing happens on this operation)
11111100 (FC) XOR 00000010 (02) = 11111110 (FE) (Aha! There’s our value!)

So, there we go.. through some calculations we figured out the checksum algorithm that z-wave uses. This is an important first step in understanding the protocol.
Now for the python part, here’s the code I used to test the checksum:

def generateChecksum(message):
    lrc = 0xFF
    for b in message:
        lrc ^= ord(b)
    message += chr(lrc)
    return message

testmessage = "\x03\x00\x02"
generateChecksum(testmessage)

And this is me, testing the code :-)

In this post I will explain how to connect a serial console to your Linksys WRT320N router!

Remember the solder pads from the last post? Here’s a closeup image:

The pads are labeled, it’s a serial connection. Connecting only the RX/TX signals and the GND signal is sufficient.
Please note that you need a logic level converter (such as a max232, or telephone datacables) to convert the signal.

Now that we have a possibility to connect to the console of the router, we can all sorts of cool stuff. Including interrupting the bootloader to flash a new firmware image!
Here’s a boot log of the router with a dd-wrt (big) image:


CFE version 1.0.37 for BCM947XX (32bit,SP,LE)
Build Date: Fri Jul 24 07:15:00 EDT 2009 (root@Raymond.Lai)
Copyright (C) 2000,2001,2002,2003 Broadcom Corporation.

Fortunately I could wrap around it with a little regular screwdriver (didn’t have any security torx driver handy, who does anyway?)
Here’s a picture of the case from the inside (note the three, damn small antenna’s):

Here’s a picture of the hardware board:

But wait.. what’s the soldered wire down the bottom left? [teaser]We will talk about that in the next blog post :-)[/teaser]

Introduction

In the Plugwise protocol unleashed series, I will describe the plugwise protocol. As far as I have been able to re-engineer it. I did this re-engineering work because there is no Linux/OSX software available to control your plugwise devices. All information in these series are based on the 2.0 firmware version!

DISCLAIMER: use of the information in these articles is at your own risk.
This information is not supported by Plugwise B.V. in any way.

So what is plugwise anyway?

Plugwise is a smart way of measuring power usage using a device called the Circle.
It’s basically a plug between your device and the power socket.
The device can be used to keep track of the following:

- Current power usage;
- historic power usage, using buffers in the device itself;
- you can also use it to power on/power off a device;
- you can also use it as standby killer (using a schema).

For more information visit: http://www.plugwise.com

General information

Before we can dive deep into the plugwise protocol, we are first going through some basics of the protocol in part one of this series.
Plugwise uses the zigbee protocol to communicatie over the air.
Once all of your devices have been setup using Plugwise source (the default Plugwise software) you can control your devices using the plugwise stick (this is a little USB stick)

Image 1: the plugwise stick

To send commands to the Plugwise stick, plugwise uses a serial communication protocol.
Actually the Plugwise stick has a FTDI FT232 UART aboard. The following information shows up when plugged into a Linux machine:

Bus 006 Device 003: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC

The serial communication takes place with the following settings:

• Baud rate: 115200
• Data bits: 8
• Stop bits: 1
• Parity: none

Plugwise data packet

The Plugwise data packet looks like this:

Image 2: the Plugwise protocol frame.

The start frame must be sent before sending any other data, the hexadecimal presentation of the start frame looks like this:

\x05\x05\x03\x03

The data formats varies, an example might look like this:

0017000D6F0000236XXX01

This actually is an example of the power change command (switch a device on or off, in this case a device on command)
0017 is the command, 00D6F0000236XXX the mac address and 01 the power code (power on)

Followed by the data, is the CRC checksum.
The used CRC checksum by Plugwise is a CRC16 checksum (often reffered to as ymodem or zmodem), it has the following properties:

• Polynomial: 0×11021
• Seed value: 0×00000
• Xor mask: 0×00000
• Width: 16

The checksum is generated over the data piece of the packet.
Last part of the packet is the end frame, this is basically a control feed followed by a linefeed. Which looks the following way, in hexadecimal:

\x0d\x0a

This concludes the first part of the Plugwise protocol unleashed series. If you have any specific protocol questions, please leave them in the comments so I can talk about it in the next part of this serie.