The error does not occur on the GPS's display. In other words, your
position and course will be correct on the GPS but what it will not do
is transmit this information out of the NMEA port. The only sure way
to see if your 276C unit is affected is to log the NMEA output to a
computer and then examine the log file.

I will do this test asap

No, the other way round, so it could be easily occur on other models.



"Pascal" wrote in message ups.com...
I Chuck

I understand that you are saying that the problem is with the
"application software" and not with the firmware of the gps engine" ?
In this case, the problem could be restricted to the 172C and not
spread to others models using the same "legacy engine"?

Thanks

Pascal





On 15 fev, 17:57, "Chuck Tribolet" wrote:
Sounds to me like the problem is in the "back end" of the software, and
would be independent of the "front end" (ie, which receiver).

BINGO .....

Yesterday I have made a test with my GpsMap 276C in my boat, using my
laptop and Hyperterminal. My Map 276C was taking 12 satellites and
running normal until I have made the test, and I have get exactly the
same results you have with your 172C. My position here (Salvador-
Bahia-Brazil) is S 12 48 W038 27 and thus GMT – 3.

The test showed:
a)The 276C was sending NMEA messages normally until 08:59 LCL (23:59
GMT) after that, it begin to send invalid NMEA messages like you
said, and little time after, stopped sending anything, see below a
small sample:

$GPRMC,235959,A,1248.705,S,03827.579,W,0.0,192.2,1 80207,23.0,W,A*3A
$GPRMB,A,0.04,L,AIC,BA01,1248.413,S,03827.698,W,0. 315,338.3,,V,A*3B
$GPGGA,235959,1248.705,S,03827.579,W,1,12,0.8,4.2, M,-10.5,M,,*60
$GPGLL,1248.705,S,03827.579,W,235959,A,A*41
$GPBOD,345.6,T,8.6,M,BA01,AIC*04
$GPBWC,235959,1248.413,S,03827.698,W,338.3,T,1.4,M ,0.315,N,BA01,A*6B
$GPVTG,192.2,T,215.2,M,0.0,N,0.0,K,A*2F
$GPXTE,A,A,0.04,L,N,A*07
$GPAPB,A,A,0.04,L,N,V,V,8.6,M,BA01,1.4,M,1.4,M,A*5 E
==================== = 23:59 GMT
$GPRMC,000002,V,,,,,,,,,,N*51
$GPRMB,V,,,,,,,,,,,,,N*52
$GPRMC,000006,V,,,,,,,,,,N*55
$GPRMB,V,,,,,,,,,,,,,N*52
$GPRMC,000010,V,,,,,,,,,,N*52
$GPRMB,V,,,,,,,,,,,,,N*52
$GPRMC,000014,V,,,,,,,,,,N*56
$GPRMB,V,,,,,,,,,,,,,N*52
$GPRMC,000018,V,,,,,,,,,,N*5A
$GPRMB,V,,,,,,,,,,,,,N*52

b)Around 09:08 LCL (00:08 GMT) the 276C started to send NMEA messages
normally, see the sample below.

$GPRMC,000134,V,,,,,,,,,,N*55
$GPRMB,V,,,,,,,,,,,,,N*52
$GPRMC,000138,V,,,,,,,,,,N*59
$GPRMB,V,,,,,,,,,,,,,N*52
$GPRMC,000142,V,,,,,,,,,,N*54
$GPRMB,V,,,,,,,,,,,,,N*52
$GPRMC,000146,V,,,,,,,,,,N*50
$GPRMB,V,,,,,,,,,,,,,N*52
$GPRMC,000150,V,,,,,,,,,,N*57
$GPRMB,V,,,,,,,,,,,,,N*52
$GPRMC,000154,V,,,,,,,,,,N*53
$GPRMB,V,,,,,,,,,,,,,N*52
$GPRMC,000158,V,,,,,,,,,,N*5F
$GPRMB,V,,,,,,,,,,,,,N*52
============== 00:08 GMT
$GPRMC,000833,A,1248.705,S,03827.579,W,0.0,192.2,1 90207,23.0,W,A*32
$GPRMB,A,0.04,L,AIC,BA01,1248.413,S,03827.698,W,0. 315,338.3,,V,A*3B
$GPGGA,000833,1248.705,S,03827.579,W,1,12,0.8,4.8, M,-10.5,M,,*63
$GPGLL,1248.705,S,03827.579,W,000833,A,A*48
$GPBOD,345.6,T,8.6,M,BA01,AIC*04
$GPBWC,000833,1248.413,S,03827.698,W,338.3,T,1.4,M ,0.315,N,BA01,A*62
$GPVTG,192.2,T,215.2,M,0.0,N,0.0,K,A*2F
$GPXTE,A,A,0.04,L,N,A*07
$GPAPB,A,A,0.04,L,N,V,V,8.6,M,BA01,1.4,M,1.4,M,A*5 E



Conclusions:

1)The problem is widespread like you and I have suspected, and
comproved in garmins 172C and 276C. What other models have this
problem?
2)As the 172C last update was in May/2006 and the last update
(software version 4.8) of 276C was much more recent in Jan/2007, the
suspicion of a widespread problem is very probable.
3)The time of day of the problem 23:59-00:08 is documented; could be
that there is another times when the error appears?
4)I will send warning messages by e-mail to all people I know that
sail using gps and autopilot.
5)I will open a new problem report with Garmin, regarding my 276C


I suggest that other people using these Garmin gps models and other
models too, do the test and open problem with garmin, since I repute
this problem a very high risk issue. Here in Bahia, almost all sailors
have Garmin Gps units interfaced with Raymarine Autopilots and we uses
extensively this interface, about 95% of time, specially when sailing
tricky routes, in narrow channels in bad weather or at night.

Congratulations John, thanks for your advise and best regards

Pascal Goncalves

S 13 00 W 038 27
Salvador – Bahia - Brazil

Pascal,

Thank you for your effort in doing this testing and the comprehensive
post with the results. It does indeed look as if this problem is
widespread throughout the Garmin product line.

I agree with your conclusions and think that your course of action is
good and correct. The more reports that Garmin receives regarding
this problem, the more likely it is that they will escalate its
significance. I just hope that Garmin is not the kind of company that
will wait until a loss of a vessel or life occurs with a resulting
impact on their sales before they take action.

I develop software professionally and would not be surprised if this
problem affects most of their line in view of what the results are
from your test of the 276C unit. When software routines have been
developed, they are often cut and pasted from one program to
another... the developers do not rewrite all of the code from the
beginning if certain routines are adaptable to the current project.

My boat is in Half Moon Bay in Northern California. The harbour
approach is treacherous with shoals, breaking waves and rocks next to
the channel. As it is Northern California, thick fog is often present
and the entrance is a small gap in a rock seawall that surrounds the
harbor. Radar and accurate navigation are essential.

I'll keep this thread informed when I hear from the Coast Guard re
what they plan to do.

Regards,
John Purins

Hi John,

In my experience with Garmin, they probabilly will fix the problem
within 3 months. I had many problems with several Garmin Gps
(GpsMap130, Map76 and Map276C) regarding the NMEA interface with my
autopilot AH/ST4000, and after reporting the problems Garmin had fixed
it within 3 months. The fix consisted of including the BWC message and
implementing the Advanced NMEA Setup (Wpt Numbers x Names). Off
course, there are another's problems that they do not recognize and
have not fixed, like the problem with the promotion of the last go-to
within a route even after a power-off/power-on, which I think is wrong
and others revendications, like the support for AIS receiver etc.

Best Regards

Pascal

I don't know enough about this to help anyone, but I found it fascinating.
Nice job guys.
I would appreciate your explaing something you said, John

"During normal operation, NMEA transmissions occur every 2 seconds.
For those who are familiar with software programming, the interesting
thing is that the error begins at 23:59:59 GMT and normal
transmissions resume at 00:08:34. The time interval of 8 minutes and
32 seconds just happens to be 512 seconds"

I know little about programming but understand that the number 512 is a
significant binary # and may be involved in some chance programming snafu.
However, I don't see how you got an elapsed time from 23:59:59 to 00:08:34
of 8 min and 32 seconds, i.e. 512 seconds. I get 1 sec elapsed until
00:00:00 then 8 min 34 secs for a total of 8 minutes and 35 seconds which
totals 480 plus 35 or 515 seconds, not 512.

Did one of us count wrong?

Thanks.
Chet

Chet,

I think my post is not clear enough as to what the 512 seconds refers
to and I did not include enough of my log file to show this.

The following sequence occurred on 2006.11.23 and in this particular
case, the GPS completely stopped transmitting NMEA sentences during
the 'error period'. The last valid transmission before the error was
at 235958 and normal transmissions resumed at 000834.

$GPRMC,235956,A,3730.121,N,12228.827,W,0.0,199.6,2 31106,15.0,E,D
$GPRMB,A,,,,,,,,,,,,A,D
$GPGGA,235956,3730.121,N,12228.827,W,2,11,0.9,-7.2,M,-28.5,M,,
$GPGLL,3730.121,N,12228.827,W,235956,A,D
$GPBOD,,T,,M,,
$GPBWC,235956,,,,,,T,,M,,N,,D
$GPVTG,199.6,T,184.6,M,0.0,N,0.0,K,D
$GPXTE,A,A,,,N,D
$GPRMC,235958,A,3730.121,N,12228.827,W,0.0,199.6,2 31106,15.0,E,D
$GPRMB,A,,,,,,,,,,,,A,D
$GPGGA,235958,3730.121,N,12228.827,W,2,11,0.9,-7.3,M,-28.5,M,,
$GPGLL,3730.121,N,12228.827,W,235958,A,D
$GPBOD,,T,,M,,
$GPBWC,235958,,,,,,T,,M,,N,,D
$GPVTG,199.6,T,184.6,M,0.0,N,0.0,K,D
$GPXTE,A,A,,,N,D
$GPRMC,235959,V,,,,,,,,,,N
$GPRMB,V,,,,,,,,,,,,,N
$GPRMC,000834,A,3730.121,N,12228.827,W,0.0,199.6,2 41106,15.0,E,D
$GPRMB,A,,,,,,,,,,,,A,D
$GPGGA,000834,3730.121,N,12228.827,W,2,10,0.9,-5.8,M,-28.5,M,,
$GPGLL,3730.121,N,12228.827,W,000834,A,D
$GPBOD,,T,,M,,
$GPBWC,000834,,,,,,T,,M,,N,,D
$GPVTG,199.6,T,184.6,M,0.0,N,0.0,K,D
$GPXTE,A,A,,,N,D
$GPRMC,000836,A,3730.121,N,12228.827,W,0.0,199.6,2 41106,15.0,E,D
$GPRMB,A,,,,,,,,,,,,A,D
$GPGGA,000836,3730.121,N,12228.827,W,2,10,0.9,-5.7,M,-28.5,M,,
$GPGLL,3730.121,N,12228.827,W,000836,A,D
$GPBOD,,T,,M,,
$GPBWC,000836,,,,,,T,,M,,N,,D
$GPVTG,199.6,T,184.6,M,0.0,N,0.0,K,D
$GPXTE,A,A,,,N,D

From this log, each normal transmission occurs every 2 seconds and the
time stamp seconds are even numbered. The error indication occurs at
235959 which is an odd numbered second so this means that the code is
posting the error during the processing time before the next
transmission. If things were operating normally, this next
transmission would have occurred at 000000.

When the code resumes normal operation, it must have done some
processing prior to the NMEA transmission at 000834 so the 512 second
interval that I refer to is the period of time that the code is not
transmitting properly. This would be from 000000 to 000832.

Of course, I don't have the Garmin source code nor do I know what
their code does but my guess is that a counter is not being reset
properly at the date rollover. It probably just keeps incrementing
until it effectively resets to zero due to overflow. For example, 512
decimal would require 10 bits to represent so if 2 bytes are allocated
to the counter, when it went to 513, the low order 10 bits would be
all zeroes. If the software is using a mask or doing logical
operations only on the 10 bits, then effectively the counter would be
reset to zero. Obviously this is just conjecture on my part and I may
be wrong.

I hope that this explains what I meant more clearly... neither of us
counted incorrectly; we were just referring to different things.

Chet,

The explanation in my previous post is wrong. The counter would not
be reset to zero at 513... it would have to go to 1024 to reset to
zero so perhaps they are using a 9 bit counter which overflows at 512
and resets to zero. As I said, I don't have the source code so the
only thing I can do is guess.

John,
I think I do see how you counted it.
I would think Garmin would be most appreciative of your input.
Chet

wrote in message
ups.com...
Chet,

The explanation in my previous post is wrong. The counter would not
be reset to zero at 513... it would have to go to 1024 to reset to
zero so perhaps they are using a 9 bit counter which overflows at 512
and resets to zero. As I said, I don't have the source code so the
only thing I can do is guess.