John E Cache

Lately, I am leaning towards a different take. A two axis sensor gives two voltages. To get a magnetic field, you convert the volts by making two field strength vectors and adding the two right angle vectors. There are two problems. Converting from hall effect volts to field strength is not linear. A curve needs to be generated by calibration. Second, the curve changes over time as sensor ages. I think saying calibrate with battery change has to do with time, not voltage. Much like changing smoke detector batteries at DST change has nothing to do with the sun's orbit.

Can't you just mark the first point and then walk away from the point so the bearing (+180 or -180) and distance to the point match the plot? If so, mark and repeat.

Been there done that. A long time ago I had a nearby cache I could not find because tree cover caused the GPS to jump around. I upgraded to a 60csx and thought maybe I could find it. No dice. The 60csx had an antenna input so I bought an antenna. Nada. This is when I gave up on finding the perfect accurate GPS. I wonder how many people have multiple GPSs looking for an accurate one.

To get the coordinates from that app, do menu->share->e-mail. I don't see why these coordinates would be any less accurate than a standalone GPS. If someone wants to say his GPS is more accurate, you have to consider that maybe he wants to justify spending a lot of money for his GPS. Errors come from atmospheric conditions and obstructions, common to both GPS and phone.

I was working in Tokyo three times before GPSs. Streets without names was challenging. The maps were puzzles. Could one of you tell me why the maps never had North at the top. Also, I remember large maps with enlarged insets that were aligned in all different directions. My method when lost was to walk until I found a subway station and then look at my subway map. Luckily all of the subway signs had English added for the Tokyo Olympics. English kind of worked. I remembered asking a Japanese co-worker to write "Tokyo Motor Show" in Japanese for the taxi driver. I handed it to the hotel doorman and he says to cab driver, "Tokyo Motor Show". I may have to go back with my GPS some time to figure out where I was. Have fun. I'm jealous.

The constant reference to "live maps" is starting to get on my nerves. Every caching app has "live maps", including TOU compliant ones like geobeagle. "Live radar" is cute because the waypoints look like blips on a radar, but there is a provider app called "radar" that is used by apps like geobeagle and c:geo to point to a destination coordinate. I have read a few Android tutorials and books so I can write a non-geocaching app idea I have. Virtually every tutorial has a section titled "Adding maps to your app". Because Google does Android and Maps and because Android platforms have GPSs it takes only a few lines of code to add "live maps" to an app. Getting the coordinates and details for geocaches needs to be done in a TOU compliant manner for cache lists or cache details(not just for map landmarks).

He used the past tense "was" for c:geo. Where is the grief counselor? Someone needs to talk people off the ledge.

I'd love to give c:geo some wriggle room, but the way I understand scraping and the TOU there isn't any. In any case, doesn't matter what we think, it's what Groundspeak thinks. Seems that Jeremy has pretty unequivocally said it is against the TOU. And now we're back to my actual point, which is: If you know it is against the ToU (and now, having read this thread, you do), why wait for Groundspeak to wrest the app from your hands? Don't cling to dishonesty - be honorable, have integrity, if you care about this site and the activity it supports, don't use an app that breaks the rules. Uninstall it of your own volition and don't look back. On this we agree totally. I don' t cache much anymore so it is easy for me not to use it. I just fire it up every time I get a market update to see what new feature has been added. I also checked the download count until it maxed out at >250,000 downloads. The TOU is kind of like putting a "don't steal this car" bumper sticker on your car.

Shame on me? "Scraping" is the common term for parsing data off a document. It is not "just some derogatory word GS invented", absolutely not. FWIW, I'm a programmer, and fancy semantics aside, I call that scraping too. I provided the Wikipedia link many posts ago, but apparently the person who claims to know what web scraping is did not bother to read. My comment was poking someone who inflated himself a little. Just a little fun and no malice intended Sorry 'bout that. Everybody and his brother seems to be a programmer. I read your link. Apparently scraping has several meanings, but you know exactly what the TOU means. The TOU is too broad for me.

Please explain how this application gets its data to operate in real time without violating that section of the TOS. c:geo is a scrapper, pure and simple, and therefore violates the TOS. There is no other way for live map to function. Of course it is not the author that has the problem, you the user do. Once the API is released I almost bet that if c:geo is fixed in it's present form there will be some really unhappy folks. The problem is far more than icons. I don't think you mean c:geo scraps the data. :-) I don't know exactly how c:geo works, but I know a little about client/server operation. The gc.com is a server that serves data to a client. The client can be a browser, which parses the data and converts the data to display data. The browser get a small html file with lots of links to images and text. The browser then GETs the image data and displays everything. Most of the work is off loaded to the client. c;geo is a client gets the html and parses it, too. Scraping is just a derogatory term GS uses for parsing(the person who claims to be programmer and calls it scraping, shame on you). c:geo doesn't need the images so it uses less bandwidth than the browser. Android is based on client/servers internally. The server is called a provider. c:geo asks for a provider to display waypoints on a map and the Google map provider displays them. The "live map" as you call it is off loaded to Google Maps. Google Maps calls the location provider which calls the GPS or phone to get the current location and the map moves. The waypoints are redisplayed from the list c:geo provided. No new search of gc.com is needed. I have no idea how c:geo determines if the location has moved outside the current list area. All I know is that if c:geo does multiple searches every time it moves, gc.com would detect this and give the error that you are a computer and not human.

People that write free software for fun quite often quit after awhile. They get bored and it is no longer fun or they get a job. It happens all the time. They usually release the source and move on. I still am a premium member even though I got bored with the hunt. I like keeping up with the technology. I am amazed at some of the fun things the c:geo designer did with Android API/SDK. I particularly like how all of the individual arrows on the the cache list page rotate when you rotate the phone. The icons with my background showing through is very nice, too, in my opinion. The back and forth with GS was entertaining. GS got in some good shots. I like the detecting of multiple searches in a short time. c:geo is a programming work of art to a geek like me and calling him just a 1-off programmer is true, but kind of insulting. I hope he finds his new job fun and rewarding.

Start with geobeagle.which has lots of info on how to build your own apk file.

Darned near, but you've got the basic understanding. On the C:GEO side: Without using the API, C:GEO would necessarily have to use scraping for ALL of the data it needs, not just the extras. It would be his only interface. Sounds as though perhaps he was offered access - I wasn't there - but declined for the time being. Perhaps it wasn't complete enough to allow him to do as much as he'd already done with his application, and he really didn't want to step backwards? Who knows? On the CG application side: The question is whether 1) GC's application had good enough access to data via their own earlier version of the unpublished API, but was just a lesser application, or 2) whether even it didn't have enough access to the needed data to produce all of the features due to a somewhat "thin" API. I doubt any of us will ever know which was the case. Just curious, you keep using the term "screen scraping" and I have no clue what you mean. Could you use more modern terms, please. I last used screen scraping 30+ years ago when the screen memory contained ASCII data.. What screen are you referring to? Are you saying there is character recognition of the screen pixels to get data?

And that is exactly what Bryan said in his post on the feedback site, the API will be a premium member benefit. I fully expect the update tomorrow to break c:geo in grand and glorious manners. And if not the one tomorrow, the one where the API is released will definitely break c:geo. So unless someone picks up the source and forks it and takes on the maintenance the app is probably dead. As a side note, if someone does pickup the support, they better be outside the United States. Unfortunately it probably will also break greasemonkey scripts. I don't see how a new API by itself would break c:geo when c:geo isn't using an API. Please explain.

The farewell post from the c:geo author brings up an interesting point that I had not considered. He said that GS was is trying to make c:geo only usable by premium members. In other words, c:geo made it possible for users to get all the benefits of PQs without actual using PQs and paying for a premium membership. Now that I think about it, the gathering of data through the web interface and causing a load maybe never was the issue. The premium membership issue can easily be solved with an API that does authentication. The API could theoretically authenticate that a user is a premium member.

Video Just hope you enter the right coordinates and don't send it to Timbuktu.

The Wouxon comes setup to transmit on two bands, right? How about receive? Do you only receive just the two bands? For instance, if I want to use a satellite repeater where you transmit on 2M and listen on 70CM, do I need the 70CM band? I'm asking because my old HF rig could receive all bands, but only transmit on ham bands.

Incorrect. The mag sensor tells the GPS how the GPS aligns with the local magnetic field. That field may or may not align with "the Earth." The GPS knows how the GPS is aligned with the earth because the GPS knows the magnetic declination. Incorrect, again. It knows the declination, so in the absence of any local deviations in the magnetic field, it knows approximately the alignment with the Earth. But in practice, local magnetic fields from high-iron rocks, metal, etc. make use of the magnetic compass quite unreliable, especially in urban areas. I guess I don't see your point. Or are you going to nitpick everything I say? Would you say Galileo's conclusion was wrong when he dropped two things off of the Tower of Pisa because he didn't consider air or even terminal velocity. Some statements are simplifications. That doesn't mean the idea behind the statements are wrong, in my opinion. BTW you forgot magnetic fields from motors and radio antennas.

OK, I will try again. If you lay a straw across the face of the GPS so it covers the N and S on the compass rose, one end of the straw points S and one end points N to incredible accuracy when compared to guessing what the GPS thinks your direction of travel is(the GPS uses inaccurate positions to guess your direction) and pointing the top of the screen that way. The S on the rose points S unconditionally. For this reason, I do not setup the GPS to turn of the sensor when moving, but that's just me. If you lay the straw on the bearing pointer and look through the straw, you can see the cache.

Incorrect. The mag sensor tells the GPS how the GPS aligns with the local magnetic field. That field may or may not align with "the Earth." The GPS knows how the GPS is aligned with the earth because the GPS knows the magnetic declination. I have been posting about the "compass" a lot and mainly the posts are aimed at very smart people because smart people tend to know so much they tend to over complicate things. I made a very simple statement that can be dissected in a complicated way. The mag sensor simplifies things if you don't over think it, in my opinion..

The mag sensor tells the GPS how the GPS aligns with the earth unconditionally. Anyone who thinks about "direction of travel" or "top of screen points here" or "speed of travel" is very old school because none of those phrases apply when the sensor is on. The compass rose aligns with the earth, the map aligns with the earth and the bearing pointer points at the destination no matter which way you travel or point the GPS. Try walking and turning the GPS any direction and everything will swing around to align with the earth.

I use Bluetooth GPS Provider Barcode

I agree. Whenever someone would get a new 60CSx my advice was always the same: "First thing to change is the settings so your compass turns off at walking speed. Having the compass on when walking will just screw you up." If given the choice now I wouldn't spend the money on a compass, which is funny because when I upgraded from my original eTrex Legend one of my "must haves" was a compass. Now it's one of the last things I worry about. Just curious. Did the video I posted change your mind? When you walking with the sensor on and the GPS at your side and then you bring up the up the GPS to see the screen the bearing arrow swings to point exactly a the cache. Don't say WTF why is this arrow swinging around. I remember wondering the same thing at first. Go with the flow and wait. To prove the arrow is pointing at the cache try an experiment. With a known destination in the distance bring the GPS up to eye level so you can use the "gun sight". The sight is formed by the arrow on the top of the multi-switch and the white arrow on the bezel on the top of the screen. Rotate your body until the bearing arrow swings and points to the bezel arrow. The sight now points to the destination within a degree or so. With the sensor off the the software make two assumptions: first the SW uses the last two positions to form a straight line that you are traveling on. Second the SW assumes you are pointing the GPS along that line. The problem is that the positions can vary several feet and the calculated line is very inaccurate. With sensor on and the SW approximation turned off the GPS only needs one point. If the destination is a long way away the 30 foot error in your position is minimized. End of sermon.

Try playing with text encoding.Safari 1.1: Selecting a Text Encoding

First the word "compass" is confusing. A real compass tells you which way magnetic north is. The electronic "compass" on the 62csx is two hall effect magnetic field strength sensors that tell the GPS software which way the GPS is pointed. The sensors are not linear and the curve needs to be plotted to calibrate the sensors. I don't think the battery voltage affects the curve, but could be wrong. In any case, periodic calibration is needed because the sensors age and vary with temp. If the software has no sensor it expects you to walk in a straight line with the GPS pointed along the line(pointing is easy in a car and on the trail it is annoying). This is an old thread and I see someone asked me to explain something and I didn't because I got tired of trying to explain the "compass" without physically showing how the "compass" works. After my post Google did a video. This video explains everything. When the person touches the upper right corner, he is turning on the "compass". The map moves just like the map and bearing pointer on the 60csx. I have a feeling some people think walking in a straight line is a feature built into all GPS hardware when in fact it is simply a software trick needed when there is no sensor.