I spent a little time this evening working on a screen for the Windows Mobile version of BlueGPS. I have a few bugs to work out and should be releasing it within the next week. Here’s a sample screen:

I plan on getting the compass to display the appropriate direction. I had a compass in the Symbian version that didn’t really do anything functional. Windows Mobile appears to make image handling 100 times easier than Symbian so integrating the compass should be pretty straightforward. I’ll post a download and feature list when it’s ready.

As I’ve been working on my Bluetooth GPS app for Windows Mobile I’ve been thinking how to display useful information on a map. The GPS receiver provides all sorts of data such as location, altitude, speed, direction and many other things. Instead of displaying this information in a simple text format I’d like to do something more visual.

Tonight I was able to work up a basic speed example that represents three different states: 0-15 MPH (red icon), 16 – 45 MPH (yellow icon), and anything over 45 MPH (green icon). You can see a screen of a recent trip. I used my Bluetooth GPS app, which currently logs data to a text file. At the end of the trip I’m able to upload the data to my server. I’m still working on getting the real-time piece in place. This would allow my Windows Mobile device to upload data to the server while I drive.

My next step for the UI piece will be to represent direction in a visual format. This will most likely come in the form of a rotated icon since the GPS receiver returns direction in degrees (in relation to north). Representing altitude will be more challenging and for now it will simply display in the info bubble when you click on a marker. You can click here or on the image below to see the interactive version.

I recently updated my Bluetooth GPS app for Windows Mobile to accommodate speed and direction.  I’m still working through a threading problem with sending data over HTTP.  This would enable more real-time communication between the device and server.  Think about driving in a car and having someone being able to see your location update automatically on a map.  This is the type of stuff we do at work, but at an enterprise level.

You can see the screen below and this doesn’t deserve any style points.  My next objective will be to put a decent looking UI behind the app and get it communicating with the server.  Right now it logs GPS data to a file every 10 seconds and one of my goals is to take it running with me.  When I’m done I think it will be cool to analyze the data (location, speed, direction) on a Google map.  It will definitely be cumbersome to run with a phone in one hand and GPS unit in another, but it’s just a proof of concept.  It won’t be long before all of this is intergrated into a single device that you can wear on your wrist.  Garmin is getting close.

In my recent post about programming my Cingular 8125 to talk to my Bluetooth GPS receiver, I failed to realize one minor detail.  Since I was pretty excited about getting longitude, latitude, and altitude to display on my phone I didn’t realize that it wasn’t updating.  No matter how long I let it run the values constantly stayed the same.  This was strange since I could see that the receiver and phone were paired and communicating.

After spending a couple of hours troubleshooting and debugging I realized that the values were being read correctly from the receiver, but weren’t being updated on the display.  Then I decided to test a quick debug hack that I normally run just to validate a value exists: MessageBox.show(longitude).  This displays a simple alert box and what suprised me was that each time I pressed “ok” the screen would redraw and display the appropriate value.  So I figured this was a simple fix and I would just need to invalidate or refresh the screen.  It turns out this was the wrong assumption.

So after another hour of pulling my hair out I decided there had to be something wrong with the thread that handled the serial port communication.  I figured this was a long shot since the values were actually coming in correctly, but for some strange reason I couldn’t get them to display (without the MessageBox hack).  My final guess was that the data was streaming so quickly that the UI didn’t have time to update with the new values.  So I updated the method responsible for reading the serial port data and placed a simple one second pause to prevent it from receiving data too quickly.  I lucked out on my final guess and everything now runs like a champ.  The one second delay did the trick and if you decide to use the code from this example then I would recommend updating your serialPort_DataReceived method with the following:

private void serialPort_DataReceived()
{
byte[] inputData = new byte[1];
string s = String.Empty;
while(serialPort.InBufferCount > 0)
{
inputData = serialPort.Input;
if(inputData[0] != ‘\r’ && inputData[0] != ‘\n’)
s += Encoding.ASCII.GetString(inputData, 0, inputData.Length);
else
{
parseNmeaSentence(s);
s = string.Empty;
}
}
Thread.Sleep(1000);
}

It’s amazing what simple lines of code can do!  I’ll be posting the app for download once I get a few more features in place.

I’ve been using the mobile version of Virtual Earth for a couple of weeks now and have found it to be very handy. This appears to Microsoft’s response to Google’s mobile mapping application. The main limitation that I’ve found with Google’s software is the fact that it cannot determine my current location. Virtual Earth Mobile tries to solve this problem in one of two ways. The first (less accurate) approach is to do an IP lookup when connected to a WiFi access point. Based on the IP of the access point, the location (generally the ISP location) can be looked up. This is somewhat accurate, but not all of the time. The other approach is using GPS, which can be accurate up to a few meters. The problem I’ve found with Virtual Earth Mobile is that it can’t find my Bluetooth GPS receiver. I’ve tried all sorts of configurations, but have fallen short.

I believe Virtual Earth Mobile is compatible with devices that have internal GPS units. At least that’s what I’m assuming. In the meantime I’m planning on experimenting with the Virtual Earth source code and hooking it up to some code I got working over the weekend.  This means I should be able to pass these location coordinates off to the Virtual Earth API and have some sort of real-time positioning and routing. It will be an interesting experiment and I’ll post what I find out. If anyone has successfully configured their Bluetooth GPS to work with Virtual Earth Mobile, then I would love to hear about it.

Since I started working at SensorLogic I’ve been fascinated with the whole machine-to-machine space. I’ve been inspired to connect everything I possibly can to the Internet. A couple of years ago I decided to write a program for my P900 called BlueGPS, which runs on several Symbian devices. BlueGPS allowed my P900 to communicate with a Bluetooth GPS receiver and send location data over the air to the SensorLogic platform. If you look at the diagram below (which I grabbed shamelessly from SL) you’ll see that the GPS receiver is represented as a sensor and my P900 is the access point.

This is a fairly common network topology for M2M communications. I recently retired the Symbian BlueGPS project and am working to make the project open source. The main reason is that I’ve switched phones and haven’t released an update in over a year. I’m hoping developers from the community will pick it up and run with it.

I’m finally getting to the subject of this post. This past weekend I was digging around for some Bluetooth code that would run on my Windows Mobile device (Cingular’s 8125). I stumbled across this article that describes how to do serial communications using the .NET compact framework. The code in the article leverages the OpenNETCF Smart Device Framework, which basically handles most of the communication between my Windows Mobile device and Bluetooth GPS receiver.

So I was able to modify a fair amount of the code to work with my Bluetooth GPS receiver and I can successfully display location information on my phone. The main thing I had to modify was the way the program parsed NMEA sentences. It was parsing the GLL sentence while I wanted to use the GGA sentence, which includes altitude information. You can see an image of the app running on my phone below.

Yes it’s extremely ugly and I hope to design a nice user interface for it in the next week or two. I’m also working on getting the information sent wirelessly to SensorLogic’s platform where the data can be displayed and exported. I’m planning on releasing a version for Windows Mobile users to download once I get everything in order.