Jump to content
Sign in to follow this  
Followers 1
Amberel

Latest version still locks up all my PDAs

Recommended Posts

A tried Wherigo a couple of weeks ago and it totally locked up my PDA, requiring a reset to recover. While browsing this evening I noticed that a cartridge has been released for an area only a few miles from me, so I thought I would give it another try. I downloaded all the latest software as of 26th Jan 2008 and installed the player on my XDA Orbit running WM6.

 

The first problem was that it installed on the device instead of the storage card, against my instructions. Never seen a program do that before, so in case I had made a mistake I uninstalled and did it again. Same thing. So I decided to carry on with it like that, and copied some cartridges over.

 

When I ran the player there was an immediate improvement over last time, in that it actually showed the welcome screen, with a message saying "Device Detection in Progress". There was a rotating wait cursor and the orange light indicating my internal GPS port was open started to flash. After a minute the backlight went off. The wait cursor became intermittent, slowing down and sometimes stopping. After 5 minutes the unit turned itself off, as it is supposed to do if there is no input and the program has forgotten to tell it not to. I switched it on again, but it was locked up solid. Poke the stylus in the reset and start again.

 

Second time I tapped the screen every 30 seconds to keep it alive. All this did was prolong the agony. After 10 minutes the thing had completely ground to a halt again. The cursor was not rotating and all controls were completely unresponsive. Poke the stylus in the reset and start again.

 

Next time I thought I would make sure I had a valid GPS signal before I started. I fired up OziExplorer and found I had an excellent signal with 9 satellites. So I closed down everything and started Wherigo again. No difference, it locked up just the same.

 

So I tried again. This time I tried using a bluetooth GPS, which I fired up before starting Wherigo and verified good satellite reception. No difference, in fact it seemed to be trying the internal GPS just the same as before.

 

So I changed tack. I also have an XDA Stellar. I tend not to use it for GPS stuff because the receiver is less sensitive than the Orbit, but it has more memory and a faster processor. Same installation bug as the Orbit, but I was used to that now.

 

Started it up, and WOW, it found the internal GPS immediately. But it couldn't find my cartridges and I realised I had put them in the wrong place, so I closed down Wherigo and moved them. When I started Wherigo again, guess what. It locked up :P Actually, this time it didn't totally lock up, but it may just as well have done. It failed to find the GPS. After 10 minutes I had enough and closed it down using the O2 task manager. But even with Wherigo shut down the machine ran at about 1/1000th of normal speed until after the ritual poking of the stylus into the reset button.

 

I'm a programmer. It's my job. I find it very sad indeed when programs are allowed to behave like this :P

 

Rgds, Andy

Share this post


Link to post

The incomapibility between Wherigo and XDA units isn't down to the Wherigo software as such; but it's the GPS library that Wherigo uses which is causing the problems.

 

I believe (and I apoligise if this is wrong) Groundspeak (or someone they've hired to do the project), is using Geoframeworks as the underlaying GPS handler, instead of writing their own NMEA routines from scratch. Browsing the Geoframeworks forum shows there is a known incompatibility.

 

The device detection routine probes all open ports (in order) on the device until a valid NMEA data stream is found - and I reckon it is the mobile phone part of the XDA devices which is causing this routine to fail.

 

I've also read in their forum that there is a way of ignoring certain ports, or forcing the routine to use a specific port - so fingers crossed the developers of Wherigo will eventually allow the users to specify the port, opening up the application to XDA units.

 

Hope this helps.

Share this post


Link to post

I believe (and I apoligise if this is wrong) Groundspeak (or someone they've hired to do the project), is using Geoframeworks as the underlaying GPS handler, instead of writing their own NMEA routines from scratch. Browsing the Geoframeworks forum shows there is a known incompatibility.

 

The device detection routine probes all open ports (in order) on the device until a valid NMEA data stream is found - and I reckon it is the mobile phone part of the XDA devices which is causing this routine to fail.

 

I've also read in their forum that there is a way of ignoring certain ports, or forcing the routine to use a specific port - so fingers crossed the developers of Wherigo will eventually allow the users to specify the port, opening up the application to XDA units.

 

Hope this helps.

Thanks, useful background. Specifying the port ought to be the default in the first place :smile:

 

GeoFrameworks is a lot more than just NMEA decoding (which by itself is a complete doddle to do), but it's a shame they felt they had to use an external library. Whenever you use an external library you lose a bit more control over your app, and by the sound of it this rather neatly illustrates the point.

 

Rgds, Andy

Share this post


Link to post

Yes, Amberel, I definitely agree with you there. You do lose a bit more control over your application if you use a library developed by another company. As a programmer myself, I can stand behind that. Yes, it does seem favorable to write the code yourself. I have done so a few times, too. The level of control is marvelous as is the ability to fix all the defects yourself.

 

However, I would like to disagree respectfully with you on a point. Companies in the business of creating and selling library code are vastly more experienced in that particular topic--the leaders are usually experts in that field. They developed the code, made a lot of the mistakes I would have encountered, and have already incorporated that learning into their product. It would take me months or more to come up with something that would even come close to matching their code--especially when it comes to robustness and exception handling.

 

With that said, in my opinion, the Wherigo player application would be of less quality had Groundspeak developed the GPSr connectivity code in-house. It would connect to less devices and be far less stable. Unfortunately, I see you are experiencing one of those stability problems right now. Quite frankly, I'd lose some respect for Groundspeak if they decided to do everything in-house. Anyone in the field will say that's just not smart developing.

 

I do hope your problem is resolved quickly. I want to see this catch on and watch how cartridge development changes over time. It's like the introduction of geocaching all over again, except I'm there to participate. For that, we definitely do need the player in working order to handle a broad range of devices, just as we needed accurate, dependable GPS receivers for geocaching.

 

---------------------------------------------------------------------------------------------------------------------

---------------------------------------------------------------------------------------------------------------------

 

Specifying the port ought to be the default in the first place :(

 

Now, taking your suggestion and running with it, let's see what we can do. Perhaps in the interim (e.g. while we're waiting on a fix from GeoFrameworks), Groundspeak could put the GPSr detection on a different thread and set a timeout timer. If the timer expires and a GPSr is still not detected, terminate the thread (before it does what it has done to your Orbit) and either go without the connection altogether or display a configuration screen, supposing the GeoFrameworks library will support such configuration method calls.

 

That does sound appealing, actually. At the very least, it'll be safer to run on your Orbit.

Share this post


Link to post

... in my opinion, the Wherigo player application would be of less quality had Groundspeak developed the GPSr connectivity code in-house. It would connect to less devices and be far less stable.

I fear we will have to agree to disagree on this one. Reliably reading NMEA input from a serial port on all NMEA compatible receivers, assuming the port is specifed rather than auto-detected, is trivially easy. It's less than half a day's work for a programmer of average competence. A bit more if you add satellite status. A day at the most. And to save them the effort they are welcome to have my source code if they want it.

 

I think the benefit of the library is not the NMEA code but the much more complex mapping stuff it subsequently does with the data. It's much harder to argue against that, and once you have that, you're probably stuck with the NMEA code they provide, bugs and all. The galling part is that almost certainly the basic NMEA code is absolutely fine, the problem is just the auto-detect part where they are trying to be too clever.

 

Rgds, Andy

Share this post


Link to post

Hmm. I see your point. So the port scanning is easy enough, but it's everything else from there on out, the mapping, that is the library's appeal. Thank you for pointing that out.

 

So I guess the threaded example I posted wouldn't work as neatly as that. Too bad. Well, you run across a lot of that while creating applications, too.

 

For instance, when I was trying to add animated gifs to my Statbar Modifier, I ran into something odd. I could deconstruct the gif frame by frame and create the animated statbar. That was fine. However, the moment I tried programmically resizing a frame's image, the code failed for some inexplicable reason no matter what I tried. I couldn't even resize it by creating a new image object and drawing the frame's image there, then resizing that. Some times, it's just odd the things you run into while programming that should work, but don't.

 

Finding a workaround or fix for things that should work is a pain.

Share this post


Link to post

Finding a workaround or fix for things that should work is a pain.

 

Isn't it just :laughing:

 

Rgds, Andy

Share this post


Link to post

The greatest joke about this version of the Wherigo player is, even the Mitac Mio168 locks up, thats the PDA shown on the link "Download the free Wherigo Player for PocketPC ". :D Lets wait for a working version.

Edited by Wally69

Share this post


Link to post

...even the Mitac Mio168 locks up...

 

Working fine on My Mio168. Is yours an original 168 or a 168RS?

 

I'm fortunate in that my 168 is used solely for Wherigo and I was therefore able to do a hard reset before installing the new version.

Share this post


Link to post

 

Working fine on My Mio168. Is yours an original 168 or a 168RS?

 

I'm fortunate in that my 168 is used solely for Wherigo and I was therefore able to do a hard reset before installing the new version.

 

Hi, i hadn't installed any other version but i made a hard reset just some days ago. It must be the old 168, here in germany sold by a discounter as Medion md95000, aka yakumo delta 300 gps. And i use mine for a lot of other stuff, cachewolf, tomtom. Therefore it can be a softwareproblem to. I would try the older version, but Groundspeak only provides, as far as i know, only one, the current, version. Cheers

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  
Followers 1

×
×
  • Create New...