after I got a Nokia C6-01 (with update to Symbian Belle) now I tried to install GpsMid on it. Here I have some difficulties that seem to be compatibility issues. I didn't find the phone in either "devices running" or "devices not working". First the summary, below the a bit lengthy the "whole story".
A - GpsMid-Generic-full-0.7.7-map69.jad+jar (V0.7.7 MO.7.7 (2011-08-22)
- GpsMid gets stuck at second startup if you don't dismiss the splash screen forever at first startup
- Problems with external map: very long startup time.
- Problems with external map: not rendered correctly
- No compatibility check when importing older settings breaks application
- Saving config seems not to work - but does.
- Compass and CellID seem not to work
B - GpsMid-Generic-editing-0.7.71-map71.jar from Osm2GpsMid-latest.jar
- Doesn't run.
- After uninstall: reinstall fails
A - GpsMid-Generic-full-0.7.7-map69.jad+jar (V0.7.7 MO.7.7 (2011-08-22)
When I use the last (signed) release, I can install it and after that hit "run" and it runs. Forgot to hit "Don't show start screen next time", accepted license.
I change some settings, most of them I import from my previous installation on my previous phone
It shows only as a generic icon in the menu.
After I set a new map (zip) as source I have to restart. When I do so, I get the start screen and no way to interact. I have to end by hitting the red button. Don't know if this has to do with not switching off the splash screen. (Or didn't I wait long enough? See below.)
Uninstalled, new install.
This time I deactivate the start screen right from the beginning. I change a few settings by hand (among them I set automatic choice between gps and compass), don't set a new map source and quit.
Restart, ok, no splash screen. Error: Failed to open connection to a local helper daemon: java.IOException: Unable … POSIX error code: -61: Unable to open socket connection.
After dismissing this GpsMid works and I can display a small part of Berlin.
(I had that error before when I wanted to activate the compass on a phone that had none. Is there a problem with java accessing a compass on Belle? Anyway: when I set it back to movement, the error doesn't appear any more.
Same happens when I set CellID logging.
Maybe not a bug, just incompatible.)
A problem I have reported before and that might be solved in newer nightlies:
I am not able to set a folder for saving images. Whenever I navigate to a folder and select it, the menu disappears and I'm back in the main settings menu, not in the camera menu. When I reenter it, I can see there is no path entered.
Now I choose a map source as zip file (44MB) that I made with 0.7.65-map69 and that I used on my previous phone, a Nokia 5230. This time GpsMid hangs a while after restart and I believe I have to force quit again, but then it becomes responsive again and shows the map of my home town.
Buildings and landuse polygons are not rendered any more. (On the previous phone they did!)
Try to save my new configuration, I ge an error: Configuration could not be saved: null: java.lang.NullPointerException: null.
Strangely, when I enter the dialogue to import settings, I get two files displayed now: GpsMid-alt.cfg, which is the old file I renamed before my try to save a new one and GpsMid.cfg - so something has been saved. And loading it after a new install works, so the error message is false alarm.
B - GpsMid-Generic-editing-0.7.71-map71.jar from Osm2GpsMid-latest.jar
Installed additionally to the previous version. That stays and so I guess the new one resides in a new folder and doesn't try to share settings with the old one.
This is unsigned? At least there is no jad file.
When I start I get heaps of error messages that flicker so fast that I can't read them.
Among them is "Couldn't load base map data" and "Map format error nul" and "couldn't find /dict-0.dat" and some more. (All translated back to English)
I can only force quit by red button.
Uninstall. Reinstall fails with "Obligatory attribute "Midlet-Name" missing". Even after restart, it fails.
Short comment: The only tested / implemented compass support on Nokia Symbian is with the python helper script, which is why GpsMid tries to open a socket to the helper app. There's documentation on the helper app in the wiki.
Do you happen to know which way should be used for accessing the compass from j2me on Belle? I'm thinking of adding the JSR179 orientation class support which might be available on a phone I can use. If the same is used on Symbian Belle, that would make compass work on your device.
Oh and the same as for compass goes for cellid, see https://sourceforge.net/apps/mediawiki/gpsmid/index.php?title=OpenCellID#HowTo_enable_CellID_logging_and_positioning_on_S60 - but if you know of another way to access cellid info on Belle, perhaps it wouln't be too complicated to add support for that.
As for strange install problems and very slow zip access and a failed install making an app uninstallable - these I've seen earlier on Nokia Symbian phones, I'd say they're probably platform issues. You could try another 0.7.71 midlet, e.g. GpsMid-Generic-full-0.7.71-map71.jar and see if you can get that to work.
As for problems at startup - the unsigned nightly snapshots don't include the map, which is why you get error messages. GpsMid should get you to setup so you should be able to choose an external map, but might be there's still bugs with this. You could build the GpsMid bundle (with map) yourself on a computer with Osm2GpsMid, so you will have an internal map, that'll get you past the startup problems.
For camera directory setting - I can confirm there's a bug which I can repeat on the Nokia E72 (Symbian S60, I forget the more exact version). The bug is that the camera directory is not properly shown in camera settings screen (I go there from setup). I also go back to the main setup screen. However at least on the E72, GpsMid does correctly use the directory I set it to. (Tested with E:\ and E:\GpsMid, pictures taken with these settings were stored in the right directories).
Can't repeat the config export spurious error on Nokia E72 with GpsMid-Generic-editing-0.7.71-map71.
I fixed the bug with non-showing of camera save directory; the snapshot is rebuilding and should be updated in a few minutes.
Can't think of what could be a reason for non-showing of areas & buildings, perhaps a map compatibility code bug. Hmm, or maybe there's something else, I have a vague recollection I might have run into this also, maybe it's that drawing buildings is not on by default. Or possibly there is an issue with a corrupted config. Have you checked whether drawing buildings are areas is enabled in map settings?
I added code for JSR179 orientation class; it's in the current ngihtly. I don't have a device to test with right now, but maybe you can give it a try on the Belle device.
A couple of notes
- before the test, calibrate the compass by waving the phone in an 8-shape
- http://www.developer.nokia.com/Community/Wiki/How_to_implement_a_compass_in_Java_ME has info in the Orientation class
Thanks a lot for your immediate help!
Yes, the obvious solution worked: If midlet without map doesn't work, take one with map. I generated my usual midlet anew (that I usually produce as external map) and it worked.
And all issues I had with the release are gone with the nightly. Except the "Saving config seems not to work - but does" bug.
And the compass works now, too. Great! Though not as precise as in an other program I use on the phone, trackaway (www.trackaway.org/). It reacts slower and often/sometimes displays a value that is by an estimated 10-20° off. Looks strange to me, I thought just reading a value from the hardware should be the same for all programs.
Is it deliberate that the compass value is not displayed/applied while the gps doesn't have a fix?
Just did a trial concerning precision:
I am at my desk indoors, but I have a low quality gps fix. I hold my phone at a certain position and the compass reading is an estimated 25-30° off. Now I move the phone about 50 cm in one direction (keeping its orientation) and it displays nearly correctly - ~5° off.
Then I switch to trackaway and test the same two positions: equally precise in both positions.
Looks as if the programs used different compasses and one of them where influenced by magnetic fields around here (which certainly exist) and the other were not.
One more strange thing:
I wanted to replace the waypoints and track files in the rms folder by those I had backed up. But I can not find the midlet's install directory in e:\private nor anywhere else on the memory card. I checked when installing that I installed to e: and not c:. And x-plore, which can access c:, doesn't find it on c: either. The file I installed was called RM-0.7.71-map71.jar. Is it possible it was renamed while installing? Anyway the directory G:\Private\102033E6\MIDlets has only 10 subdirs in which I can identify the present *.jar files positively as other programms.
About digital compass: "Though not as precise as in an other program I use on the phone, trackaway (www.trackaway.org/). It reacts slower and often/sometimes displays a value that is by an estimated 10-20° off. Looks strange to me, I thought just reading a value from the hardware should be the same for all programs. Is it deliberate that the compass value is not displayed/applied while the gps doesn't have a fix?"
The magnetic North pole is at a different place than the geographic North pole, which is why a direct hardware compass reading generally is not correct and does not correspondent to movement compass (Around a week ago I listened to a guy at our kids' school who had taken a skiing trip to the (geographic) North pole in 2006; went from North America, and apparently there the difference is bigger than here in Northern Europe)
Some programs may employ a correction to the value - there are tables published which can be used to correct the reading to correspond to the geographic North pole. GpsMid currently doesn't have this correction, but could be someone someday adds that. But GpsMid does have a manual correction - if I remember correctly, single tap on the compass letter(s) and then +/- keys on touch display will change the correction. I think however that the correction is not saved however.
Another, more easily implemented compass correction (when compared to the table method) is to calibrate compass based on movement, when movement direction is valid. I've been thinking of adding this.
BTW I noticed the auto-switch between compass and movement doesn't really work, I'm working on a fix now.
"Is it deliberate that the compass value is not displayed/applied while the gps doesn't have a fix?"
Yes, but if you think there should be changes to this, these should be considered. Earlier when compass turning was enabled always, it felt too much moving to me (part of this is, it was enabled also when panning the map), and I decided to disable updates partly for this reason, but partly also for technical reasons when I changed the compass update to happen at the time of map drawing and then it was natural to tie it to GPS location. But if you have viewpoints on how things should be changed, please tell.
I think I found what's probably the cause for the spurious error message at export - GpsMid was getting the name of the file after closing the file, which apparently fails on your device but strangley enough apparently works on some others. I changed this, please tell if this fixes the issue; the change is in the current nightly.
Compass autoswitch (autoswitch between movement & compass) should now work too.
I added the option for compass auto-calibration by movement, though I haven't tested it live yet.
As for slowness - looks like the compass code can use some improvement. There are two polling loops which introduced unncessary delay. With, Android compass provider, callbacks should be used to pass info directly from Android to GpsMid, no need for polls. On JSR179 Orientation class - there's no callback, so some kind of polling is required. If we keep the current behaviour with compass direction being updated with GPS location, it'd probably be best to trigger a compass update from JSR179 location handling. If we want to update compass more frequently than we get locations and/or even when location is not available, polling is required I think, but limiting to just one poll loop should improve things.
I rewrote some of the compass code - now Android is handle by callback and now there's only one poll, so things should be better.
Unfortunately the Samsung Xcover 271 (B2710) which has a digital compass and which I though might support the Orientation class doesn't seem to support the Orientation class, so I don't have a device to test that method. Hopefully I didn't break anything with the changes, please report if I did.
"Then I switch to trackaway and test the same two positions: equally precise in both positions. Looks as if the programs used different compasses and one of them where influenced by magnetic fields around here (which certainly exist) and the other were not. "
Trackaway seems to be a Symbian (QT) app, it's possible the API is different, and might have some kind of quality info so Trackaway can avoid bad readings (just guessing, haven't looked at the source).
The J2ME API also has a possibility for the device to return a geographic reading (non-magnetic), currently GpsMid ignores the reading type.
Info on the J2ME interface: http://www.developer.nokia.com/document/Java_Developers_Library_v2/GUID-4AEC8DAF-DDCC-4A30-B820-23F2BA60EA52/javax/microedition/location/Orientation.html
There's a new compass option "Rapid rotate map" which seems to work quite well at least on the Nokia E72, will keep the map quite well aligned with compass direction. On the android with a bigger display it doesn't feel as responsive.
Currently it also rotates the display when panning the map, but it'd probably be better to switch rotation off when pannning. Would be good to have a compass needle though, and perhaps to align the panned map to compass direction when touching the needle.
Now I messed something up when installing to try, so I can't test yet. But a few other replies:
When to use compass
I think the compass should be used when gps signal seems erratic and using the compass avoids jitter. Or when there is no signal. Otherwise turning by gps signal always worked fine. Is that what "automatic" is supposed to do?
(Doesn't the compass need a lot of energy? Probably you don't switch it off between readings? So it's on all the time when you have the setting "on"?)
Magnetic north pole
The magnetic declination is between 1° and 2° here in my region, this can not be the cause. (Btw it is not as much related to the distance from the next pole: look at an isogonic chart, e.g. at http://en.wikipedia.org/wiki/Earth%27s_magnetic_field or http://www.ngdc.noaa.gov/geomag/WMM/data/wmm-D05.pdf)
What confused me a lot more than the difference between the two applications was the variation of the reading while moving the phone. Which it did in only one application.
Trackaway is qt, true.
Yes, that would be good. And the idea to use it as a gui element sounds good as well.
(Midlet runs again, but I have to do some more testing.)
Yes, currently automatic compass has pretty much the idea you describe. In addition however, though this is not practically implemented yet, I'm thinking that the reading could be used used for showing small "target needles" in the search results list to point to each result.
What I currently find troublesome with the compass is fluctuation, which causes frequent redraws of the map. I have "simplify map when needed" on (so the display won't lag behind even if there are a lot of map elements). This combined with compass fluctuation cause things like buildings not shown most of the time when compass is on. I'm thinking that some kind of an "inertia machine" kind of filter should be added so that compass wouldn't cause frequent small-turn redraws. A bit like there's a direction filter for GPS direction source, which ignores course directions which can be classified as erratic, and IIRC slows map rotation a bit sometimes.
If there wasn't that much fluctuating and if the compass readings were reliable (this seems to vary a lot from device to device), I might want to expand compass use - but currently due to the fluctuation the map tends to be too restless to my taste with compass rotation. Some kind of inertia-providing filter could help; it hopefully could stabilize and filter out small movements but would still allow for rapid turns when big movements happen. For things like compass needle or search result pointer needle the fluctuations probably wouldn't be a problem if the drawing machinery is made to redraw just the needles on compass events.
I have no idea about the power consumption of the compass, or when it consumes power (just when it is read or all the time when interface is activated). However when compass is switched to on or to automatic, compass readings are acquired four times a second on J2ME devices and whenever the OS sends them on Android.
On issue is that drawing the map overlay (destination mark, target line, gps position when panning the map) is out of phase with the map. This happens on GPS rotation mode as well, but becomes more evident when using digital compass. Not sure if or how to change this - not a big problem I think, but might be irritating to some people, so if someone has ideas on how to improve, they're welcome.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.