Showing posts with label gps. Show all posts
Showing posts with label gps. Show all posts

August 2, 2009

tidbits

S40 Nokias do weird things when you put a StringItem on a form, give it a label but no text. It will prevent users from scrolling that form.
S60 Nokias do some weird stuff too, but only sometimes. Best not to do this.

SonyEricssons, on the other hand, retain image size on ImageItem when you setImage(null). You have to set a dummy 1x1 image first (or instead).

And last but not least, with certain bluetooth devices (GPSr's, in this case), Nokia phone would perform a bluetooth service search, but return error instead of the service.
When you're searching for a serial port service (UUID 0x1101) and get an error instead, just take "btspp://" + RemoteDevice.getBluetoothAddress() + ":1" as a connection url and you have a solid chance of connecting successfully.
(That means BT address + channel 1. On single-purpose devices, you'll most likely find the only service on channel 1. Makes sense, eh?)

December 5, 2008

internal affairs filed under JSR179

OpenWIG 0.3.07 is out and it supports JSR-179 style "Location Providers" a.k.a. internal GPS.

Getting that to work was no picnic, though.

Here's a basic overview of how it's supposed to work:
  1. choose a list of things you want from your GPS device and set it all up in a Criteria object
  2. instantiate a LocationProvider by calling LocationProvider.getInstance(myCriteriaObject);
  3. periodically ask for a new location by calling provider.getLocation(timeout)
  4. or implement a LocationListener interface, and register that with the provider. You can then specify some refresh intervals and timeouts and whatnot. Fortunately, you can also leave it on default values.
Sounds rather easy, no?
Well, yes, but with a caveat: there's no listProviders or equivalent method. If the phone has more than one provider, it can return pretty much anything it wants.
And it turns out that e.g. Nokia N95 has more than one provider, and one of them is very dumb and coincidentally that's the one that is selected when you specify "empty" criteria (the default Criteria instance means basically "anything will do")

It seems to work when you say that you want to get speed, course, altitude and you allow it to cost money:
Criteria c = new Criteria();
c.setAltitudeRequired(true);
c.setSpeedAndCourseRequired(true);
c.setCostAllowed(true);
provider = LocationProvider.getInstance(c);
Oh and then there's the fun with invalid locations that can either have isValid flag set to false or be null. But that is easy to get right. Finding out that a phone is giving you a bad provider is the real pain.

May 22, 2008

openWIG status report

Version 0.2.99 was released sometime this night, as opposed to what I wrote last week.
It has pretty navigation and crude but functional reading from filesystem. Everything important is on the project page, follow the link on your right.
...oh, and did I mention that we can now decode the GWC format? Well, we can. Feel free to load your memory card with cartridges and head outside.

May 14, 2008

Dilution of Precision

a.k.a. DOP, a.k.a. PDOP, HDOP and VDOP. And, in some very special cases, TDOP, but i haven't seen that one and have no idea what's it good for.
What they are and how to make heads (but not tails) of them.

In today's GPS applications, you will see those values under "precision". Plus, if you happen to be writing a GPS application, you will see them in NMEA messages. When people compare their GPS receivers, they compare precision by DOP (at least I and my friend did).
But unless the application is pretty clever, it won't tell you the actual position error, only the DOP values. And, unless you as a programer are pretty clever, you can't read the actual position error from the GPS receiver! Which is slightly worse.

So. As some of you probably already noticed, DOP stands for Dilution of Precision. HDOP is Horizontal DOP (that is latitude and longitude), VDOP is Vertical (altitude). PDOP is Positional, which is an overall measure containing both horizontal and vertical, and TDOP is Time DOP, which doesn't seem to be good for anything useful.
In various sources you can find that DOP values are dimensionless and they express "geometric strength" of satellite configuration. And that lower is better.
Which is all nice, but doesn't tell you anything about what the hell those numbers mean.

So here goes: DOP values are coefficients. That is the most important thing to know about them. To obtain the position error range in some meaningful units, e.g. metres, you multiply the GPS receiver's precision by the DOP value.

That's all there is to it. Just take a DOP, multiply it by a known value, and there you go, now you have a meaningful number. Piece of cake, really. Why couldn't they tell you earlier, right?

Alright, i confess, that's not all. This is where the real fun begins.

For one, there seems to be no way of determining your GPS unit's precision. It certainly won't tell you through NMEA. So you can either read the full-of-propaganda manual, or take an educated guess.
My educated guess, based on GPS system properties and quality of today's receivers, is that average precision is 5 metres. In fact, my favourite GPS app, TrekBuddy, shows HDOP x 5 m as an error range. And for openWIG I'm going to do the same.

And for two, while some receivers (such as my NaviLock BT-451 with uBlox Antaris4 chip) exclude signal strength from DOP (that is technically correct approach, since DOP is geometric strength), others apparently count it in (technically wrong, but way more useful).
Either that, or SiRF starIII chip's geometric capabilities are way below Antaris's. What's a poor guy like me to think, eh?

Anyway, now you know what a DOP is. Have fun dealing with it, I certainly will.

April 7, 2008

OpenWIG: GPS support ready, gwc format possible

Version 0.2.0 of OpenWIG has crude support for Bluetooth GPS modules. Plus a Play Anywhere mode, so you can play the included Zooventure Level Two regardless of where you live.

In other news: misch of geocaching.cz said that the gwc format doesn't look at all difficult to him. And that he would probably be able to decode it.
That means that OpenWIG will probably have support for original Wherigo Player cartridges, and that means that you will be able to play full-featured Wherigo on your mobile phone!
Isn't that just wonderful?

April 5, 2008

Wherigo midlet ... or is it?

Once upon a time, there was Wherigo. It was closed-source, closed-format, and worked only on PocketPCs (and some kind of obscure navigation device). It did not work on cellphones and the developers apparently weren't interested in making it work.

Turns out, however, that the Wherigo Builder produces plain Lua source files. It can't be too hard to make that work on a mobile phone, now can it?

Well, let's hope not. Enter matejcik, who just recently bought a bluetooth GPS module to use with his phone. And whose idea of fun is, among other things, staying up late (or early, you might say) coding weird stuff.

Working name of the project is OpenWIG. As of now, it can run nearly all of Zooventure Level Two from the tutorial.
No GPS connectivity yet, but you can input coordinates by hand. I might keep this feature, as it would enable folks without GPS-enabled mobiles to play. Then again, I might not - you know how things go, cheaters are everywhere and this would only make it easier for them.

You can't load your own cartridges yet, and you will probably never be able to load gwc files, as the format is closed and I have no experience in reverse engineering. But once the loading functionality is there, I will probably set up a web service that would take your sources and compile them to OpenWIG-friendly format.

Heart of the midlet is called Kahlua and it is a Lua virtual machine for J2ME. It eats Lua 5.1 bytecode compiled files and works pretty damn well, considering its size. It is also fast enough on all phones I tested.
(Then again, it's not like the Lua scripts in the cartridges do a whole lot of work. Setting variables, conditional branch here and there, that's about it.)
And as an added value, the guy who wrote it was very helpful and the (two) bugs I reported were fixed immediately.

No download link today, but you can find some testing versions in this thread (in Czech).

Update: check out OpenWIG's Google Code page.