.NET Gadgeteer Core 2.42.700

The .NET Gadgeteer Core installer includes the core libraries and end user project templates for Microsoft .NET Gadgeteer. This is a prerequisite for end users to build and deploy .NET Gadgeteer projects. It includes a project template wizard in the New Project dialog in Visual Studio 2012 or 2010 (or express versions) under the Gadgeteer tab - ".NET Gadgeteer Application". This template uses a graphical designer built for Visual Studio which allows end users to visually configure .NET Gadgeteer hardware builds and then write the software logic for that hardware in C# or Visual Basic.

The .NET Gadgeteer Builder Templates installer is for hardware vendors who are building modules, mainboards or kits comprising multiple modules/mainboards. This adds additional project templates for modules, mainboards and kits. Each template includes instructions on how to use it, and automatically builds an MSI installer which can be distributed to end users.

If you are a prospective module or mainboard builder you should also look at the Module Builder's Guide and Mainboard Builder's Guide, which includes the full specifications for what it means to be ".NET Gadgeteer compatible" and other helpful examples and guidelines.

Neither installer includes libraries for specific hardware modules/mainboards, so by themselves these installers do not enable users to use .NET Gadgeteer hardware. Hardware manufacturers should release installers (based on the templates above) for their hardware.

================================================================
Microsoft .NET Gadgeteer Core
RELEASE NOTES
Version 2.42.700 19 April 2013
...

================================================================
Change Log
================================================================
Version 2.42.700, 19 April 2013
MAJOR CHANGES

• VS 2012 support (if using NETMF 4.3 SDK) added alongside VS 2010 support (using NETMF 4.2 or earlier) (When using VS 2012 you can target NETMF 4.2 or 4.1 devices too)
• Visual Studio Express 2012 for Windows Desktop support (and older 2010 Express version support maintained)
• Application template wizard which checks for compatibility between VS, NETMF SDK and mainboard
• Power consumption data is specifiable in GadgeteerHardware.xml schema and shown in VS designer

MINOR CHANGES

• Socket type D and H compatibility check fixed
• Managed software I2C (used by DaisyLink) uses repeated start condition when appropriate
• Added StorageDevice.DeleteDirectory method and fixed StorageDevice.Delete to delete files
• Text templates no longer used by designer, avoiding permissions warning
• License updated to clarify that VS extensions are binary-only

**** ALPHA SUPPORT *****
This release also includes alpha support for the following. This is for evaluation purposes only, and features may change.

• NETMF 4.3, with feature changes:
• AnalogOutput uses NETMF native support

...

And remember, the source for all of this, and even some 3D models, are available;

Here's a few of the past posts;

• Controlling a .NET Gadgeteer Device with your mind...
• Mind Control with C# (and the Emotiv and Emotiv Engine Client Library)
• It's as if it can read your mind...

Today we show off Antonio Blescia's work in his ThinkUino project.

ThinkUino Project

ThinkUino (Thinking Arduino) is an open source project that allows to connect the Arduino board with Mindwave headset. The cognitive application opens new frontiers for control the electronic circuits through  the reading of brainwaves. With this article I explain how to make a cognitive application for control a single LED light.

Mindwave... what is it?

Mindwave is an innovative headset produced by Neurosky. Mindwave converts the brainwaves into digital electronic signals. There are two version of this device:   

• Mindwave Headset: is the basic configuration of Mindwave. It can be connected only to pc for reading data only with Neurosky applications. Its color is white. You can buy it from this link: http://store-eu.neurosky.com/collections/hardware/products/mindwave-1
• Mindwave Mobile Headset: this version allow to connect with mobile device through bluetooth SPP communication. This device retrieves the brainwaves with more precision. This device, than, can be connected to Android and iOS operating system. Its color is black. You can buy it form this link: http://store-eu.neurosky.com/collections/hardware/products/mindwave-mobile

Mindwave... two versions, but which i should choose?

For the scope of this project the Mindwave Mobile is indispensable. That device supports the bluetooth connection, through the bluetooth connection it send the data in RAW mode to the connected devices. With the retrieved data we can parse the various frequency reading by the headset. 

What do I need to implement this project?

The fundamental elements to create this project are:  

1. Mindwave Mobile Headset 
2. Arduino 2009 or higher 
3. Led  

 

...

Best of all is the code is all C# and looks pretty simple (as must code does in hindsight

The device's price seems reasonable, the Brainwave Starter Kit is currently $99, it's developer tools are free and this project shows just a glimpse of how you can start turning it into the "Internet of [Mind] Things"...

So Philips recently introduced their Hue Connected Bulbs: an easy-to-use set of LED light bulbs and Wi-Fi connected bridge which allows you to dynamically change the color of your home lighting using their iOS or Android app. What’s particularly cool is that the bridge has a web API which you can access to set the colors of each bulb with your own app.

We at untitled network developed our own Philips Hue app called Oni: light Control, which is currently available on the Windows Phone Store. In addition to allowing you to set the color of your home lighting with defined “Moods”, the app also allows you to do the same using your phone’s built in voice commands or inexpensive NFC stickers. Here’s a demo of the Oni: Light Control in action:

I’m going to show you how you can develop your own app using the color picker from the Coding4Fun Toolkit for Windows Phone and the Json.Net library from Newtonsoft. These libraries can be found on NuGet, but you’ll obviously need the Philips Hue Connected Bulbs kit to test things out.

Getting Started:

The Philips Hue API uses a restful JSON interface you can access using any http client. Documentation on all of the supported methods by the Philips Hue bridge can be found at http://blog.ef.net/2012/11/02/philips-hue-api.html.

To get started, you’ll need authorized access to your bridge’s API. Once the bridge has successfully established a network connection with your router, discover its internal IP address via the URL: http://www.meethue.com/api/nupnp

You should get a response similar to:

[{"id":"ffss00fffe123456","internalipaddress":"192.168.1.100","macaddress":"0aa:bb:cc:dd:00:11"}]

Note the internalipaddress value and use the IP to access the bridge’s API directly the with the URL http://192.168.1.100/api

Now, since we haven’t registered a user for authorization, attempting to access the hub will return an error from the bridge:

[{"error":{"type":1,"address":"/","description":"unauthorized user"}}]

To register a new user, we’ll first POST the username we wish to use.

var client = new WebClient();
 
//our uri to perform registration
var uri = new Uri(string.Format("http://{0}/api", HostnameTextBox.Text));
 
//create our registration object, along with username and description
var reg = new
{
    username = UsernameTextBox.Text,
    devicetype = "Coding4Fun Hue Light Project"
};
 
var jsonObj = JsonConvert.SerializeObject(reg);
 
 
//decide what to do with the response we get back from the bridge
client.UploadStringCompleted += (o, args) =] Dispatcher.BeginInvoke(() =]
{
    try
    {
        ResponseTextBox.Text = args.Result;
    }
    catch (Exception ex)
    {
        ResponseTextBox.Text = ex.Message;
    }
});
 
//Invoke a POST to the bridge
client.UploadStringAsync(uri, jsonObj);

Note the response we get back from our hub will be

[{"error":{"type":101,"address":"","description":"link button not pressed"}}]

This is because bridge requires you to first push the link button before new registrations can be made. After pushing the button and invoking the registration function again, you should receive the following result from the bridge:

[{"success":{"username":"coding4fun"}}]

Setting the Bulb Color:

We should now be able to access all methods on the bridge. You can get all of the configuration details, including all of the bulbs and their statuses with the same base url: http://192.168.1.100/api/coding4fun

Now comes the fun part. There are three color modes in which you can use to set the color of your bulbs:

• hue & sat: ‘hue’ is a color range between 0-65535 which represent 182.04*degrees, ‘sat’ is saturation with a range of 0-254
• xy: are coordinates in the CIE 1931 space
• ct: is a color temperature expressed in mireds from 154 to 500, coolest to warmest respectfully

Source: http://rsmck.co.uk/hue

We’ll be setting the colors of our bulbs using hue & saturation parameters. Luckily, the Coding4Fun Toolkit for Windows Phone has three awesome color picker controls and some useful color extensions which makes setting the bulb colors a breeze. We start by building our state object – a list of parameters we want our bulb to be set to. Then we use the PUT verb to set the light with the following URL: http://{BRIGE-IPADDRESS}/api/coding4fun/lights/1/state

The “1” in the url is the 1-based index of the bulb you want to set.

//Get the HSV Value from the currently selected color
var hsv = LightColorSlider.Color.GetHSV();
 
//build our State object
var state = new
{
    on = true,
    hue = (int)(hsv.Hue * 182.04), //we convert the hue value into degrees by multiplying the value by 182.04
    sat = (int)(hsv.Saturation * 254)
};
 
//convert it to json:
var jsonObj = JsonConvert.SerializeObject(state);
 
//set the api url to set the state
var uri = new Uri(string.Format("http://{0}/api/{1}/lights/{2}/state", HostnameTextBox.Text, UsernameTextBox.Text, LightIndexTextBox.Text));
 
var client = new WebClient();
 
//decide what to do with the response we get back from the bridge
client.UploadStringCompleted += (o, args) => Dispatcher.BeginInvoke(() =>
{
    try
    {
        ResponseTextBox.Text = args.Result;
    }
    catch (Exception ex)
    {
        ResponseTextBox.Text = ex.Message;
    }
     
});
 
//Invoke the PUT method to set the state of the bulb
client.UploadStringAsync(uri, "PUT", jsonObj);

That’s it! Be sure to check out all of the other functions the (other functions the Hue API supports) at http://developers.meethue.com/index.html

Bio:
Jarem Archer is a self-taught Software Developer and UX Designer. He’s part of a small team at untitled network who have a passion for video games, digital motion, entertainment and gadgets. Follow him on Twitter at http://twitter.com/unt1tled.

The best part of all is that it's not really a project as much as it is a "teach you to fish all the while creating an awesome thing" kind of... well... thing.

Demo connecting 11 Netduinos to Windows Azure Service

I put together a talk that includes a lab on building a security/home automation system using 11 netduinos communicating over MQTT with a broker located in Windows Azure.  The attendees of this talk will walk through the lab and build out various components of a security system.

Here is a video demonstrating the various components of the system.  

...

My Security

Overview

This project was created to show off some fun things you can do to get started in the Internet of Things craze. This project was never intended to be an actual working Home Security system so don’t try and use it for that unless you really think about addressing some of the internet security issues that need to be tackled with a project like this. Please use this code as an example only!

Each device that is connected to the system's central hub will perform a specific function in the security platform. In a real security system you wouldn’t have mission critical devices dependent on external connectivity to the cloud. The connectivity to such an external system could be easily disrupted. Again this is just a fun example to get you thinking about connecting many devices to a cloud service.

The hardware used for this project is the Netduino Plus 2 from Secret Labs LLC. All code samples you see on this sight will target the Netduino Plus 2 device. However, the protocol to communicate with the cloud service is not platform specific so any device can be used to communicate with the Home Security service. So feel free to use a different .Net Micro Framework device. You could even use one of the very popular Arduino devices.

Of course the cloud service part of this project is running on the Windows Azure Platform. There are so many options available to you with the Azure platform. I decided to use a small subset of the features available just to prove that it doesn't take a lot to get something going on the Azure platform.

Where to start

As a participant in this project you will be building the devices that complete the Home Security system. Some basic code will already be written for you but for the most part it will be your job to complete the code and make the device functional. The cloud service that connects the devices is already completed and deployed to Windows Azure for you to use, so you wont need to do any of that coding. However the code for the cloud service is available in source control for you to look at.

• Documentation - This is where you will spend most of your time because it contains all the documentation to complete the lab exercises.
• Getting Ready For the Meeting - All the information you need to come prepared for the event.
• Azure Source Code Repository - All the source for the Azure components of the security system.
• Netduino Source Code Repository - All the source for the Netduino components of the security system
• Dashboard - This is the Home Security Dashboard where you can see the status of a device and interact with it
• Slide Deck - The slides for the presentation

Documentation

What do I need

Before you attend this event you need to get a few things in order. We don't have a lot of time during the event to spend it setting up your development environment so make sure you check out Getting Ready For the Meeting.

What will I be doing

You will be building one of the following devices in the home security system:

• External Door Entry- This device handles all the I/O for any External Door
• Door Bell- This device handles the I/O for letting the user know a door bell was pushed
• Alarm- This device handles the I/O for letting the user know the alarm was tripped
• Alarm Control Panel- This device handles the I/O for the control panels placed in each room of the house
• Master Control Panel- This isn't really a device (but it could be) and it is already built for you. I am calling it out here because without it the entire system would be a bunch of devices that are independent of one another with no real central control managing the whole security system logic.

Determine which one of the devices that you want to attempt to build. Some of the devices are harder to complete than others. If you want to start out easy then you can do the doorbell device. If you want a tougher challenge then go ahead and try the Alarm Control Panel.

There will be some code that is already written for you so that you don't have to worry about the communication protocols needed to publish and subscribe to the MQTT message bus. Since the protocol is abstracted away from you all you need to know is that the MQTT messages are basically made up of two parts: a Topic and a Message. There is a lot more to the MQTT standard that you can read up on your own but you won't need it for this project. Basically, topics are a series of words separated by a / topic separator. The message is simply any string. The devices on the bus are expected to understand the topics and message formats, but like all pub/sub designs the devices don't know

...

What is running in the cloud

There are two main components that already exist in Azure that the devices will interact with: MQTT Message Broker and Master Control Panel. The message broker runs under an Azure Worker Role. The Master Control Panel runs in Windows Azure Web Role. The broker simply routes MQTT messages and has no real home security specific business logic on it. The Master Control Panel manages the state of the security system as well as the business rules around how the security system functions as a whole. SignalR is used to update the client browsers when the state of the security system changes. Take a look at the Master Control Panel for more details on how it functions.

...

As you can see, pretty awesome. If you're in his area, make sure you see him, and build this project with him... Scroll to the bottom of http://www.cloudhomesecurity.com/ to see where and when.

Just kidding... but with all the cool work Matt, aka RogueCode, has been doing, and which we've been highlighting, it kinds of feels that way doesn't it? Now if only the stuff he was doing wasn't just so darn cool.

We have just about everything in this project. Hardware, electronics, development, mobile even 3D printing!

Netduino + WP8 real-life maze game

When I was young my parents bought me a wooden maze game. I loved that thing. I don’t think I ever cared much for the actual maze element – but the mechanism to tilt the stage was intriguing, and very simple.

When I remembered it the other day I managed to both find it online, and actually find my original one in an old cupboard from storage.

Moving on a decade or two, we now have hundreds of these ball games on smartphones using their accelerometers (like this one – a random one from the WP store), but their graphics leave a lot to be desired. Which is why I’ve made a photorealistic one

The objective was to make a maze game that was a merge between the old-school and new-school ones. So the phone is used as a tilt controller to control the physical maze via Bluetooth with a Netduino. The maze is a simple model printed on my 3D printer and is tilted by using two servos. Bonus points for adding a switch mechanism to report back to the phone when the player gets to the end.

What you need:

• 2 fairly strong servos. I used Turnigy metal-gear ones from HobbyKing.
• Bluetooth module
• Netduino
• Small square maze-like object
• 10K ohm resistor
• 4.8V battery pack
• Conductive ball-bearing/marble

The maze:

This probably took longer than all the other parts combined because my 3D printer’s extruder nozzle jammed up rather solidly. And even when I did eventually get it to print, the result was pretty terrible. However, the actual maze model at the end of this post is perfect and will print fine on your printer if you have one. I printed it 9CM x 9CM because that is about the biggest my Makerbot Thing-O-Matic can print.

To make the model, I first went to http://www.mazegenerator.net/ and generated a 9X9 maze. Then imported the result into SketchUp, traced out the lines, and extruded the walls up. I only made the walls high enough to steer the ball – not encase it.

And of course, Matt's made everything that can be downloaded, downloadable...

The Parrot AR.Drone 2.0 is an awesome device packed with cool features. The drone contains two cameras, one pointed forward that streams live video, and one pointed downwards (for all your surveillance needs). Its got four powerful engines that make it fast and maneuverable. The drone’s firmware keeps it stable and level while stationary or performing maneuvers, handling a huge burden for the user. It’s a fun device to write code for, and even more fun to pilot when you’re done!

There’s a few projects that have created AR.Drone APIs that can be used for Windows 8 Desktop Apps. However, I wanted to fly my drone from a Windows Store App, so I decided to build my own API compatible with WinRT. The result is covered in this series of posts. Thanks to Nisha Singh (http://blogs.msdn.com/b/nishasingh/) and everyone else who helped me out with this project!

In the first post, I’ll go over how the API handles communicating with and controlling the drone, and then demonstrate how to use the API to make a simple control App.

API Information and Terms

The API consists of 5 files:

• DroneConnection.cs: functionality to connect to, and disconnect from, the drone.
• DroneControl.cs: contains the control loop.
• DroneMovement.cs: contains methods that construct and return fully-formatted commands.
• InputProcessing.cs: determines the next command to issue to the drone.
• InputState.cs: used to pass information between the UI and back-end.

• The terms the API code uses to refer to axes of movement are as follows:

• DroneStrafeX: left-right.
• DroneStrafeY: forward-backward.
• DroneRotateX: yaw, or rotation.
• DroneAscendY: up-down.

•  

  Communicating with the Drone

  The AR.Drone 2.0 communicates with other devices through its own wireless network. Sending the drone instructions is as simple as connecting your computer to the drone’s network, opening a UDP connection to the drone (I.P. 192.168.1.1, Port 5556), and then sending commands over this connection. The code to connect to the drone is contained inside DroneConnection.cs:

  // Initialize the connection to the drone
  public static async Task ConnectToDrone()
  {
        
           ...
        
           // Set up the UDP connection
           string remotePort = "5556";
           HostName droneIP = new HostName("192.168.1.1");
        
           udpSocket = new DatagramSocket();
           await udpSocket.BindServiceNameAsync(remotePort);
           await udpSocket.ConnectAsync(droneIP, remotePort);
           udpWriter = new DataWriter(udpSocket.OutputStream);
        
           ...
        
  }
  

   

  Once a connection has been established, we can begin to send the drone messages:

  // Send a command to the drone
  public static async Task SendDroneCommand(string command)
  {
           udpWriter.WriteString(command);
           await udpWriter.StoreAsync();
  }
  

  This networking code is discussed more in-depth here: Try, Catch, Finally... - UDP and Windows 8 Apps

  The drone needs to continuously receive commands for it to remain responsive. If the drone doesn’t receive any commands for two seconds, it assumes the connection has been lost, and it will ignore any further commands. If this happens, you need to close and re-establish the connection before you can continue to pilot the drone. DroneConnection.cs contains methods that allow you to do this.

   

  Commanding the Drone

  You can command the drone by sending it strings called AT commands. There are seven different categories of AT commands, but only two are required to fly the drone, and are the only ones included in the API:

• AT*REF – Used for basic behavior such as takeoff/landing, and emergency stop/reset.
• AT*PCMD – Used to fly the drone once airborne. This controls pitch, yaw, roll, and altitude.

• AT commands have very specific formatting, and consist of four parts. An improperly formatted command will be ignored by the drone. The different sections of an AT*PCMD command are highlighted below:

   

  AT*PCMD=23,1,0,0,0,0\r\n

   

  Header: The type of the AT command

  Sequence Number: The sequence number is used by the drone to keep track of which commands it needs to execute. The drone will not execute any commands with a sequence number lower than the highest sequence number it has received so far. The first command sent should always have a sequence number of 1, and each command sent subsequently should increment this number by 1. The sequence number can be manually reset by sending a command with the number 1.

  Payload: This carries the command arguments. Its format and content vary from command to command. In the AT*PCMD command, the first value is a flag indicating whether the drone should do nothing (low) or move according to the other arguments (high). The next four values denote roll, pitch, vertical speed, and angular speed respectively. These values are floats ranging from [-1, 1], where (0, 1] represents movement speed in one direction, and [-1, 0) represents the other. A 0 causes the drone to remain stationary along that axis, a 1 or –1 is maximum movement speed in their respective directions, and each value between is a fraction of the maximum possible speed. For example, in the pitch argument, a .75 would cause the drone to move backward at 3/4 maximum speed, while a –.5 would make it move forward at 1/2 the possible speed. However, the drone doesn’t respond to values in the [-1, 1] range. The actual value that needs to be inserted into the AT command is the signed integer value represented by the bytes the float is actually stored in. This conversion is done for you in the FloatConversion method in DroneMovement.cs.

  Carriage Character: A newline character. Use the one specific to your environment.

  DroneMovement.cs has a set of methods to generate AT*REF and AT*PCMD commands, all of which take the current sequence number as an argument, and return a ready-to-send AT command. Some methods take additional arguments to control the movement speed. An example of one of these methods is:

  // Strafe drone forward or backward at velocity in range [-1,1]
  public static string GetDroneStrafeForwardBackward(uint sequenceNumber, double velocity)
  {
           // Convert the ratio into a value the drone understands
           int value = FloatConversion(velocity);
           return CreateATPCMDCommand(sequenceNumber, "0," + value + ",0,0"); 
  }
    
  // Return a full ATPCMD command
  private static string CreateATPCMDCommand(uint sequenceNumber, string command)
  {
           return "AT*PCMD=" + sequenceNumber + ",1," + command + Environment.NewLine;
  }
  

  Control Infrastructure

  The drone is controlled with an continuous loop that sends a command to the drone every 30 ms. Each cycle, the loop determines the next command, sends the command to the drone, and then increments the sequence number. The method is asynchronous and awaits the call to System.Threading.Tasks.Task.Delay() so that it doesn’t block the UI between cycles.

  public static async void ControlLoop()
  {
           while (true)
           {
            
                   ...
            
                   // Get and send the next command
                   string commandToSend = InputProcessing.NextCommand(sequenceNumber);
                   await DroneConnection.SendDroneCommand(commandToSend);
            
                   sequenceNumber++;
            
                   await System.Threading.Tasks.Task.Delay(30);
           }
  }
  

  You need to implement the InputProcessing.NextCommand() method to return an AT command based on criteria of your own choosing. The API includes the class InputState.cs that you can use to pass information between your UI and the control infrastructure. The example App contains an example of this.

  Example App

  I’ve included a simple example App to demonstrate how to use the API. The App allows you to connect to the drone and make it take off, land, and rotate. It also illustrates how to pass input information between the UI and the control infrastructure using InputState instances. In the App, FlyingPage contains the method GetState() that returns an instance of InputState. GetState() looks at the input the App is receiving, then creates and returns an instance of InputState containing that information.

  // returns the current state of the input controls
  public static InputState GetState()
  {
           // slider value is in the range [-1,1]
           return new InputState(0, 0, 0, sliderValue, isFlying);
  }
  

  InputProcessing.NextCommand() calls GetState, and then interprets the state to decide on the next command to send:

  // returns the next command that should be executed
  public static string NextCommand(uint sequenceNumber)
  {
           InputState state = MainPage.GetState();
        
           // Determine if the drone needs to take off or land
           if (state.startFlying && !isFlying)
           {
                   isFlying = !isFlying;
                   return DroneMovement.GetDroneTakeoff(sequenceNumber);
           }
           else if (!state.startFlying && isFlying)
           {
                   isFlying = !isFlying;
                   return DroneMovement.GetDroneLand(sequenceNumber);
           }
        
           
           // Check if the drone needs to rotate
           if (state.rotateX != 0)
           {
                   return DroneMovement.GetDroneRotate(sequenceNumber, state.rotateX);
           }
        
           // Otherwise have the drone do nothing.
           return DroneMovement.NullCommand(sequenceNumber);
  }
  

  The command decision is made in order of importance. Takeoff and landing commands are the most important, followed by movement commands. If there is no other command to send, NextCommand() returns a null command so that the drone will continue hovering and listening to the connection.

  Once NextCommand() has been implemented, all the App needs to do is connect to the drone and initiate the control loop by calling DroneConnection.ConnectToDrone(), followed by calling DroneControl.ControlLoop(). In the example App, this is done in the handler for the connect button. Once the control loop is running, the drone is ready to fly!

  Get Flying

  The API should give you everything you need to get started writing drone Apps for Windows Store. In part 2, I’ll discuss a more complete App I’ve written to pilot the drone. There’s still so much drone functionality to be exposed, so get coding and get flying!

Here's a hint from Chris Walker...

Summary

2x the RAM, 4x the speed, and 6x the flash of GEN1   Many users have run out of flash/RAM on gen1, so the huge upgrade is going to be pretty big news.

Most Vital Specs

• 168 MHz
• 384KB code space (1MB total flash)
• 100KB+ available RAM (192KB total RAM)

New Features

• OneWire support
• Four serial ports (vs. 2 serial ports on gen1)
• Compatibility with even more Arduino shields
  • Higher current
  • All six core PWMs
  • Compatible with new extended Arduino shield form factor
• MiniJTAG – for debugging of native code (side-by-side with C#/VB debugging via USB)

Figured it out yet?

netduino plus 2

system requirements

Windows

• Windows XP, Vista, or 7 (32 or 64 bit)
  Recommended: Windows 7 or 8
• 1.6 GHz or faster processor
• 1 GB RAM
• Up to 3 GB of available hard drive space for Visual Studio Express 2010

design files and source code

design files (open source)

• netduino plus 2 schematics
• netduino plus 2 board layout

source code (open source)

• .NET Micro Framework v4.2 source
• netduino firmware v4.2.1 source
  coming soon
• netduino sdk v4.2.1 source
  coming soon

Also remember if you want something a bit easier, try the Netduino Go! Or the Gadgeteer boards over at GHI. We love all our hardware vendors providing .Net Microsoft Framework compatible systems. There's hardware for every skill level (even one for a dev like me!... cough... Gadgeteer... cough...  Now that's saying something)

Remember when you build something awesome with one of these systems, drop us a line. Thanks and most importantly, have fun!

• Windows 8 GA launch
• [00:58] Build Pre-conference stats
• [01:54] Day 1 keynote - Ballmer's demos Rick's Ballmer moments
• Hardware
  • [03:27] Acer UX31A
  • ASUS Zenbook Touch
  • [05:08] Lenovo Yoga
  • [06:13] Surface RT + Touch and Type Covers
  • [08:15] Dell XPS all-in-one
• [10:23] Day 2 keynote - Azure stuff relevant for IT Pros
• [12:43] Windows Phone 8 - Nokia 920 and Kid mode
• [14:55] Relevant BUILD sessions for IT Pros
  • Extending and customizing Dynamic Access Control
  • Delivering Apps with Remote FX in Windows Server 2012
  • Developing highly-available, scale-out applications for Windows Server 2012
  • Security in Windows Store Applications

Connect with the Edge Team:

Facebook – Twitter - Email

Led-matrix controller driven via SPI

Time ago, Stanislav -a Netduino community user- posted a problem on how to drive a 6-by-4 led-matrix using its Netduino. After some experiment, he got stuck with the circuit, because a matrix must be multiplexed, and that’s not easy to solve.

Here is the link to the forum thread.

If you read the message exchange on the thread, then you’ll collect easily a list of constraints. Here they are:

• the leds have been already assembled (i.e. only the multiplex driver is needed)
• the overall price should fall within 10 Euro
• must be handcrafted, thus no use of small parts (e.g. SMDs)
• the multiplex should not stop its cycling as the Netduino stops (avoid leds burnout)
• the circuit should avoid complicate wiring, so that the PCB can get pretty easy
• reliable enough
• finally, Stanislav asked to learn how to design such a circuit

It was clear that Netduino only wasn’t enough to drive a 6×4 led-matrix. First off, for the inability to give enough current for the leds, and secondly for the relative slowness of the managed code running into.

The problem in depth.

Light up a led is very simple. Starting from the power supply, as parameter you have the current flowing through the led, then calculating the resistor to put in series. A led needs from few mA (SMDs), to several hundreds of mA (or even more) for the high-power class.
Let’s face the multiplex problem thinking to a normal discrete-led which needs 10 mA for a normal brightness.

So, what is a multiplex?
The multiplexing is a technique for driving many loads (e.g. leds), using a relatively low number of wires. Thinking to a 6×4 led-matrix, instead having 24 wires (one for each led), the multiplex-way needs only 6+4 = 10 wires at all. The trick is enabling one column at once, and issuing the related row pattern. If this process is fast enough, our eyes can’t perceive the scanning.

Now, let’s focus on a single column of four leds: the scan process cycles over, but each column is enabled only at 25% (i.e. 1/4) of the total cycle-time. It means that to yield the same brightness as the led was lit with 10 mA, we should raise it of a factor of 4, thus 40 mA. This current is off the upper limit achievable by a normal logic chip.

By the way 40 mA is probably above the led’s limit. However, the current is flowing only for a quarter of the cycle, so there’s no warm up in the *average*. We only should take care to *avoid* any cycle break, otherwise the 40 mA will flow for a too long time, and the led blows.

That’s not all. When a column is enabled, there are 6 leds composing it, and they might be all on (worst case). So, the total current flowing is 40 mA x 6 = 240 mA.
How much is the current of each row, instead? A row drives only the led at where the column is enabled, but at 25% duty, of course. It means the 40 mA seen above.

My solution.

To solve this problem, I see three ways:

...

I mentioned holidays? Well don't you see yourself coding something up to display some kind of holiday stuff with this? Come on, you know you want to code this to display some kind of little animated Christmas Tree...

In early January, we were tasked with creating a unique, interactive experience for the SXSW Interactive launch party with Frog Design. We bounced around many ideas, and finally settled on a project that Rick suggested during our first meeting: boxing robots controlled via Kinect.

The theme of the opening party was Retro Gaming, so we figured creating a life size version of a classic tabletop boxing game mashed up with a "Real Steel"-inspired Kinect experience would be a perfect fit. Most importantly, since this was going to be the first big project of the new Coding4Fun team, we wanted to push ourselves to create an experience that needed each of us to bring our unique blend of hardware, software, and interaction magic to the table under an aggressively tight deadline.

Hardware

The BoxingBots had to be fit a few requirements:

1. They had to be fun
2. They had to survive for 4 hours, the length of the SXSW opening party
3. Each robot had to punch for 90 seconds at a time, the length of a round
4. They had to be life-size
5. They had to be Kinect-drivable
6. They had to be built, shipped, and reassembled for SXSW

Creating a robot that could be beaten up for 4 hours and still work proved to be an interesting problem. After doing some research on different configurations and styles, it was decided we should leverage a prior project to get a jump start to meet the deadline. We repurposed sections of our Kinect drivable lounge chair, Jellybean! This was an advantage because it contained many known items, such as the motors, motor controllers, and chassis material.  Additionally, it was strong and fast, it was modular, and the code to drive it was already written.

Jellybean would only get us part of the way there, however.  We also had to do some retrofitting to get it to work for our new project. The footprint of the base needed to shrink from 32x50 inches to 32x35 inches, while still allowing space to contain all of the original batteries, wheels, motors, motor controllers, switches, voltage adapters. We also had to change how the motors were mounted with this new layout, as well as provide for a way to easily "hot swap" the batteries out during the event. Finally, we had to mount an upper body section that looked somewhat human, complete with a head and punching arms.

 
Experimenting with possible layouts

The upper body had its own challenges, as it had to support a ton of equipment, including:

• Punching arms
• Popping head
• Pneumatic valves
• Air manifold
• Air Tank(s)
• Laptop
• Phidget interface board
• Phidget relay boards
• Phidget LED board
• Xbox wireless controller PC transmitter / receiver
• Chest plate
• LEDs
• Sensors to detect a punch

Brian and Rick put together one of the upper frames

Punching and Air Tanks

We had to solve the problem of getting each robot to punch hard enough to register a hit on the opponent bot while not breaking the opponent bot (or itself). Bots also had to withstand a bit of side load in case the arms got tangled or took a side blow. Pneumatic actuators provided us with a lot of flexibility over hydraulics or an electrical solution since they are fast, come in tons of variations, won't break when met with resistance, and can fine tuned with a few onsite adjustments.

To provide power to the actuators, the robots had two 2.5 gallon tanks pressurized to 150psi, with the actuators punching at ~70psi.  We could punch for about five 90-second rounds before needing to re-pressurize the tanks.  Pressurizing the onboard tanks was taken care of by a pair of off-the-shelf DeWalt air compressors.

The Head

It wouldn’t be a polished game if the head didn’t pop up on the losing bot, so we added another pneumatic actuator to raise and lower the head, and some extra red and blue LEDs. This pneumatic is housed in the chest of the robot and is triggered only when the game has ended.

To create the head, we first prototyped a concept with cardboard and duct tape. A rotated welding mask just happened to provide the shape we were going for on the crown, and we crafted each custom jaw with a laser cutter.  We considered using a mold and vacuum forming to create something a bit more custom, but had to scrap the idea due to time constraints.

Sensors

Our initial implementation for detecting punches failed due to far too many false positives. We thought using IR distance sensors would be a good solution since we could detect a “close” punch and tell the other robot to retract the arm before real contact. The test looked promising, but in practice, when the opposite sensors were close, we saw a lot of noise in the data. The backup and currently implemented solution was to install simple push switches in the chest and detect when those are clicked by the chest plate pressing against them.

Power

Different items required different voltages. The motors and pneumatic valves required 24V, the LEDs required 12V and the USB hub required 5V. We used Castle Pro BEC converters to step down the voltages. These devices are typically used in RC airplanes and helicopters.

Shipping

So how does someone ship two 700lb robots from Seattle to Austin? We did it in 8 crates. . The key thing to note is that the tops and bottoms of each robot were separated. Any wire that connected the two parts had to be able to be disconnected in some form. This affected the serial cords and the power cords (5V, 12V, 24V).

Software

The software and architecture went through a variety of iterations during development. The final architecture used 3 laptops, 2 desktops, an access point, and a router. It's important to note that the laptops of Robot 1 and Robot 2 are physically mounted on the backs of each Robot body, communicating through WiFi to the Admin console. The entire setup looks like the following diagram:

Admin Console

The heart of the infrastructure is the Admin Console. Originally, this was also intended to be a scoreboard to show audience members the current stats of the match, but as we got further into the project, we realized this wouldn't be necessary. The robots are where the action is, and people's eyes focus there. Additionally, the robots themselves display their current health status via LEDs, so duplicating this information isn't useful. However, the admin side of this app remains.

Sockets

The admin console is the master controller for the game state and utilizes socket communication between it, the robots, and the user consoles. A generic socket handler was written to span each computer in the setup. The SocketListener object allows for incoming connections to be received, while the SocketClient allows clients to connect to those SocketListeners. These are generic objects, which must specify objects of type GamePacket to send and receive:

public class SocketListener<TSend, TReceive> where TSend : GamePacket                                                
                                             where TReceive : GamePacket, new()

GamePacket is a base class from which specific packets inherit:

public abstract class GamePacket
{
    public byte[] ToByteArray() 
    {   
        MemoryStream ms = new MemoryStream();           
        BinaryWriter bw = new BinaryWriter(ms);
                
        try
        {           
            WritePacket(bw);
        }
        catch(IOException ex)
        {
            Debug.WriteLine("Error writing packet: " + ex);
        }
        
        return ms.ToArray();
    }
        
    public void FromBinaryReader(BinaryReader br)
    {        
        try
        {    
            ReadPacket(br);       
        }
        catch(IOException ex)       
        {
            Debug.WriteLine("Error reading packet: " + ex);
        }
    }
    
    public abstract void WritePacket(BinaryWriter bw);
    public abstract void ReadPacket(BinaryReader br);
}

For example, in communication between the robots and the admin console, GameStatePacket and MovementDescriptorPacket are sent and received. Each GamePacket must implement its own ReadPacket and WritePacket methods to serialize itself for sending across the socket.

Packets are sent between machines every "frame". We need the absolute latest game state, robot movement, etc. at all times to ensure the game is functional and responsive.

As is quite obvious, absolutely no effort was put into making the console "pretty". This is never seen by the end users and just needs to be functional. Once the robot software and the user consoles are started, the admin console initiates connections to each of those four machines. Each machine runs the SocketListener side of the socket code, while the Admin console creates four SocketClient objects to connect to each those. Once connected, the admin has control of the game and can start, stop, pause, and reset a match by sending the appropriate packets to everyone that is connected.

Robot

The robot UI is also never intended to be seen by an end user, and therefore contains only diagnostic information.

Each robot has a wireless Xbox 360 controller connected to it so it can be manually controlled. The UI above reflects the positions of the controller sticks and buttons. During a match, it's possible for a bot to get outside of our "safe zone". One bot might be pushing the other, or the user may be moving the bot toward the edge of the ring. To counter this, the player's coach can either temporarily move the bot, turning off Kinect input, or force the game into "referee mode" which pauses the entire match and turns off Kinect control on both sides. In either case, the robots can be driven with the controllers and reset to safe positions. Once both coaches signal that the robots are reset, the admin can then resume the match.

Controlling Hardware

Phidget hardware controlled our LEDs, relays, and sensors. Getting data out of a Phidget along with actions, such as opening and closing a relay, is shockingly easy as they have pretty straightforward C# APIs and samples, which is why they typically are our go-to product for projects like this.

Below are some code snippets for the LEDs, relays, and sensor.

LEDs – from LedController.cs

This is the code that actually updates the health LEDs in the robot's chest. The LEDs were put on the board in a certain order to allow this style of iteration. We had a small issue of running out of one color of LEDs so we used some super bright ones and had to reduce the power levels to the non-super bright LEDs to prevent possible damage:

private void UpdateLedsNonSuperBright(int amount, int offset, int brightness)
{
    for (var i = offset; i < amount + offset; i++)
    {
        _phidgetLed.leds[i] = brightness / 2;
    }
}

private void UpdateLedsSuperBright(int amount, int offset, int brightness)
{
    for (var i = offset; i < amount + offset; i++)
    {
        _phidgetLed.leds[i] = brightness;
    }
}

Sensor data – from SensorController.cs

This code snippet shows how we obtain the digital and analog inputs from the Phidget 8/8/8 interface board:

public SensorController(InterfaceKit phidgetInterfaceKit) : base(phidgetInterfaceKit)
{    
    PhidgetInterfaceKit.ratiometric = true;
}

public int PollAnalogInput(int index)
{
    return PhidgetInterfaceKit.sensors[index].Value;
}

public bool PollDigitalInput(int index)
{
    return PhidgetInterfaceKit.inputs[index];
}

Relays – from RelayController.cs

Electrical relays fire our pneumatic valves. These control the head popping and the arms punching. For our application, we wanted the ability to reset the relay automatically. When the relay is opened, an event is triggered and we create an actively polled thread to validate whether we should close the relay. The reason why we actively poll is someone could be quickly toggling the relay. We wouldn't want to close it on accident. The polling and logic does result in a possible delay or early trigger for closing the relay, but for the BoxingBots the difference of 10ms for a relay closing is acceptable:

public void Open(int index, int autoCloseDelay)
{   
    UseRelay(index, true, autoCloseDelay);
}

public void Close(int index)
{
    UseRelay(index, false, 0);
}

private void UseRelay(int index, bool openRelay, int autoCloseDelay)
{
    AlterTimeDelay(index, autoCloseDelay);
    PhidgetInterfaceKit.outputs[index] = openRelay;
}

void _relayController_OutputChange(object sender, OutputChangeEventArgs e)
{
    // closed
    if (!e.Value)
        return;

    ThreadPool.QueueUserWorkItem(state =>
    {                                          
        if (_timeDelays.ContainsKey(e.Index))
        {                                              
            while (_timeDelays[e.Index] > 0)                       
            {
                Thread.Sleep(ThreadTick);           
                _timeDelays[e.Index] -= ThreadTick;
            }                                            
        }
                                            
        Close(e.Index);
                                        
    });
}

public int GetTimeDelay(int index)
{
    if (!_timeDelays.ContainsKey(index))
        return 0;
    return _timeDelays[index];
}

public void AlterTimeDelay(int index, int autoCloseDelay)
{
    _timeDelays[index] = autoCloseDelay;
}

User Console

Since the theme of the party was Retro Gaming, we wanted to go for an early 80's Sci-fi style interface, complete with starscape background and solar flares! We wanted to create actual interactive elements, though, to maintain the green phosphor look of early monochrome monitors. Unlike traditional video games, however, the screens are designed not as the primary focus of attention, but rather to help calibrate the player before the round and provide secondary display data during the match. The player should primarily stay focused on the boxer during the match, so the interface is designed to sit under the players view line and serve as more of a dashboard during each match.

However, during calibration before each round, it is important to have the player understand how their core body will be used to drive the Robot base during each round. To do this, we needed to track an average of the joints that make up each fighter's body core. We handled the process by creating a list of core joints and a variable that normalizes the metric distances returned from the Kinect sensor into a human-acceptable range of motion:

private static List<JointType> coreJoints = newList<JointType>( 
    newJointType[] {
        JointType.AnkleLeft,
        JointType.AnkleRight,
        JointType.ShoulderCenter,
        JointType.HipCenter
    });
private const double RangeNormalizer = .22;
private const double NoiseClip = .05;

And then during each skeleton calculation called by the game loop, we average the core positions to determine the averages of the players as they relate to their playable ring boundary:

public staticMovementDescriptorPacket AnalyzeSkeleton(Skeleton skeleton)
{           
    // ...

    CoreAverageDelta.X = 0.0;
    CoreAverageDelta.Z = 0.0;
    foreach (JointType jt in CoreJoints)
    {
        CoreAverageDelta.X += skeleton.Joints[jt].Position.X - RingCenter.X;
        CoreAverageDelta.Z += skeleton.Joints[jt].Position.Z - RingCenter.Z;
    }

    CoreAverageDelta.X /= CoreJoints.Count * RangeNormalizer;
    CoreAverageDelta.Z /= CoreJoints.Count * RangeNormalizer;

    // ...

    if (CoreAverageDelta.Z > NoiseClip || CoreAverageDelta.Z < -NoiseClip)
    {
        packet.Move = -CoreAverageDelta.Z;
    }

    if (CoreAverageDelta.X > NoiseClip || CoreAverageDelta.X < -NoiseClip)
    {
        packet.Strafe = CoreAverageDelta.X;
    }
}

In this way, we filter out insignificant data noise and allow the player's average core body to serve as a joystick for driving the robot around. Allowing them to lean at any angle, the move and strafe values are accordingly set to allow for a full 360 degrees of movement freedom, while at the same time not allowing any one joint to unevenly influence their direction of motion.

Another snippet of code that may be of interest is the WPF3D rendering we used to visualize the skeleton. Since the Kinect returns joint data based off of a center point, it is relatively easy to wire up a working 3D model in WPF3D off of the skeleton data, and we do this in the ringAvatar.xaml control.

In the XAML, we simply need a basic Viewport3D with camera, lights, and an empty ModelVisual3D container to hold or squares. The empty container looks like this:              

<ModelVisual3D x:Name="viewportModelsContainer2">                   
    <ModelVisual3D.Transform>
        <Transform3DGroup>           
            <RotateTransform3D x:Name="bodyRotationCenter" CenterX="0" CenterY="0" CenterZ="0">      
                <RotateTransform3D.Rotation>             
                    <AxisAngleRotation3D x:Name="myAngleRotation" Axis="0,1,0" Angle="-40"/>                 
                </RotateTransform3D.Rotation>           
            </RotateTransform3D> 
        </Transform3DGroup> 
    </ModelVisual3D.Transform>
</ModelVisual3D>

In the code, we created a generic WPF3DModel that inherits from UIElement3D and is used to store the basic positioning properties of each square. In the constructor of the object, though, we can pass a reference key to a XAML file that defines the 3D mesh to use:

public WPF3DModel(string resourceKey)
{
    this.Visual3DModel = Application.Current.Resources[resourceKey] as Model3DGroup;
}

This is a handy trick when you need to do a fast WPF3D demo and require a certain level of flexibility. To create a 3D cube for each joint when ringAvatar is initialized, we simply do this:

private readonly List<WPF3DModel> _models = new List<WPF3DModel>();
private void CreateViewportModels()
{           
    for (int i = 0; i < 20; i++)
    { 
        WPF3DModel model = new WPF3DModel("mesh_cube");
        viewportModelsContainer2.Children.Add(model);

        // ...

        _models.Add(model);
    }

    // ...
}

And then each time we need to redraw the skeleton, we loop through the skeleton data and set the cube position like so:

if (SkeletonProcessor.RawSkeleton.TrackingState == SkeletonTrackingState.Tracked)
{
    int i = 0;  

    foreach (Joint joint in SkeletonProcessor.RawSkeleton.Joints)
    {
        if (joint.TrackingState == JointTrackingState.Tracked)
        {
                                        
            _models[i].Translate(                                        
                joint.Position.X * 8.0,                                    
                joint.Position.Y * 10.0,
                joint.Position.Z * -10.0);

            i++;
        }
    }

    // ...

}

There are a few other areas in the User Console that you may want to further dig into, including the weighting for handling a punch as well dynamically generating arcs based on the position of the fist to the shoulder. However, for this experience, the User Console serves as a secondary display to support the playing experience and gives both the player and audience a visual anchor for the game.

Making a 700lb Tank Drive like a First Person Shooter

The character in a first person shooter (FPS) video game has an X position, a Y position, and a rotation vector. On an Xbox controller, the left stick controls the X,Y position. Y is the throttle (forward and backward), X is the strafing amount (left and right), and the right thumb stick moves the camera to change what you're looking at (rotation).  When all three are combined, the character can do things such as run around someone while looking at them.

In the prior project, we had existing code that worked for controlling all 4 motors at the same time, working much like a tank does, so we only had throttle (forward and back) and strafing (left and right). Accordingly, we can move the motors in all directions, but there are still scenarios in which the wheels fight one another and the base won't move. By moving to a FPS style, we eliminate the ability to move the wheels in an non-productive way and actually make it a lot easier to drive.

Note that Clint had some wiring "quirks" with polarity and which motor was left VS right, he had to correct in these quirks in software :

public Speed CalculateSpeed(double throttleVector, double strafeVector, double rotationAngle)
{
    rotationAngle = VerifyLegalValues(rotationAngle);
    rotationAngle = AdjustValueForDeadzone(rotationAngle, AllowedRotationAngle, _negatedAllowedRotationAngle);

    // flipped wiring, easy fix is here  
    throttleVector *= -1;
    rotationAngle *= -1;
    
    // miss wired, had to flip throttle and straff for calc
    return CalculateSpeed(strafeVector + rotationAngle, throttleVector, strafeVector - rotationAngle, throttleVector);
}

protected Speed CalculateSpeed(double leftSideThrottle, double leftSideVectorMultiplier, double rightSideThrottle, double rightSideVectorMultiplier) 
{ /* code from Jellybean */ }

Conclusion

The Boxing Bots project was one of the biggest things we have built to date. It was also one of our most successful projects. Though it was a rainy, cold day and night in Austin when the bots were revealed, and we had to move locations several times during setup to ensure the bots and computers wouldn't be fried by the rain, they ran flawlessly for the entire event and contestants seemed to have a lot of fun driving them.

Gadgetab – the Gadgeteer Tablet

This story…

…begins a couple years ago when I started the Omnicopter.  To fly the copter, I needed a remote.  So, I built the Omnimote (right).  It was a Panda-II powered remote that used XBee to communicate with the copter.  It also had a small (slow) FEZ Touch display that was useful for displaying some info but had limited ability as a touch screen due to it being a resistive touch screen and it was just too slow to be depended on for use during flight.

As I’ve built other projects since then, it’s become more and more evident that I have a need for a universal device that can communicate and display information with other projects. 

In the past year, most of my focus has been drawn toward the Gadgeteer platform for electronics prototyping.  It’s a much more flexible and productive platform than anything else that exists at the moment and has dozens of powerful modules (subcircuits) that can be attached to it.  Gadgeteer has become my go-to platform when developing electronics projects.

I’ve been doing quite a bit of Gadgeteer evangelizing the past year by giving presentations at our local .NET users’ group and at conferences.  I’m also starting the Nashville Microcontrollers users’ group.  So, the desire to have a truly portable and compact solution for demoing Gadgeteer in addition to something that is useful for my other projects has become a little more important.

However, one piece has been missing to allow me to build the Gadgetab of my dreams – a large capacitive touch display. GHI Electronics recently solved that problem with the release of their CP7 module – a 7” capacitive touch display.  So, let the building begin!

The design goal was to build a tablet type device that could be useful as a remote, demo device, have some room for storage, be battery powered, and look nice – lots of software & sawdust.

Ian takes us from hardware;

To hardware...

Introduction

In our previous article, we examined what an Arduino shield is, how to build a simple custom shield and discussed how to quickly identify shields that are good candidates for a Netduino adaptation versus shields that may not be.

In this article, we’ll take a popular Arduino Logger Shield produced by Adafruit and we’ll interface it with a Netduino / Plus microcontroller

The Arduino Logger Shield is an excellent one to start with because it offers immediate benefits to a Netduino / Plus user:

• Time-keeping
• SD card storage
• Two user-controllable LEDs
• A small prototyping area
• An onboard 3.3v voltage regulator for clean analog readings and power decoupling

In our C# data logging application, we'll interact with the time keeper, the SD card storage and its 'card detect' pin, the two LEDs as well as a temperature sensor (not included with the shield).

Before diving into the details associated with the hardware, you may want to take a look at the C# objects representing the hardware:

public static readonly string SdMountPoint = "SD";
public static OutputPort LedRed = new OutputPort(Pins.GPIO_PIN_D0, false);
public static OutputPort LedGreen = new OutputPort(Pins.GPIO_PIN_D1, false);
public static InputPort CardDetect = new InputPort(Pins.GPIO_PIN_D3, true, Port.ResistorMode.PullUp);
public static readonly Cpu.Pin ThermoCoupleChipSelect = Pins.GPIO_PIN_D2;
public static DS1307 Clock;
public static Max6675 ThermoCouple;

and their initialization:

public static void InitializePeripherals() {
    LedGreen.Write(true);
    Clock = new DS1307();
    ThermoCouple = new Max6675();
    InitializeStorage(true);
    InitializeClock(new DateTime(2012, 06, 14, 17, 00, 00));
    ThermoCouple.Initialize(ThermoCoupleChipSelect);
    TemperatureSampler = new Timer(new TimerCallback(LogTemperature), null, 250, TemperatureLoggerPeriod);
    LedGreen.Write(false);
}

The SD card, represented by the SdMountPoint string, communicates with the application over SPI. The presence of the SD card in the reader is determined through the CardDetect input pin.

The LEDs are simple outputs that we'll turn ON / OFF as the peripherals gets initialized and file I/Os take place with the SD card.

The clock communicates with the application over the I2C protocol. The clock's most important functions are accessed through the Set() and Get() methods respectively used to set the time once and to get updated time stamps afterward.

The thermocouple communicates over SPI with the application. It exposes a Read() method which caches a raw temperature sample accessed through the Celsius and Fahrenheit properties.

Note: the Netduino Plus already features a built-in microSD card reader, in which case, having another one on the shield is not really needed. Except for this hardware difference, everything else discussed within this article applies equally to the regular Netduino and the Netduino Plus.

Interfacing with the Arduino Logger shield’s hardware

Adafruit is pretty good about making usable products and generally provides Arduino libraries to use with their hardware. Indeed, the Arduino Logger Shield is well documented and comes with two C++ libraries: SD which implements a FAT file system and supporting low-level SD card I/O functions. RTCLib which wraps the I2C interface required to communicate with the DS1307 real time clock.

The SD Card Interface

Let’s deal with the SD card reader and the file system first: a quick review of SD.h reveals two C++ classes:

• class File : public Stream {} exposing standard read, write, seek, flush file access functions.
• class SDClass {} exposing storage management such as file and directory operations.

This is good news because the .NET Micro Framework on the Netduino already supports file streams and directory management through the use of the .NET MF System.IO assembly. This assembly comes with the .NET MF SDK port to the Netduino.

By the same token, interfacing with an SD card is provided by an assembly built by Secret Labs named SecretLabs.NETMF.IO which comes with the Netduino SDK.

SecretLabs.NETMF.IO provides two functions for 'mounting' and 'un-mounting' an SD card device and the associated FAT file system so that it can be made usable by the .NET MF through assemblies such as System.IO.

It's important to note that the SecretLabs.NETMF.IO assembly must not be deployed with an application targeting the Netduino Plus: on boot, the .NET Micro Framework implementation specific to the Netduino Plus automatically detects and mounts the SD card if one is present in its microSD card reader. This functionality is redundant with the MountSD / Unmount functions provided by the SecretLabs.NETMF.IO assembly which is only needed on Netduino SKUs without a built-in SD card reader.

How does the .NET MF interact with the SD card through the shield?

At this point, it's a good time to review the Arduino Logger Shield's pin-out and the shield's schematics:

As we know from our previous article, pins D10-D13 map to the SPI interface and pins A4-A5 map to the I2C interface of the Netduino. On the shield's schematics, the SPI interface leads us to the SD & MMC section of the diagram, connected through a 74HC125N logic-level shifter chip indicated as IC3A-D.

The role of the logic-level shifter is to ensure that logic voltages supplied to the SD card do not exceed 3.3v, even if they come from a microcontroller using 5v logic levels, such as the Arduino. When using an SD card with a Netduino, a level-shifter is not required since all logic levels run at 3.3v on the AT91SAM7x chip but it doesn't interfere with any I/O operations either when the voltage is already 3.3v.

The SD card reader in itself is just a passive connector, giving access to the controller built into the SD card. It also provides a mechanical means (i.e. switches) of detecting the presence of a card in the reader (see JP14 pin 1) as well as detecting if the card is write-protected (see JP14 pin 2). We'll make use of the card detection pin in the sample temperature logging application later on.

For background on how SD cards work, the following application note "Secure Digital Card Interface for the MSP430" is excellent and much easier to digest than the extensive 'simplified' SD card protocol specifications provided on the SD Card Association site. The following table taken from the "Secure Digital Card Interface for the MSP430" shows the pin out of an SD card and the corresponding SPI connections:

An SD standard-compliant card can support 3 distinct access modes, each one providing different performance characteristics:

• SD 1-bit protocol: synchronous serial protocol with one data line, one clock line and one line for commands. The full SD card protocol command set is supported in 1-bit mode.
• SD 4-bit protocol: this mode is nearly identical to the SD 1-bit mode, except that the data is multiplexed over 4 data lines, yielding up to 4x the performance of SD 1-bit mode. The full SD card protocol command set is supported in 4-bit mode.
• SPI mode: provide a standard SPI bus interface (/SS, MOSI, MISO, SCK). In SPI mode, the SD card only supports a subset of the full SD card protocol but it is sufficient for implementing a fully functional storage mechanism with a file system.

As you might have guessed, the .NET Micro Framework on the Netduino makes use of the SD card in SPI mode (see \DeviceCode\Drivers\BlockStorage\SD\SD_BL_driver.cpp). The block-oriented SD card I/Os are abstracted thanks to the FAT file system provided by the System.IO assembly (see \DeviceCode\Drivers\FS\FAT\FAT_FileHandle.cpp and FAT_LogicDisk.cpp).

The role of the SecretLabs.NETMF.IO assembly on the Netduino (or its built-in equivalent on the Netduino Plus) is to initialize the SD card in SPI mode during the 'mounting' process by sending the proper set of commands as defined in the SD Card protocol.

In the C# code of the AdafruitNetduinoLogger sample application, which we will review as a whole later on in the code walkthrough section, the following function takes care of the SD card initialization:

public static void InitializeStorage(bool mount) {
    try {
        if (mount == true) {
            StorageDevice.MountSD(SdMountPoint, SPI.SPI_module.SPI1, Pins.GPIO_PIN_D10);
        } else {
            StorageDevice.Unmount(SdMountPoint);
        }
    } catch (Exception e) {
        LogLine("InitializeStorage: " + e.Message);
        SignalCriticalError();
    }
}

Once mounted, the file system is accessed through System.IO calls such as this:

using (var tempLogFile = new StreamWriter(filename, true)) {
    tempLogFile.WriteLine(latestRecord);
    tempLogFile.Flush();
}

Using the StreamWriter class in this context made sense for writing strings as used in the sample application:

However, there are many other file I/O classes available in System.IO that may be better suited depending on the scenario.

The DS1307 real time clock

Our next step is to examine the interface with the DS1307 real time clock (RTC). We'll start by extracting the most important parts of the DS1307 datasheet and reviewing how it's wired up on the shield's schematics.

DS1307 features

• Real-Time Clock (RTC) Counts Seconds, Minutes, Hours, Date of the Month, Month, Day of the week, and Year with Leap-Year Compensation Valid Up to 2100
• 56-Byte, Battery-Backed, General-Purpose RAM with Unlimited Writes
• I2C Serial Interface
• Programmable Square-Wave Output Signal
• Automatic Power-Fail Detect and Switch Circuitry
• Consumes Less than 500nA in Battery-Backup Mode with Oscillator Running

Note: If you need to measure the time something takes in milliseconds, a time granularity that the DS1307 clock does not provide, you can use the Utility functions provided by the .NET Micro Framework like this:

var tickStart = Utility.GetMachineTime().Ticks;

// <...code to be timed...>

var elapsedMs = (int)((Utility.GetMachineTime().Ticks - tickStart) / TimeSpan.TicksPerMillisecond);

This timing method relies on the CPU's internal tick counter and is not 100% accurate due to the overhead of the .NET MF itself but may be sufficient in most scenarios. In addition, the internal tick counter rolls over every so often, something that should be taken into account in production code.

DS1307 register map

Accessing the clock's features comes down reading and writing to and from a set of registers as described on page 8 of the datasheet.

Page 9 of the DS1307 datasheet provides more details about the square wave generation function of the clock, which we will not be using here. The generated square wave signal is available on the shield through connector JP14 on pin 3 as you can see on the schematics below and can be used to provide a slow but reliable external clock signal to another device such as a microcontroller.

DS1307 I2C bus address

The final piece of the puzzle needed before we can use the DS1307 is the device's address on the I2C data bus and its maximum speed (specified at 100 KHz on page 10 of the datasheet). The device address is revealed on page 12 as being 1101000 binary (0x68) along with the two operations modes (Slave Receiver and Slave Transmitter) of the clock. The 8th bit of the address is used by the protocol to indicate whether a 'read' or a 'write' operation is requested.

Note: I2C devices sometime make use of 10-bit addresses. If you aren't familiar with the I2C data bus, you should read the section of the datasheet starting on page 10 which provides a good foundation for understanding how I2C generally works.

It can be summarized as follows:

• I2C is a 2-wire serial protocol with one bidirectional data line referred to as SDA and one clock line, referred to as SCL.
• The I2C bus is an open-drain bus (i.e. devices pull the bus low to create a '0' and let go of the bus to create a '1'). To achieve this, I2C requires a pull-up resistor on the SCL and SDA lines between 1.8K ohms and 10K ohms. I2C devices do not need to provide pull-ups themselves if the bus already has them.
• The I2C master (i.e. the Netduino microcontroller) always provides the clock signal, generally between 100 KHz (or lower) for standard speed devices or 400 KHz for high-speed devices. There's also a 'Fast Mode Plus' allowing for speeds up to 1MHz on devices supporting it. There can be more than one master on the bus even though this is uncommon.
• An I2C device can have a 7-bit or 10-bit address, allowing for multiple I2C devices to be used on the same bus.
• I2C read and write operations are transactions initiated by the I2C master targeting a specific device by address. Some I2C slave devices can notify their master that they need to communicate using a bus interrupt.
• A transaction is framed by 'start' and 'stop signals, with each byte transferred requiring an acknowledgement signal.

At this point, we have all the pieces needed to communicate with the RTC using I2C transactions.

Using the I2C protocol with the .NET Micro Framework

On the Arduino, the library used with the shield to communicate with the DS1307 is a C++ library called RTClib. The header of the library declares a DateTime class, similar in functionality to the standard .NET Micro Framework DateTime class provided by System in the mscorlib assembly. We'll use the standard .NET MF data type to work with the clock instead.

The next declared class is RTC_DS1307 which implements the driver for the DS1307 chip using the Wire library to wrap the I2C protocol. The .NET Micro Framework also supports the I2C protocol through to the Microsoft.SPOT.Hardware assembly. Here again, we'll use the .NET MF implementation of I2C in order to communicate with the clock. However, the I2C transaction patterns implemented by the C++ driver can still provide a useful guide for writing a C# driver for the DS1307 when you don't know where to begin just based on the datasheet.

For instance, the following functions taken from RTClib.cpp shows the call sequence used with the Wiring API to address the date and time registers of the clock:

int i = 0; //The new wire library needs to take an int when you are sending for the zero register

void RTC_DS1307::adjust(const DateTime& dt) {
    Wire.beginTransmission(DS1307_ADDRESS);
    Wire.write(i);
    Wire.write(bin2bcd(dt.second()));
    Wire.write(bin2bcd(dt.minute()));
    Wire.write(bin2bcd(dt.hour()));
    Wire.write(bin2bcd(0));
    Wire.write(bin2bcd(dt.day()));
    Wire.write(bin2bcd(dt.month()));
    Wire.write(bin2bcd(dt.year() - 2000));
    Wire.write(i);
    Wire.endTransmission();
}

DateTime RTC_DS1307::now() {
    Wire.beginTransmission(DS1307_ADDRESS);
    Wire.write(i);
    Wire.endTransmission();
    Wire.requestFrom(DS1307_ADDRESS, 7);
    uint8_t ss = bcd2bin(Wire.read() & 0x7F);
    uint8_t mm = bcd2bin(Wire.read());
    uint8_t hh = bcd2bin(Wire.read());
    Wire.read();
    uint8_t d = bcd2bin(Wire.read());
    uint8_t m = bcd2bin(Wire.read());
    uint16_t y = bcd2bin(Wire.read()) + 2000;
    return DateTime (y, m, d, hh, mm, ss);
}

The final class is RTC_Millis, a utility class converting time data into milliseconds, effectively providing the functionality of the DateTime.Millisecond property on the .NET MF.

Having assessed that the functionality of RTClib only handles date and time registers and knowing the role of the other clock registers, we can proceed with implementing a complete DS1307 C# driver, supporting the square wave and RAM functions, using the native I2C protocol support of the .NET Micro Framework.

The driver starts by defining key constants matching the clock registers according to the datasheet:

[Flags]
// Defines the frequency of the signal on the SQW interrupt pin on the clock when enabled
public enum SQWFreq { SQW_1Hz, SQW_4kHz, SQW_8kHz, SQW_32kHz, SQW_OFF };

[Flags]
// Defines the logic level on the SQW pin when the frequency is disabled
public enum SQWDisabledOutputControl { Zero, One };

// Real time clock I2C address
public const int DS1307_I2C_ADDRESS = 0x68;

// Start / End addresses of the date/time registers
public const byte DS1307_RTC_START_ADDRESS = 0x00;
public const byte DS1307_RTC_END_ADDRESS = 0x06;

// Start / End addresses of the user RAM registers
public const byte DS1307_RAM_START_ADDRESS = 0x08;
public const byte DS1307_RAM_END_ADDRESS = 0x3f;

// Square wave frequency generator register address
public const byte DS1307_SQUARE_WAVE_CTRL_REGISTER_ADDRESS = 0x07;

// Start / End addresses of the user RAM registers
public const byte DS1307_RAM_START_ADDRESS = 0x08;
public const byte DS1307_RAM_END_ADDRESS = 0x3f;

// Total size of the user RAM block
public const byte DS1307_RAM_SIZE = 56;

Next the driver defines an I2C device object representing the clock:

// Instance of the I2C clock
protected I2CDevice Clock;

In the class constructor, the I2C clock device is initialized, specifying its address and speed in KHz:

public DS1307(int timeoutMs = 30, int clockRateKHz = 50) {
    TimeOutMs = timeoutMs;
    ClockRateKHz = clockRateKHz;
    Clock = new I2CDevice(new I2CDevice.Configuration(DS1307_I2C_ADDRESS, ClockRateKHz));
}

The driver retrieves the date and time from the clock through a Get function returning a DateTime object.

public DateTime Get() {
    byte[] clockData = new byte [7];

    // Read time registers (7 bytes from DS1307_RTC_START_ADDRESS)
    var transaction = new I2CDevice.I2CTransaction[] {
    I2CDevice.CreateWriteTransaction(new byte[] {DS1307_RTC_START_ADDRESS}),
        I2CDevice.CreateReadTransaction(clockData)
    };

    if (Clock.Execute(transaction, TimeOutMs) == 0) {
        throw new Exception("I2C transaction failed");
    }

    return new DateTime(
        BcdToDec(clockData[6]) + 2000, // year
        BcdToDec(clockData[5]), // month
        BcdToDec(clockData[4]), // day
        BcdToDec(clockData[2] & 0x3f), // hours over 24 hours
        BcdToDec(clockData[1]), // minutes
        BcdToDec(clockData[0] & 0x7f) // seconds
    );
}

Let's break it down:

• A 7-byte array is allocated which will receive the raw date and time data registers, starting at address DS1307_RTC_START_ADDRESS (0x00) and ending at DS1307_RTC_END_ADDRESS (0x06).
• An I2C transaction object is allocated, comprising two parameters:
  • A 'write' transaction object telling the DS1307 device which register address to start reading data from. In this case, this is DS1307_RTC_START_ADDRESS (0x00), the very first time-keeping register.
  • A 'read' transaction object specifying where the clock's time-keeping data registers will be stored, implicitly defining the total number of bytes to be read and acknowledged.
• Clock.Execute is the function calling into the .NET MF I2C interface to run the prepared transactions. The second parameter specifies a time out value expressed in milliseconds before the transaction fails, resulting in a generic exception being thrown.
• When the transactions succeed, a DateTime object is instantiated with the 7 time-keeping registers returned by the 'read' transaction. Each register is converted from Binary Coded Decimal form to decimal form using a custom utility function:

protected int BcdToDec(int val) {
    return ((val / 16 * 10) + (val % 16));
}

Conversely, the driver provides a Set function to update the clock's time-keeping registers. Because the driver doesn't expect a response from the DS1307 in this scenario, the I2C transaction is write-only. The fields of the DateTime parameter corresponding to the time -keeping registers are converted from decimal form to BCD form and stuffed in a 7-byte array before executing the transaction.

public void Set(DateTime dt) {
    var transaction = new I2CDevice.I2CWriteTransaction[] {
        I2CDevice.CreateWriteTransaction(new byte[] {
            DS1307_RTC_START_ADDRESS,
            DecToBcd(dt.Second),
            DecToBcd(dt.Minute),
            DecToBcd(dt.Hour),
            DecToBcd((int)dt.DayOfWeek),
            DecToBcd(dt.Day),
            DecToBcd(dt.Month),
        DecToBcd(dt.Year - 2000)} )
    };

    if (Clock.Execute(transaction, TimeOutMs) == 0) {
        throw new Exception("I2C write transaction failed");
    }
}

The rest of the functions provided by the C# driver implement the other DS1307 features, such as

• SetSquareWave
• Halt
• SetRAM
• GetRAM
• The [] operator used to access a specific clock register
• WriteRegister

In all case, these functions are wrappers around the 'read' and 'write' I2C transaction model, involving the appropriate DS1307 registers as defined in the datasheet. 

Using the Adafruit Arduino Logger Shield as a temperature logger

To illustrate the points discussed so far, we'll use the Adafruit Arduino Logger shield with a Netduino and a MAX6675 thermocouple amplifier for the purpose of recording ambient temperature samples at ten second intervals.

Each record includes a date, a time and the temperature expressed in Celsius and Fahrenheit. The records are written to daily files in CSV format for easy export to a spreadsheet, making the application easily adaptable for acquiring data from different sensors:

Device Connections

Instead of permanently soldering the temperature sensor to the prototyping area of the shield, female / female jumper wires were used to make connections between the shield's own pin headers as well as the thermocouple's male pin headers.

The following table enumerates these connections:

Reading temperature using an Adafruit Max6675 Thermocouple amplifier breakout board

The Max6675 thermocouple amplifier chip on the breakout board is a read-only SPI device. When the CS pin (SPI /SS) of the device is asserted with a 1ms delay before reading, the chip returns a 12-bit value on its DO pin (SPI MISO) corresponding to the temperature measured by a K-type Thermocouple wire. The resulting C# driver for the Max6675 is short:

using System;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;

namespace Maxim.Temperature{
    public class Max6675 : IDisposable {
        protected SPI Spi;

        public void Initialize(Cpu.Pin chipSelect) {
            Spi = new SPI(
            new SPI.Configuration(
            chipSelect, false, 1, 0, false, true, 2000, SPI.SPI_module.SPI1)
            );
        }

        public double Celsius {
            get { return RawSensorValue * 0.25; }
        }

        public double Farenheit {
            get { return ((Celsius * 9.0) / 5.0) + 32; }
        }

        protected UInt16 RawSensorValue;
        protected byte[] ReadBuffer = new byte[2];
        protected byte[] WriteBuffer = new byte[2];

        public void Read() {
            RawSensorValue = 0;
            Spi.WriteRead(WriteBuffer, ReadBuffer);
            RawSensorValue |= ReadBuffer[0];
            RawSensorValue <<= 8;
            RawSensorValue |= ReadBuffer[1];

            if ((RawSensorValue & 0x4) == 1) {
                throw new ApplicationException("No thermocouple attached.");
            }

            RawSensorValue >>= 3;
        }

        public void Dispose() {
            Spi.Dispose();
        }

        ~Max6675() {
            Dispose();
        }
    }
}

Temperature logger application walkthrough

Let's review the key parts of the temperature logging application code and how it interacts with the devices connected to the shield.

public static readonly string SdMountPoint = "SD";

Defines an arbitrary string used to refer to the SD card when using StorageDevice.MountSD and StorageDevice.Unmount functions.

public static readonly int TemperatureLoggerPeriod = 10 * 1000; // milliseconds

Defines the interval between temperature samples.

public static OutputPort LedRed = new OutputPort(Pins.GPIO_PIN_D0, false);

Defines an output connected to pin D0 controlling the state of the red LED on the shield.

public static OutputPort LedGreen = new OutputPort(Pins.GPIO_PIN_D1, false);

Defines an output connected to pin D1 controlling the state of the green LED on the shield.

public static InputPort CardDetect = new InputPort(
    Pins.GPIO_PIN_D3,
    true,
    Port.ResistorMode.PullUp);

Defines an input connected to pin D3 used to determine if an SD card is inserted in the SD socket.

public static ManualResetEvent ResetPeripherals = new ManualResetEvent(false);

Defines a manual reset event object that will be used in the main application loop to determine when to re-initialize the shield's peripherals.

public static readonly Cpu.Pin ThermoCoupleChipSelect = Pins.GPIO_PIN_D2;

Defines D2 as the SPI chip select pin connected to the Max6675 Thermocouple board.

public static Timer TemperatureSampler;

Defines an instance of a timer object which will drive temperature sampling.

public static DS1307 Clock;

Defines an instance of the DS1307 real time clock driver.

public static Max6675 ThermoCouple;

Defines an instance of the Max6675 thermocouple driver.

public static ArrayList Buffer = new ArrayList();

Defines an array list instance which will be used as a temporary buffer when the SD card is removed from its socket.

The application's main loop is only concerned about the state of the peripherals:

• It initializes the devices connected to the shield
• It waits indefinitely for a signal indicating that a hardware error occurred
• It disposes of the current device instances and starts over

public static void Main() {
    while (true) {
        InitializePeripherals();
        ResetPeripherals.WaitOne();
        ResetPeripherals.Reset();
        DeInitializePeripherals();
    }
}

InitializePeripherals indicates that it is working by controlling the green LED on the shield. Its role is focused on object creation and initialization.

public static void InitializePeripherals() {
    LedGreen.Write(true);
    Clock = new DS1307();
    ThermoCouple = new Max6675();
    InitializeStorage(true);
    InitializeClock(new DateTime(2012, 06, 14, 17, 00, 00));
    ThermoCouple.Initialize(ThermoCoupleChipSelect);
    TemperatureSampler = new Timer(
    new TimerCallback(LogTemperature),
    null,
    250,
    TemperatureLoggerPeriod);
    LedGreen.Write(false);
}

If the initialization of a peripheral fails, the shield will quickly blink its LEDs, indefinitely:

public static void SignalCriticalError() {
    while (true) {
        LedRed.Write(true);
        LedGreen.Write(true);
        Thread.Sleep(100);
        LedRed.Write(false);
        LedGreen.Write(false);
        Thread.Sleep(100);
    }
}

The clock initialization function only sets the clock date and time when it is unable to find a file named 'clockSet.txt' on the SD card, ensuring that the initialization of the DS1307 only happens once in the InitializePeripherals function or until the file is deleted.

public static void InitializeClock(DateTime dateTime) {
    var clockSetIndicator = SdMountPoint + @"\clockSet.txt";

    try {
        if (File.Exists(clockSetIndicator) == false) {
            Clock.Set(dateTime);
            Clock.Halt(false);
            File.Create(clockSetIndicator);
        }
    } catch (Exception e) {
        LogLine("InitializeClock: " + e.Message);
        SignalCriticalError();
    }
}

The LogTemperature function is the callback invoked by the Timer object every 10 seconds. The function indicates that it is working by turning the red LED on the shield ON and OFF.

public static void LogTemperature(object obj) {
    LedRed.Write(true);
}

The function reads the current time from the clock with Clock.Get() and takes a temperature sample with ThermoCouple.Read().

var tickStart = Utility.GetMachineTime().Ticks;
var now = Clock.Get();
ThermoCouple.Read();
var elapsedMs = (int)((Utility.GetMachineTime().Ticks - tickStart) / TimeSpan.TicksPerMillisecond);

Then, it concatenates a string containing the date, time and temperature expressed in Celsius and Fahrenheit, with each field separated by commas.

var date = AddZeroPrefix(now.Year) + "/" + AddZeroPrefix(now.Month) + "/" + AddZeroPrefix(now.Day);
var time = AddZeroPrefix(now.Hour) + ":" + AddZeroPrefix(now.Minute) + ":" + AddZeroPrefix(now.Second) + ":" + AddZeroPrefix(elapsedMs);
var celsius = Shorten(ThermoCouple.Celsius.ToString());
var farenheit = Shorten(ThermoCouple.Farenheit.ToString());
var latestRecord = date + "," + time + "," + celsius + "," + farenheit;

To make the data more manageable, daily temperature files are created as needed, each one starting with the column headers expected for parsing the values in CSV format.

var filename = SdMountPoint + BuildTemperatureLogFilename(now);
if (File.Exists(filename) == false) {
    using (var tempLogFile = new StreamWriter(filename, true)) {
        tempLogFile.WriteLine("date,time,celsius,fahrenheit");
    }
}

The temperature sampling application lets the user remove the SD card from its socket so that the CSV files can be moved over to a PC for processing without losing data in the meantime. In order to do this, the application checks the state of the 'Card Detect' pin before attempting file system I/Os.

When the SD card is not present, the latest temperature record is preserved in the array list buffer until the SD card is put back in its socket. The array list data is then flushed to storage.

if (CardDetect.Read() == false) {
    using (var tempLogFile = new StreamWriter(filename, true)) {
        if (Buffer.Count != 0) {
            foreach (var bufferedLine in Buffer) {
                tempLogFile.WriteLine(bufferedLine);
            }
            Buffer.Clear();
        }
        tempLogFile.WriteLine(latestRecord);
        tempLogFile.Flush();
    }
} else {
    LogLine("No card in reader. Buffering record.");
    Buffer.Add(latestRecord);
}

The temperature logging function expects to run out of memory if the array list buffer grows too large, in which case, all the records get purged. Other memory management strategies could be used to mitigate data loss in this case. However, this depends entirely on the requirements of the data logging application and is out of scope for this discussion.

catch (OutOfMemoryException e) {
    LogLine("Memory full. Clearing buffer.");
    Buffer.Clear();
}

The temperature logging function also handles file system exceptions caused by the removal of the SD card and reacts by signaling the ResetPeripherals event. In turn, this lets the application's main loop know that the peripherals, and most specifically the SD card, need to be recycled and initialized again in order to recover from the error.

catch (IOException e) {
    LogLine("IO error. Resetting peripherals.");
    Buffer.Add(latestRecord);
    ResetPeripherals.Set();
}

Conclusion

In this article, we took a shield designed for the Arduino and learned how to critically review the Arduino code libraries supporting it, drawing parallels with features offered by the .NET Micro Framework. This process allowed us to identify areas in the Arduino code which were not necessary to port over to C# such as SD card and file system handlers. It also allowed us to see the similarities in the way the Arduino and the Netduino handle I2C communications.

Most importantly, we also learned the importance of reviewing a device's schematics and component datasheets to ensure that important features have not been omitted and potentially incorrectly implemented when considering using an unknown library: in the case of RTClib, we saw that the implementation was limited to the basic date and time functions of the DS1307, leaving out other useful features such as the clock's built-in RAM and the square wave generation functions.

In our next article, we'll take on a much more complex shield and we will learn how to analyze Arduino libraries in depth before porting them from C/C++ to C#.

Bio

Fabien is the Chief Hacker and co-founder of Nwazet, a start-up company located in Redmond WA, specializing in Open Source software and embedded hardware design. Fabien's passion for technology started 30 years ago, creating video games for fun and for profit. He went on working on mainframes, industrial manufacturing systems, mobile and web applications. Before Nwazet, Fabien worked at MSFT for eight years in Windows Core Security, Windows Core Networking and Xbox. During downtime, Fabien enjoys shooting zombies and watching sci-fi.

LogicCircuit

Description

LogicCircuit – is educational software for designing and simulating digital logic circuits.
Intuitive graphical user interface, allows you to create unrestricted circuit hierarchy with multi bit buses, debug circuits behavior with oscilloscope, and navigate running circuits hierarchy.

Official Web site

The official web site was created. Please visit it at: http://www.LogicCircuit.org

How does it work? How do you create your own?

Short user guide

There are two modes the program can be in: edit mode and running mode. To switch use power button on the status bar, checkbox on the sliding tool panel on the bottom or use short cut: Ctrl+W.

In edit mode on the left side you can see all available circuits. Just drag and drop them where you want on the diagram – right part of the window. In order to wire circuits just click connector – bold dot on the side of the circuits and then click where you want your wire be extended to. Wires are connected only if their ends are in the same location. If you just cross two wires they are not connected.

By double clicking items on the diagram you can start editing them. So double click on pin, constant, memory, or button will open dialog where you can change properties of the item. Double click symbol of logical circuit you’ve created will switch you to this circuit. To change properties of the entire project select menu Circuit/Project, to change properties of the currently edited logical circuit either double click anywhere in empty space on the diagram or select menu Circuit/Logical Circuit.

In order to select an item on diagram, just click it. To add an item to selection or remove it from - hold Ctrl and click. Press and move mouse you can select everything in marked area. Hold Shift and click wire to select entire conductor. Ctrl+A will select everything on the diagram. Edit menu contains some other useful commands to select and unselect symbols on the circuit diagram.

When you create a new circuit it becomes available for you to use on other circuits.

• Use input and output pins as interface with external circuits.
• Use probes to observe state of the circuits when it is in running mode.

When in running mode you can interact with you circuits through buttons and double clicking constants – which increment value of constant within it bit width.
If you have some probes connected on your circuits you can open oscilloscope and watch history of the states of your probes.

To switch between your circuits you can double click them on the left panel or pressing Ctrl + Tab or Ctrl + Shift + Tab to navigate through circuits in reverse historical order. Press Tab more than once while holding Ctrl to navigate further in the history.

Happy designing!

Logic Circuit - Editing circuits

When you first open LogicCircuit it will be one empty logical circuit visible on the right pane of the program window named "Main".

Following the above getting started guides, I had my first circuit running in seconds.

What can you build with?

I mentioned the source was available? Yep! And the latest check-in ran for me the first time... Here's a snap of the Solution.

That's right, you get all the source behind this cool tool.

If you want to play with building circuits but soldering iron phobia, want to quickly play with some design ideas or are looking for some really interesting code to spelunk, LogicCircuit is a project that's under active development and just a download away...

Posture Regulator using .NET Gadgeteer Accelerometer from Seeed Studio

People who work in technology often spend many hours at the computer, which can make it difficult to maintain good posture. I’ve been advised by a physical therapist to keep my chest high with my head and neck upright. The problem is that fatigue tends to make me slouch. Then my neck is out of alignment, leading to some unpleasant grinding of vertibrae and tension in the shoulders.

The .NET Gadgeteer device in this example uses the Seeed accelerometer module, which can be calibrated with a single function to set the base position that should be maintained. I use a relay module, also from Seeed Studio, to activate a beeper when the Z axis of my posture varies too far from the calibrated normal.

The accelerometer is similar to the sensor in a cell phone that detects whether the phone is in the horizontal or vertical orientation. The methods that the Seeed module supports are more than adequate for this application. There is a method to calibrate the position from which variation is measured. Monitoring the Z axis of the variation is sufficient to detect the kind of slouching I’m trying to avoid. For this prototype I simply attached the accelerometer to my sweater with a safety pin, as shown in the following photo.

Posture Regulator with LED Alert – Silent

This is a second iteration on the device using a Seeed accelerometer as posture sensor that sends alerts when the user’s posture lapses from the position desirable for working extended periods in the seated position. The previous version used a buzzer on a relay circuit as an alert. It produced a sound that could drive one to distraction. This version uses a LED that simply turns red when the user wearing the accelerometer slouches or leans too far from the desirable vertical position.

The modules used in this application are shown in the following screen shot from the .NET Gadgeteer Designer.

Posture Accelerometer Sensor LED Alert

This implementation of the posture sensor is different from the previous version in that it doesn’t require a relay circuit to turn on a buzzer. It uses the GHI Electronics multicolored LED module. It also uses the Seeed OLED Display module instead of the larger and more expensive Display T35 from GHI Electronics.

The application logic is similar in this version to the previous except that it omits the relay circuit and turns on the LED instead of the buzzer. The following illustration shows the working components.

...

One surprising discovery in this version is that the Accelerometer.StartContinuousMeasurements method has to be set at a lower frequency than the previous version. Having the relay running on the board changed the configuration so that the button could interupt the continuous measurements and turn off the measurements. In this version I found that pushing the on/ off button had no effect until I slowed the rate of continuous measurements.

Come on, what hardware hacker wouldn't want to wear something like that? Now to make it portable, and report posture results to a web site (and tweet them?), maybe some Bluetooth integration to an app, and... and... and...

OBD-II

OBD stands for On-Board Diagnostics.  In the world of cars, this can be thought of as the computer which has a variety of data points which can be queried, such as speed, fuel level, and even trouble codes that relate to the check engine light.  If you've ever taken your car in for service, your service center has hooked up the car to a computer via the OBD port to get the status of the car and what may not be working properly.

Getting Started

To use the OBD library with your vehicle, first you need an OBD to USB or serial cable.  These can be found in numerous places, but we recommend this cable from ScanTool.net, which was used with the Project Detroit car and our software.  Here's how to get connected:

1. With the car off, plug the OBD end into your vehicle.  The port is in a different location in every vehicle, but it's guaranteed to be somewhere near the driver's location.
2. Plug the USB/serial end of the cable into your computer and note which COM port the cable is connected to.
3. Update the app.config file of the InstrumentCluster project with that COM port.
4. Start the car.
5. Run the InstrumentCluster application, and data should start flowing.

Calling the OBD library programmatically

• Create an instance of the ObdDevice class
• Call the Connect method with the appropriate COM port, baud rate, and, if known, OBD protocol
• From here, the library works in two ways: automatic polling or manual polling
  • Automatic – Pass true to the Connect method. This will poll the OBD as quickly as it can requesting RPM, MPH, MPG, Fuel Level and Engine Coolant Temperature. Note that not all vehicles will support all of these. In this mode, hook the ObdChanged event to receive an ObdState packet with the new data.
  • Manual – Pass false to the Connect method. Then, create your own thread and call the ObdDevice's Get methods to retrieve the data you want as quickly as you want it.  This is the way we used the library in Project Detroit.  We polled manually, collecting the speed, RPM, and other critical data as quickly as possible, while only reading things like fuel level every few seconds.

OBD is a polled system, so data can only be returned as quickly as the time it takes to request it and return it. In short, only retrieve what you need when you need it.

ObdDevice obd;

obd = new ObdDevice();
obd.ObdChanged += _obd_ObdChanged;

// com port, baud rate, protocol (if known), automatic polling
obd.Connect("COM1", 115200, ObdDevice.UnknownProtocol, true);

...

void obd_ObdChanged(object sender, ObdChangedEventArgs e)
{
    e.ObdState.ToString();
}

Customizing the Instrument Cluster

The Instrument Cluster application is a WPF application that has 3 different skins which can be viewed by swiping left or right in the application, either with a finger, or the mouse.  This is a simplified version of the actual application we used in the Project Detroit car, modified to talk straight to the OBD port instead of our intermediate WCF service.  Please note that this isn't a robust, drop-in replacement application for a car dashboard, but only a sample of how the OBD library can be used.

Internally, the application uses the OBD library and hooks the ObdChanged event.  The ObdChanged event returns a minimal amount of important data.  When the event fires, the the SetInstrumentClusterValues method is run, which sets the OBD values to each gauge in whichever skin is currently visible.

private void SetInstrumentClusterValues(ObdState measurement)
{
    foreach (var item in _skins)
    {
        if(!item.IsVisible)
            continue;
        item.IsMalfunctionVisible = measurement.MilLightOn;
        item.IsLowFuelVisible = item.Fuel < 10;
        item.MPG = measurement.MilesPerGallon;
        item.MPH = measurement.MilesPerHour;
        item.RPM = measurement.Rpm;
        item.Fuel = measurement.FuelLevel;
        item.Temperature = measurement.EngineCoolantTemperature;
    }
}

More Information

• Project Detroit
• More information on OBD-II
• ELM323/327 Datasheet
• OBD-II to USB cable

Known Issues / Limitations

• This is known to work with cables that uses the ELM323/327 chipset. The specific cable that was used to develop this library is available from ScanTool.net, however other ELM323/327 OBD-II to USB cables should work.
• There are a variety of different OBD-II signal protocols. This library only supports a few of them. If your car's OBD protocol is not supported, please feel free to add it and send us the changes to integrate back into the library!
• If the vehicle has multiple ECUs, the ECU with the most PIDs is used. The other ECUs are ignored.
• Not every standard PID is supported.
• No custom manufacturer/model-specific PIDs are supported.

The Netduino is an open source electronics platform based on a 32-bit microcontroller running the .NET Micro Framework. The Netduino Plus is similar to the original Netduino, but adds a built-in Ethernet controller and MicroSD slot. Since the Netduino Plus can connect directly to a network, it can independently communicate with Twitter’s API without being connected to a computer.

Hardware Overview

The MakerShield is a simple prototyping shield that is compatible with the standard Arduino and Netduino boards.

In this configuration, the MQ-3 alcohol gas sensor will output an analog voltage between 0 and 3.3V to indicate the amount of alcohol detected. This output will be connected to one of the Netduino’s analog input pins and read by its ADC.

While it would possible to convert the sensor’s output to a numeric BAC level, this would require careful calibration and would be prone to error. For this project, I will use approximate value ranges to determine which of several messages should be posted to Twitter. An approximate reading will be displayed on an RGB LED.

RGB LED

The RGB LED is the primary status indicator. During normal operation, it shows the level of alcohol, represented by colors ranging from green to red.

Three transistors are used to provide power to the RGB LED. The microcontroller used on the Netduino has a relatively low current limit per IO pin (around 8 mA for most pins) so it is generally not advised to drive LEDs (which can require 20-30 mA) directly from these pins. Using a transistor (or another LED driver) helps ensure that enough power will be made available to each LED without damaging the Netduino.

This page shows some common transistor circuits, including a few "transistor as a switch" circuits. Since the RGB LED I am using has a common cathode (low side) lead, I am using PNP transistors to switch the anode (high side) of each color.

Alcohol Gas Sensor

The MQ-3 essentially has two components: a heater and an alcohol gas sensor. The heater literally applies heat to the sensor in order to provide more accurate measurements and requires a constant 5V power source. The alcohol sensor acts as a variable resistor, where the resistance decreases as the level of alcohol increases.

While the heating element requires 5V, the alcohol sensor can actually operate at a different voltage. Applying 3.3V to the sensor (V_C in the above diagram) will ensure that the output voltage (V_RL) doesn’t exceed the Netduino’s input limits.

The sensor and R_L act as a voltage divider. The datasheet for this sensor shows that the resistance across the sensor is between 2K-20K ohms, so an R_L value of 10K ohms will provide a wide voltage output range.

Other Components

The MakerShield has two LEDs that I am using to display some additional status information. The red LED indicates whether the device is ready to post to Twitter, and the Green LED indicates that a post is in progress.

I am also using the button on the MakerShield to trigger the Netduino to post a message on Twitter. You could also write code to automatically post based on level peak detection, but for simplicity I decided to just use the button as a trigger.

Code

Pin configuration, Twitter API keys, the NTP server address, and other settings are stored in a Config class (Config.cs in the project root). If you download the source code for this project from CodePlex, make sure you copy the Config.sample.cs to Config.cs and take a look through the file to confirm all the settings:

public static class Config
{
    // NTP Server
    public const string NTPServer = "time-a.nist.gov";
    public const int TimeOffset = -7;    // MakerShield LEDs
    public const Cpu.Pin RedLEDPin = Pins.GPIO_PIN_A5;
    public const Cpu.Pin GreenLEDPin = Pins.GPIO_PIN_A4;    // RGB LED
    public const Cpu.Pin RGBRedPin = Pins.GPIO_PIN_D10;
    public const Cpu.Pin RGBGreenPin = Pins.GPIO_PIN_D6;
    public const Cpu.Pin RGBBluePin = Pins.GPIO_PIN_D9;
    public const bool RGBInverted = true;    // Button
    public const Cpu.Pin ButtonPin = Pins.GPIO_PIN_A3;    // Alcohol Gas Sensor
    public const Cpu.Pin SensorPin = Pins.GPIO_PIN_A0;
    // The Netduino's 10-bit ADC has a maximum value of 1023, but the sensor may not reach the highest possible voltage.
    // Input values >= the SensorMaxValue will be treated as 100%.
    public const int SensorMaxValue = 900;    // Twitter
    public const string ConsumerKey = "YourConsumerKey";
    public const string ConsumerSecret = "YourConsumerSecret";
    public const string UserToken = "YourUserToken";
    public const string UserTokenSecret = "YourUserTokenSecret";
}

In order to post messages on Twitter, it is necessary to register an application through Twitter’s developer portal. Instructions for this can be found on the MicroTweet CodePlex Page.

Startup

When the Netduino first powers on it will wait for a few moments to let the alcohol gas sensor heat up and establish a baseline reading. The sensor’s datasheet recommends a preheat time of 24-48 hours, but the readings typically stabilize after a few minutes. During this time the RGB LED will slowly fade from blue to red to indicate that the sensor is heating up.

RGB LED

A simple RGB LED helper class is included to help make controlling the color and output of the LED easier. The class must be instantiated with three Cpu.Pin addresses, one for each color:

protected static RGBLED rgbLed = new RGBLED(Config.RGBRedPin, Config.RGBGreenPin, Config.RGBBluePin, Config.RGBInverted);

In the sample code, these pins are pulled from the Config class. The last parameter for the RGBLED constructor, invertOutput, is used to determine whether a logical high output value turns the LED on or off.

NTP

Next, the Netduino will attempt to update the system time from an NTP server. This is necessary for communication with Twitter’s OAuth API because all requests must contain an accurate timestamp. If the NTP server is unreachable, the Twitter functionality will be disabled, but it will still be possible to see the alcohol level on the RGB LED.

The code to communicate with an NTP server is included with the MicroTweet library. The UpdateTimeFromNTPServer method will contact the specified NTP server and update the Netduino’s time:

NTP.UpdateTimeFromNTPServer(Config.NTPServer);

If the time is updated successfully, a new instance of the TwitterClient class is created:

twitterClient = new TwitterClient(Config.ConsumerKey, Config.ConsumerSecret, Config.UserToken, Config.UserTokenSecret);

Measurements

Measurements from the alcohol sensor are repeatedly taken within the main program loop. The 10-bit ADC will return a value between 0 and 1023, but these values don’t necessarily correspond to the minimum/maximum readings from the alcohol sensor so some calculations are performed to convert the ADC value to a number between 0 and 100:

protected static AnalogInput SensorInput = new AnalogInput(Config.SensorPin);// ...public static int GetSensorValue()
{
    int rawValue;
    lock (SensorInput)
    {
        rawValue = SensorInput.Read();
    }
    int adjustedValue = (rawValue - SensorMinValue) * 100;
    int result = adjustedValue / (Config.SensorMaxValue - SensorMinValue);
    return result;
}

SensorMinValue is the baseline measurement established when the program was starting up. Config.SensorMaxValue is the configured "maximum" value that indicates the highest detectable alcohol level. Depending on your sensor, this maximum value may need to be adjusted.

It’s also worth noting that it can take about 30 seconds for the sensor to return to its baseline value after a measurement. This screenshot shows the sensor’s output before and after taking a reading:

In this test, the baseline measurement (with no alcohol applied to the sensor) was about 1V. When alcohol was applied to the sensor the output quickly peaked at just under 3V, and then slowly decreased once the alcohol was removed.

Posting to Twitter

Sending a tweet from a TwitterClient instance is simple:

twitterClient.SendTweet("Hello, world!");

In this project, the MakerShield’s button is used to trigger the Netduino to post a message on Twitter. This button is monitored by an instance of the InterruptPort class, which fires a C# event when the input changes on the selected pin:

protected static InterruptPort button = new InterruptPort(Config.ButtonPin, true, Port.ResistorMode.PullUp, Port.InterruptMode.InterruptEdgeLevelLow);// ...static void button_OnInterrupt(uint data1, uint data2, DateTime time)
{
    if (twitterClient == null)
        return;
    greenLED.Write(true);    int sensorValue = GetSensorValue();    string message;
    if (sensorValue < 20)
        message = "No alcohol detected";
    else if (sensorValue < 40)
        message = "Tipsy";
    else if (sensorValue < 60)
        message = "Drunk";
    else if (sensorValue < 80)
        message = "Whoa! #WINNING";
    else
        message = "x_x";    DateTime adjustedTime = DateTime.Now + new TimeSpan(Config.TimeOffset, 0, 0);    message += " at " + adjustedTime.ToString("h:mm:ss tt");    try
    {
        twitterClient.SendTweet(message);
    }
    catch (Exception e)
    {
        Debug.Print(e.ToString());
    }    greenLED.Write(false);
    button.ClearInterrupt();
}

The button event handler code in this project is relatively simple: the current level from the alcohol sensor is read, a message is generated, and it attempts to post the message to Twitter. The current time is appended to the end of the message to avoid issues with multiple identical tweets.

Conclusion

The code for this project is included in the Samples folder of the MicroTweet library. Be sure to check out the MicroTweet project page on CodePlex for the source code and more information.

MicroTweet is released under the Apache 2.0 license, so it can be freely used in your own projects with attribution.

About the Author

Matt Isenhower is a desktop and mobile application developer who primarily works with the .NET Framework. His company, Komodex Systems, is currently focused on building new and exciting apps for Windows Phone 7 and other platforms. He also has a blog and can be followed on Twitter at @mattisenhower.

Glenn shares his expertise gained at Newsgator with ISV Architect Evangelist Bruce Kyle. Glenn's book, SQL Server Hardware from Simple Talk Press provides the fundamental knowledge and resources you need to make intelligent decisions about choice, and optimal installation and configuration, of SQL Server hardware, operating system and SQL Server.

Glenn provides a few tips from his book in this video.

You find out more about the book on Amazon. See SQL Server Hardware.

Chapter Outline

1. Processors and Associated Hardware
2. The Storage Subsystem
3. Benchmarking Tools
4. Hardware Discovery
5. Operating System Selection and Configuration
6. SQL Server Version and Edition Selection
7. SQL Server Installation and Configuration

Glenn's Blog

Glenn Berry's SQL Server Performance is one of the best resources for SQL Server tips and tricks. He blogs daily exploring both the hardware and software sides of SQL.

Follow Glenn on Twitter at @GlennAlanBerry.

See his interview with John O'Donnell at Talking with NewsGator at PDC 2009.

About Most Valued Professionals (MVP)

Microsoft recognizes the best and brightest from technology communities around the world with the
Microsoft Most Valuable Professional (MVP) Award. These exceptional community leaders come from a wide range of backgrounds. They are teachers, artists, doctors, engineers, as well as technologists, who actively share their high-quality, real-world technical expertise with the community and with Microsoft.

About NewsGator

NewsGator was founded in 2004 to realize the potential of RSS (Really Simple Syndication) to transform the way people consume information. Today NewsGator's flagship product - Social Sites – is social computing software that’s built directly into Microsoft SharePoint.

Other ISV Videos

For other videos about independent software vendors (ISVs):

• Quark Extends SharePoint for Dynamic Publishing
• ProModel Adds Simulation, Visualization to Microsoft Project
• Thumb-Driven Workflow on Windows 7 Slates from Blue Dot Solutions
• Accumulus Makes Subscription Billing Easy for Windows Azure
• Azure Email-Enables Lists, Low-Cost Storage for SharePoint
• Crowd-Sourcing Public Sector App for Windows Phone, Azure
• Food Buster Game Achieves Scalability with Windows Azure

Up to Date News for ISVs and Software Developers

See US ISV Community blog.

It has gone through quite a few changes and I have expanded it to easily display MJPEG streams on a variety of platforms.  The developer just references the assembly appropriate to their platform, adds a few lines of code, and away it goes.

Usage

For those that are just interested in the usage, it's as simple as this:

1. Reference one of the following assemblies appropriate for your project:
   • MjpegProcessorSL.dll - Silverlight (Out of Browser Only!)
   • MjpegProcessorWP7.dll - Windows Phone 7 (XNA or Silverlight, performance maxes out around 320x240 @ 15fps, so set your camera settings accordingly)
   • MjpegProcessorXna4.dll - XNA 4.0 (Windows)
   • MjpegProcessor.dll - WinForms and WPF
2. Create a new MjpegDecoder object.
3. Hook up the FrameReady event.
4. In the event handler, take the Bitmap/BitmapImage and assign it to your image display control:
5. In the case of XNA, use the GetMjpegFrame method in the Update method, which will return a Texture2D you can use in your Draw method.
6. Call the ParseStream method with the Uri of the MJPEG "endpoint".

That's it!  The source code and binaries above both include projects demonstrating how to use the library on each of these platforms.  As long as you set the appropriate reference, you can just copy and paste the code in the sample to get your project running (changing the Uri, of course).

public partial class MainWindow : Window
{
    MjpegDecoder _mjpeg;

    public MainWindow()
    {
        InitializeComponent();
        _mjpeg = new MjpegDecoder();
        _mjpeg.FrameReady += mjpeg_FrameReady;
    }

    private void Start_Click(object sender, RoutedEventArgs e)
    {
        _mjpeg.ParseStream(new Uri("http://192.168.2.200/img/video.mjpeg"));
    }

    private void mjpeg_FrameReady(object sender, FrameReadyEventArgs e)
    {
        image.Source = e.BitmapImage;
    }
}

If that doesn't fit your needs, you can also access the Bitmap/BitmapImage properties directly from the MjpegDecoder object, or the CurrentFrame property, which will contain the raw JPEG data prior to being decoded.

A Word About Network/IP Cameras

I have tested this against several different cameras.  Each device has its own quirks, but all of them seem to work with this library with one exception:  several cameras will respond differently when an Internet Explorer user agent header is sent with the HTTP request.  Instead of sending down an MJPEG stream, it will send a single JPEG image as Internet Explorer does not properly support MJPEG streams.  Unfortunately, this causes the Silverlight processor to not work properly as the header cannot be changed from the Internet Explorer default.  When this happens, only a single frame will be sent, and the decoding will fail.  The only fix I have found is to use a different camera that doesn't work in this way.

What is MJPEG?

Pretty simply, it's a video format where each frame of video is sent as a separate, compressed JPEG image.  A standard HTTP request is made to a specific URL, and a multipart response is sent.  Parsing this multipart stream into separate images as they are sent results in a series of JPEG images.  The viewer displays those JPEG images as quickly as they are sent and that creates the video.  It's not a well documented format, nor is it perfectly standardized, but it does work.  For more information, see the MJPEG article on Wikipedia.

How Do I Find the MJPEG URL of My Camera?

Excellent question.  Not an excellent answer.  The user manual may mention the URL.  A quick internet search with the model number should get you a result.  Or, you can also try this company's lookup tool.

How Does It Work?

Glad you asked.  If you take a look at the project, you'll notice there isn't much code.  One single file is used with a variety of compiler directives to compile certain portions based on the platform assembly being generated.  The MjpegDecoder.cs/.vb contains the entire implementation.

First, an asynchronous request is made to the provided MJPEG URL inside the ParseStream method.  If we are in a Silverlight environment, the AllowReadStreamBuffering property must be set to false so the response returns immediately instead of being buffered.  Additionally, we need to register the http:// prefix to use the client http stack vs. the browser stack.  Finally, the request is made using the BeginGetResponse method, specifying the OnGetResponse method as the callback.  This will be called as soon as data is sent from the camera in response to our request.

public void ParseStream(Uri uri)
{
#if SILVERLIGHT
    HttpWebRequest.RegisterPrefix("http://", WebRequestCreator.ClientHttp);
#endif
    HttpWebRequest request = (HttpWebRequest)HttpWebRequest.Create(uri);

#if SILVERLIGHT
    // start the stream immediately
    request.AllowReadStreamBuffering = false;
#endif
    // asynchronously get a response
    request.BeginGetResponse(OnGetResponse, request);
}

OnGetResponse grabs the response headers and uses the Content-Type header to determine the boundary marker that will be sent between JPEG frames.

private void OnGetResponse(IAsyncResult asyncResult)
{
    HttpWebResponse resp;
    byte[] buff;
    byte[] imageBuffer = new byte[1024 * 1024];
    Stream s;

    // get the response
    HttpWebRequest req = (HttpWebRequest)asyncResult.AsyncState;
    resp = (HttpWebResponse)req.EndGetResponse(asyncResult);

    // find our magic boundary value
    string contentType = resp.Headers["Content-Type"];
    if(!string.IsNullOrEmpty(contentType) && !contentType.Contains("="))
        throw new Exception("Invalid content-type header.  The camera is likely not returning a proper MJPEG stream.");
    string boundary = resp.Headers["Content-Type"].Split('=')[1];
    byte[] boundaryBytes = Encoding.UTF8.GetBytes(boundary.StartsWith("--") ? boundary : "--" + boundary);
...

It then streams the response data, looks for a JPEG header marker, then reads until it finds the boundary marker, copies the data into a buffer, decodes it, passes it on to whoever wants it via an event, and then starts over.

...
    s = resp.GetResponseStream();
    BinaryReader br = new BinaryReader(s);

    _streamActive = true;

    buff = br.ReadBytes(ChunkSize);

    while (_streamActive)
    {
        int size;

        // find the JPEG header
        int imageStart = buff.Find(JpegHeader);

        if(imageStart != -1)
        {
            // copy the start of the JPEG image to the imageBuffer
            size = buff.Length - imageStart;
            Array.Copy(buff, imageStart, imageBuffer, 0, size);

            while(true)
            {
                buff = br.ReadBytes(ChunkSize);

                // find the boundary text
                int imageEnd = buff.Find(boundaryBytes);
                if(imageEnd != -1)
                {
                    // copy the remainder of the JPEG to the imageBuffer
                    Array.Copy(buff, 0, imageBuffer, size, imageEnd);
                    size += imageEnd;

                    // create a single JPEG frame
                    CurrentFrame = new byte[size];
                    Array.Copy(imageBuffer, 0, CurrentFrame, 0, size);
#if !XNA
                    ProcessFrame(CurrentFrame);
#endif
                    // copy the leftover data to the start
                    Array.Copy(buff, imageEnd, buff, 0, buff.Length - imageEnd);

                    // fill the remainder of the buffer with new data and start over
                    byte[] temp = br.ReadBytes(imageEnd);

                    Array.Copy(temp, 0, buff, buff.Length - imageEnd, temp.Length);
                    break;
                }

                // copy all of the data to the imageBuffer
                Array.Copy(buff, 0, imageBuffer, size, buff.Length);
                size += buff.Length;
            }
        }
    }
    resp.Close();
}

The ProcessFrame method seen above takes the raw byte buffer, which contains an undecoded JPEG image, and decodes it based on the environment.  However this isn't called in the case of XNA which we'll see in a moment:

private void ProcessFrame(byte[] frameBuffer)
{
#if SILVERLIGHT
    // need to get this back on the UI thread
    Deployment.Current.Dispatcher.BeginInvoke((Action)(() =>
    {
        // resets the BitmapImage to the new frame
        BitmapImage.SetSource(new MemoryStream(frameBuffer, 0, frameBuffer.Length));

        // tell whoever's listening that we have a frame to draw
        if(FrameReady != null)
            FrameReady(this, new FrameReadyEventArgs { FrameBuffer = CurrentFrame, BitmapImage = BitmapImage });
    }));
#endif

#if !SILVERLIGHT && !XNA
    // I assume if there's an Application.Current then we're in WPF, not WinForms
    if(Application.Current != null)
    {
        // get it on the UI thread
        Application.Current.Dispatcher.BeginInvoke((Action)(() =>
        {
            // create a new BitmapImage from the JPEG bytes
            BitmapImage = new BitmapImage();
            BitmapImage.BeginInit();
            BitmapImage.StreamSource = new MemoryStream(frameBuffer);
            BitmapImage.EndInit();

            // tell whoever's listening that we have a frame to draw
            if(FrameReady != null)
                FrameReady(this, new FrameReadyEventArgs { FrameBuffer = CurrentFrame, Bitmap = Bitmap, BitmapImage = BitmapImage });
        }));
    }
    else
    {
        // create a simple GDI+ happy Bitmap
        Bitmap = new Bitmap(new MemoryStream(frameBuffer));

        // tell whoever's listening that we have a frame to draw
        if(FrameReady != null)
            FrameReady(this, new FrameReadyEventArgs { FrameBuffer = CurrentFrame, Bitmap = Bitmap, BitmapImage = BitmapImage });
    }
#endif
}

In the case of Silverlight, the BitmapImage object has a SetSource method which takes a stream to be decoded and turned into the image.  In WPF, BitmapImage works differently.  In this case, BeginInit is called, then the StreamSource property is set to the stream of bytes, and finally EndInit is called.  In WinForms, the library will return a Bitmap object which can be initialized with the stream right in the constructor.

In the code above, I look at the Application.Current property to determine if the library is being used by a WPF project.  If that property is not null, it is assumed the library is being called from a WPF project.

When compiled as an XNA library, we have no use for a BitmapImage or a Bitmap…we need a Texture2D object.  The GetMjpegFrame method seen below is what is called by an XNA application during the Update method to pull the current frame:

public Texture2D GetMjpegFrame(GraphicsDevice graphicsDevice)
{
    // create a Texture2D from the current byte buffer
    if(CurrentFrame != null)
        return Texture2D.FromStream(graphicsDevice, new MemoryStream(CurrentFrame, 0, CurrentFrame.Length));
    return null;
}

Conclusion

And that's about it for the library.  Give it a try and please contact me with feedback or if you run into any issues.  Enjoy!

Follow Ben on Twitter or see more on the Windows Team Blog.

00:25 - Acer ICONIA - Dual screen multitouch laptop. We looked at one in the back of the booth because there was a constant crowd around the one out front. Place 5 fingers on the bottom screen to bring up a wheel launcer or 10 fingers to bring up the keyboard.
02:00 - Toshiba Satellite A665-3D - A fast i7-based gaming laptop with 3D glasses with a retail price of around $1300.
02:33 - Sony Vaio P - 8" screen that fits in a back pocket. It has available turn-by-turn GPS navigation and Verizon Broadband built in.
03:18 - HP Envy 14 - The brains inside the much-feared and arguably dangerous Coding4Fun T-Shirt cannon, the 17" version is my main PC, used to edit many of my Channel 9 videos. Why? Because it's a huge screened beauty with Beats Audio that gets a 7.1 WEI score.
04:05 - Samsung Note PC 9 Series 900X - You've never seen a PC like this before. It's one of the lightest, thinnest 13" laptops in the world. The body is Duralumin aircraft metal which feels both solid as a rock and light as a feather. Backlit keyboard, i5 processor. The screen is twice as bright as what you're probably used to, and for speed - world record holder at 12 seconds boot time. When you retire this machine you could use it to split wood. 
05:00 - ASUS Eee Slate EP121 - A slate PC that works as a multitouch device, as a Tablet PC, or with a BlueTooth keyboard. Forward facing camera for video chat and a home button that drives AeroFlip3d.
06:33 - Dell Inspiron duo - Very cool little convertible tablet that works as a laptop and with a push the screen flips around and it works as a touch tablet. It has an optional Audio Station, 2GB of RAM and will play HD movies.

Awesome job Don and thanks for telling us about it! 

Update:  Don has shared his sequence file with us!