Umm, to which post are you responding? Not any of the last few from me.
Indeed, on the 1.5 the power for the GPS sensor comes from the VMS. That's the red and black wires in the black connector where my adapter cable attaches.
-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
Caution - Annual Service - Car power-down - GPS issue
- Thread starter jfischer
- Start date
-
- Tags
- clock gps broken gps rollover
Indeed, on the 1.5 the power for the GPS sensor comes from the VMS. That's the red and black wires in the black connector where my adapter cable attaches.
supersnoop
Tesla Roadster #334
In the end, this problem set me back over $2k. Service said that the antenna had to be replaced, and then the whole VDS had to be replaced. I have no idea if they figured out how to flash the antenna or if they somehow got a new one with updated firmware. I’m sad to say by schedule didn’t allow me to attempt to fix it on my own, so I ended up with the new parts and a nice loaner for a few weeks.
Was it the VDS or the VMS that was replaced? The GPS sensor connects to the VMS, so the VDS seems a bit distant from the original problem. I wonder if the VDS (or VMS) really needed replacement.
supersnoop
Tesla Roadster #334
That's the correct TLA; the VMS is a box mounted above the passenger footwell. Was the VDS exhibiting any problem before you took the car in? I wonder if they broke it.
supersnoop
Tesla Roadster #334
I should have asked to keep the original part. I wasn’t confident in the diagnosis, but I wasn’t in a position or mindset to argue.
The GPS issue manifested as the inability to locate the car in the OVMS, but the only way to demonstrate the issue in the car was the lack of directional and elevation on the VDS. After the gps antenna replacement, the issue was not solved. I assume they hadn’t updated the firmware. They tried to return the car but I rejected it because the repair was incomplete. A couple days later, everything appeared correct in OVMS, but they said the VDS was still not displaying the direction or elevation. That was the reason given for VDS replacement.
OK, I agree that it would be hard to say anything definitive about the real cause of the lack of direction and elevation information without additional diagnosis with the old VDS unit. I can't think of a way that hardware in the VDS would fail such that all the rest of its functions would work but the GPS position information wouldn't be processed correctly. I can imagine the firmware getting into some bad state to cause this, but a reset should correct such problems. Anyway, spilled milk...
I have now used the adapter cable I made to successfully update the GPS firmware in a friend's 2.5 Roadster. This was the test I wanted to do before sending out the cable to be used by others. I'm preparing a more detailed instruction sheet to go with it. If you would like to borrow the adapter to update your car, please PM me. I have one request so far.
I learned a few interesting things in preparing for and performing this test:
I learned a few interesting things in preparing for and performing this test:
- The proper procedure for replacing the VMS is to inhibit the APS (the 12V power supply) and then unplug the two cables (black and blue), but no order is specified for the unplugging. For this firmware update only the black cable needs to be unplugged, so I left the blue one connected.
- Before doing the firmware update I disconnected the black connector, which removes power from the GPS sensor, then plugged it back in after about 15 seconds. Then I uninhibited the APS and turned the car on. The date was still correct!
- Viewing the PGRMT NMEA sentence output by the GPS sensor before the update confirmed that it was the 18x LVC model that is susceptible and the firmware version was 3.20 which is definitely old enough to exhibit the date problem. So it looks like the sensor must be unpowered for a longer period of time to induce the problem.
I agree. The VDS is an embedded app, nothing complicated. All it takes is stuff of the can bus and displays it (with keyboard menu for moving around, and some entry functions). I cannot see any way it would break in such a way that everything worked except the VDS display. They were probably just changing things to try to fix it, without the VDS actually being broken.
I know when they replaced my GPS with a new one from corporate, it had the older firmware in it. Hence where I got to diagnosing the problem and fixing it myself. Maybe now they have updated the older stocking parts with the newer firmware.
Think in my 2.5 it was 3.20 firmware on the Garmin GPS OEM sensor before I updated and fixed it
backmost
Member
Now I know why some Roadsters with the 18x are having issues and not others. I noticed this in the description of features:
Built-In Battery
"The onboard rechargeable backup battery can maintain the real-time clock for up to 10 days."
Built-In Battery
"The onboard rechargeable backup battery can maintain the real-time clock for up to 10 days."
It turns out that this USB to TTL Serial adapter does not fit the bill. Contrary to what the GPS 18x Technical Specifications document says, the data signal output by the sensor is bipolar +/-5V, not 0-5V. That means the signal exceeds the allowable input voltage range for the DTECH FTDI device, as discovered by @hcsharp as he tried to use the cable I made. Even though I successfully used my cable to update one car, its tolerance for the negative voltage after extended attempts appears to have caused damage to the chip resulting in a short. A revised design for my adapter is under discussion.
I'm going to modify my update cable using a normal bipolar USB to RS232 serial adapter as I initially proposed before I came across the DTECH device. I have purchased one with a 6' cable and will cut into the end with the DE9 connector so I can pick up +5V from the USB. Then I will mount the adapter's circuit board inside the box of my adapter and connect GND, +5, RX and TX directly to the AMPSEAL connector to again have a self-contained update adaper.
OK, I have now modified my update cable using a normal bipolar USB to RS232 serial adapter from which I completely removed the molded plastic housing at the end with the DE9 connector. That housing contained the little printed circuit board soldered to the pins of the DE9 connector. I have mounted that circuit board inside the box of my update cable so I can pick up +5V from the USB and connect GND, +5, RX and TX to the AMPSEAL connector. So again this forms a self-contained GPS sensor firmware update cable requiring only a USB connection to a Windows laptop.
I have tested this revised update cable on my 1.5 Roadster as much as I can, but it is not a complete test because there is no firmware update for the older model of the GPS sensor in the 1.5 Roadsters. I'm going to send off the update cable now to @JohnGarziglia to test on his 2.x Roadster. Assuming that is successful, I intend to loan this update cable to others who would like to use it.
I have tested this revised update cable on my 1.5 Roadster as much as I can, but it is not a complete test because there is no firmware update for the older model of the GPS sensor in the 1.5 Roadsters. I'm going to send off the update cable now to @JohnGarziglia to test on his 2.x Roadster. Assuming that is successful, I intend to loan this update cable to others who would like to use it.
Ok, so the resistance of the 2010 cars to the GPS issue appears be overstated...
I've had my car in for its annual maintenance, and then maintenance to fix the issues caused by the annual maintenance, several times since late summer. Each time with no issue related to the GPS. Except this last time.
In a determined effort to get to the bottom of the 1146 errors, the SC agreed to do some deeper troubleshooting, as opposed to simply replacing the $1,000 fan. See the saga here: What exactly is the 1146 Alert? Bottom line, there's nothing wrong with the fan. I got the car back last Thursday afternoon, and pulled the logs when I got home. All fine.
I did some driving today, and pulled the logs again to see if the 1146 errors had returned, only to discover that the log file was not named what it should have been; GPS had reset some time between Thursday and today. Today, according to the car, is in May 2000. The car has not been disassembled in any way during that time.
I'm really puzzled about this, since there was no issue during the maintenance, nor at the time I got the car home and pulled the logs. It's been sitting the in the garage in its usual place since then, except for a pair of errand runs today.
Is this one of those mythical "coincidences", or did something happen during the maintenance that set me up for this? Like, did they forget to re-connect something?
I've had my car in for its annual maintenance, and then maintenance to fix the issues caused by the annual maintenance, several times since late summer. Each time with no issue related to the GPS. Except this last time.
In a determined effort to get to the bottom of the 1146 errors, the SC agreed to do some deeper troubleshooting, as opposed to simply replacing the $1,000 fan. See the saga here: What exactly is the 1146 Alert? Bottom line, there's nothing wrong with the fan. I got the car back last Thursday afternoon, and pulled the logs when I got home. All fine.
I did some driving today, and pulled the logs again to see if the 1146 errors had returned, only to discover that the log file was not named what it should have been; GPS had reset some time between Thursday and today. Today, according to the car, is in May 2000. The car has not been disassembled in any way during that time.
I'm really puzzled about this, since there was no issue during the maintenance, nor at the time I got the car home and pulled the logs. It's been sitting the in the garage in its usual place since then, except for a pair of errand runs today.
Is this one of those mythical "coincidences", or did something happen during the maintenance that set me up for this? Like, did they forget to re-connect something?
To clarify: The logs you pulled when you got the car back last Thursday have the correct date, but logs you pulled today are dated in 2000? If so, that's outside the bounds of what I thought I understood about the problem.
As I understood it, the reason the date didn't regress for everyone on April 6, 2019 is that the GPS sensor would remember which week-number epoch it was operating in until power was lost and its internal rechargeable battery ran down. That spec for the GPS sensor says, "Onboard rechargeable backup battery can maintain the real-time clock for up to 10 days." I assumed that included remembering the week-number epoch, but perhaps not.
A second possibility is that some component in the car keeps track of time and date and only needs to get input from the GPS sensor periodically. How long might that period be? 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.
As I understood it, the reason the date didn't regress for everyone on April 6, 2019 is that the GPS sensor would remember which week-number epoch it was operating in until power was lost and its internal rechargeable battery ran down. That spec for the GPS sensor says, "Onboard rechargeable backup battery can maintain the real-time clock for up to 10 days." I assumed that included remembering the week-number epoch, but perhaps not.
A second possibility is that some component in the car keeps track of time and date and only needs to get input from the GPS sensor periodically. How long might that period be? 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.
Hi Steve,
Correct. The log was good last Thursday evening (3am Friday UTC), and bad today. That's the reason for posting. Unfortunately, I don't know when during that period the GPS lost its mind, but the last valid log entry appears to be from Friday 6:13pm local time.
12/12/2019 18:13:55 | 1576203235 | DAY | odo = 52965.5 range soc = 72%, brick ave 139.268Ah, brick min 136.474Ah, min Ah brick 14, CAC 136.77 Ah
12/13/2019 18:13:55 | 1576289635 | DAY | odo = 52965.5 range soc = 81%, brick ave 139.268Ah, brick min 136.474Ah, min Ah brick 14, CAC 136.77 Ah
12/13/2019 18:13:57 | 1576289637 | ERR | error code 104 7 bytes
12/14/2019 18:13:54 | 1576376034 | DAY | odo = 52969.7 range soc = 82%, brick ave 139.268Ah, brick min 136.474Ah, min Ah brick 14, CAC 136.77 Ah
------------------- | 957147234 | DAY | odo = 52969.7 range soc = 82%, brick ave 139.268Ah, brick min 136.474Ah, min Ah brick 14, CAC 136.77 Ah
------------------- | 957217235 | ERR | error code 104 7 bytes
Long-term Record Stats
======================
12/13/2019 18:13:55 | 1576289635 | DAY | odo = 52965.5 range soc = 81%, brick ave 139.268Ah, brick min 136.474Ah, min Ah brick 14, CAC 136.77 Ah
12/13/2019 18:13:57 | 1576289637 | ERR | error code 104 7 bytes
12/14/2019 18:13:54 | 1576376034 | DAY | odo = 52969.7 range soc = 82%, brick ave 139.268Ah, brick min 136.474Ah, min Ah brick 14, CAC 136.77 Ah
------------------- | 957147234 | DAY | odo = 52969.7 range soc = 82%, brick ave 139.268Ah, brick min 136.474Ah, min Ah brick 14, CAC 136.77 Ah
------------------- | 957217235 | ERR | error code 104 7 bytes
Long-term Record Stats
======================
There was a "vehicle being flatbedded" alert this afternoon, but they've been a fairly frequent occurrence over the past months, without any negative consequences. It was sitting out in the open in the parking lot of the local shopping center at the time. I usually get them when the car is safely snoozing in the garage, if only because it spends most of its time there.
I hesitate to tell Tesla about what happened, being reminded of the quote from Will Rogers that "When you find yourself in a hole, stop digging." The car's been through enough at the hands of the local SC for quite some time. I presume John has your update tool?