A post on hackaday alerted me to google power meter and them releasing their new powermeter API. This looks pretty cool- especially for my energy monitoring project!

Taking a look at the more detailed information it looks like Google have some pretty interesting requirements for devices:

• Have to be able to do HTTPS (so need SSL)
• Have to have a webserver on the device (for configuration etc)

SSL is going to be the biggest challenge if we choose to go down this route. Once we have SSL the rest should be pretty easy. The concern with the SSL is the size of the stack and whether one can be implemented and fitted on an XMOS core.

Thankfully Google provide some libraries for the power meter implementation of their API which might go a long way to providing an initial solution - again this is going to need to be ported to whichever TCP/IP stack is used and what SSL stack is used. The current C implementation is specifically tailored for Microchip PIC libraries... so to work I guess!!

Share/Bookmark

So, now I hopefully(!) have my cable which will give me access to the UART RX of the CC128 energy monitor. Time to try it out and begin processing some data with it!

Firstly, I go to the XMOS website and get the UART code and play around with it to create the UART code I want (RX only at the moment), compile it and give it a run.

But it's never that simple! All I get are null characters. Odd I think - so I recheck the wiring, recheck the code. All seems to be ok.

So I strip down the code to a really simple function- one that just receives a character and prints it out (see the Super Simple UART receive function source file)

I still get null characters - maybe I got the wrong pins? Check again... nope, seems fine. So I decide its time to void the warranty (follow these CC128 teardown instructions at your own risk!).

Turns out there is a bit of solder between a via into the ground plane and the UART TX pin on the RJ45 connector (pin 8). After removing this I connected the XC-3 back up to the device and wah lah- it gives me the first character (a '<') of the XML data string.

Now to get the whole string out - so off I go to re-implement the more complex UART code.

After some battling I got it running!

The output looks like the following is in line with the CC128 XML documentation.

Next time... parse the XML and output to somewhere a little more useful!

Share/Bookmark

The "Thats the warranty gone..." aka as a 'teardown' post!

With the UART TX not working properly I was forced to open it up... so here is a bit of analysis and some photos of what is inside for the curious!

The device is pretty easy to open up - there are 3 clips down each  side of the plastic case. Once those are popped out the front of the unit comes away with the board firmly attached to it. Above is the photo of the board after opening it initially.

This shows a PIC microcontroller (18F85J90) . There is also a receiver module on the board - most likely a ZigBee unit (Current Cost have a Zigbee logo on their website!) . Apart from that there is just the power regulator (a tiny thing on next to the power plug).

It is also interesting to  note that there is a set of footprints that are unpopulated that look like they should be for a transmitter (the big clue is the ANT pad!). This might be the same zigbee configuration, but made up of discrete components as the circuit layout (particularly the LC filter arrangement connected to the antenna!) are remarkably similar. Also, the box is marked RX1 as is the Zigbee module. Maybe this is done as a cost reduction option if the separate modules weren't cheap enough or available?

The rest of the IC's look like memory - so nothing too exciting there.

So to the other side of the board is basically componentless - apart from the LED and the contacts for the display (massive IO hog!) and the buttons.

What I did confirm is that the following pins are connected on the RJ45 (there are some others, but I couldn't be bothered to put the effort in at this stage to get the data sheet out for the PIC and work out where they were going!):

• pin 1 is the unregulated +3V from the power unit
• pin 4 goes into the GND plane
• pins 7 and 8 are RX and TX

What was particularly annoying was the solder bridge (blob really!) I located between pin 8 and the via near it. This explained the 0's I was getting on my data line!

Share/Bookmark

My energy monitor arrived today! It's working well - I was slightly worried about how good the reception would be for the transmitter, but I am pleasantly surprised that even with the receiver 3 floors above the transmitter it seems to register a good signal.

But that's boring - time to start hacking!

So, first thing I need is the interface cable. The back of the unit has a handy RJ45 connector that has serial in it (see my initial energy monitoring post). This needs connecting to my XC-3 kit so that I can begin to get the data out of it. So time to get the soldering iron out!

So, initially all I need are two wires from the RJ45 network cable (standard network wiring configuration)-

• Brown = the UART transmit (from the energy monitor)
• Blue = ground

I soldered the rest of them onto the strip board in case I wish to use them later and it keeps things neat and tidy.

For the moment I am using the the GPIO port on the XC-3, using pin 1 for a 1 bit port (XCore UART RX) and pin 16 is ground. This should give a good base from which to work. Eventually I would like to put it on the LED connectors to keep the GPIO free. The other bonus of using the LED connector is that the output side is buffered up to 5V which is what the UART on the energy monitor needs - though I think I will have a check of the Microchip PIC they use inside and see if it will take 3.3V logic levels.

Next time... getting data into the XC-3

Share/Bookmark

Was at a friends today and he showed me an energy monitor that he had bought and was using to monitor his electricity supply. I was like "hmm... this could be something fun to attach to an XCore and get some graphs out of".

My thought is to use my XC-3 (or maybe get an XC-2) to connect to an energy monitor receiver - or hack/make a receiver and then push the data somewhere useful via Ethernet. In fact I could combine it with my network monitor, ditch the screen and have it push the all the different types of data out into some nice pretty graphs. Anyway, enough brain dump - onto the hardware!

My proposal is to use a Current Cost Envi (CC128) device. There is a helpful CC128 write up from dale lane. It has several nice features:

1. The receiver has a RS232 output
2. The receiver outputs XML from the RS232
3. The system has support for up to 9 individual appliance monitoring (IAMs)

Some thoughts on software/graphing features:

• Display a comprehensive history (device can output real-time, or 2hr block data)
• Calculate some averages (particularly for time of day, month, season)
• Plot electricity use vs. temperature? - the relationship should be pretty obvious... but I like pretty graphs
• Plot the electricity generation stats and calculate my carbon footprint (ooh err!) - see Amee

Could even add some X10 stuff in there to... the possibilities are endless - watch this space!

Update: CC128 connector pinout- looks like you might be able to reprogram the internal PIC as well!

Share/Bookmark

The XMOS XS-1 architecture is a multi-threaded architecture. As opposed to normal systems it has a single processor core that can run 8 hardware threads, in real-time with no operating system overhead. But what happens if you run out of threads... 2 answers: either (1) add more cores or (2) virtualize.

So I thought I would do option (2) as option (1) is too easy in the XMOS architecture and its not very efficient if I want to run 1MIPs processes on a thread that has 50MIPs available. The code for this is freely available from the virtual threads sourceforge page.

More information after the break...

The base of the system is simple context switching within a single thread - this allows multiple processes to be run on a single thread. The current implementation has only time-slicing for processes and doesn't currently have any way to handle events, ports or channels in a sensible way. Hopefully this soft of thing will be implemented when I spend some more time on the project.

The tricky things to handle are those which I haven't implemented yet... The risk of deadlocking the whole lot of virtual threads is quite high when working with events or waiting for external stimulus. Essentially a carefully implemented library would have to be used to stop this, but still provide the level of functionality you get using the hardware threads.

Its probably fairly safe to assert that the virtual threads will not ever be able to be as functional as the hardware threads.

So, a summary of current features:

• Able to start an arbitrary number of virtual threads
• Simple time sliced context switching of virtual threads
• Ability to disable the interrupt for atomic operation

Future features:

• Context switch on external stimulus
• Context switch on demand (so a virtual thread can "release" itself from the current hardware thread)
• Implementation of access to events, channel comms, hardware
• Call to allocate stack space to vthread
• More flexible vthread params (ports, chans, etc)

Share/Bookmark

This is the initial release of the embedded traffic monitor which I implemented on an XMOS XC-3 development kit. It has a 256x32 VFD attached to it with a custom board that was designed from another application (hence the buttons/IR sensor you'll notice if you are observant). Full source code is available from the embedded traffic monitor sourceforge page.

More information and pictures after the break...

The basic premise of the system is that data comes in and then goes out the other side (to general traffic the device looks like a wire) and information about that traffic collected on its way through (so at the moment it just looks at packet byte length). The data is then aggregated appropriately with the throughput being averaged over a second (sample at an interval of 100mS).

The information as well as being displayed on screen (via a simple I2C bus) is stored to an SPI flash once every 10s. This is so that if power is lost then the logged data is not.

Current Feature Summary:

• Dual MII ethernet interface
• I2C VFD for showing the resulting information
• Saving of data to on-board SPI flash memory

Future features:

• Internal switch for custom applications (so you can access the device over IP)
• A web interface to allow a user to reset stored data and maybe produce a SVG graph?
• Change display for lower cost, lower power OLED? (Farnell order code: 1498842)

And some pictures:

XC-3 Network Monitor and Display

Network Monitor Display showing a graph and data rates

Share/Bookmark