Jump to content

Garmin 3.70 Firmware Update for 60C/CS


GeoBobC

Recommended Posts

The next to last item in the upgrade is "Improved WAAS search and selection process to be smarter in its handling of multiple SBAS service providers, overlapping service volumes, and exceptional conditions."

 

I've noticed some very unusual behavior after upgrading. Has anyone else?

 

Prior to 3.70, my satellite page would always display WAAS satellite numbers 35 and 47, even if no signal was being received from them (they are the two WAAS satellites visible in the U.S.)

 

After upgrading to 3.70, I notice that sat 47 only stays on the satellite page for about 40 seconds if no signal is received from it. The 47 is then replaced by 33 and the unit subsequently cycles from the WAAS/SBAS satellite numbers in pairs: 35/36, 37/38, and so forth until it reaches 47: it then skips to 46/48.

 

It acts as if the firmware initially looks for satellite 47, and if it does not find it quickly it then ignores 47. I called Garmin and they said they if a signal from 47 was received while the unit was cycling through the 33-51 satellites, it would replace one of the other numbers on the satellite page. However, my unit does not work that way. I turned the unit on (not in view of satellite 47), waited for the 47 to be be replaced by 33 on the satellite page, and then placed the unit in clear view of satellite 47. No luck - it never acquired even after 10 minutes. However, if I turn the unit on in clear view of 47, it instantly acquires sat 47within 15 seconds.

Link to comment

I was driving home tonight about 5:15 CST in the light drizzle we're getting around here and noticed something strange. I was picking up 10 normal birds, 1 WAAS bird - #35 is the only one we can see from here, and the slot to the RIGHT of 35 was numbered. I took a harder look and saw a satellite 50 labelled. No signal, and the grayed out satellite icon was drawn on the horizon line (I didn't think to take note what azimuth) a few minutes later, 51 was in that slot, and 5-10 minutes later it was 43. Then slot 12 emptied out, another "normal" satellite came into view and pushed the waas bird into slot 12.

 

Does anyone know what I was seeing?

 

Garmin GPSMAP 60C v3.70 firmware

 

****

Hemlock merged the topics for me. I had originally posted this under a new thread and later found this topic.

****

Edited by DBleess
Link to comment

So the strange numbers I am seeing are the other augmentation birds' reserved slot numbers. As I sit and write this, I have the GPS on my desk and the remote antenna slapped in the window. It cannot see 35 and is merrily cycling through the other high numbers trying to find a WAAS satellite to chew on.

 

From the looks of the process, the high-number series search mirrors independently the search used when the GPS goes through a cold start sky search to reinitialize its position when the almanac gets dumped.

 

You would think WAAS position/skyview data from the almanac would be enough to know what to look for once a 3D nav solution is up and a search would be unnecessary and frivolous.

 

Am I wrong? Shouldn't the GPS know what satellites are above it and know what it will expect to find once it knows its position? Is there is some flexibility on the location of the WAAS birds and will they be repositioned eventually? (Maybe as more are added?)

Edited by DBleess
Link to comment

Upgraded to 3.7 a couple of days ago, and now I seem to be having some lock-ups requiring me to remove the battery to reset the unit. Never had anything like this happen with the prior version. Anyone experiencing this as well?

Edited by Svenster
Link to comment

It looks as if the GPS is now more intelligent when it comes to WAAS. If it can see 35, it uses it. If it can see 47, it uses it. If it can see both 35 and 47, it uses them both. If it can only see one WAAS bird (either 35 or 47), it then fills the empty WAAS slot with a non-WAAS bird but continues to periodically search for WAAS birds until it can see one, then it uses it again and dumps the non-WAAS bird. I haven't really studied this very extensively, but in my short observation after the firmware update, that's what it looks like it's doing. Anyone else have any thoughts on this?

Edited by SergZak
Link to comment

Ditto. Everything was hunky-dory for the first coupla' days after upgrading from the beta.

 

Then on day three, was doing cache maintenance and noticed it had dropped 35 and was using two slots to search through all the high numbers that aren't available around here.

 

Needless to say, since it wasn't trying to look for 35, it wasn't going to find it again!

 

So I had to leave the unit on and gave up getting another reading, returned to the car and drove away with it still on.

 

After many minutes and traffic lights later, it had finally cycled around to pick up 35 again and given up on the rest and was back to normal.

 

I suppose if 35 ever went out of service and other WAAS birds were available in the area I'd be very happy about this "intelligent" behaviour, but I do hope it doesn't decide to do this again at a time I would rather have straight-forward functionality.

 

The question I suppose, is what triggers that behaviour? Not picking up it's usual WAAS sat for a certain period of time?

 

Enjoy,

 

Randy

 

PS: Now that it's back to "normal", 11 channels are available for regular sats...

Link to comment

If you don't receive a signal from 35 or 47 within the first 45 seconds, the 3.70 firmware starts searching for other SBAS/WAAS signals (33-51) and appears to give up on 35 or 47. I turned on my unit and after 45 seconds the "47" was replaced by 33. I put the unit in plain view of 47 and it was a no-go, even after 10 minutes. With 3.61 it would keep 35 and 47 on the satellite page, and instantly reflect a signal.

 

I think Garmin messed up on this. It appears that they added it just before release since it was not on the 3.61 beta (check the release notes for 3.61 and it is not there, but it is for 3.70.) Tsk tsk, Garmin. That's what betas are for.

Link to comment
Upgraded to 3.7 a couple of days ago, and now I seem to be having some lock-ups requiring me to remove the battery to reset the unit. Never had anything like this happen with the prior version. Anyone experiencing this as well?

Yes it locked up on me as well. I had to remove battery to reset it. i thought Garmin fixed all this BS. :(

Link to comment

I have to say, v3.70 is the first firmware upgrade I've been satisfied with since v3.40. The versions in between had a bug that made it impossible for me to drive with guidance text turned on. Also, with v3.70, a side benefit has been that my 60cs seems to find the sats quicker and implement WAAS differentiation much sooner.

 

Overall, I must say I'm extremely pleased with v3.70. Sorry to hear it has caused you guys lockups, because believe me, I know how you feel. I suffered with the "locks up when approaching certain roads" bug for -- what has it been, 6 months or more since v3.40?

Link to comment

I can reproduce the lockup over and over. If anyone wants to try it heres how I did it .

 

1- select a wayoint and choose "goto" next choose "offroad" for routing method.

2- hit the menu button and choose "recalculate route" then select "follow road"

 

Locks up tighter than a drum:( every single time.

 

I am calling garmin to report the problem so hopefully they can fix it.

Link to comment
If you don't receive a signal from 35 or 47 within the first 45 seconds, the 3.70 firmware starts searching for other SBAS/WAAS signals (33-51) and appears to give up on 35 or 47.  I turned on my unit and after 45 seconds the "47" was replaced by 33.  I put the unit in plain view of 47 and it was a no-go, even after 10 minutes.  With 3.61 it would keep 35 and 47 on the satellite page, and instantly reflect a signal.

 

I think Garmin messed up on this.  It appears that they added it just before release since it was not on the 3.61 beta (check the release notes for 3.61 and it is not there, but it is for 3.70.)  Tsk tsk, Garmin.  That's what betas are for.

 

I suspect the same. Once the GPS has a 2d or better navigation solution, it should have a point to derive almanac data to know exactly what satellites are in view. After that, the GPS should only be searching for satellites it *knows* are overhead in order to speed aquisition of the highest accuracy position, and recover accuracy quickly after passing places of sky obscuration. (Heavy cover, bridges, structure, etc.)

 

This is how the previous firmware loads seemed to work. They knew where the local WAAS bird(s) was (were) and only bothered to look for and reacquire it (them).

 

I'm beginning to wonder if the almanac data for the WAAS birds is getting corrupted somehow and if that is the cause of the weird behavior.

 

I'd bet the change is undocumented because it is a "break" and not a "fix" that got by their testers. Hopefully someone from Garmin is monitoring the boards and sending out word to their engineers to work an immediate repair.

 

Expect a quick 3.71

Link to comment
I can reproduce the lockup over and over. If anyone wants to try it heres how I did it .

 

1- select a wayoint and choose "goto" next choose "offroad" for routing method.

2- hit the menu button and choose "recalculate route" then select "follow road"

 

Locks up tighter than a drum:( every single time. 

 

I am calling garmin to report the problem so hopefully they can fix it.

Yep, that is exactly what I am now experiencing as well using the procedure you have outlined. Hope Garmin fixes this soon. Until then, I'm going back to the prior version as this is real anoying when I'm doing mutiple caches and want to autoroute between them. At least I know I'm not the only affected 60cs user.

Link to comment

First, on the original topic, my quick solution to the ridiculous WAAS wild goose chase--turn the unit off/on. It comes back to find #35 instead of wasting time looking for non-existent birds.

 

I ran the beta and it didn't behave this way.

 

Secondly, my unit locked up per the described method too. (CitySelect)

 

I can't pull the batteries as I type so...

 

Enjoy,

 

Randy

Link to comment

I just got on to read the latest posts from this weekend -- I ALSO experienced the lockup problem. My post on another forum reads as follows:

 

Out geo-marathoning this past weekend. 60CS -- new set of batteries -- 3.7 software installed. It locked up on me 3 times during the day!! In all cases the circumstances were the same -- I was on a Follow Road with the Map Page showing. As we approached the cache, clicked on Menu -> Recalculate and was presented with the Follow Road or Off Road choices. At this point, everything locked. Could NOT even turn off the power. Had to open the case, remove the batteries, and start up again. Didn't have this problem with 3.5 or 3.6...

Link to comment

I received a reply from Garmin Engineering today regarding the original topic here it is:

 

This is in fact the expected behavior of the search process. First, the

satellites with almanac are looked for. If they are not found, a scan is

started for all other possible WAAS satellites (33 - 51). This search will

not include the satellites with almanac that were already looked for. Only

after this scan is complete will the satellites with almanac (47, 35) be

looked for again.

 

The reasoning behind this is best illustrated by a potential situation that

could happen in Europe with the EGNOS system which contains 4 satellites.

Say a user had almanac for two EGNOS satellites (33 and 37), however these

satellites were for some reason unhealthy or had stopped transmitting

altogether. It is not desirable to continuously look for these satellites

when there could possibly be others out there with a usable signal (44 or

39). This is the reason for the scan when the satellites with known almanac

are not found.

 

If the user misses 47 and 35 on the first try the scan will start so the

order of the search I would expect to see is:

47,35,33,34,36,37,38,39,40,41,42,43,44,45,46,48,49,50,51, and then back to

47 and 35 again. A user will need to wait a little longer for the scan to

complete before 47 is tried again. To avoid the scan, waiting until you

have a clear view of the sky to turn the unit on is beneficial. This will

help with GPS acquisition time as well as WAAS acquisition time.

 

Let me know if you have any further questions on this.

Link to comment
I received a reply from Garmin Engineering today regarding the original topic here it is:

 

This is in fact the expected behavior of the search process.  First, the

satellites with almanac are looked for.  If they are not found, a scan is

started for all other possible WAAS satellites (33 - 51).  This search will

not include the satellites with almanac that were already looked for.  Only

after this scan is complete will the satellites with almanac (47, 35) be

looked for again.

 

The reasoning behind this is best illustrated by a potential situation that

could happen in Europe with the EGNOS system which contains 4 satellites.

Say a user had almanac for two EGNOS satellites (33 and 37), however these

satellites were for some reason unhealthy or had stopped transmitting

altogether.  It is not desirable to continuously look for these satellites

when there could possibly be others out there with a usable signal (44 or

39).  This is the reason for the scan when the satellites with known almanac

are not found.

 

If the user misses 47 and 35 on the first try the scan will start so the

order of the search I would expect to see is:

47,35,33,34,36,37,38,39,40,41,42,43,44,45,46,48,49,50,51, and then back to

47 and 35 again.  A user will need to wait a little longer for the scan to

complete before 47 is tried again.  To avoid the scan, waiting until you

have a clear view of the sky to turn the unit on is beneficial.  This will

help with GPS acquisition time as well as WAAS acquisition time.

 

Let me know if you have any further questions on this.

The more I ponder that explanation, the more I think it doesn't make any sense at all.

 

Satellites don't just appear out of nowhere. It takes time to move them to cover losses and outages, and almanac data can be updated as fast as they are moved.

 

Once you have both an updated almanac, and a 2d or better fix, you have an absolute sense of what is in the sky above you.

 

The almanac is constantly getting updates, and for all intents and purposes has to be considered always to be correct once it has a current load. (at the very least for the USAF birds)

 

If EGNOS birds aren't in the almanac, then

 

a. they need to be added somehow or

b. the software has to be written to use the 2d position fix to discount the need to go hunting for them under the almanac-covered area of the USAF birds flying over North America.

 

In the western hemisphere, if the almanac is loaded, listed as current, and you still manage a 3-d fix that doesn't agree and says your almanac is wrong; say it says that you shouldn't see the satellites it does see above you, then the system is FUBARed anyhow, isn't it?

 

Look at the position side of the constellation. If I'm driving along with a 3d fix and can only see 6 of 10 "normal" satellites, the system isn't going to start hunting for different birds with the no-signal slots.

 

Why?

 

Because someone in the GPS system design process said something like this: "We have an almanac, we know they are there, we will simply patiently wait for the signal to become "audible" to the receiver and not go frolicking about looking for birds we already know we cannot see"

 

Get my point?

 

There's two different logics now being applied between the position birds and the augmentation birds. You shouldn't go hunting for something that the almanac says either doesn't exist or is over the horizon and out of sight.

 

I'm already seeing operationally that the new augmentation logic is flawed and actually can HURT performance rather than enhance it. You delay higher accuracy signal by wandering off looking for something the almanac should already be telling you isn't there.

 

On the ground in a cluttered world, it is easy to lose signal on a satellite. So when the GPSr stops looking for a bird simply because it loses signal lock, you're only going to make a bad problem worse if you go looking for something that isn't there in favor of something that alamanc knows is there.

 

Logic should follow that it is just a temporary obstruction-caused loss of signal. Once that signal is audible again, if you are "on the wrong channel" and not even listening for it, you miss the opportunity to quickly reaquire it.

 

Doesn't that seem incredibly stupid to anyone else?

 

The system logic needs to be set back to the "patiently wait" concept that was abandoned for flawed reasons. If there really is a reason to go looking for these other satellites, it shouldn't be made to override the need to "keep looking for what you KNOW" first.

 

Add a logic routine to determine where in the world you are that blocks looking for augmentation birds that aren't there in favor of using the almanac to search for what should be there instead.

 

How complicated can that be? It has to be easier than it was to add the code that "broke" the system in the first place.

Edited by DBleess
Link to comment

i'm getting the lockup bug as well when changing from an offroad routing to follow road but not in the reverse... don't s'pose anyone has ver 3.6 or 3.61 sitting around they could email me?

 

EDIT: gonna answer my own question here, hopefully it will help others...

 

http://www.tramsoft.ch/gps/garmin_gpsmap60...pgrades_en.html

 

has previous versions of firmware for several models...

Edited by rokclimber
Link to comment
I am in total agreement.  To suboptimize accuracy for the vast majority (I would guess 99% of more) of the Garmin customers who do not use EGNOS sats seems backwards to me as well.  Please tell Garmin.  They've heard it from me.

Took the advice and emailed support, I'm getting the "deer in the headlights" response. This rep doesn't seem to know what I'm talking about. I left them my work number in the response tonight.

 

Since I work for a Garmin Avionics distributor (and I told him), they might actually take me seriously and call me and gather some information.

 

We shall see.

Link to comment
If EGNOS birds aren't in the almanac, then

 

Engnos and Waas satellites do not move on the sky like GPS satellite, they are geostationary (at a fixed position all time). (Like TV satellite, you don have to follow them with your parabolic antenna)

 

As long as you got 2d fix, the GPS the know were to look for satellites 33 +

 

http://www.esa.int/export/esaNA/GGGQI950NDC_index_0.html

Edited by jotne
Link to comment

Got a response from Garmin today about the lock up here is what they have to say

 

Thank you for contacting Garmin Product Support,

 

You are correct, that this is a known issue with the update. Our engineers are aware of it and as soon as they make some other changes, they will release a new update that will have this corrected. I do appreciate your information and I have passed it long so that they are aware of more customers dealing with the situation.

 

Best Regards,

 

Kyle Candy

Product Support Specialist

Garmin International

1200 East 151st St.

Olathe KS 66062

1-800-800-1020

www.garmin.com

 

I hope they fix this soon, other than the lock up I still love my 60cs.

Link to comment

Finally, after a week and a half of being sent e-mails and informed of a lockup problem, Garmin accepts and acknowledges it -- I don't think this has ever happened before -- not quite like this. They denied anything was wrong for days. Not like them...

Edited by stantastic
Link to comment
If EGNOS birds aren't in the almanac, then

 

Engnos and Waas satellites do not move on the sky like GPS satellite, they are geostationary (at a fixed position all time). (Like TV satellite, you don have to follow them with your parabolic antenna)

 

As long as you got 2d fix, the GPS the know were to look for satellites 33 +

 

http://www.esa.int/export/esaNA/GGGQI950NDC_index_0.html

Exactly, which is why it is strange that anyone would even bother to program in an aqusition search that is active AFTER a 2d-3d position is computed. Which is what we are (were) seeing.

 

The Garmin rep I was talking to couldn't reproduce the error on three different units so I did a hard reset* of my unit and have been putting it through the paces ever since and haven't been able to reproduce the problem.

 

*hold ENTER and PAGE while powering up. You will LOSE all your user settings so record them first and save time to sit down and reset them back to what you want.

 

http://www.gpsinformation.org/dale/secret.htm

 

I never saw the route lockups and hangs, but this solution seems to have solved my WAAS satellite problems.

Edited by DBleess
Link to comment
I never saw the route lockups and hangs, but this solution seems to have solved my WAAS satellite problems.

Went caching last weekend, happened to set my GPS next to a tree while I logged and traded, and 5 minutes later when I picked it up, it had abandoned 35 and was hunting for non-local WAAS satellites again. I ended up powering off and back on the unit to get 35 back quicker so I could take my WAAS reading on the cache.

 

So, my hard reset didn't fix it, and my "tests" must have been flawed.

 

Just loaded 3.80 and I'll try to get a laptop interfaced to get screen captures of what I am seeing. Since there is no mention of it having been addressed in the update, I would guess the problem is still there.

Link to comment

Yep, I can confirm the bug fix as well -- went out the weekend after 3.8 was posted and ran a good test -- switched back and forth between Off Road and Follow Road in both directions and everything seemed to hold together. Don't know if any other "feature" was introduced in 3.8, but haven't come across any.

 

As an added note (which I don't think was ever mentioned) -- in 3.7 during a Follow Road, the "highlighted" route on the map sometimes actually MISSED the road I was on -- by a good amount!! I was toodling down a main highway and the computed route was overlayed on the map BETWEEN the road I was on and the next street over. But this too seems to have gone away with 3.8.

Link to comment

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...
×
×
  • Create New...