This is stricly for GPSr lugging geocaching fanatics, of which there are a few on this BBS.

I recently upgraded my ancient Sony first-generation CDMA/AMPS telephone to a slightly newer AudioVox-8300, which has WAP capability (for "surfing the wireless web"). So.. first thing I've done, is code a CGI script on my webserver to allow me to do cache page lookups from the field.

You see, when I travel, I usually load my GPSr with waypoints for most caches in the area I plan to visit (I have another script to do that for me), but I don't always have the cache descriptions with me. Many caches which are marked as "traditiional" (simple walk ins) are actually more complex than that, and may be difficult or impossible to visit without the detailed cache instructions..

So now, in theory, I can lookup such cache pages using just my mobile telephone. And so can you!

http://rtr.ca/GCxxxx -- just replace the GCxxxx part with the geocaching.com waypoint label for the cache in question -- upper/lowercase don't matter.

Let me know if it crashes your phone, or otherwise does something weird. One thing I know about, is that it reformats the cache page (text only, btw.) to fit within a single "page" (or "deck") sent to your phone in one burst. To do this, it first tries to find out how large of a buffer your phone reports to it. It does NOT currently implement paging to break up a very large page into multiple smaller ones of acceptable size. I may add that in the future.

And now, someone will point out at least two other sites that already have this, right?

Cheers

WHOA. That is awesome. You've just made this so much more convenient. The page loaded quicly on my phone and all the info was there -- very nice.

So, no matter how long the page is on the actual geocaching website, it still displays as one long screen on the phone?

So, no matter how long the page is on the actual geocaching website, it still displays as one long screen on the phone?

Yes, for now. Except that some of the the long description may get chopped off (replaced with ... if the page is too big for your phone. The web script tries to keep the uncompiled WML (webpage) within the max size reported by your phone.

But I notice in the logs that it did not correctly figure out the size allowed by your SprintPCS Samsung phone, so it likely defaulted to 1397 bytes max. Since your phone reports 64KB max, I'll fix that today.

Cheers (and thanks for trying it out!)

Mark, very nice job!!! It seems that you have it set to download everything up to the hint(already decoded) and to stop there. Very nice work. My phone (Sony-Ericsson T616) seems to handle it well and it loads quickly.

I'll test it on Saturday. Meatballman, his wife, and I are going to hit a few caches in a park that he and I visited last weekend. We didn't get to all of them (there are 11 in one park I believe) so we are heading over that way this weekend.

I probably won't need it much this weekend b/c I already have all the waypoints entered and the pages printed but this will come in very handy down the road.

Thanks again!!

Sweeeet!!! Now i can just dump the waypoints to the GPS and not have to print out 10 pages when we want to go caching! Thanks Mark. Really cool.

Good! I am gradually building up a small database of telephone types every time a new one connects, and the script is evolving to match as needed.

There is also now a TravelBug lookup by tag number. Again, upper/lower case don't matter on the URL.

http://rtr.ca/TAGnnnnnn

That's a feature I have needed for some time now, useful when finding a bug unexpectedly in a cache, and wondering whether to take it or not. Knowing the bug's goals/destination comes in handy in such situations.

Meanwhile, I have emailed the geocaching.com site gods to seek permission to make this functionality available to others (anyone other than me). I don't know whether they'll say yes or no, so keep it in the family for now, please!

Cheers

Didn't work when I tried it from my Ericsson T39m. It said there was something wrong with the page, which I think sometimes mean it found HTML when it was expecting WML.

Hi Andy.. try again once more please --> I've set it up to log everything so I can see what might be wrong.

Thanks!

Just tried again.

Thanks. Your phone is requesting "compiled" WML rather than the original "source" text.. My scripts don't support that (yet). But I've just hacked them to return the WML source regardless.. Try it one more time and let me know what happens now.

Thanks!

Mark...I hate to encourage feature creep, but how bout a way to send a lat/long ie...

rtr.ca/latN3422930longW08004760

and have it return nearby waypoints like:

GCH2A3
GCB436
GCB7D0

This would enable one to go caching at a moments notice. One could query the nearby caches and then query each individual waypoint to get the info.

Hi,

I plan to perhaps add some scripting capability to run on the handset to allow convenient entry of coords from the field. But later..

Cheers

Okay, I fixed it.

The webserver now compiles the WML into WMLC form before returning it, if the phone supports it of course (like yours does).

Cheers

I plan to perhaps add some scripting capability to run on the handset to allow convenient entry of coords from the field. But later..

Sounds good to me.

/me walks away thankful for what IS available.

That is effin' sweet. I can't use it - I only have a Palm and my GPS unit, but if I ever get something that supports that technology, I can see myself loading in benchmarks (does it work for benchmarks, too? -- I got for the 'harder' caches around the coutry. Muhaha.) and going off in search for a few.

Me.

I am now getting the message:

"Your request for a service could not be fulfilled. Please try again or contact your operator if the problem persists."

Not sure whether that is being generated by your site, or Orange's WAP gateway or somewhere else.

Seemed to work for me though I only got a description of the cache and no coordinates.

> I only got a description of the cache and no coordinates.

Yup, that's the idea for now. I usually have all the waypoints for an area pre-loaded on my GPS unit, and just need access to the descriptions when actually hunting -- so that's what I've implemented first. More is planned..

And I just got this reply from geocaching.com on the subject:

Hi Mark

Thanks for your email. We are currently working on a WAP section on the
site to replace the one we had a couple of months ago at
http://www.geocaching.com/wap . Good luck in your further education
programming pages for your cellphone.

Please let me know if you have any further questions or concerns.

Happy Geocaching!

Nate

Cheers

I am now getting the message:

"Your request for a service could not be fulfilled. Please try again or contact your operator if the problem persists."

Not sure whether that is being generated by your site, or Orange's WAP gateway or somewhere else.

Mmm.. my logs show that a compiled wmlc file was passed back to your gateway. But I have since found a bug in the code that causes a miscalculation of max bytecount. Shouldn't have mattered much in this case, but..

???? any difference now?

Thanks

Before heading off to eat Kenmore's dust in the Gatineau today,
I did manage to add a front page menu to the wireless web geocaching
site that I am working up. Now one can "bookmark it" on the phone
to avoid having to renter the address each time.

The new front-end is here: http://rtr.ca/geo

Currently, the menu prompts for either a Cache number
or a Travel Bug tag number for lookups.

More features coming soon.. feel free to suggest improvements.

Cheers!

OOoopppsss.. drat. I just discovered it has been broken for the past 4-5 hours. Fixed now, but it works only on phones that accept non-compiled .wml (nearly all WAP phones except Andy's).

Cheers

My phone definitely accepts non-compiled WML, as I have a simple WML page that I host on my server to use as a home page on my phone. My WML is complete dumb, it doesn't try to work out what the phone is, just sends it:

<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1.xml">

<wml>
<card id="normancx" title="norman.cx">
<p>
<a href="http://orange.multimedia/" title="orange">Orange home</a>
<a href="http://mobile.msn.com/" title="google">MSN</a>
<a href="http://wap.google.com/" title="google">Google</a>
<a href="http://wap.maporama.com/" title="maporama">maporama</a>
<a href="http://rail.kizoom.co.uk/" title="kizoom">kizoom</a>
<br/>
08/11/2003 09:34:20
</p>
</card>
</wml>

Which is probably against all the WML specs, but I only spent a couple of hours getting it working and it works on the Nokia and Ericsson phones I own.

Your WAP gateway is sending my server this line:

HTTP_ACCEPT=text/x-vcard, application/vnd.wap.wmlscriptc, text/x-vcalendar, */*,

 application/vnd.wap.wbxml, application/vnd.wap.wmlc, text/x-vmel

Also, your phone itself reports this:

                                

<prf:BrowserName>Ericsson</prf:BrowserName>

<prf:CcppAccept>

    <rdf:Bag>

        <rdf:li>application/vnd.wap.wmlc</rdf:li>

        <rdf:li>application/vnd.wap.wbxml</rdf:li>

        <rdf:li>application/vnd.wap.wmlscriptc</rdf:li>

        <rdf:li>application/vnd.wap.multipart.mixed</rdf:li>

        <rdf:li>text/x-vCard</rdf:li>

        <rdf:li>text/x-vCalendar</rdf:li>

        <rdf:li>text/x-vMel</rdf:li>

        <rdf:li>text/x-eMelody</rdf:li>

        <rdf:li>image/vnd.wap.wbmp</rdf:li>

        <rdf:li>image/gif</rdf:li>

        <rdf:li>application/vnd.wap.wtls-ca-certificate</rdf:li>

        <rdf:li>application/vnd.wap.sic</rdf:li>

        <rdf:li>application/vnd.wap.slc</rdf:li>

        <rdf:li>application/vnd.wap.coc</rdf:li>

        <rdf:li>application/vnd.wap.sia</rdf:li>

    </rdf:Bag>

</prf:CcppAccept>

No mention of text/vnd.wap.wml compatibility there. Buggy gateway, I suppose, or perhaps the gateway automatically compiles WML on your handset's behalf. Or maybe your phone doesn't like the compiler I'm using If you can flush your browser's cache (on the handset) and try one more time to verify now, I'd appreciate it (I have made some changes). If it still doesn't work, I'll hack the site to always return WML to your type of phone.
Also, the top menu should now be working for you http://rtr.ca/geo since that is entirely wml regardless of who requests it.

Cheers

Hi all,

I spent much of the weekend doing "paperless" cache hunting,
using my cell phone to do lookups instead.

Worked great!

I went 10/10 for the weekend, including some virtuals and a D5 cache.
And I think this may even be cheaper (for me, at 2-cents/cache) than printing them out!

New on the menu now is a "Find Caches.." entry, which allows lookup
of caches either near a known GCXXXX waypoint, or by direct entry of
Lat/Lon coordinates.

Planned features:
1. access to cache log entries.
2. (maybe) the ability to log a "find" from the field.

If you have a modern cellphone with "wireless web" capability,
then you can use it to access Cache/Bug pages at: http://rtr.ca/geo

Cheers

Today I completed some updates to the WAP GeoCaching Portal to make it viewable/usable on Nokia handsets. I hadn't realized before just how ugly the "browser" is on those, so the site now presents itself differently to make it usable on handsets which lack the OpenWave browser (used by almost everyone except Nokia).

     http://rtr.ca/geo

Feedback (for any handset type) would be appreciated.

Cheers

Mark, I tried the geo link with my Motorola T70 and I get a:

1019: compile error

Let me know if you need any other info.

Thanks,
rjf&

Does it work better now? (you may need to flush the cache on your phone first).

I just fixed a problem whereby it was sending too large of a page for the top menu to some phones.

Cheers

I've also added several new features over the past couple of days, including multi-page responses, most recent log entries, lookups by ownerid, zip-code, and postal-code, etc.

All of this seems to have spurred the geocaching.com gods into implementing their own version at last, but it's clumsier on my phone (they're doing one size fits all, rather than customizing the pages for the type of browser).

Cheers

After resetting the memory via the OpenWave advanced menu and trying again, I still get the 1019: compile error

rjf&

Thanks.

Fixed (for real) this time!

Cheers