Posts Tagged IoT

Windows 10 IoT Core – Setting Default App

The default startup app supplied with Windows 10 IoT core provides interesting information about your device and basic settings, but does not do anything and does not even provide a launcher for your app.

What we want is for our application to start when we power on the device. This will allow us to specialize the device, and its purpose essentially becomes to run our application and nothing else.

This procedure only deploys debug version applications. Its good for temporary setup AND to demonstrate Setting Default Application. Because the debug certificate is temporary, the application will eventually stop working. I will write a post about deploying release application at some point.

Updating the Manifest

This step is optional, but it makes things easier.

The first step is to identify our application. By default when we create the Universal Windows application, the identity of your application is set as a guid. The identity for our application was:

  • 234b35b2-e6d4-471c-8473-5d584ad0ee1a

To make it much easier to find our application in a list, I want to change it to:

  • ChristianLavigne-LogicGate

To change the identity you need to change the manifest. Here is how:

  1. Right Click on your Project (Windows Universal)
  2. Select ‘Properties’ you will get the following screen. Click on the ‘Package Manifest’ button, you will get the manifest page:
  3. Select the ‘Packaging’ tab:Default-PackageManifest
  4. Take note of the Package Name (to uninstall from the device later)Default-PackagePackaging
  5. Replace the Package Name, I used ‘ChristianLavigne-LogicGate’:
    Note: The ‘Package family name’ contains the name as displayed on the device 
  6. Click the Visual Studio ‘Save’ button to save the manifest.

Deploying the Application

To do this, I will use Visual Studio to deploy a debug version of the application. Building release packages is a bit more complicated and will be the subject of another blog entry.

After updating the manifest, re-build the application (in debug) and start a debugging session by clicking run with remote machine selected. Same as we have done before.

When starting the debug process, Visual Studio will deploy a new version of our application on the device. Once started, you can stop the application from Visual Studio by using the menu Debug | Stop Debugging.

Setting the Device Default App

To update the default app, we start Windows Device Portal web page of our device.

  1. Navigate to the ‘Apps’ page.Default-SelectApp1
  2. In the Installed apps drop down lisbeforet, select your app, ChristianLavigne-LogicGate_1.0.0.0_arm_xxx in our case, and click the Set Default.Default-SelectApp2

What this does is interesting. With the Raspberry Pi on, we can see that our app immediately starts. If it shuts down for any reason, our app will re-start. When you reboot your Raspberry Pi, it will start our app again.

In essence it will only run this application, until we set a new default. If we want to go back to the original application supplied with the OS, select IoTCoreDefaultApp and set it as the default.

Removing Old Application

Because we renamed the application in the manifest, we now have a duplicate of the application installed. To remove the old version, we select it in the Installed apps and click the Remove button. I also had another application I created earlier, so I removed it.



Setting the Default App allows you to specialize your device to perform only a single task. You can use you Raspberry Pi to run hardware specific applications, or to run as a media player, or run kiosk software. Any Universal Windows application will work, so capability offers a wide range of possibilities.



, , ,

Leave a comment

GPIO Test Application Part 4 – ViewModel

Previous: GPIO Test Application Part 3 – Model

This post is part 4 of 6 of the GPIO Test Application. You can find the initial post here: GPIO Test Application part 1 – Overview.

The ViewModel (VM) encapsulate all the functionality provided by the application.Each page, user control or dialog should have it’s own VM to implement the page, user control or dialog functionality.

For our Main Page, we have a MainPageVM which is the view model for this page.

MainPageVM vs Model

The MainPageVM creates and maintains the current instance of the LogicGateModel and makes it available to the UI. MainPageVM also performs operations on the Model.

Here, we see the intialization code that creates the Model:

private void Initialize()
    Logger.AddLogEntry("Initializing Main Window VM!");


    m_Model = new LogicGateModel();
    m_Model.PropertyChanged += Model_PropertyChanged;

    Logger.AddLogEntry("Done Initializing Main Window VM!");


private LogicGateModel m_Model = null;
/// <summary>
/// This is the instance of the Model.
/// </summary>
public LogicGateModel Model
        return m_Model;

When the model is created, the MainPageVM attaches an event handler to the PropertyChanged event of the LogicGateModel.

The handler is used to detect and act uppon changes in the values of LeftSwitch and RightSwitch. When those properties are changed, the MainPageVM recalculates the required outputs and updates the Model accordingly.  It also recalculates on changes to the IsEnabled function.

Bellow is the Model_PropertyChanged event handler code:

private void Model_PropertyChanged(object sender, PropertyChangedEventArgs e)
    if (e.PropertyName == "LeftSwitch" || e.PropertyName == "RightSwitch")
    else if(e.PropertyName== "IsEnabled")

MainPageVM functionality


The calculation portion of the MainPageVM is pretty simple. A case statement performs the actual logic operation on the RightSwitch and LeftSwitch of the Model, then the result is pushed back to the RedLED (false) and GreenLED (true) properties of the model.

private void RecalculateOutput()
    Logger.AddLogEntry("Recalculating output!");

    bool result = false;
        case LogicTypeEnum.AND:
            result = Model.LeftSwitch && Model.RightSwitch;
        case LogicTypeEnum.OR:
            result = Model.LeftSwitch || Model.RightSwitch;
        case LogicTypeEnum.NAND:
            result = !(Model.LeftSwitch && Model.RightSwitch);
        case LogicTypeEnum.NOR:
            result = !(Model.LeftSwitch || Model.RightSwitch);
        case LogicTypeEnum.XOR:
            result = Model.LeftSwitch ^ Model.RightSwitch;

    Model.GreenLED = result;
    Model.RedLED = !result;


Note: We could have used a more powerful pattern, such as the Strategy pattern, to select and perform the logic operation. But in the spirit of keeping the code readable a case statement is better.

Logic Property

The formula used to calculate the output is dependent on user input. The user selects the logic operation to perform then the application uses it to calculate the output. The Logic property of the MainPageVM is used to define the operation currently used. The MainPageVM also provides a list of available operations so that the View is able to display a list to the user. Following is the code related to the Logic property.

LogicTypeEnum represents the available operations.

public enum LogicTypeEnum

Logic and LogicList properties provide the functionality to the View. Notice the call to RecalculateOutput on the Logic setter.

private LogicTypeEnum m_Logic = LogicTypeEnum.AND;
/// <summary>
/// This is the logic applied to the inputs to define how calculation is done.
/// </summary>
public LogicTypeEnum Logic
        return m_Logic;
        if(value != m_Logic)
            m_Logic = value;

private List<LogicTypeEnum> m_LogicList = null;
/// <summary>
/// This is the list to populate the list or ddl used to select
/// the logic to apply on the inputs. 
/// </summary>
public List<LogicTypeEnum> LogicList
        if(m_LogicList == null)
            m_LogicList = new List<LogicTypeEnum>();
            Array a = Enum.GetValues(typeof(LogicTypeEnum));
            foreach(var v in a)
        return m_LogicList;

Other Functionality

Other functionality have also been added to the MainFormVM. For debugging purpose the UI can display buttons on the Main Page simulating the right and left switches. Those buttons are only available if the GPIO fails to initialize which in turn enables the ShowSimulatedSwitches property on the VM.

There is also an Exit command that will close the application. This is useful to stop debugging sessions from the Main Page.


The MainPageVM performs all the function related to the calculation and maintains the information related to the calculation. This allows the Model to focus on content and not worry about functionality.

Next: GPIO Test Application Part 5 – View

, , , , ,

Leave a comment

GPIO Test Application Part 3 – Model

Previous: GPIO Test Application Part 2 – Hardware

This post is part 3 of 6 of the GPIO Test Application. You can find the initial post here: GPIO Test Application part 1 – Overview.

The model of our application will provide the data used by the application. The data in this case represents the information that is sent and received on the GPOI.

Model Application Interface

The Model exposes a simple and easy to use interface to the application. This interface hides all the complexity of working with the GPIO. The properties for the interface look like regular content properties of an INotifyPropertyChange object.

The following properties compose this interface:

  • RightSwitch: bool value that returns true when the right switch is pressed.
  • LeftSwitch: bool value that returns true when the left switch is pressed.
  • RedLED: bool value that represents if the red LED is on / off. Setting this value will turn the green LED on.
  • GreenLED: bool value that represents if the green LED is on / off. Setting this value will turn the green LED on.
  • IsEnabled: read only bool value that specify if the GPIOs have been successfully initialized and are available. This property is used to enter simulation mode. In simulation mode, the application adds buttons on the screen to simulate the left and right push buttons on the screen. This is useful for debugging the application on your computer.

The switch properties looks like this:

private bool m_RightSwitch = true;

/// <summary>
/// Provides access to the value of the Right push switch on the hardware
/// </summary>
public bool RightSwitch
        return m_RightSwitch;
        if (value != m_RightSwitch)
            m_RightSwitch = value;

The LED properties looks like this:

private bool m_RedLED = false;

/// <summary>
/// Reads and Sets the value of the red LED
/// </summary>
public bool RedLED
        return m_RedLED;
        if (value != m_RedLED)
            m_RedLED = value;
            UpdateGPIO(m_RedLEDPin, value);

Notice that in the setter of the LED properties, a call is made to UpdateGPIO to send the value to the GPIO.

GPIO processing

In the case of our application, the Model is encapsulating all the GPIO access. The flow of GPIO runs something like this:

  1. Initialize the GPIO
  2. While the application is running:
    1. Wait for events on the Input pins
    2. Write Outputs to the Output pins
  3. Shut down the GPIO

We keep the instance of the GpioPin for each pin that we use. The GpioPin are created in the initialization process and released in the dispose. For simplicity, we keep the pin numbers in constants fields.

private const int GPIO_LEFT_SWITCH = 21;
private const int GPIO_RIGHT_SWITCH = 20;
private const int GPIO_RED_LED = 6;
private const int GPIO_GREEN_LED = 5;

private GpioController m_Controller = null;
private GpioPin m_LeftSwitchPin = null;
private GpioPin m_RightSwitchPin = null;
private GpioPin m_RedLEDPin = null;
private GpioPin m_GreenLEDPin = null;

Initializing / Shutting down the GPIO

During the initialization process the following sequence occurs:

  1. The application attempts to retrieve the default GpioController. If the controller cannot be retrieved, this means that the device does not support GPIO.
  2. All the pins are initialized.
  3. If all the pins are initialized correctly, the IsEnabled property is set to true.
  4. If one of the pins fails to initialize, the Release() function is called to free up all the allocated resources.
private void Initialize()
    Logger.AddLogEntry("Initializing GPIO on LogicGateModel");

    m_Controller = GpioController.GetDefault();
    if (m_Controller != null)
        string startupMessage = "Startup:\r\n";
        bool success = true;

        success &= InitializeLEDPin(GPIO_GREEN_LED, "green LED", out m_GreenLEDPin, ref startupMessage);
        success &= InitializeLEDPin(GPIO_RED_LED, "red LED", out m_RedLEDPin, ref startupMessage);

        success &= InitializeSwitchPin(GPIO_LEFT_SWITCH, "left switch", out m_LeftSwitchPin, ref startupMessage);
        success &= InitializeSwitchPin(GPIO_RIGHT_SWITCH, "right switch", out m_RightSwitchPin, ref startupMessage);

        Message = startupMessage;
        if (!success)
            // Read the current values...
            LeftSwitch = m_LeftSwitchPin.Read() == GpioPinValue.High;
            RightSwitch = m_RightSwitchPin.Read() == GpioPinValue.High;

            IsEnabled = true;
        Message = "Unable to access the GpioController!";

    Logger.AddLogEntry("Initialization of GPIO on LogicGateModel complete!");

When the LED pins are created:

  1. We use the controller to try to open up the pin
  2. If that succeeds, we make sure the pins supports the Output Drive Mode.
  3. Then we set the Drive Mode to Output
  4. If any of the operations do not succeed, we set the result to false to indicate that there was an error initializing the GPIO
private bool InitializeLEDPin(int pin, string pinName, out GpioPin output, ref string message)
    bool result = true;

    Logger.AddLogEntry("Initializing Pin #{0}, {1}", pin, pinName);

    GpioOpenStatus status;
    if (m_Controller.TryOpenPin(pin, GpioSharingMode.Exclusive, out output, out status))
        if (output.IsDriveModeSupported(GpioPinDriveMode.Output))
            message += string.Format("   Pin {0} initialized: status = {1}\r\n", pinName, status.ToString());
            message += string.Format("   Pin {0} error: Drive mode {1} not supported.\r\n", pinName, status.ToString());
            result = false;
        message += string.Format("   Can't initialize {0}: status = {1}\r\n", pinName, status.ToString());
        result = false;

    return result;

When the switch pins are created:

  1. We use the controller to try to open up the pin
  2. If that succeeds, we make sure the pins supports the Output Drive Mode.
  3. Then we set the Drive Mode to Output
  4. Then we attach an event handler to the ValueChanged event of the GpioPinto  to receive notification whenever there is a change of state on the pin.
  5. If any of the operations do not succeed, we set the result to false to indicate that there was an error initializing the GPIO
private bool InitializeSwitchPin(int pin, string pinName, out GpioPin output, ref string message)
    bool result = true;

    Logger.AddLogEntry("Initializing Pin #{0}, {1}", pin, pinName);

    GpioOpenStatus status;
    if (m_Controller.TryOpenPin(pin, GpioSharingMode.Exclusive, out output, out status))
        if (output.IsDriveModeSupported(GpioPinDriveMode.Input))

            //Intentional, we do not use debounce this time but this is where you would set it
            //output.DebounceTimeout = TimeSpan.FromMilliseconds(5);

            output.ValueChanged += PinValueChanged;
            message += string.Format("   Pin {0} initialized: status = {1}\r\n", pinName, status.ToString());
            message += string.Format("   Pin {0} error: Drive mode {1} not supported.\r\n", pinName, status.ToString());
            result = false;
        message += string.Format("   Can't initialize {0}: status = {1}\r\n", pinName, status.ToString());
        result = false;

    return result;

The Release function is strait forward, it disconnects the event handler from the input pins and calls Dispose on each of the pins.

private void Release()
    Logger.AddLogEntry("Releasing GPIO on LogicGateModel");

    if (m_Controller != null)
        // Release all the GPIO pins used
        if (m_LeftSwitchPin != null)
            m_LeftSwitchPin.ValueChanged -= PinValueChanged;

        if (m_RightSwitchPin != null)
            m_RightSwitchPin.ValueChanged -= PinValueChanged;

        if (m_GreenLEDPin != null)

        if (m_RedLEDPin != null)
    Logger.AddLogEntry("Completed Releasing GPIO on LogicGateModel");

Handling OnChange event on the input PINs

When initializing the pins we assigned an event handler to the ValueChanged event of the input pins. The following code shows the OnValueChanged function:

private void PinValueChanged(GpioPin sender, GpioPinValueChangedEventArgs args)
    // normally we would use the arg to get the value, as follow:
    //    (args.Edge == GpioPinEdge.FallingEdge);
    // but at this point it is completely unreliable and returns garbage
    bool value = sender.Read() == GpioPinValue.High;

    if (sender == m_LeftSwitchPin)
        CoreApplication.MainView.Dispatcher.RunAsync(CoreDispatcherPriority.High, () =>
            LeftSwitch = value;
    else if (sender == m_RightSwitchPin)
        CoreApplication.MainView.Dispatcher.RunAsync(CoreDispatcherPriority.High, () =>
            RightSwitch = value;

We first read the value of the pin by calling the Read() function. The GpioPin that raised the event is received as the sender parameter, so we use it to identify which button was pressed. Then we just set the value on the appropriate property.

One particularity of this code is that the ValueChange event is raised on a separate thread. In order to interact with the User Interface, we need to bring the call back on the UI thread. That is done here with the CoreApplication.MainView.Dispatcher.RunAsync call.

Turning LEDs On/Off

When the ViewModel sets the value of the RedLED or GreenLED, we need to send that value GPIO, the UpdateGPOI function does that for us:

private void UpdateGPIO(GpioPin pin, bool value)
    if (IsEnabled && pin != null)
        GpioPinValue v = value ? GpioPinValue.Low : GpioPinValue.High;


The Model already provides a big portion of the overall functionality we require. It reads inputs from the GPIO, maintains the current state of Input/Outputs and provides a way to turn LEDs on and off. All that using a simple interface that the rest of the application can use.

Next: GPIO Test Application Part 4 – ViewModel

, , , ,

Leave a comment

GPIO Test Application Part 2 – Hardware

This post is part 2 of 6 of the GPIO Test Application. You can find the initial post here: GPIO Test Application part 1 – Overview.

The hardware portion of this project is quite simple. It uses just enough components to be able to test the different aspects of the GPIO, input, output and events monitoring.

This project can be easily realized with the components supplied in the Microsoft IoT Pack for Raspberry Pi 2 starter pack.


The following components are required:

  • 1 – Raspberry Pi 2
  • 1 – Breadboard
  • 2 – Push switch
  • 1 – Green LED
  • 1 – Red LED
  • 2 – 560Ω resistors
  • Wires


Here is the wiring diagram I created:

LogicGate Hardware_bb

I used the application Fritzing to draw my electronic diagram. I found it to be very adequate to put together a quick wiring diagram. The nice part about it is that it already contains the Raspberry Pi 2 as a component and you can just drag the wires to/from the pin you want to use.


Next step we’ll look at the Model portion of the application code. The model is used to control the GPIOs used to manipulate the electrical components supplied here.

Next: GPIO Test Application Part 3 – Model

, ,

Leave a comment

GPIO Test Application part 1 – Overview

This post is part 1 of 6 of the GPIO Test Application. The following parts together compose the full article:

As a first application that involves hardware, I decided to keep things simple. The idea is just to hook up a couple Inputs and Outputs and have a program that will work with the GPIO to read/write the values.

Source Code

To follow along, you might want to download the full solution right here:

You can run the application on your computer, but it will run in simulation mode (no GPOI). See the First Windows 10 IoT Core Windows Application post for information on how to run it on your Raspberry Pi.

The source code for the project has the same requirements as stated in my post: Setting up Visual Studio 2015 for Windows 10 IoT Core development


The requirements that I chose for this application will allow us to explore the GPIO and programming model associated with creating User Interface on the Raspberry Pi 2 under the Windows 10 IoT Core operating system. The application should incorporate:

  • Hardware components accessed through the GPIO
  • A responsive UI that will display the status of the hardware components as it changes.
  • And some control by the user to set how the output are calculated.

For simplicity, this application assumes the Raspberry Pi is configured for user interactivity and that it is connected to a full size screen and has an input pointing device. I will explore different form factors as well as headless device development at another time.


To achieve these requirements I will create a programmable LogicGate application that will take input from 2 push buttons, will calculate a result based on a logic operation applied to the 2 inputs, and will light up a green LED for true and a red LED for false.

In addition, we will include UI to control the calculation by selecting which logic operation is used. We will also include UI to visually display the status of the Inputs and Outputs.

Whenever any of the inputs or logic operation parameter changes, the application should update the displayed status, recalculate the output and light up the appropriate LED.

Application Components Overview

The application will be based on the MVVM pattern that we have shown earlier. This pattern is well adapted to the creation of reactive WPF applications. It this case, the application is composed of 4 main components that are:

  • Hardware
  • Model
  • View Model
  • View

The components are organized as follow:



The hardware is composed of:

  • 2 switches (right / left)
  • 1 red LED
  • 1 green LED

More details about the electronic circuit will be available in the following post GPIO Test Application Part 2 – Hardware.


On this application , we will used the model to encapsulate the access to the hardware through the GPIOs.

The model will provide a comprehensive Model API that allows seamless access to read the Inputs and write to the Outputs. The interface will contain the following Properties:

  • SwitchRight
  • SwitchLeft
  • RedLED
  • GreenLED

More details about the Model will be available in the post GPIO Test Application Part 3 – Model.


The ViewModel contains an instance of the Model and makes it available to the View. It also provides the functionality to calculate the Output based on the Logic Operation selected by the user on the View.

The available Logic Operations are:

  • AND
  • OR
  • NAND
  • NOR
  • XOR

More details about the ViewModel will be available in the post GPIO Test Application Part 4 – ViewModel.


The View provides the User Interface that the user to view the hardware status and to select the Logic Operation that determines the output. The user interface will look something like this:ViewScreenShot


  • Logic Operation: Section that allows the user to select which logic operation is used to calculate the output.
  • Device Interface: Displays the symboles that represents the different hardware components. The symbol is only displayed when the switch is pressed or the LED is lit. The symbols are:
    • Blue Square: for the switches
    • Red Circle: for the red LED
    • Green Circle: for the green LED

More details about the View will be available in the post GPIO Test Application Part 5 – View.


In the last section, GPIO Test Application Part 6 – Result,  I will provide access to the full source code of this application and we’ll see the resulting application in action.

Next: GPIO Test Application Part 2 – Hardware

, , , , , ,

Leave a comment

First Windows 10 IoT Core Windows Application

So now that I have my device up and running, time to start coding. So I’ll be writing my first application.


I could start coding a complicated app using the GPIO or talking with advanced devices using I2C. But I just wanted to see what was possible on the device first.

The objective of this first application are:

  • Creating a MINIMAL basic UI based application.
  • See if it could be deployed to the device.
  • See my application run on the Raspberry Pi.
  • Start a debugging session, place break points and watch variable values.

Getting Started

Creating a Universal Windows Project

In Visual Studio 2015, I clicked File | New Project….



Once the project was loaded, I opened up the main page MainPage.xaml. I created a basic layout, added a TextBlock, a TextBox and a Button. Here is the code:


<Grid Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">
        <RowDefinition Height="*"/>
        <RowDefinition Height="51"/>
        <RowDefinition Height="51"/>
        <RowDefinition Height="51"/>
        <RowDefinition Height="*"/>
    <TextBlock x:Name="textBlock" Grid.Row="1" TextWrapping="Wrap" Text="Hello World!" HorizontalAlignment="Center"/>
    <TextBox x:Name="textBox" Grid.Row="2" TextWrapping="Wrap" Text="" HorizontalAlignment="Center" Margin="5" Width="150"/>
    <Button x:Name="Greet" Content="Button" Grid.Row="3" HorizontalAlignment="Center" Click="Greet_Click"/>

I double clicked on the button to write an event handler. And typed in the following code:


private void Greet_Click(object sender, RoutedEventArgs e)
    string greet = "Hello World!";
        greet = string.Format("Hello {0}!", textBox.Text);
    textBlock.Text = greet;

Testing the application

To make sure the application was working as expected I started it from my local machine.


As expected, I got a new window with the following in it:


I typed in my name, clicked the button and got:


Fantastic! The app works! So I closed the window to stop the debug process before I continue.

Starting on the Raspberry Pi

Now that I have a working app, it’s time to try to run it on the device. To do this:

  1. Change set your debug target to Remote Machine
  2. Specify the machine address
  3. Change your build target to ARM
  4. Click Remote Machine to start the debugging session

Once this is done a number of things will happen:

  1. The application will be built.
  2. If this is the first time, Visual Studio will check some of the requirements on the remote device and install missing packages.
  3. Visual Studio will deploy the application to the remote device
  4. Visual Studio will start the remote debugger for the application on the device
  5. Visual Studio start the application.

This is the build output for this process:
Output Window (Build)

1>------ Build started: Project: HelloWorld, Configuration: Debug ARM ------
1>  HelloWorld -> C:\prog\IoT\HelloWorld\HelloWorld\bin\ARM\Debug\HelloWorld.exe
2>------ Deploy started: Project: HelloWorld, Configuration: Debug ARM ------
2>Creating a new clean layout...
2>Copying files: Total 16 mb to layout...
2>Checking whether required frameworks are installed...
2>Framework: Microsoft.NET.CoreRuntime.1.0/ARM, app package version 1.0.23819.0 is not currently installed.
2>Framework: Microsoft.VCLibs.140.00.Debug/ARM, app package version 14.0.23918.0 is not currently installed.
2>Installing missing frameworks...
2>Registering the application to run from layout...
2>Deployment complete (0:01:52.439). Full package name: "ad63be4b-92ac-472f-8c68-f4537d5b5ce9_1.0.0.0_arm__7j55shkp2zhzg"
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
========== Deploy: 1 succeeded, 0 failed, 0 skipped ==========

After that the application will start on the Raspberry Pi.


So I first tried the application on the Raspberry Pi. I typed in my name, clicked “Button” and got the expected result.

Now going back to my development machine, I place a break point in the button click event handler.

On the device I type Test in the TextBox and click “Button”.

As expected, on development machine, Visual Studio breaks on the break point. I press F10 to step through and I am debugging.


When I look at the watch I can see all the variables value:


I press F5 to resume and the application continues to run as normal.

To stop the application, you need to stop the debugging session in Visual Studio.


It works! I can create a XML based application and run it on my Raspberry Pi.

One thing I have noticed is that the application on the Raspberry Pi is Modal. You cannot stop the application or get out of it. This will be useful in the future.

, , , ,

Leave a comment

Re-imaging the SD Card to default

For some reason, my SD card got corrupted. I had to re-build it.


The process to create new SD card for Windows 10 IoT Core is quite simple. All you need is the Windows IoT Dashboard application and an SD card (at least 8Gb is recommended).

  1. Start Windows IoT Dashboard application
  2. Give it a few seconds to populate Device type
  3. Select your device
  4. Insert you SD card into your computer
  5. Select your SD card in the Drive drop down list
  6. Click the “Download and install”
  7. The application will then download the image (this will take a few minutes). A progress bar is provided.
  8. Then a command line application will then write the image on the card (again this will take a few minutes). A progress bar is provided.
  9. When completed you get the following screen:
  10. Once your device is booted up, you should see it in the My device.


Re-imaging an SD is an easy strait forward process. It takes only 5-10 minutes and you get a brand new device.

You will loose any changes or information stored on your card. So you will have to re-configure it after.

, , ,

Leave a comment

Windows Updates Issues

I’ve had somewhat of an adventure with the Windows Update process on the Windows 10 IoT  Core.

Updating Windows

In the Windows Device Portal I was on the Windows Update page. So to make sure my device was up to date, I clicked the “Check for updates” button and … nothing happened on screen. Knowing that the process was probably running in the background, I moved on to check other pages.

When I came back to that screen later I got a You must restart your device to apply the updates kind of button. So I clicked on it and the device proceeded to reboot as expected. I got the cog wheel going and a progress bar for a number of minutes. Then I got a giant frown emoticon:


And the screen went blank. I waited for 30 minutes then turned off the device. Then turned it back on, got cog wheels for a few minutes, then frown, then blank. It had essentially screwed up the Operating System.

Flashing the SD card

I took out my SD card, placed it in my development machine. And proceeded to re-image it without issues. Placed the card back in my device and it started without issues.

In any case, it gave me the material to write a post about Flashing the SD card…


This happened to me on a brand new device with a new SD card that is part of a starter pack.

This may have been a bad fluke. But getting errors like this on a clean device is a bit worrisome.

, ,

Leave a comment

Getting Started with Raspberry Pi

So I finally got the Raspberry Pi hardware yesterday. I will spare you the unboxing video, I’m sure there are a number of them already.

I plugged in the Raspberry Pi to a keyboard, a mouse, and a screen. Added the Wifi USB dongle and started it up.

This blog explores the different ways we can access the device by default. This is only an introduction, we probably will return to see some of those interfaces in more depth as we need them in the future.

Raspberry Pi on screen Experience

(Sorry, I have not figured out how to take screen shots on the Raspberry Pi yet, and phone picture are horrible. I will add screen shots when/if I figure it out)

First Start Up

After churning for a couple minutes, it prompted me for language and selecting the wireless network. That done, it re-directed me to the main screen.

If you saved the default settings, on subsequent start ups, the boot process sends you directly to the main screen.

Main Screen

On the main screen, the device information application is displayed. The top of the screen look like a task bar with applications running on the left with a system tray to the right.

The applications running are:

  • Device info
  • Tutorials

The system tray has:

  • Time
  • Device Settings
  • On/Off button

The On/Off button offers:

  • Shutdown
  • Restart

Device Settings Page

The Device Settings page allows you to set:

  • Basic preferences: Only sets language at this point
  • Network & Wi-Fi: Select and configure Wi-Fi

Windows 10 IoT Core Dashboard

Going back to my development computer and I fired up the Windows 10 IoT Core Dashboard to see what would show up.

Start up

The startup page gets you on the Set up a new device. Setting up a new device is used to create a new SD card. I already had a pre-configured SD card (from the starting pack) so I went directly to My devices.Dashboard1

Device List

My devices show a list of devices connected on your network. Give it a few minutes to detect your device.


From here you can open up the device Settings or Open in Device Portal. I went for Settings.

Device Settings

The Device Settings page allows you to change your device name and set your administrator password. You should take the time to at least change the password. The default password for the Administrator account is: p@ssw0rd


From here we’ll go to the Windows Device Portal in browser.

Windows Device Portal

The Windows Device Portal is a web page served directly by the device. It provides a lot more functionality than the IoT dashboard or the device interactive UI. The left hand menu allows you to navigate to different sections. PortalMenu

The sections are:

  • Home
  • Apps
  • Processes
  • Performance
  • Debugging
  • ETW
  • Perf Tracing
  • Devices
  • Bluetooth
  • Audio
  • Networking
  • Windows Update

Also a number of functions are available on the right hand header:


Here are the more high level and useful pages for now:


The home page provides information about the device, allows you to change the device name and change the administrator password.


App Manager

The App Manager page provides a lot of functionality. It allows you to manage applications, uninstall application, select default startup application. It also allows you to deploy new applications.



The debugging page provides a list of the current processes, displays error logs and set error reporting parameters. It also allows you to manually start the Visual Studio Remote Debugger.


Note: The remote debugger is not installed by default on Windows IoT Core 10586. It is only deployed the first time you start a debugging session from Visual Studio. If you attempt to start the Remote Debugger before you start a debugging session, you get the following error message is:



The networking section allows you to set the networking parameters. It provides a list of available networks and displace the current IP configuration for the different networking interfaces on the device (I snipped the screen shot, it actually showed 3 network adapters).




The Windows Update page allows you to check for available operating system updates. If updates are available they will be installed on the next restart.

Note: See my next post before clicking this button



This seems to be most of the out of the box high level user interfaces available to interact with the Windows 10 IoT Core operating system.

Of course there are also more advanced mode of interaction available like command lines, PowerShell and programming APIs. But we will see those in other posts in the future.




, , ,

Leave a comment

Why I’m writing this blog

Before going too far into the specific of Windows 10 Core IoT, I should define the guidelines of what I am trying to achieve with this blog.

As with any project, this blog needs objectives. Objectives helps guide development. They should be used to validate what you do on the project. And they can ultimately be used to identify success or failure.

Here are my objectives:

  1. Explore and learn the many different aspects of IoT. Form device building to cloud integration to user interfaces, there are a wide variety of IoT related subjects I want to explore.
  2. Leverage my software development knowledge to put together a system(s) and create re-usable components that will be useful for the development of IoT devices and infrastructure.
  3. Promote programming best practices and leverage OOP to build sound software systems to control IoT devices.
  4. Help other developers get started or do more with IoT.

As with any vision, I expect these objectives to evolve over time. But I think it should be enough get us started.


Leave a comment