We met up last night to have a look at a .NET Gadgeteer module, picking a nice easy module to look at to begin with for: http://www.meetup.com/GadgeteerSouthCoast/. Despite being called the GHI PIR Sensor it is found in the toolbox as a “Motion Sensor”

Here is the view from the top of the module:

There is just the one event which is triggered whenever the sensor spots an IR source (Heat/person), called Motion_Sensed. There is a property that can be checked to see if the sensor can still see the source once it was triggered.

I would have expected to see a data sheen in codeplex, http://gadgeteer.codeplex.com/SourceControl/latest, but there is nothing. Next stop is the module manufacture website/forum. In this case it is GHI and I am not the first to ask questions about the PIR module:

• GHI Forum: http://www.ghielectronics.com/community/forum/topic?id=6930
• Datasheet: http://elecfreaks.com/store/download/datasheet/sensor/DYP-ME003/Specification.pdf
• Info: http://www.elecfreaks.com/398.html

Based on this information I have labelled the POTS and jumper below.

Motion_Sensed event

First lets see how often this event gets triggered. First add code for the event:

And here is what we will execute every time it is triggered:

By setting the time POT to min (anti-clockwise) so the events will be triggered as often as possible. (The distance POT is at the mid point). We get the following output.

Using mainboard GHI Electronics FEZHydra version 1.2
Program Started
Sensor = False
Time span = 00:00:09.9934515
TRIGGER
The thread ‘<No Name>’ (0×3) has exited with code 0 (0×0).
Time span = 00:00:07.8206963
TRIGGER
Time span = 00:00:07.7379289
TRIGGER
Time span = 00:00:06.4709773
TRIGGER
Time span = 00:00:08.7667315
TRIGGER
Time span = 00:00:07.6156723
TRIGGER
Time span = 00:00:06.2445184
TRIGGER
Time span = 00:00:06.6116992

By setting the time POT to max (Clockwise) we get the following output:

Time span = 00:03:42.0452275
TRIGGER
Time span = 00:03:58.3361766
TRIGGER
Time span = 00:03:41.4596557
TRIGGER
Time span = 00:03:40.7306982

So the time range is around 7sec (min) to 230sec (max) which is in keeping with the data sheet, which I think says 5 sec – 300 sec :

Changing the distance POT certainly did change range or sensitivity but it was not so easy to work out the exact trigger distances. however the datasheet shows a range or around 5 –7m and it certainly gets triggered within those ranges.

SensorStillActive property

There is a property that is readable and is of type Boolean, but what can we use it for?

If we run in with the time POT on minimum, distance on 50% and the jumper set to “Repeatedly trigger” we get the following output:

TRIGGER
State changed to: False @ 00:00:00.0011277
State changed to: True @ 00:00:02.2871399
Time span = 00:00:09.5215143
TRIGGER
State changed to: False @ 00:00:00.0650803
State changed to: True @ 00:00:02.4655180

And if we set the jumper to “Single trigger” we get the following:

TRIGGER
State changed to: False @ 00:00:00.0010278
State changed to: True @ 00:00:08.3824435
Time span = 00:00:11.9519795
TRIGGER
State changed to: False @ 00:00:00.0300698
State changed to: True @ 00:00:03.0303744
Time span = 00:00:06.5282752
TRIGGER
State changed to: False @ 00:00:00.0019021
State changed to: True @ 00:00:02.5016538
Time span = 00:00:04.7239091
TRIGGER
State changed to: False @ 00:00:00.0771596
State changed to: True @ 00:00:02.9764812
State changed to: False @ 00:00:06.4768678
Time span = 00:00:06.4945881
TRIGGER
State changed to: True @ 00:00:07.4823129
Time span = 00:00:11.0135769

So I am unsure what the jumper does, but the event is triggered when the SensorStillActive goes to false, it is held false for around 3 seconds then returns to true. The trigger happens every 6sec as expected. I suspect this will get held to false as long as the sensor can still detect an IR source, however my one always stops sensing despite being waved around at a source. Here is what the datasheet has to say about the jumper:

Have some source code:

Fig 1: Adding a compass module to the designer.

This way you are ready to just use the module in your code. This is the normal way to to things… However what if you want to make a change to the driver for a particular module, for example to:

• add an event, method or property,
• perhaps fix an annoying bug,
• add extra debug, or work out how the hardware works,
• load a different driver, such as the GPS/Bluetooth module drivers from Codeplex.com ,
• copy the driver for a similar piece of hardware,
• you want to compile a driver for a different version of NetMF (e.g. upgrade 4.1 –> 4.2)
• you cant be bothered to get WIX setup and working just to make a small change.

The correct way to change a driver is to get the source code VS solution, edit it and then rebuild. This will build an installer (msi) which can be installed and distributed with the changes intact. This process is fine for the final edits and distribution of a driver, but what if you just want to try a few changes? This is a long process as each change results in a build, reinstall , test.

This post is designed to show how to simply edit drivers or include different drivers. It is NOT a substitute for building the install files which should be distributed with each hardware module.

Example

Lets say we want to make an edit to the compass driver, perhaps it does not function as we expected. Here is a summary of what to do:

1. Get the source code. (Either the existing source, or substitute with a different one)
2. Remove the existing driver from your solution.
3. Add the (new) source code to your solution.
4. Add the module to your project.
5. Edit the driver and test.

Get the source code.

There are multiple drivers for some modules, and the alternatives can often be better. (Well at least until the manufacturer incorporates the changes into the distributed driver.)

If you are looking for other drivers try: http://www.codeplex.com/site/search?query=.net%20gadgeteer

The source for the distributed drivers lives here: http://gadgeteer.codeplex.com/SourceControl/latest

I use SVN to get the latest source, but if you just want the source then click the download button. It will give you a zip, be sure to expand it to somewhere sensible, we will be using it later.

Remove the existing driver from your solution.

This step is important as it can drive you crazy later by swapping your new driver with the old one when you least suspect it.

Here is some background information first:

If we look a the code behind the designer we can see what happens when the compass module is added.

Click “Show all files” if you cannot see the “Program.gadgeteer.cs” file. This file is generated EVERY time you save the designer (the place you drag modules onto). Inside this file there is the following code. (For this example project)

The first line of importance creates a compass variable of type Gadgeteer.Modules.Seeed.Compass.

The second line of importance is the one that creates an instance of the compass object and specifies the socket number.

In order to create the compass object it needs to know about it. This is achieved automatically by adding a reference to the compiled DLL, when you dragged in a new module.

Here are the things you need to change to remove the old driver:

1) Delete the module from the designer.

- This will remove it from the generated code and will stop the auto generated code swapping back to the old driver when you save.

2) Check that the references on your project no longer reference the DLL for the old driver. (highlighted above)

or

You could just start with a blank project.

The reason I show all this is that later on you will need to instantiate the object yourself. If you don’t know what to write you can copy the auto generated code … more later.

Add the (new) source code to your solution.

At this point you have a blank project or one that does NOT reference/use the module that you plan to edit the driver for. First we need to add the source code, this is the code that you downloaded earlier or can be a different driver that you wish to try.

In Visual studio right click on the solution and add an existing project by navigating to the correct project. (This can be a little confusing as it tends to be a long way down the folder structure, and you need to be sure of the version you are using, v4.2)

Inside the Compass –> software folder you are looking for the compass.csproj file. (I would expect to see 2 versions, one for 4.1 and one for 4.2, but this may not be the case if an old driver template was used.)

A little note: In this particular case there is just a driver for the 4.1 version of NetMF, yet when you install the latest SDK the compass is available in 4.2. This means that the manufacturer has updated the driver but not uploaded the changes to Codeplex. Be sure to encourage manufacturers to keep the source updated. This could also be the case if the Codeplex source code has different methods/signatures. Since my project is v4.2 I will just choose to update the target framework in the project properties.(Good example of how to upgrade versions)

Add the module to your project

At this stage you should have multiple projects in your solution. Your project as well as the project for the module you are wanting to edit. So now we have all the source code in place. Lets use it.

First we need to let our project know about the new project by adding a reference, but instead of referencing the DLL we reference the project with the source code.

It is under projects not the .NET tab:

You will then see a reference to the Compass project, note that this is different to the reference show above when you let the designer import it.

Now we are ready to use the module. Remember all the automatically generated code that the designer does for you, well now you have to do it yourself. Instead of adding to code to the generated file (you will loose it , when it auto generates) we add it to the main program.cs file. (only 2 lines)

First create a private variable for the compass then in the program started create an instance, on socket 8. Be sure not to use the socket in the designer – you will get a warning if you do so fear not.

Edit the driver and test.

If you have made it this far then you have a solution that builds a module from source and instantiates the module, ready for use. Have a go to see if it works as expected and all the methods are there.

Now down to the best bit, you can now just change the module source and deploy as you normally would. The compass project will be rebuild every time. For example you may want to know exactly what the ‘Gain’ value is and how it is set. The module has a setgain method which takes a Gain property. The property ranges from Gain1 to Gian8, if you hold your mouse over the property it will display a tooltip, but lets go look at the source.

If you right click on a method (and have the source available) you can select “Go to definition” and it will take you to the code – got to love Visual Studio.

The method source simply writes a value to a register, where the value is of type ‘Gain’ (Right click on ‘Gain’ and go to definition)

Here are the values :

If you rename one of these values, it will have an immediate effect on your code. For example:

Will immediately change in your program.cs

Job done, you are now able to edit the driver and have the changes take effect immediately. Compile is same as always and the solution will deploy your latest code to the hardware when you deploy. This way you can edit and change code until you are satisfied. Once that is done you can then go back to the Compass SOLUTION and build an installer…..

Advanced – where did these numbers come from?

But you have to wonder what these values are and what do they mean? Here is where we need the datasheet. A few folders up from the source code there is a ‘Hardware’ folder that has a datasheet. I you have a custom modules or there is not datasheet you can do very well by searching for the chip number. If stuck pester the manufacturer to add a link to the datasheet for the module. 

This compass module is a HMC5883 and there is a data sheet in the Hardware folder (in the downloaded zip from codeplex) :

These can be hard to read, but we can use the bits we are interested in. For example searching the datasheet for ‘Gain’ shows that there is a gain control and that there are 3 bits dedicated to changing it.

Further on in the datasheet there is a section about ‘configuration register B’ this is for setting the gain. Remember that the gain method just writes a byte (8 bits) to a register (Register B), table 10 lets us know that the register is 1 byte (8 bits) – same as our code. So now we just need to check the values that are to be written. Table 10 on page 13 shows that bits 7,6,5 are for setting the gain and 4-0 must be set to zero. Table 12 shows the different gain values and shows how this changes the output.

For example the default gain is 1024 counts/Gauss and this is done by setting the 8 bits of the register to [0,0,1,0,0,0,0,0] but if we look at the code the values are written in hex not binary.

If you are not comfortable converting, believe it or not calculator is your friend! Change calculator into programmer mode:

Select binary and then input the binary you want to convert, in this case [0,0,1,0,0,0,0,0]  (note you do not need to leading zeros)

If you then select hex, it will convert the value. (Answer 20)

Since the compiler would not know if we meant 20 (twenty) or 20 (thirty two in decimal,or binary [0,0,1,0,0,0,0,0]) there is a prefix added to a number to let it know that it is hex, the prefix is ‘0x’. And sure enough if we look at the code the default gain is ‘0×20’ which is the correct value according to the data sheet.

Have a look around the datasheet, perhaps there are hardware features that are not implemented in code, so you can improve the performance, enhance the driver, solve bugs or trouble shoot issues.

For example register A can be used to set the sensor rate (default 15Hz) as well as a bias for different axis, but if you right click on the register name and select ‘find all references’, it shows that the driver never uses it….

Happy Gadgeteering…. check www.gadgeteering.net for a complete list of hardware.

Tips

If you are using the express version of Visual Studio it only supports one language. So if you have a VB project and import a C# project, you wont get any debug and things will look a bit strange.

Remember that since you are compiling from source you can now add a break point inside the driver! (F9) This is a fantastic way to halt execution and inspect what is going on, with out having to write tonnes of output lines……

This problem is to do with the USB driver and it has been addressed, so why are you still getting it? Well you are using the wrong driver . The old drivers run in kernel mode and hence can cause a BSOD, but this has since been switched to WinUSB which runs in user mode, so cannot BSOD. There are some issues with WinUSB and virtualised installs and not all hardware supports it.

The solution: swap the driver. Note this does not work for all hardware. If you cannot swap the driver for various known reasons. Learn to recognise the symptoms to avoid a BSOD. Usually Visual studio just sits on the deployment stage, if you do almost anything it will BSOD. However if you click ‘Build –> Cancel’ and wait 2 sec it will cancel and you can reset/redeploy. (Note on VS Express you don’t have this menu item.)

GHI have a great article on this http://www.ghielectronics.com/docs/109/usb-drivers-choices-including-winusb

The steps below let you check to see what driver you are using and how to swap it. (Use the GHI description for more info or if you get stuck)

What driver am I currently using?

During a deploy I hit the reset button on my spider today and it rebooted my laptop, strange as I thought I was using the WinUSB driver. Open Device Manager and look for the Gadgeteer device. In the case of a Spider mainboard it will appear as a .NET debugable device. Here is the device driver information for the old USB drivers, so turns out I am running the wrong one, hence the BSOD.

Swapping the driver.

If you click “Update Driver” you can navigate to the GHI drivers directory and select the WinUSB driver.

Once that has completed you will see that new drivers have been loaded. Horary! The spider mainboard also now appears under a different section in device manager.

(WinUSB drivers)

Notes:

GHI firmware from 14Feb (listed as updated 18 Feb) 2013

VS 2010

Spider mainboard.

As requested here is an example of my colour sensor in continuous mode setting the colours of the LED strip. The code below uses the tweaks shown in these two posts:

1) http://stevenjohnston.co.uk/2013/04/15/colour-sensor-on-net-gadgeteer-tcs3414/

2) http://stevenjohnston.co.uk/2013/04/11/individually-addressable-multicolour-leds-on-net-gadgeteer/

Video

The colour changes are much better that this video captures but it is hard to record them (Rather than looking at the ‘white’ over saturated LED, look at the surrounding colour!) In the first few seconds of the video I reset the entire 5m of LEDs and you can see the delay in sending the messages all the way to the last LED. Running the SPI bus at 14MHz I get a refresh of about 5hz (5 full refreshes per second)

Source code

This post addresses the issues with the colour sensor.

I am using the ColorSense REV 1.2 which has a TCS3414 digital colour sensor and 4 white LEDs to illuminate any sources. Each sensor has 16 photodiodes, 4 per channel (R,G,B,Clear)  each channel has a 16 bit ADC and we are communicating to the module using I2C. The original driver form GHI can be found in Codeplex: http://gadgeteer.codeplex.com/SourceControl/changeset/view/24955#333941

There are a few settings you may wish to change in order to calibrate she sensor for the task you have in mind. (you may even want to change these values during operation)

1) Integration time.

You can change the length of time that the sensor takes per integration cycle. There are 3 settings and 12ms is the default. (10ms / 400ms being the other options.) The code to enable changes to this is shown below. (If you are getting saturated, lower the integration time)

2) Setting the Gain and the prescalar.

The gain and prescalar are set in a single operation. The gain provides “gain control for all four parallel ADC channels” and can be used to ensure the ADC range is modified to avoid saturation. I.e. if the output is always low, then increasing the gain will improve the sensitivity and the channel outputs will increase. The gain can be changed to 4 discrete multipliers, 1x, 4x, 16x and 64x – 64x would make the sensor very sensitive. (Saturation can be avoided by lowering the integration time)

The prescalar divides the ADC output, thus reducing the sensitivity of the ADC. There are 7 different prescalars -  divide by 1,2,4,8,16,32,64.

I have put the gain and prescalar options into a struct with a supporting method to change them:

3) Enable disable

It may also be useful to enable/disable the module.

Example

For the task I have in mind setting the following provides me with RGB values between 0-65k and rarely gets saturated (About as sensitive as I dare push it) . Note there are public methods on this module to change these parameters.

Complete code below

The first hurdle was finding out how to power the module 160×3 LEDs (RGB) is a lot to power and GHI recommend a good power supply which is attached to the FEZtive module board part A, this way you are not drawing power through the .NET Gadgeteer mainboard. In the picture below you can see my power connector. (Not I have not split the PCB as I only need one connector for now and this way I don’t loose the other half.)

Next I need to connect the connect the LED strip to the PCB, my strip had a connector on each end and as I planed to run this as a single strip, I cut the connector off the end and attached it to the PCB. This way I can disconnect the LED strip. Now I have power, data (Gadgeteer cable) and a connector for the lights.

Connect it all up and we are ready for some software….

There is a great example of how the use the module here : http://wiki.tinyclr.com/index.php?title=FEZtive_Module 

At the time of writing the FEZtive module is not part of the main GHI installer (I guess it will be in time) so you need to download the project from the link above. Be sure to add this project to your solution (or new project),

Next add a reference from your project to the FEZtive project you just downloaded. (I am using NetMF 4.2 so add a reference to the _42 project.)

Since you cannot drag and drop the module from the designer (not yet) you need to create the object on the socket that you are using, I have a Spider with SPI on socket 9. Here is the example code from: http://wiki.tinyclr.com/index.php?title=FEZtive_Module 

Fantastic this works! (It is hard to take a picture, they look better in real life)

The FEZtive part B

The LED’s are connected by 4 lines (Gnd, CI, DI, +5v) and you don’t need anything on the ‘end’ of the LED strip, as it is just one big long SPI bus. So in theory you can cut the strip (there are marked points to cut after each LED- see the white line) into different sizes. The PCB that my kit came with has 2 parts and A and a B, each with 5 areas to connect an LED strip. Think of these PCBs as U-turns in the LED strip. You can cut it into 5 x 1m strips and then zigzag them between part A and part B, note that this will make the order of the LEDs into a long snake, so if you are writing text or showing a picture you will need to calculate which LED is where. (Yes you can link multiple together – I only have one)

How does it work?

If you look at the GHI driver for this module you can see that there is a large array (one for each LED) which contains a custom ‘colour’ object. There are a series of public methods that let you manipulate this array (change the colour) and then there is a draw method that will ‘write’ the entire array of ‘colour’ objects to the SPI bus.

There are some interesting effects of this. Imaging you have a LONG strip, say 5m and decide to set the colour to blue, you can see the new colour advancing along the strip. It is easier to see if you slow the clock speed down.

This got me thinking, how is it working? Imagine you built a new (very large) HD TV out of this would it work? Well not exactly, you would get rather ugly ‘scan’ lines and the refresh would be poor.

Change the colour

I have a .NET Gadgeteer colour sensor and setup a button that would read the sensor and set all LEDs to that colour. Handy to test and a little more fun as you can point it at an object, press a button and all the LEDs change colour.

Here is a bit of code:

Something is a bit strange here, the colour sensor returns a uint for each of RGB as well as an intensity. The FEZtive LED strip takes a value between 0-127 for each of the RGB. For now I halved the channels, but this is not correct and for extreme lighting conditions it will produce strange results. I plan to normalise these values, but so I can test a bit more this will do for now. I could not find a datasheet for the Colour sensor module and the source code does not give away much. humph! – GHI? The driver reads 2 bytes fore each channel 2^16 colour options per channel, but I noticed that with a bright light the values rarely top 10,000. (e.g RED: 9715, GREEN: 12368, BLUE: 11918) [UPDATE : http://stevenjohnston.co.uk/2013/04/15/colour-sensor-on-net-gadgeteer-tcs3414/]

The LDP8806

Each multicolour led on the strip has a processor next to it, yes every one! This is the LDP8806 – anyone got a data sheet?

Something is interesting here, you just tell the Gadgeteer initialiser how many LEDs there are, and then ram data down the SPI bus. If you say there are only 10 LEDs then only the first 10 in your strip will work. This means that the data is fed to the first led in the strip, the colour is set and then all subsequent data is passed down the SPI bus, to the next LED and so on. 

There is a series of zeros that are passed into SPI before and after each call, and this depends on the length of the strip. (presumably to set the LED into a state where it can obtain a new colour). I think this explains why each value is limited to a range of 0-127, the high bit is being used to command each LED.

Ok, enough speculation, here is a much better explanation: https://github.com/adafruit/LPD8806/blob/master/LPD8806.cpp

Can it go faster?

For a bit of fun I decided to see what SPI clock rates would work with my 5m strip.

So it would look like 14MHz is as fast as this will run without errors. It is not exactly scientific, so the plan is to run at at this speed for a bit and see how it copes.

I have had a few people mention that they hit issues when swapping from the GHI Camera module to a GHI SerCam module. So here is an explanation and example:

First remember that things are constantly being updated so make sure you have the updates! (Updates/Debug help)

I am using NetMF QFE2, version 4.2 with the GHI software last updated Feb 18, 2013, (I also have no idea if the source code on codeplex has been updated to reflect this release.)

(Expect this post to get out of date, it is here to help those who need a workaround NOW – solution at the bottom)

Issue 1

1) The NullReferenceException:

Create a new project and call the take picture method on the camera.

When you run the code it throws an exception. The exception is in the SerCam.dll and you do not have the source code in your project so you cant see what is going on.

I downloaded the latest GHI source from codeplex (http://gadgeteer.codeplex.com/)

Link the downloaded code into your project:

1) Delete the reference to the GHI SerCam.dll

2) Add the 4.2 SerCam project to your solution (codeplex source folder : \Main\Modules\GHIElectronics\SerCam\Software\SerCam\SerCam_42).

3) Add a reference from your project to the codeplex SerCam.

Right now you are good to go, when it deploys it will now halt execution at the code that is causing the problem :

The problem here is that the code assumes that there is at least one delegate to call when the StartDataCaptured event is triggered. A simple work around (if you don’t want to change the source) is to ensure that all events have something to call, even if it is empty. Then when you run the code you should not get the NullReferenceException.

Issue 2

The methods are not the same as the camera I am used to, where is the Picture object, how do i get it and why is it not returned to me?

There are 3 events on the SerCam, one that is triggered at the start of a picture capture (StartDataCaptured), one that is triggered once the picture has been captured (FinishDataCaptured) and one that is triggered when some data is available (OnDataCaptured). The key here is that you only get the picture back in chunks, handy if memory is an issue. You have to take these chunks and piece them together. If we take a picture and set a breakpoint in the ReadFrameBuffer method (the one that triggers the OnDataCaptured event)  we can see that the picture is split into blocks, each block is returned as it is read. There are 95 blocks in this particular picture, so we have to put them all back together to reconstruct the picture for the display.

<snip>

Solution/workaround

Make sure there is code to execute for every event and rebuild the picture.

1) First create a Byte array to store the reconstructed picture in your program, I will call it rawPicData:

3) When we start to take a picture lets reset the rawPicData array. That way we know it is initialised and is reset for every picture.

4) Every time there is a block (chunk) of picture data ready, we read it and append it to the end of the picture array (Not the optimal solution, it will be a bit slow, but it is one line). I added a debug line so you can see that something is happening.

5) Finally when the camera has finished taking a picture and you have read all the blocks, the FinishedDataCaptured event will be triggered. Now you can take the byte array and convert it into a picture object. You can only do this once you have ALL the blocks and you should check for an exception, in case of an error.  In this case it is Jpeg

You can then display the picture:

Source Code

If you read nothing above and just want a working example here it is:

And in VB (Thanks to Sue)

(as is, no warranty, and I am sure there are bugs etc blah blah)

The code is supplied below, it has a display buffer that you fill with text and it will scroll based on the timer ( turn off if annoying) . This is a class that you can just add to your project and call the methods to display text.

1) Add code to project (new class)

2) Create instance, supplying an array of your hardware modules to the constructor

3) Call DrawString with the text you need to display.

NOTE: You will have to create a lookup table for each character/digit you want to display. I have only added a few.

[Note: I assume you have the latest SDK’s installed and that the firmware has been updated. I am using Visual Studio Ultimate, but the following will also work in the free version of VS.]

1) Lets start with a new project..

I have updated to the latest SDK/Drivers and firmware so we are currently targeting v4.2

2) There are currently a wide variety of sensors, actuators and displays available (over 130 different modules)- Lets start with a simple temperature sensor, this module uses the SHT10 temp and humidity sensor. To create a basic prototype using this we will need a mainboard ( GHI Spider) and a power module. This is achieved by dragging the modules from the toolbox on the right into the designer (main panel). By right clicking and selecting connect all modules you should end up with the following in the designer.

3) To begin with we will code the bare minimum so we can see the development cycle and get a feel for the environment. Notice that dragging modules on to the designer instantiates them, so they are ready to be used in your code. First we add some code to the MeasurementCompleted event and then put the sensor into continuous measurement mode. Each time the sensor acquires a new measurement our code will just print the readings out to the debug console. (Remember to turn this on if you are using VS Express – Debug-> Windows-> Output, See http://wp.me/p2pktY-3q). As you type VS will prompt you with intellisense and auto complete assistance, be sure to use these as it saves time.

4) Next we will deploy the solution (hit F5/ Green arrow) this will compile the code and flash your mainboard with the solution. Note we are using the USB cable to power hardware as well as debug inside VS. Once the program has been deployed it will start and you can see the debug output in VS.

5) This is all very well but the Debug output is not a great place to view data, so let us add a display. There are a few to choose from but lets start with the T35 from GHI. Dragging and dropping the display in the designer and selecting connect all modules will result in the layout below.

6)I prefer to have a separate method to configure the display but feel free to have the code inside the program started method. We will need a font, one of the two supplied with the template. There are 2 modes of operation for the display, WPF and simple graphics. Many examples include the simple graphics option so we will use the WPF as a demo, suffice to say that this is a very basic interface and WPF is very powerful, so worth looking at further. The hardware display module has a WPFWindow property, this is the root of all the graphics that we will add. First we will add some text to the main canvas.

7) Each time the sensor returns a new reading we can use it to change the text content on the canvas. Note that we do not need to refresh the text, we are using the same text object.

8) This text is a bit long, and has a few too many decimal places, so lets shorten the text.

9) The text is also rather close to the top of the screen, so we can nudge the canvas down a bit by adding a margin.

10) If all went well we are left with a user interface that updates, but is perhaps not beautiful.

11) Imagine that you are happy with this prototype and show it to friends/colleagues, who like the prototype but think the display is not very good and suggest adding a larger display. (Substituting hardware is something that is often required but can be very difficult to achieve, particularly when working with embedded systems). Lets go to the designer and deleted the T35 display and drag and drop the CP7 display into the solution. Connecting up the new display is the same as the old one and hitting build will result in an error. The error occurs because the display variable names are different (I just used the default names) – correcting this will let the solution compile and deploy.

12) With minimal effort the new display should look like the picture below. (Still not a fantastic interface) Remember that you need to build different prototype versions, experiment with hardware and test your ideas. The quicker you can develop new versions the quicker you can test you ideas and bring them into reality. 

13) The next step is to do something about this interface, it is lacking a bit of readability. The first step is to make the font bigger. This is not as simple as you imagine as there are just 2 default fonts in the template and they do not come in different sizes. Basically you would not want to waste all your precious embedded device memory on fonts! So you can add just the fonts (and character sets) that you need! There is a tool to import fonts called TFConvert which is command line driven (TFConvert more info: http://msdn.microsoft.com/en-us/library/cc533019.aspx). Like most things someone has written a tool to improve it :- http://informatix.miloush.net/microframework/Utilities/TinyFontTool.aspx

Once you have a new .tinyfnt file simply import is as a resource in VS (Add resource –> File-> *.tinyfnt) and it will become available in your code.

14) Lets just swap the font for the new font, intellisense will auto complete the FontResources, to show all the fonts you now have (should be 3).

15) Simply writing text to the display is a bit lazy, remember this is a WPFWindow, we have a canvas and a whole collection of WPF components that we could add. Most things in WPF end up in a stack panel of some sort, think of it as a bag that lets you throw things into and can display them either as a row or a column. I will add a stack panel to the canvas and then add the text for humidity and temperature as two separate text objects. Feel free to explore some of the methods at this point. For example you can catch touch events on WPF components such as a text object. I have added the complete code below as a reference.

16) Text that updates is lovely but sometimes you just need to draw something! This is the only code that I will not manually type but it is short and simple enough to read through and understand. There is a basic graphing class that will draw grid lines and plot data points. Source code copied from from http://gadgeteering.net/sites/default/files/users/nvillar/files/SimpleGraph.cs . Code listed below for completeness.

17) Import the simple graphing class and create a graph object.

Select the colours, size and grid lines. Then add the graph object to the stack panel that we created earlier.

Then every time the sensor event triggers add the data to the graph.

The result should be a nice stack of text , text, graph! (Axis, units, colour, background, buttons are still required!) Hopefully that demonstrates how quite sophisticated GUIs can be generated using .NET Gadgeteer and very few lines of code.

18) Clearly we are making a sensor logger here, assuming the display now meets all you requirements, lets log the data to an SD card. First step is to add an SD module to the designer. (Drag, drop)

19) First be sure to check you have an SD card, that it is formatted etc! We will just mount the storage that is in the SD module.

20) Every time the sensor gets some data, append it to the end of a file. Be sure to consider if this is a wise move, especially if you are polling the sensor frequently.  ( I will add a fs.flush() for the demo to show that data is written). There is also a storage FileWrite method that is worth considering, I did not use it here as I plan to flush the FileStream, to show that data ends up on the card without having to wait for a flush.

21) We have a data display, and logger, but nothing is complete without some sort of internet capability. Lets make our sensor available across the internet! .NET Gadgeteer easily lets you set up a web server. Lets add an Ethernet connection in the designer:

You could just as easily add a WiFi module:

Note: If you use a WiFi module here is a handy way to setup an adhoc network on your Win8 laptop/PC

Setup wireless network (from http://www.addictivetips.com/windows-tips/how-to-create-wireless-ad-hoc-internet-connection-in-windows-8/)

> netsh wlan set hostednetwork mode=allow ssid=MyNetwork key=MyNetwork

> netsh wlan start hostednetwork

(Be sure to run as admin)

Note: Here is a good webserver example http://mikedodaro.net/2011/10/15/gadgeteer-web-service-surveillance-camera/

22) Be sure to add more error checking than is shown here,  to your networking capabilities.

23) Lets start a webserver when we get an IP address. First register to get notifications when the IP changes, enable DHCP and then open the network.

As an aside I noticed that it can take the WiFi module a while to start-up so I added the initialisation into a delayed timer.

24) Again it is wise to add some sanity checks here, but we will assume that our networking is perfect , that we get an IP address and simply start a webserver on port 80. The great thing about the webserver is that you can setup events on the url, here we add an event that will be triggered when the url http://<IP>/Temp is requested.  (Simple eh!)

It is always polite to return a response,  we can simply return a webpage (basic!)

Summary

In just 2 hours we have built an example data logger, with a graphical frontend, storage capabilities as well as making the datalogger internet capable! Aside from the SimpleGraph capabilities we have assembled all the hardware and typed all the code to make the prototype work, including importing a custom font. Hopefully this demonstrates the power of .NET Gadgeteer for rapid prototype creations! A few shortcuts were taken and it is highly recommended to add some error checking.

Note: Throughout this presentation I have purposely iterated through the development cycle to simulate the process you will encounter developing a prototype. Each change resulted in a build, compile and deploy (F5 in VS) and then a simple test to show the expected output. We will have also experienced the debug breakpoint feature which is very powerful. It is important to realise that we can halt execution on the actual hardware and inspect the objects that are in scope, this is probably one of the most valuable debug features and is a fantastic capability for embedded devices!