So, one difference in this past service event was that the OVMSv3 reported APS Disabled, which it hasn't done in the past. However, the GPS week issue didn't appear until 2 days later. If disabling APS drops power to the VMS, I can see your point, but why the delay?Sounds like for some reason your VMS rebooted / reset which caused the GPS to power cycle. If you have one of the "faulty" GPS units, power cycling the VMS or an Annual can trigger the issue. Mine was an annual service that triggered
Well, scratch that idea. An informed source told me that the VMS is not running ntpd but just sets its real-time clock directly from the NMEA sentences received from the GPS sensor.Oh, an idea just hit me: If the linux system in the VMS is running ntpd using the GPS sensor time as input, then what you might have observed is the long time that ntpd takes before it will give up on its own notion of the correct time and start believing an input that is significantly different. This is protection against "falsetickers", so named by Dave Mills, AKA Father Time, the creator of the Network Time Protocol.
I have successfully updated my GPS sensor using Steve's update connection box. I want to thank Steve for all of his assistance.Yes, it arrived there today. I hope it works smoothly for him.
So, who's next in line?
Hi Steve, I probably will be down there in the next couple of weeks, though probably not with the Roadster. I'll let you know by PM once schedules settle out. Thanks!@ShawnA requested first, so I've asked @JohnGarziglia to send the cable to Shawn (also, the distance is shorter). Presuming that Shawn is able to complete the update quickly, there may still be time for it to go to you first before it needs to come back to me by January 15. Let me know if you have any plans to be near Sunnyvale in early January.
Is your Roadster showing a date in 2000? If so, that would be very interesting because my Roadster US VIN 33 has a GPS 18 LVC (rather than GPS 18x LVC in the 2.x cars) which is claimed by Garmin not to need or have any update. However, I am able to communicate with the GPS sensor in my car and see the data stream of NMEA sentences.I tried to update via the FHC47 connector ( I used singular Pins/Nails) the Powersupply came from a USB Port an I usd the RS232 connector of my computer and than I tried a USB/RS232 Adapter but I couldn`t get a communication between the Computer and the GPS Modul.
I have a 2008 1.5 Roadster.
Also, if you don't mind saying, what is the VIN of your car? I made an assumption that 1.5 cars had a GPS 18 whereas 2.x cars had GPS 18x, but yours appears to be a counterexample. I suppose it is possible that the sensor in your car failed and was replaced. Or perhaps the GPS 18 is also susceptible to this problem but has no firmware update to fix it.
May 14 is the date we would expect for the GPS week-number rollover problem, but the year would be 2000, not 2010. When you look at the log file there would be some dates in 2010 because there is some permanently recorded information. But when you do the log file download, the filename should be something like 200005141234.tar which would indicate the year 2000.
The voltage measurements you made and the information on the display both indicate that the GPS is working, as you say. So you should be able to see the data with your computer. You don't need to use the SNSRXCFG program, you can use any program that allows showing data from the RS232 port in a terminal window. For example, I first looked at the data from my car using my MacBook Pro with a USB-RS233 adapter. Just make sure you get the RX pin of your computer hooked to the TX from the GPS, and set the baud rate to 4800.
Yes, a GPS 18x would work in a 1.5 Roadster, too. I don't know if the factory configuration of a new unit needs to be changed to fit what the car expects.
I assume that the configuration that you see there is just a set of defaults built into SNSRXCFG since if you have not been able to connect to the sensor yet it would not have had any way to pull the configuration from the sensor.Thats what I got from SNSRXCFG, I tried to set the baud rate to a higher level, because the Garmin update program starts with min. 9600 bps but it didn`t work.
No, i could connect in the beginning, the Latitude, Longitude and Altidude are from my place, than I changed the parameter of the Baud rate.I assume that the configuration that you see there is just a set of defaults built into SNSRXCFG since if you have not been able to connect to the sensor yet it would not have had any way to pull the configuration from the sensor.