Jim Travis's Blog

Learning Pathways for Sensors and Location

We've published a new Windows Developer Center on MSDN. Part of the update includes a nice page for learning about Windows 7 sensors and location. Here's the link: http://msdn.microsoft.com/en-us/windows/ee658252.aspx

Enjoy!

u-blox Releases Windows 7 Driver

Press release here: http://www.u-blox.com/en/press-and-events/press-release-archive/845.html

If you're looking for GPS hardware to use for developing your Windows 7 location-aware apps, u-blox has a solution available now.

Driver here:  http://www.u-blox.com/en/usb-drivers/windows-7-driver.html

Sensor API interop in Windows API Code Pack

Here's a source code release for .NET interop with Win32 features, including the Sensor API:

http://code.msdn.microsoft.com/WindowsAPICodePack

The Windows® API Code Pack for Microsoft® .NET Framework provides a source code library that can be used to access some new Windows 7 features (and some existing features of older versions of Windows operating system) from managed code. These Windows features are not available to developers today in the .NET Framework.

Sensor Constants and VECTOR Types

In the Windows 7 Sensor platform, some properties and data fields contain arrays of information. For example, the SENSOR_PROPERTY_LIGHT_RESPONSE_CURVE property contains an array of 4-byte unsigned integers. However, when you receive such arrays through the Sensor API, they will always represented as type VT_VECTOR|UI1, an array of single-byte characters, regardless of the actual type of the data in the array. This requirement arises because the platform uses the WPD serializer when moving data from the sensor class extension to the API layer. The WPD serializer can serialize arrays of data only if the individual data type is UI1.

From the driver perspective, this means that PROPVARIANT for these array types should be created by using InitPropVariantFromBuffer. This function creates the PROPVARIANT as type VT_VECTOR|UI1. Here's some example code that creates a light response curve:

UINT responseCurve[10] = {0}; // Array to contain the response curve data.

// ****************************************************************************************

// The response curve consists of an array of integer pairs.

// The first integer contains the percentage brightness offset to be applied to the display.

// The second integer contains the corresponding ambient light value (in LUX).

// ****************************************************************************************

// (0, 10)

responseCurve[0] = 0; responseCurve[1] = 10;

// (10, 40)

responseCurve[2] = 10; responseCurve[3] = 40;

// (40, 80)

responseCurve[4] = 40; responseCurve[5] = 80;

// (68, 100)

responseCurve[6] = 68; responseCurve[7] = 100;

// (90, 150)

responseCurve[8] = 90; responseCurve[9] = 150;

// Create the buffer.

PROPVARIANT pvCurve = {0};

InitPropVariantFromBuffer(responseCurve, 10 * sizeof (UINT), &pvCurve);

// Add the values to the IPortableDeviceValues object.

hr = m_pSensorProperties->SetValue(SENSOR_PROPERTY_LIGHT_RESPONSE_CURVE, &pvCurve);

PropVariantClear(&pvCurve);

From the API perspective, you must be careful to cast arrays to the correct data type for the property or data field. Here's an example of how to "unpack" the light response curve data on the API side:

PROPVARIANT pvCurve;
PropVariantInit(&pvCurve);

// Retrieve the property value.
hr = pSensor->GetProperty(SENSOR_PROPERTY_LIGHT_RESPONSE_CURVE, &pvCurve);
if (SUCCEEDED(hr))
{
    if ((VT_UI1|VT_VECTOR) == V_VT(pvCurve)) // Note actual type of UI1
    {
        // Cast the array to UINT, a 4-byte unsigned integer.

        // Item count for the array.
        UINT  cElement = pvCurve.caub.cElems/sizeof(UINT);
        // Array pointer.
        UINT* pElement = (UINT*)(pvCurve.caub.pElems);

        // Use the array.
    }
}

// Remember to free the PROPVARIANT when done.
PropVariantClear(&pvCurve);

Earlier documentation for the Sensor API and WDK (or the header, sensors.h) did not call out this re-typing requirement. We've been updating the docs, but the header comments will continue to show the actual data type, without mention of the serialization issue.

New page on Freescale's Web site for the Windows 7 Sensor Development Kit

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=JMBADGE2008-B

Location Sensors Question from a Reader

A reader asks: 

I've searched for information on Internet how to say to Windows 7 that external Bluetooth GPS should be used as the location sensor, but actually I have not found any answers, just the similar questions in forums. Probably it would be a good post in your blog which will explain what is possible and what not. I suspect there should be some driver support for translating information from Bluetooth COM ports to location, but it should be some class driver that is part of Sensor & Location API. I am using Nokia LD-3W BT GPS. It has category Other and from services there is only Serial Port. GPS function works just fine with legacy applications that use COM port directly, but I would like to know how Win7 can utilize this device as Location sensor.

The Sensor and Location platform in Windows 7 does not provide a class driver for location sensors. In this particular instance, Nokia would have to write an updated native driver for the GPS. Alternatively, you could write a COM port-based sensor driver, but this is not a trivial exercise.

Firmware update for Freescale Windows 7 Sensor Development Kits

http://code.msdn.microsoft.com/SensorsAndLocation/Release/ProjectReleases.aspx?ReleaseId=2359

See the “Sensor Development Kit for Windows 7”  link.

This firmware puts the badge board into sensor demo mode, by default. See the readme for details about how to update your firmware.

Windows 7 Sensor Development Kits available from Freescale

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=JMBADGE&tab=Buy_Parametric_Tab&fromSearch=false

If you've seen the sensor development kits we handed out at PDC and WinHEC last year, but couldn't get your hands on one, great news! They're now for sale through Freescale's website.

Be forewarned: Freescale's web page doesn't quite indicate that this is the Windows 7 Sensor Development Kit, yet, but rest assured that the product is the correct one.

Enjoy!

Sometimes, it's the low-tech solution that's best

Here's a great article that spotlights a colleague in PC3 at Microsoft. Mike LaManna has done some great work, here, with a low-tech (and virtually free) accessibility solution that will help a lot of people.

 Click here for the article.

The .NET Interop Sample and 64-bit

If you don't compile the interop sample for 64-bit and then try to use the x86 version in your 64-bit project, you'll get a BadImageFormatException when you try to compile your project. This is to be expected. However, we've noticed that the x64 configuration in the interop sample isn't correct, so when you specify x64, you get a x86 compilation anyway. You can change the configuration settings yourself in the configuration manager so that Windows7.SensorAndLocation build as x64 when the x64 configuration is chosen for Debug or Release. Note that XNA framework is x86 only, so you should uncheck the MarbleSample's Build check box in x64 configurations.

The team that posted the sample is working to update the download package. (Thanks to Yochay Kiriaty.)

The DEFINE_PROPERTYKEY macro

If you've worked with property keys, say with Windows Portable Devices, you've probably run across this macro. The Sensor platform would require you to define your own property keys if, say, you want to define a custom sensor data type. This macro isn't currently well documented (we're working to fix that), so it can be a bit confusing to use.

Here's the current macro definition from Propkeydef.h:

#ifdef INITGUID
#define DEFINE_PROPERTYKEY(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8, pid) EXTERN_C const PROPERTYKEY DECLSPEC_SELECTANY name = { { l, w1, w2, { b1, b2,  b3,  b4,  b5,  b6,  b7,  b8 } }, pid }
#else
#define DEFINE_PROPERTYKEY(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8, pid) EXTERN_C const PROPERTYKEY name
#endif // INITGUID 

When using this macro, you basically have two options:

1. Include Initguid.h in your project. In this case, the macro will declare the property key names and define the property keys for you. This approach works in most cases, but can cause naming collisions in large, complex projects.
2. Do not include Initguid.h. Instead, compile your definitions into a static library file having a .lib file name extension. In this case, the macro will simply declare the names for your property keys for the compiler's use, but you will need to reference your .lib file in your project's linker settings. This approach works best in large projects that use multiple modules, because it avoids the naming collisions mentioned in option 1. 

Using the macro without including Initguid.h and without referencing a library file will raise the error LNK2001, so if you see that error for your property key declarations, now you know what to do about it.

By the way, the property keys declared in Sensors.h are defined in Sensorsapi.lib. So, you can see that the sensor team chose option 2 when coding the platform.

.NET interop sample available for Sensor API and Location API

If you've been itching to work with sensors and location, but prefer to use .NET, here's great news for you!

http://code.msdn.microsoft.com/SensorsAndLocation

Here's a direct link to the code download:

Siftables: Toy Blocks Become a Computer

MIT Team Shows 'Sixth Sense' Wearable Computer

Sensor Windows Driver Kit beta docs on MSDN

http://msdn.microsoft.com/en-us/library/bb870493.aspx 

We're experiencing some issues with rendering bulleted and numbered lists and working diligently to resolve this issue. Thanks for being patient.