Hand held old gps units?

Some of the old handheld units need a little help getting started. One of my first consumer GPS units had a menu where you picked a city and state or gave it an approximate lat long to get it started.

When I got my used Garmin many years ago it was too far from the last position it had been used, and I had to tell it so in order for it to do the right search. Look in the menus for something like "New Location".

I would expect any cable that fits its USB port to work. Older units didn't have a USB port, but rather a serial port on a round 4-pin connector. Garmin has two computer programs to talk to the units: the old MapSource program works with the serial port, and the newer BaseCamp to talk with USB. Some units had two sets of memory and only one could be reached by each port.

I think it is ephemeris.

If a unit is receiving any satellites, shouldn't it get the current ephemeris in 20 or 30 minutes?

I did that, but I think it is dealing with a 1998 ephimerus.

Yes, once the unit locks onto at least one satellite it should get the full ephemeris in about 16 minutes or so. Most receivers have a program that puts them in a search mode after a certain amount of time powered up with nothing tracked; I would turn the thing on with fresh batteries and set it outside for a few hours. If it still works it will pick something up eventually, and once it does it should be working as good as new within a half hour or so.

One ephemeris,

Two or more ephemerides.

If you dig around on Garmin's site they have firmware updates for a lot of their units.

GPS rollover

Depending on how old the unit is and the last time it was turned on you may be dealing with the GPS Rollover issue. I forget the exact number, but when GPS hit the one-billionth second mark, GPS time rolled back to zero and many receivers had problems. I forget exactly when that was, but several years ago.

Just looked it up. It is a time period of 1024 weeks and it happened in 1999.

GPS rollover

The GPS week rollover is different from the billion-second problem. The latter only affected software (e.g. TGO) that didn't provide enough significant digits in the time variable to accommodate an elapsed time in excess of 1 billion seconds.

An example of the week rollover problem is the Topcon GP-DX1. I have 3 of them, and they all think it's 1994.

GPS rollover

That's right - there are 2 different issues. As you mention it I remember about the TGO issue. The other one I dealt with was for a GPS unit in my plane.

GPS rollover

I think my problem is one or the other of those. My GPS thought it was 1994 too, I set the correct date manually but it still wouldn't get a fix. The screen is not the best anyway, I should probably just toss it in the recyclers but you know how old surveyors tend to hang onto old equipment.

GPS rollover

For the 1999 rollover there were specific instructions for different models on how to over come the problem. Try Googling your model for instructions.

GPS rollover

> but you know how old surveyors tend to hang onto old equipment.

I probably know this better than most!

GPS rollover

After reading this thread, I went and dug out my old Magellan. Hadn't been powered on since 2008, and luckily stored without batteries. Fired it up, gave it a rough initialization, and within 30 minutes finally got a cold acquisition.

I assume it pulled the ephemeris.

Now what to do with it? 😀 the iPhone is so good! and the iPad has GPS, and the Mac doesn't even have a RS-232 to connect to the Magellan.

Oh well, such is the life of a gadget guy.

Does anyone know how/if one can import the .ssf files from previously processed files directly into TBC 2.81. I have a large inventory of baselines and from time to time, I would/could use the old fixed solution baselines on new work without re-observing if possible.

AND

I have experienced the "billion second" issue first hand. I am still running (10) old Trimble 4600LS receivers that work just fine, except their date stamps are screwed up. As the data produced by TBC 2.81 checks out quite well against ground ties, it is clear that the receivers and software is using the acquired ephemeris data. The problem seems to be logistical, with regard to being able to associate files and dates, etc.

AND

In GPSurvey (v2.35) it was possible to retrieve deleted files. There has to be a method to do the same by way of the DOS prompt to access these and other files.

AND lastly,

I am told that the 4600LS, 4700LS series has an on board "solder in" battery that keeps the memory alive. Anyone ever had one replaced, and does anyone know of experienced repair techs besides North Coast Geoquip that services these receivers?

61 and too old to invest in newer equipment for work in remote North Idaho unless I have to.

Cash

There has to be a manual method to reset the dates in the receivers affected by the rollover...

3rd post as required.

I was victimized by Trimble at the discontinuation of GPSurvey (v2.35) which I had used long after the entry of TGO. I went directly to TBC which is way more software than one needs to do simple GPS baseline processing and appears to be designed mostly for the real time dual-frequency user and topographical work. There are many useful options and after the posterior intercourse I experienced without proper foreplay (if you get my drift) I am reluctantly satisfied with the product, except it keeps advancing and I do not want to pay for an update every 3 to 6 months. The TBC seems to be a much more robust processor and once set up downloads are a snap, errors in HI entry and such are easily fixed without reloads and there are other frills that work well.

Having a large inventory of previously processed, high quality baselines, I am disappointed that I cannot directly import .ssf files produced by the old WAVE processor into TBC without first importing to TGO (do not have) and then to TBC. Who wants to re-process all those baselines.

In the old GPSurvey, the broadcast ephemeris files were accessible (delete, copy, etc.) on the receiver. TBC has no way to access these files. I was told by a Trimble rep that TBC was simply overwriting this file (and does not show it) and not to worry about it...or simply go and download the precise ephemeris???? OK. That is like walking around to block to get in your car parked in the front door. Whatever blondie. With the ephemeris question and the recent billion second rollover and the date stamping thing, I was afraid. I would be interested in any responses on the previous three posts if possible.

I still have an old TDC-1 data collector, perhaps the defaults on the receivers can be reset with that??????? Was told by a Geoline Rep who only sells equipment, "hell those receivers are obsolete". I doubt he ever cracked a section in mountain country with conventional methods???? They AIN'T up to date. They ARE still extremely effective on 1 man boundary work.

Who knew the big T would do this?????

Cash

I have a Garmin III Plus with extra external antenna and various cables and it will not power up.

The Etrex models start at $20 or less on Ebay.

For recon I have Garmin 60CSx and a DeLorme PN40 loaded with regional topo maps that get me relative close, just not the accuracy of the PM3s and without the ability to record and transfer vectors. They are great because they will fit in any pocket.

The best thing to get for a replacement is something like a PM3 that will load all kinds of background maps and record the data to get you 1meter standalone and within a foot with moble mapper post processing.

I don't use the PM3s often enough and it takes awhile to get three of them tuned in to start static sessions.

On my last outing a thunderstorm caused one to stop recording. Glad I use two on control points and one as a rover.

Glen D. Cash Sr., post: 392417, member: 12145 wrote: I have experienced the "billion second" issue first hand.

The billion second issue pertains to TGO, not to receivers. The GPS week variable is what's causing the receivers to report an incorrect date. As far as I know, there's no fix for it in the receiver, you have to fix it in the data file.