Click here to Skip to main content
13,349,997 members (48,812 online)
Click here to Skip to main content
Add your own
alternative version


30 bookmarked
Posted 27 Nov 2008

PlanetFinder for Windows Mobile

, 17 Dec 2008
Rate this:
Please Sign up or sign in to vote.
PlanetFinder application for Windows Mobile Smartphones

Planet Finder is a Java applet that constructs sky images. The applet shows the locations of the planets, stars, moon, and sun in the sky from any location and for any date and time. It basically uses Kepler Laws to calculate the position of the stars and the planets. Only for the moon are more complex calculations employed. This means that the accuracy of a generated sky map is not perfect, however, it is still helpful for identifying an object in the night sky.

A few years ago, I ported this applet for Nokia's Series60 2nd Edition phones. Recently I decided to port the code to Windows Mobile. Although I already had the C++ code, I've decided to write the application using the .NET Compact Framework. I've used the version 2.0 of the framework and I've targeted the Smartphone platform. The application can run both in Windows Mobile 5 and Windows Mobile 6 devices.

On top of the existing functionality I have added some interesting features, specifically for the Windows Mobile port, that enhance user's experience:

  • Ability to add user-defined coordinates sets
  • Ability to read position and time from a GPS receiver
  • Set the backlight On and Off for night viewing

Of course there is also a list of missing features and todos that are presented at the end of the article.


To install the application simply extract the contacts of the zip file and copy them to a folder in your device.

User Guide

Although I believe it will be possible to run the application without reading any instructions, I list some common operations here.

Selecting your position: When you run the application for the first time, it will read the timezone information from the phone and pick the biggest city in your timezone. You can then select a new city by the Settings, Position menu item. Only the cities in your timezone will be listed. Alternatively you can fine tune your position using the panel.

Configuring time: By default the application paints a sky image that corresponds to the current time, as this is read from the phone. The image of the sky is updated every minute. If you want to construct an image for some time in the future or the past, uncheck the Autoupate box in the preferences dialog (select Settings, Preferences from the menu to display the dialog). Then use the panel to choose the time.

Timezone and daylight savings: By default the application reads this information from the phone. If you prefer to set it manually, uncheck the auto box in the Time Settings dialog. When the application deducts that the daylight savings are in effect (either from the phone or a manual setting), it will deduct one hour from the current time. This isn't 100% accurate, it is adequate for most circumstances.

Add a new position: When you fine tune your position, you may want to save it for future reference. You can do this by selecting Settings, Position from the menu and then selecting Add. You need to define the name, longitude, latitude and timezone for the new position.

Using a GPS receiver: The application reads GPS information from the GPS intermediate driver. Unfortunately, the GPS Control Panel that is needed may not be available in all smartphones. In this case you need to do some extra work. I refer you to some external links (Configuring Your Device to Use GPS MSDN article and Setting up GPS on Windows Mobile 5 blog entry) for information. To start using GPS data, select GPS from the menu. A box with the information read from the GPS receiver will be displayed. As soon as the GPS signal is adequate for extracting longitude, latitude and time, the box will disappear and the sky image for your current position will be presented. To stop using GPS, select GPS from the menu again. If the information read by GPS was valid, then the application will continue to use the same longitude and latitude. You then could go on creating a position with these values.

Backlight: The application will be mainly used at night and, contrary to usual conditions, the backlight may not be desirable. The reason is that after looking to a bright source, it is very difficult for someone to look at the night sky and locate stars and planetary objects. I therefore thought that giving the user the option to disable the backlight operation is a good idea. You can do this through the preferences dialog, by checking the "Backlight off" box. Please note that this is an experimental feature and it may not work in all phones. Also, the change will be applied even after the application is minimized, but it won't survive exiting the application or a soft reset.

Source Code

The application was developed in Visual Studio 2005 using the Windows Mobile 5.0 SDK. The GPS sample from the Windows Mobile 6.0 SDK was used.

I really can't say much about the PlanetFinder's engine, since I did the port without trying to fully understand the astronomic concepts underneath. I have verified however that the outcome of the Windows Mobile port matches the one of the original applet.

The user interface part is a standard Mobile Windows Form application. I've tried to use as many programming techniques as possible (persisting user's preferences in the registry, reading and writing positions to a file, switching to numeric input for latitude and longitude controls), in order to give a more professional tone to the application.


The backlight is controlled by invoking the DevicePowerNotify function. I've created a class with a single static method to enable/disable the backlight and the code is displayed below. After calling Backlight.Enable(false); the backlight will remain switched off, even if the user presses some keys. As I've said before, this code may not work in all phones. Windows Mobile mandates that the backlight driver is called "BKL1:", however the power states may be handled differently by various drivers or a driver may not fully support this operation.

public class Backlight
    static public void Enable(bool enable)
        if (enable)
            DevicePowerNotify("BKL1:", CEDevicePowerState.D0, 1);
            DevicePowerNotify("BKL1:", CEDevicePowerState.D4, 1);

    private enum CEDevicePowerState
        PwrDeviceUnspecified = -1,
        D0 = 0,
        D1 = 1,
        D2 = 2,
        D3 = 3,
        D4 = 4,
        PwrDeviceMaximum = 5

    [DllImport("coredll.dll", SetLastError = true)]
    extern private static IntPtr DevicePowerNotify(string pvDevice,
        CEDevicePowerState DeviceState, UInt32 StateFlags);

Comparison of the Symbian and Windows Mobile Ports

After completing the port both for Windows Mobile and Symbian Series60 devices, I would like to write some words comparing my experiences. From the application developer's point of view, Windows Mobile environment is much easier to work with. When working with the Series60 device, I have to struggle for things outside of the application's scope. I spent considerable time trying to create dialogs and controls, reading and writing to resource files and enabling on-device debugging. In the Windows Mobile platform I solved all these problems easily and I could focus on my application. That's why I was able to deliver a much richer port without spending more time. Of course now things have become easier for the Series60 platform, however, Visual Studio is still way better than Symbian tools. And I won't even dare compare C# with the idiomatic Symbian C++. One thing that got worse with Symbian, is the introduction of restricted APIs, forcing the developer to buy a certificate or go through an unreliable open-source signing process, if access to these APIs is required.

Below I've listed some possible enhancements to the application. I would never consider going on to implement them for Series60 devices — in fact I don't even maintain this port any more. I may, however, implement them for the Windows Mobile, when time permits it.


The application still lacks some useful features. The most important of them are listed here.

  • Localization. Currently neither the User Interface nor the PlanetFinder engine (name of the planets) are localized.
  • The PlanetFinder engine uses the 1/1/2000 as reference date for the calculations. The positions of the objects in this date are hardcoded and are used in the calculations of the future positions. Because only the Kepler laws are employed in these calculations, the longer away from this date you go, the biggest the inaccuracies will get. Therefore, it would be good to use a more recent reference date. Even better it would be to make the application load reference information from external files.
  • Add the names of the most bright stars and constellations. Identify them in the sky.
  • Zoom in functionality


  • 27/11/2008: Uploaded at the CodeProject
  • 17/12/2008: Modified exit code. Added logic to stop gps and animation when the application is minimized.


This article, along with any associated source code and files, is licensed under The GNU General Public License (GPLv3)


About the Author

Giannakakis Kostas
Software Developer (Senior) Self employed
Greece Greece
No Biography provided

You may also be interested in...


Comments and Discussions

-- There are no messages in this forum --
Permalink | Advertise | Privacy | Terms of Use | Mobile
Web03 | 2.8.180111.1 | Last Updated 17 Dec 2008
Article Copyright 2008 by Giannakakis Kostas
Everything else Copyright © CodeProject, 1999-2018
Layout: fixed | fluid