1. Enable unsupported time machine devices. In the Mac terminal type:
   defaults write com.apple.systempreferences TMShowUnsupportedNetworkVolumes 1
2. Enable “Computer Backups” on the Stora through the web interface – this is an option in preferences. Select a password and set the changes through “Submit”
3. Mount the share in finder by going to Finder -> Go -> Connect to Server. Use smb://ComputersBackup@Stora/ComputersBackup
4. Enter the password (username should be ComputersBackup)
5. Open up a terminal and create a “sparsebundle” image locally by following the steps below:
   1. In a local directory run:
      hdiutil create -library SPUD -size $SIZESPEC -fs HFS+ -type SPARSEBUNDLE $MACHINENAME_$MAC_ADDRESS.sparsebundle
      where $SIZESPEC is the size (in bytes, or suffixed with g or t for Gigabytes and Terabytes – note you can resize it later, but you can’t make it bigger than the space on your HD. $MACHINENAME is the ‘name’ of your machine and $MAC_ADDRESS is the mac address (seen in Network Preferences) in the form aabbccddeeff (i.e. no colons!).
   2. Copy it to your network drive by typing
      cp -r $MACHINENAME_$MAC_ADDRESS.sparsebundle /Volumes/ComputersBackup\$/
      you can now delete the local .sparsebundle file
   3. Resize to the size of backup you want by running the following command on the network mount:
      hdiutil resize -size $SIZEg $MACHINENAME_$MAC_ADDRESS.sparsebundle
      where $SIZE is the size in GB (note the g after the size number
   4. Load up time machine and select the ComputersBackup mount for backup. It should now detect the image and start backing up to it, using only the size of image that you have created (e.g. 200GB, rather than filling the entire drive!)
6. Pat yourself on the back get a cup of tea which it backs up and wonder why it wasn’t easier!

The Board

The system comes shipped as a bare board – so I need to get some self adhesive rubber feet for it really – I will also keep my eye out for a potential case as well.

The main components is a Xilinx Spartan FPGA. The whole thing is based on the SUMP FPGA base logic analyser – so no big surprises that this is the main work horse!

It also has a Microchip 18F24 which looks like it is handling the USB interface.

The board also has several non-populated through hole headers which are for PIC ICSP, FPGA JTAG and some kind of expansion pins (as well as a set of four labelled TRG1 CK1 TRG0 and CK0). There is also a populated set of ROM ISP headers and what looks like some UART pin headers.

Alongside all this we have a number of indicator LEDs for ARM, Trigger, Power and USB Activity. Also some buttons for update and reset actions.

At the end of the board we have the analyser bus. This has a GND connection at both ends and 16 signals available for connecting flying leads to. The signals are fed into a LCX16245 – which is a low voltage bidirectional buffer (so in theory the FPGA could drive the the signals out if you wanted to re-purpose the board!)

Anyway, for more detailed information on the project see the Gadget Factory page – this has the user guide, schematics, board design and software on it as well as installation videos and a video tutorial on UART analysis (something I will be trying soon!).

Installation

Once I had dug out a USB A to Mini-B cable and downloaded the software I was set to go. I had tried getting it to run on Linux (Ubuntu 10.04), but I gave up after about 20 minutes of fiddling and getting nowhere and decided to revert to good old windows XP – so if anyone has any easy to follow instructions on that one let me know!

After extracting the archives I plugged in the device, at which point windows requests a driver. Find the inf folder from the OpenLogic binaries archive, select that and the correct driver will be installed. This creates a virtual COM port. The number of the COM port can be found in the Device Manager (it is the one with Manufacturer = “Microchip Technology, Inc.” and Location = “Location 0 (CDC RS-232 Emulation Demo)”).

Once this is installed run the OB_Logic_Sniffer.exe file and you get the client.

Select Device -> Capture and you get the Capture setup menu. This enables you to setup triggers, sampling rate and recording size.

Testing

To test it I grabbed my XMOS XC-3 and connected 8 of the the lines to the GPIO port (XS1_PORT_8C on Core 0). I wrote a simple XC program to simply count up in a sequence continuously in a loop at 25Mhz. Here is the setup I used for testing.

After fiddling around wondering why Bank 1 wasn’t working, I enabled all the banks and discovered that the signals were on bank 3 (channels 16 -24). I have no idea why this is… but hey ho. It is working and the output is below.

Conclusion

Overall this has the all the makings of a strong tool. It is very affordable @ $45 shipped (available from Seeed Studio) and 16/32 channels of logic analyser @ 100MSPS is certainly not to be sniffed at.

Quality of the software is one of the most important things in a logic analyser as without good analysis software they are a waste of time. The Logic Sniffer doesn’t disappoint in this area- It has the capabilities to do simple single trigger or a complex 4 stage triggering and the analyser Java based client is easy and intuitive to use. While basic in the professional logic analyser world they are pretty good for most peoples needs. Extension of the triggering modes would be well worth the development time. Also simple improvements such as the ability to type in Hex values would be nice, rather than having to build a trigger mask with tick boxes.

Alongside the triggering features is the systems ability to analyse SPI, I2C and UART signals. Expanding this protocol analysis is something that should be actively worked on, though it has a good base (these features will hopefully be subject to another review at a later date).

However, the project in its entirety is currently it is a little rough around the edges. A couple of pointers for simple improvements would be:

• an integrated installer – especially the windows stuff. It’s a small point, but they aren’t hard to make and it makes the whole software installation process a lot less painful (rather than downloading two zips and having to extract them!)
• a simpler firmware upgrade process ( i.e. more integrated PC side software) – the current one looks fairly daunting (even for someone like me who is a relatively experienced user of embedded hardware).

Over all, as an open source hacking tool, I would give this project 8/10, a few minor improvements would push it up. Open source hardware like this can be functionally good, but is often let down by the lack of polish in the user experience.

MikroElektronika EasydsPIC4 Development Kit / Board for Microchip PIC devices

Included in this sale -

• EasydsPIC4 Development kit/board
• USB cable (board is USB powered)
• ‘Easy Connect’ expander
• 2 x 16 Character LCD (white on blue)
• DIP devices -
  • 2 x dsPIC30F4013 30I/P
  • 3 x 16F818 I/P
  • 3 x 16F872 I/SP
  • 2 x 16F72 I/SP
  • 1 x 16F84A 04/P

This board is in excellent condition and was used only for a short project I was involved with – new this board retails at $129.

It is a comprehensive development kit/board that allows simple development of Microchip PIC applications across a variety of devices.

It has everything you need for almost any project – character display, RS232 level shift/connector, ADC Vref, expansion ports, LEDs, keypad, integrated debug and programming.

More pictures and specific information (including manual and documentation downloads) can be found at here

SOLD Microchip In Circuit Debugger (ICD 2)
Summary -

• 1 x Microchip ICD 2 device
• 1 x USB Cable
• 1 x Standard ‘phone’ ICD connection cable

This item is in excellent condition.

The bottom left circles show my hard disk usage (top circles) and my network rx/tx. The ones above that show CPU0 and CPU1 and also RAM usage.

The big one in the middle is a clock that ticks round with seconds, minutes, hours, day, month working from the outside in.

It’s quite a nice funky addition to my desktop. I like it!

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!!

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!

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!

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

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!

1) Laser Cutter

Not massively complex in terms of software – but a pretty cool outcome. UART in – granite engravings out! Nice… Maybe an ethernet interface with a web client to upload images into it could come next… laser engraver source code here

2) Aquatic Bot Explorer (ABE)

The main purpose of the project it’s to create an autonomus vehicle to explore lakes and reefs. Aquatic Bot Explorer (ABE) its based on a ROV (Remotely Operated underwater Vehicles ) and AUV (Autonomus Underwater Vehicles ) class robots.
This bot it’s powered by an XK-1 processor by XMOS, several boards for sensing: pressure, temperature, depth, etc. Motor control, demux, ADC, etc. are developed.

Looks pretty cool… can’t wait to see what it turns up from the depths!