“The UML stencil for Microsoft Visio supports all symbols of the UML 2.2, specified in OMG UML Superstructure Specification, formal/2009-02-02, as well as all previous versions, UML 2.1, UML 2.0, UML 1.5, UML 1.4, UML 1.3 and UML 1.1.“

I am SO glad that I forked out the extra $’s to get the AUS/US power adapter with the surge protector… Thank you very f*cking much Jackson!!! I should have know better and sent the power through my real surge protector as well. Thankfully all of my equipment attached to my Powersmart board didn’t even shut down.

Two days of relatively solid work to get the build process working, I had just successfully deployed my OS image to the device for the first time and I am never going to see if it actually bloody worked!

I have put too much effort into this in the last few weeks to walk away. I will get on to the competition organisers and see what my options are from here.

Time to get serious about the core code for the Control System (which, incidentally, is what I will largely be assessed on).

Before I can start developing in anger, I will need an IDE and tool chain to build the Windows CE OS for the device that I won. Being a novice with CE, I’m not too proud to RTFM. The manual provided with the hardware from the competition is very comprehensive and well written. A few pages in, I am confronted with the following:

Recommended Software Installation Sequence.
It’s important to install the software in their proper sequences. Here is the recommended software installation sequence, in numeric order.

1. Visual Studio 2005
2. Visual Studio 2005 SP1
3. Visual Studio 2005 SP1 update for Vista
4. Windows Embedded CE 6.0 <– this wasn’t a “next, next…” install, there was a custom step to select the x86 BSP for my device (I missed that the first time and had to return to here and reinstall everything down the line! )
   
5. Windows Embedded CE 6.0 SP1
6. Windows Embedded CE 6.0 R2
7. Windows Embedded CE 6.0 R3    <– this wasn’t included in the SPARK your Imagination kit supplied by MS. No biggie, except that I live in the sticks and get 75kB/sec download speed…
8. Windows Embedded CE 6.0 R3 Update Rollup    <– this was omitted from the instructions that came with my embedded device
   
9. ICOP_VDX6326_60B_BSP.msi
10. VDX6326_WINCE600_SDK.msi
11. CoreCon_v200_x86_WinCE600.msi
12. AutoLaunch_v200_x86_WinCE600.msi
13. RegFlushApp_v100_x86_WinCE600.msi

Long story short: 1.5 days later, I have the OS building successfully.I do have 12 warning(s). But hey, if they were serious they’d make them error(s).

Thankfully, now that this is sorted, it is not something that I will likely have to go through again in a hurry. I am thinking about building a virtual instance of a Win 7 machine solely for developing in CE so that I don’t have to have Visual Studio 2005 living along side VS 2008+.

The hardware to build a quadrature encoder is pretty simple. For the sensors, you need a couple of photo-interrupters and something to do some very lightweight logic and timing calculations (in my case the Arduino). The encoder is a slotted disk, with equal length and spacing of “light” and “dark”, which rotates through the slot of the photo-interrupters (I will post the circuit that I used in a follow-up). The photo-interrupters need to be spaced at a quarter of a wavelength (1 wavelength = the total length of one light and dark section of the slotted disk.)

For my proof of concept, I bread-boarded the components and used a piece of card, cut to mimic the slotted disk.

High-Tech Encoder Simulator

Spaghetti

The Logic

Below is a table and sequential images showing the sensor outputs. Note that the reference sensor is the left one. (The phase number printed on the card when aligned with this sensor corresponds to the phase in the table.)

Phase	Sensor A	Sensor B	Image
1	0	0
2	0	1
3	1	1
4	1	0
1	0	0
2	0	1
etc…	etc…	etc…	*Mongkut

By only looking at the outputs each time Sensor A changes state, we can tell which direction the encoder is travelling.

If we step through the table rows above, when the state of Sensor A changes from 0 to 1 (phase 2 –> 3), the sensor values are both 1. When Sensor A changes from 1 to 0 (phase 4 –> 1), the values are 0 and 0.

Forward Direction

If we now go from bottom to top. When the state of Sensor A changes from 0 to 1 (phase 1 –> 4), the sensor values are 1 and 0. When the state of Sensor A changes from 1 to 0 (phase 3 –> 2), the sensor values are 0 and 1.

Reverse Direction

In simpler terms: when Sensor A is triggered, if both of the sensor outputs are the same, our encoder is travelling forward; if the sensor outputs are different, the encoder is travelling in the reverse direction.

Give or take a negation, this is the exact behaviour of the exclusive disjunction (or exclusive or ; “XOR”) logical connective.

Restructured to look more similar to my sensor output table:

So, this very long-winded look at the sensor outputs and comparison to the “XOR” logic table gives us the following pseudo-code:

When Sensor A changes

if Sensor A XOR Sensor B then

direction = reverse

else

direction = forward

All that’s left to do is to time how long between interrupts on Sensor A; count the number of notches on your disk and calculate RPM to give you the shaft speed. Easy!

I will do another post shortly with the Arduino specifics and code. (TODO: insert link here)

NB: The forward and reverse directions of the encoder, the reference sensor and the logical states represented in each phase are entirely arbitrary. I am sure many examples will have made different assumptions around these conditions and will therefore show variations of the output tables etc. The concepts remain the same, it’s just the detail that changes.

One of my feeds recently popped up a post on a competition run by the Microsoft embedded group to develop a Windows CE device with a project that encompasses their theme of “Fun and Games.”

The format of the comp is:

• Round 1 - Write a three page proposal for your project idea.

• Round 2 - With the hardware you won for getting through Round 1, build out the proof of concept in around 8 weeks and submit a video of the working prototype and your design documentation.

• Round 3 - Once it’s sunk in that you’re going to present in a keynote at a conference in Silicon Valley and the happy dancing has ceased; start to prepare your notes (with associated freaking out, of course!) At this stage you’re also looking at a pocket-full of cash and the respect and adulation of adoring fans! (okay, the pocket-full of cash at least…)

I already had an idea that had been simmering for a while, that fitted the theme really well and this seemed like the opportunity to see if anyone else thought it a worthwhile pursuit.

Well, someone liked it and I’m through to Round 2. The dev kit that’s core to the project is on it’s way from the US of A at this very moment.

I decided to get a bit of a jump start and have spent the last week or so madly building out the micro-controller and sensor parts. Things are actually going way better than expected and and I will blog about some of the adventures with Arduino, XBee and other assortments, shortly.

I can’t wait to start tying all the disparate pieces together. (Nor can my wife, who commented this morning on the “bomb” of electronics components and scribbled notes that had gone off in the study.)