Arduino Fun – Door Entry Alarm

 

Arduino UNO based door entry alarm

Physical computing and “internet of things” is a super exciting area that is unfolding right now. Even decades back one could hook up sensors and remotely get those data and process it. What is special now is that powerful micro-controllers are dirt cheap and most of us have in our pockets a really powerful computing device. Connecting everything wirelessly is also very easy now and almost every home has a wireless network.

All of these put together can create some really compelling and cool stuff where data travels from sensor over wireless networks into the cloud and finally into the cell phone we carry everywhere. I finally want to create a smart door so that I can get an notification while at work when someone knocks at our home door. Maybe I can remotely open the door. The possibilities are endless, but time is not, so lets see how far I get in some reasonable amount of time.

Arduino UNO

I unboxed the Arduino Uno Ultimate Starter Kit that I had got last week and spend some time with my daughter setting it up. The kit comes with a fantastic manual that helped me recap the basics of electronics. It contains an Arduino UNO prototyping board based on ATmega328 chip. It is a low-power 8-bit microprocessor running at max 20 MHz. To most people that seems paltry but it’s amazing what you can pull off with one of these chips.

The final assembled setup of the kit looks as follows. It comes with a nice handy plastic surface on which the Arduino (in blue) and a breadboard is stuck. It’s connected over USB to my PC.

Getting everything up was easy with the instruction booklet that came. Only glitch was that Windows 8 wouldn’t let me install the drivers because they are not properly signed. So I had to follow the steps given here to disable driver verification.

Post that the Arduino IDE connected to the board and I could easily write and deploy code (C like syntax).

The tool bar icons are a bit weird though (side arrow for upload and up arrow for open????).

There was no way to debug through the IDE (or at least couldn’t find one). So I setup some easy printf style debugging. Basically you write to the serial port and the IDE displays it.

It was after this that I got to know that there’s a Visual Studio plugin with full debugging support. However, I haven’t yet used that.

The Project

I decided to start out with making a simple entry alarm and see how much time it takes to get everything done. In college I built something similar, but without a microcontroller (based on 555 IC and IR photo-transistors) and it took decent amount of time to hook up all the components. Basically the idea is that across the door there will be some source of light and a sensor will be on the other side. When someone passes in between the light on the sensor will be obstructed and this will sound an alarm.

When I last did it in college I really made it robust by using pulsating (at fixed frequency) IR LED as source and IR sensors. Now for this project I relied on visible light and the photo-resistor that came with the kit.

I built the following circuit.

Connected a photo-resistor in series with another 10K resistor and connected the junction to the analog input pin A0 of Arduino. Essentially this acts like a voltage divider. In bright light the junction and hence A0 input reads around 1.1 V. When light is obstructed the resistance of photo-resistor changes and the junction reads 2.6 V. The analog pins read in a range of 0 (means 0 volt) and 1023 (for 5V). So this roughly comes to around 225 in light and 530 in the shade. Obviously these are relative based on the strength of the light and how dark it becomes when someone obstructs the light. To avoid taking absolute dependency on the value I created another voltage divider using a potentiometer and connected that to another analog input pin A1. So now I can change the potentiometer to control a threshold value. If the voltage of A0 is above this threshold it would mean that it’s dark enough that someone obstructed the light falling on the resistor and it’s time to sound the alarm.

The alarm consists of flashing blue and red LEDs (obviously to match police lights) and a standard siren sound played using a piezo crystal that also came with the kit.

This full assembled and deployed setup looks as follows.

Update*** The picture above says photo-transistor, it should be photo-resistor

Code

The key functions are setup() which is automatically called at startup and loop() which as the name suggests is called in a loop.setup() sets up the digital pins for output to drive the flashing LEDS. In loop() I read in the values of  photo-resistor and that from the potentiometer. Based on comparison I sound the alarm

// Define the constants
const int sensorPin  = 0;  // Photo-resistor pin
const int controlPin = 1;  // Potentiometer pin
const int buzzerPin  = 9;  // Buzzer pin
const int rLedPin    = 10; // Red LED pin
const int bLedPin    = 11; // Blue LED pin

// Always called at startup
void setup()
{
  // Set the two LED pins as output
  pinMode(rLedPin, OUTPUT);
  pinMode(buzzerPin, OUTPUT);
}

// This loops forever
void loop()
{
  int sensorVal = analogRead(sensorPin);
  int controlVal = analogRead(controlPin);

  if(sensorVal < controlVal)
  {
    // Light is below threshold so sound buzzer
    playBuzzer(buzzerPin);
  }

  delay(100);
}

void playBuzzer(const int buzzerPin)
{
  for(int i = 0; i < 3; ++i)
  {
    // alternate between two tones, one high and one low
    // at the same time alternate the blue and red LED flashing
    digitalWrite(rLedPin, HIGH);   // Red LED on
    tone(buzzerPin, 400);          // play 400 Hz tone for 500 ms 
    delay(500);
    digitalWrite(rLedPin, LOW);    // RED LED off
    
    digitalWrite(bLedPin, HIGH);   // Blue LED on
    tone(buzzerPin, 800);          // play 800Hz tone for 500ms
    delay(500);
    digitalWrite(bLedPin, LOW);    // Blue LED off
  }

  // Stop the buzzer
  noTone(buzzerPin);
}

Next Steps

This system has some obvious flaws. Someone can duck below or over the light-path or even shine a flashlight on the sensor while passing through. To make this robust consider using strips of mirrors on the two side and then use a laser (preferably IR) bouncing off them so that it’s virtually impossible to get through without breaking the light

Also you can decide to use a pulsating source of light and detect the frequency on the sensor. This will just make it more harder to break.

Information Management on our California Road Trip

I am just back from a road-trip that spanned 3200 miles (5000kms) from Seattle to San Diego and back. We travelled with a 8 year old, which meant more fun and excitement, for everybody ;)

My digital gear on this trip was as follows

	My Cyan Nokia Lumia 920 Wife’s White Lumia 920 Both with AT&T unlimited 4G connectivity. The Live Tile based Windows Phone 8 worked amazingly well. See below for the apps I used
	My daughter’s magenta Microsoft Surface RT My Gray Surface RT The tablets worked remarkably well and battery life was well beyond my expectation. My daughter could just shove in a USB thumb drive and watch videos off it directly on the Surface RT.
	Wife’s Acer Aspire. She still uses a Laptop and I needed it to process photos. The Surface RT unfortunately falls short as it cannot run Photoshop Lightroom for me. This sleek powerful laptop with ultra fast startup (due to SSD) worked pretty well.
	Cannon T1i (time to upgrade) and a bunch of lenses, flash, tripod, reflector, etc….
	Miscellaneous stuff, like thumb drives to backup photos, various chargers, etc…

I kept all of these stuff (other than the camera) in a single bag and carefully hauled them around. I ensured that they were never left unattended in the car.

My Windows Phone 8 (Nokia Lumia 920) rocked this trip. I am sure other phones would’ve worked as well, but the live tiles of Windows Phone really shined through. I installed a bunch of apps and pinned them all together.

One-Note: I literally run my life on One-Note these days. From planning trips, hikes, to debugging notes, I keep everything in One-note. Using One-Note I could plan my trip on the Surface from the hotel bed. The One-note doc would auto-sync with our phones ensuring that the information was on our finger-tips the next day when we were on the road. The large pinned California One-Note tile contained all our trip plans.

Weather App: I used The Weather Channel app. In the screen shot you can see the live tile for my next destination pinned to the home screen. WP8 allowed multiple of those to be pinned and I could always see what was coming up (sunny and mild day in SFO) in all the cities I was planning to be in. I could and did switch around order of cities I was travelling to based on weather forecast.

Nokia Drive + Maps + City Lens: In addition to the car GPS we used Nokia suite of tools including the Drive, Maps and City Lens to get our bearing while walking around in the city. Few times we used the phone for in car navigation as well. The maps didn’t let us down.

gMaps: Unfortunately the gMaps Google map app didn’t work out that well for me. Google maps has much better data in some contexts (e.g. trails and street view) but the app was unstable and also it always needed connectivity and reduced network coverage on the road was seriously hampering the usage. I think it is sad that Google doesn’t make their own apps for the Windows Phone.

Music: We used Nokia Music as it has better Bollywood coverage. We also got a ton of our Bengali music collection onto the phone. By the end of the trip, Prokriti (my daughter) was humming tunes from our college day music.

Hotels.com: I did most of my booking on hotels.com. Especially because it gives 1 day free stay on making 10 reservations. The limited screen on the device did pose some issues in making the right hotel choices but I even made a reservation while standing in a queue in Seaworld.

TripAdvisor: for finding local points of interest

Yelp: For deciding where to eat.

4th & Mayor for making foursquare checkins so that I can later recollect where I’d been.

Netflix: To keep my daughter busy when the trip really seemed long. I do have unlimited AT&T 4G on our phones but high-speed connectivity is hard to come by on the road. So she mostly watched stuff on her Surface.

Photoshop Lightroom: On most nights after settling down in the hotel, I would transfer photos from my camera and do a quick pass with Lightroom. I’d make reject and keep calls on them. Then backup the photos on a thumb-drive and also copy over to one of the Surface RT. So I essentially had 3 copies backed up at all times.

C++/CLI and mixed mode programming

I had very limited idea about how mixed mode programming on .NET works. In mixed mode the binary can have both native and managed code. They are generally programmed in a special variant of the C++ language called C++/CLI and the sources needs to be compiled with /CLR switch.

For some recent work I am doing I had to ramp up on Managed C++ usage and how the .NET runtime supports the mixed mode assemblies generated by it. I wrote up some notes for myself and later thought that it might be helpful for others trying to understand the inner workings.

History

The initial foray of C++ into the managed world was via the managed extension for C++ or MC++. This is deprecated now and was originally released on VS 2003.  This MC++ syntax turned out to be too confusing and wasn’t adopted well. The MC++ was soon replaced with C++/CLI. C++/CLI added limited extension over C++ and was more well designed so that the language feels more in sync with the general C++ language specification.

C++/CLI

The code looks like below.

ref class CFoo
{
public:
    CFoo()
    {
        pI = new int;
        *pI = 42;
        str = L"Hello";
    }

    void ShowFoo()
    {
        printf("%d\n", *pI);
        Console::WriteLine(str);
    }

    int *pI;
    String^ str;
};

In this code we are defining a reference type class CFoo. This class uses both managed (str) and native (pI) data types and seamlessly calls into managed and native code. There is no special code required to be written by the developer for the interop.

The managed type uses special handles denoted by ^ as in String^ and native pointers continue to use * as in int*. A nice comparison between C++/CLI and C# syntax is available at the end of http://msdn.microsoft.com/en-US/library/ms379617(v=VS.80).aspx. Junfeng also has a good post at http://blogs.msdn.com/b/junfeng/archive/2006/05/20/599434.aspx

The benefits of using mixed mode

1. Easy to port over C++ code and take the benefit of integrating with other managed code
   
2. Access to the extensive managed API surface area
   
3. Seamless managed to native and native to managed calls
   
4. Static-type checking is available (so no mismatched P/Invoke signatures)
   
5. Performance of native code where required
   
6. Predictable finalization of native code (e.g. stack based deterministic cleanup)

 

Implicit Managed and Native Interop

Seamless, static type-checked, implicit, interop between managed and native code is the biggest draw to C++/CLI.

Calls from managed to native and vice versa are transparently handled and can be intermixed. E.g. managed --> unmanaged --> managed calls are transparently handled without the developer having to do anything special. This technology is called IJW (it just works). We will use the following code to understand the flow.

#pragma managed
void ManagedAgain(int n)
{
    Console::WriteLine(L"Managed again {0}", n);
}

#pragma unmanaged
void NativePrint(int n)
{
    wprintf(L"Native Hello World %u\n\n", n);
    ManagedAgain(n);
}

#pragma managed

void ManagedPrint(int n)
{
    Console::WriteLine(L"Managed {0}", n);
    NativePrint(n);
}

The call flow goes from ManagedPrint --> NativePrint –> ManagedAgain

Native to Managed

For every managed method a managed and an unmanaged entry point is created by the C++ compiler. The unmanaged entry point is a thunk/call-forwarder, it sets up the right managed context and calls into the managed entry point. It is called the IJW thunk.

When a native function calls into a managed function the compiler actually binds the call to the native forwarding entry point for the managed function. If we inspect the disassembly of the NativePrint we see the following code is generated to call into the ManagedAgain function

00D41084  mov         ecx,dword ptr [n]         // Store NativePrint argument n to ECX
00D41087  push        ecx                       // Push n onto stack
00D41088  call        ManagedAgain (0D4105Dh)   // Call IJW Thunk

Now at 0x0D4105D is the address for the native entry point. If forwards the call to the actual managed implementation

ManagedAgain:
00D4105D  jmp         dword ptr [__mep@?ManagedAgain@@$$FYAXH@Z (0D4D000h)]  

Managed to Native

In the case where a managed function calls into a native function standard P/Invoke is used. The compiler just defines a P/Invoke signature for the native function in MSIL

.method assembly static pinvokeimpl(/* No map */) 
        void modopt([mscorlib]System.Runtime.CompilerServices.CallConvCdecl) 
        NativePrint(int32 A_0) native unmanaged preservesig
{
  .custom instance void [mscorlib]System.Security.SuppressUnmanagedCodeSecurityAttribute::.ctor() = ( 01 00 00 00 ) 
  // Embedded native code
  // Disassembly of native methods is not supported.
  //  Managed TargetRVA = 0x00001070
} // end of method 'Global Functions'::NativePrint

The managed to native call in IL looks as

Manged IL:
  IL_0010:  ldarg.0
  IL_0011:  call void modopt([mscorlib]System.Runtime.CompilerServices.CallConvCdecl) NativePrint(int32)

The virtual machine (CLR) at runtime generates the correct thunk to get the managed code to P/Invoke into native code. It also takes care of other things like marshaling the managed argument to native and vice-versa.

Managed to Managed

While it would seem this should be easy, it was a bit more convoluted. Essentially the compiler always bound to native entry point for a given managed method. So a managed to managed call degenerated to managed -> native -> managed and hence resulted in suboptimal double P/Invoke. See http://msdn.microsoft.com/en-us/library/ms235292(v=VS.80).aspx

This was fixed in later versions by using dynamic checks and ensuring managed calls always call into managed targets directly. However, in some cases managed to managed calls still degenerate to double P/Invoke. So an additional knob provided was the __clrcall calling convention keyword. This will stop the native entry point from being generated completely. The pitfall is that these methods are not callable from native code. So if I stick in a __clrcall infront of ManagedAgain I get the following build error while compiling NativePrint.

Error	2	error C3642: 'void ManagedAgain(int)' : cannot call a function with
 __clrcall calling convention from native code	<filename>

/CLR:PURE

If a C++ file is compiled with this flag, instead of mixed mode assembly (one that has both native and MSIL) a pure MSIL assembly is generated. So all methods are __clrcall and the Cpp code is compiled into MSIL code and NOT to native code.

This comes with some benefits as in the assembly becomes a standard MSIL based assembly which is no different from another managed only assembly. Also it comes with some limitation. Native code cannot call into the managed codes in this assembly because there is no native entry point to call into. However, native data is supported and also the managed code can transparently call into other native code. Let's see a sample

I moved all the unmanaged code to a separate /C++:CLI dll as

void NativePrint(int n)
{
    wprintf(L"Native Hello World %u\n\n", n);
}

Then I moved my managed C++ code to a new project and compiled it with /C++:PURE

#include "stdafx.h"
#include 

#include "..\Unmanaged\Unmanaged.h"
using namespace System;

void ManagedPrint(int n)
{
    char str[30] = "some cool number";     // native data  
    str[5] = 'f';                          // modifying native data
    Console::WriteLine(L"Managed {0}", n); // call to BCL
    NativePrint(n);                        // call to my own native methods
    printf("%s %d\n\n", str, n);           // CRT
}

int main(array ^args)
{
    ManagedPrint(42);
    return 0;
}

The above builds and works fine. So even with C/++:PURE I was able to

1. Use native data like a char array and modify it
   
2. Call into BCL (Console::WriteLine)
   
3. Call transparently into other native code without having to hand generate P/Invoke signatures
   
4. Use native CRT (printf)

However, no native code can call into ManagedPrint. Also do note that even though Pure MSIL is generated, the code is unverifiable (think C# unsafe). So it doesn't get the added safety that the managed runtime provides (e.g. I can just do str[200]  = 0 and not get any bounds check error)

/CLR:Safe

/CLR:safe compiler switch generates MSIL only assemblies whose IL is fully verifiable. The output is not different from anything generated from say C# or VB.NET compilers. This provides more security to the code but at the same time losses on several capabilities over and above the PURE variant

1. No support for CRT

1. Only explicit P/Invokes

So for /CLR:Safe we need to do the following

[DllImport("Unmanaged.dll")]
void NativePrint(int i);

void ManagedPrint(int n)
{
    //char str[3000] = "some cool number"; // will fail to compile with  
    //str[5] = 'f';                        // "this type is not verifiable"

    Console::WriteLine(L"Managed {0}", n);

    NativePrint(n);                        // Hand coded P/Invoke

Migration

MSDN has some nice articles on people trying to migrate from /CLR to

1. To /CLR:Pure http://msdn.microsoft.com/en-US/library/ms173253(v=vs.80).aspx

1. To /CLR:Safe http://msdn.microsoft.com/en-US/library/ykbbt679(v=vs.80).aspx

Moving to Outlook from Google Reader

I am sure everyone by now knows that Google Reader is being shutdown. I am a heavy user of Google Reader or Greeder as I call it and I immediately started looking for an alternative, when this suddenly occurred to me, that all PC’s I use have Outlook installed on them. So if you work for an organization that runs on Exchange server, this could really work out well. You can use Office Outlook and Exchange as a great RSS feed reader. Consider this

1. It will provide full sync across multiple Outlook clients running on different PCs
2. It will provide on the go access via Outlook Web-access
3. Your phone’s outlook client should also work with it
4. You can pretend to work while wasting time on boingboing

First things first: Export the opml file from Google Reader

Login to www.google.com and then go to https://www.google.com/takeout/#custom:reader

This will take some time and create an archive.

Click on the download button and save the zip. Then extract the zip as follows

Inside the extracted folder you will have the opml file. For me it’s in C:\Users\admin\Desktop\XXXXXXXX@gmail.com-takeout\XXXXXXXX@gmail.com-takeout\Reader\subscriptions.xml

Import to Outlook

This opml file needs to be imported into outlook. Use the File tab and bring up the following UI in Outlook.

Then use Import. To bring up the following

Choose OPML file and tap on Next. Now point it to the file you extracted. For me it was C:\Users\admin\Desktop\XXXXXXXX@gmail.com-takeout\XXXXXXXX@gmail.com-takeout\Reader\subscriptions.xml

Hit next and finally choose the feeds you want to import (Select All).

The tap on Next and here you have Outlook as an Rss feed reader…

Read Everywhere

It totally sync’s on the cloud. Here I have it open on the browser. As you read a post it tracks what you are reading and across the browsers and all your outlook clients at work and home it will update and keep everything in sync.

Works great on the Windows Phone as well. I assume any Exchange client should work.

Pain Points

While reading on Outlook was seamless, there are some usability issues in both the browser and the phone. Surface RT is broken. Someone should really fix the mail client on Surface

The major paint point I see is that in the Outlook Web Access the pictures are not shown. Tapping on the picture placeholders work. I think some security feature is blocking the embedded images.

Also on the Windows Phone you have to go to each feed and set it up so that it syncs that folder. This is a pain but I guess this is to protect against download over the carrier networks.

C# code for Creating Shortcuts with Admin Privilege

 

Context

If you just care about the code, then jump to the end
 

In the CLR team and across other engineering teams in Microsoft we use build environments which are essentially command shells with a custom environment setup using bat and cmd scripts. These scripts setup various paths and environment variables to pick up the right set of build tools and output paths matching the architecture and build flavor. E.g. one example of launching such a shell could be…

cmd.exe /k %BRANCH_PATH%\buildenv.bat <architecture> <build-flavor> <build-types> <etc...>

The architectures can vary between things like x86, amd64, ARM, build flavors vary between debug, check, retail, release, etc… The build-types indicate the target like desktop, CoreCLR, metro. Even though all combination is not allowed, the allowed combination approaches around 30. In case of .NET Compact Framework which supports way more architectures (e.g. MIPS, PPC) and targets (e.g. Xbox360, S60) the combination is even larger.

For day to day development I either need to enter this command each time to move to a different shell, or I have to create desktop shortcuts for all the combination. This becomes repetitive each time I move to a different code branch. I had created a small app that I ran each time I moved to a new branch and it would generate all the combination of shortcut given the branch details. However, our build requires elevation (admin-privilege). So even though I created the shortcuts, I’d have to either right click and use “Run as administrator” OR set that in the shortcuts property.

This was a nagging pain for me. I couldn’t find any easy programmatic way to create a shortcut with Administrator privilege (I’m sure there is some shell API to do that). So finally I binary compared two shortcuts, one with the “Run as administrator” and one without. I saw that only one byte was different. So I hacked up a code to generate the shortcut and then modify the byte. I am sure there is better/safer way to do this, but for now this “Works for me”.

The Code

Since I didn’t find any online source for this code, I thought I’d share. Do note that this is a major hack and uses un-documented stuff. I’d never do this for shipping code or for that matter anything someone other than me would rely on. So use at your own risk… Also if you have a better solution let me know and I will use that…

   1:  // file-path of the shortcut (*.lnk file)

   2:  string shortcutPath = Path.Combine(shortCutFolder, string.Format("{0} {1}{2}.lnk", arch, flavor, extra));

   3:  Console.WriteLine("Creating {0}", shortcutPath);

   4:  // the contents of the shortcut

   5:  string arguments = string.Format("{0} {1} {2} {3}{4} {5}", "/k", clrEnvPath, arch, flavor, extra, precmd);

   6:   

   7:  // shell API to create the shortcut

   8:  IWshShortcut shortcut = (IWshShortcut)shell.CreateShortcut(shortcutPath);

   9:  shortcut.TargetPath = cmdPath;

  10:  shortcut.Arguments = arguments;

  11:  shortcut.IconLocation = "cmd.exe, 0";

  12:  shortcut.Description = string.Format("Launches clrenv for {0} {1} {2}", arch, flavor, extra);

  13:  shortcut.Save();

  14:   

  15:  // HACKHACK: update the link's byte to indicate that this is a admin shortcut

  16:  using (FileStream fs = new FileStream(shortcutPath, FileMode.Open, FileAccess.ReadWrite))

  17:  {

  18:      fs.Seek(21, SeekOrigin.Begin);

  19:      fs.WriteByte(0x22);

  20:  }