I just wanted to share an initiative that we’re working on here at Ublip. We believe there’s a shortage of information and collaboration in the M2M space. There are a lot of hardware manufacturers and wireless carriers releasing independent discussion groups, but they’re mainly centered around promoting/supporting named company’s product. We’re proposing something different. There are so many different moving parts in creating an end-to-end working solution and we’re trying to capture these conversations at M2MForums.com. If you have expertise in hardware, software, wireless networks, or the business side of M2M, then we believe M2MForums is the place for you. Some good discussions are already taking place and please feel free to join our growing community.

I’ve been doing a considerable amount of hacking with the iPhone SDK, mainly to get the iPhone communicating with our Foundation product. Last night I was trying to display the horizontal accuracy from the iPhone’s CoreLocation API in our Foundation user interface. The horizontal accuracy is the radius of uncertainty of the iPhone’s location (and it’s measured in meters). The uncertainty I was dealing with at the time of development was 1618 meters. I’ve seen the iPhone come close to 100m and even better when connected via WiFi, but more on that later.

As part of our Foundation product we provide some simple JavaScript functions that make it easy to draw geofences on Google Maps. If you’re not familiar with a geofence, it’s basically a virtual boundary you can create to receive a notification if a device moves into or out of it. In most circumstances a circular geofence is used. So I spent an hour trying to understand why I couldn’t get the geofence overlay to display on Google Maps. Here’s my initial screen:

After a considerable amount of time and frustration passed (1 hr to be exact) I decided to zoom nearly all the way out and was surprised to see that I geofenced all of North America. Then I came to the realization that units were keeping me down (m vs mi). I was passing 1618 meters into our function, which was expecting miles. This yielded the following screen:

My geofence was only 1,617 miles off. It turns out that 1618 meters is just a tad bit more than a mile. Finally, I ended up with exactly what I needed:

Ah yes, much better. The image above shows the reading from inside our office building where we’re surrounded by all sorts of windows, walls, cubes, etc. Because of triangulation we’re able to get readings indoors and even underground. Even though the accuracy isn’t all that precise it’s enough to do some really interesting things. If you’d like to get your iPhone hooked up to the Ublip Foundation for development and testing purposes please feel free to comment or drop us a line.

Cnet reports that Keyhole Markup Language (KML) has been accepted as an open standard by the Open Geospatial Consortium. This is the language that Google Earth and Google Maps data is stored in, and can be used to describe anything from a point in 3D space, to polygons, to the shape, style, and color of the lines used to draw them. Although KML has already been used by a number of companies other than Google, this should help it gain even wider acceptance.

If you’re interested in what KML looks like and how to write or consume it, Google Code has some great KML documentation. The spec itself (at least, in the form that will go through the working committee for final approval) is here.

I’ve always been a firm believer in the fact that “Location Matters”. Location is important and relevant in nearly every instance I can think of. Do you ever hear a song on the radio and it triggers a thought of where you were when you first heard it? Whenever I hear Daughter by Pearl Jam I think back to a bus trip to UNC Chapel Hill to get our butts kicked in a soccer game. Brad Harris actually had the CD and let me listen to it. But I digress.

What triggered this blog post was a recent trip we took to Six Flags with our daughter. I decided it would be a fun experiment to take one of our portable GPS trackers with us to Six Flags and map our trip. The biggest incentive for me was to see if I could get a 90 mph speed reading while plummeting down the first hill of the Titan. Unfortunately, we didn’t get around to riding the Titan but plan on making it back. You can see a sample of our trek around Six Flags below.

It’s amazing the amount of detail that some of Google’s satellite imagery provides. In an instance I could look at all the blips and think of a “story” that was associated with each one. As an example, blip #1 was when we rode the Judge Roy Scream and blip #9 is where we stopped (note the red color) and ate dinner. Each one of these blips tells a story and if a picture’s worth a thousand words, then a map with blips is worth a thousand more. Here’s some YouTube footage of the Judge Roy Scream that I just stumbled across. Nothing too crazy, but with a 4 yr old you gotta ease them into the wild world of rollercoasters:

As a side note, I think there could be incredible value for Six Flags to actually rent these portable GPS trackers at the gate. It would be a great way for parents to keep track of kids/teens while at the park (on a parents cell phone). They already rent a “Flash Pass” that allows holds your virtual place in line. Based on the current wait times you get notified when it’s your turn in line. This all happens while you’re off somewhere else eating lunch or riding another ride. So it’s apparent that Six Flags has embraced the whole upsell model.

As I see it, the leading M2M equipment manufacturers are fighting for market share by chosing one of two device design philosophies. A few are even trying to place their bets on both. Ultimately, the market will decide their fate. The question is whether the market wants “closed” devices with predefined, though configurable, functionality or whether it wants “open” devices with the flexibility to be programmed for a specific application.

In the M2M world today, there are “closed” devices that are configurable, but not programmable, and some that are “open” devices that can be programmed. The largest volume of devices seem to be the “closed” type, but they exist to satisfy several very specific business needs — examples include sub-prime car loans, teen tracking, and various specialized security applications.

When I talk to people who have application ideas, they are very creative about how to use the existing “closed” devices to help them solve a business problem, but often the “closed” device can only get them to the starting gate. So much of their “wish list” requires special features that can’t be justified in a general-purpose device. However, if the specialization can be defined in terms of software and not additional hardware, suddenly the “open” device options become much more attractive.

The tradeoffs are pretty straightforward. “Closed” devices benefit from larger production runs leading to lower costs per unit. With larger numbers come more tested scenarios leading potentially to greater stability and robustness. “Open” devices currently sell fewer numbers, have higher costs, and have been tested less. BUT they also can acheive a wider range of functionality and address a larger number of business solutions.

If “closed” devices are winning on price, volume, and robustness, “open” devices could surge forward by continuing price reductions and the availablity of effective over-the-air programming (OTAP) options, leading to the potential for even greater volume and the hardening through real field use.

Which will win this time? There are serious contenders in both camps. I’m not picking winners here (yet) and am holding off (for now) naming “front runners.” But I’m enjoying watching the battle. Stay tuned…