When you click on links to various merchants on this site and make a purchase, this can result in this site earning a commission. Affiliate programs and affiliations include, but are not limited to, the eBay Partner Network.
You can see in this post https://www.corvetteforum.com/forums...post1591345523 a screen shot of the Cosworth toolbox. Look at the time delta line. It goes near vertical at about the 30 sec mark even though I’m still running normally.
Also, you can watch this video at around the 1:52 mark. Just watch it in ¼ speed and you can clearly see the lap time go from 21s to 19s. https://youtu.be/PRsLojTdA6Q
Is GM aware of this problem and is there a fix in the works? It's not the sort of thing a dealer is going to be able to replicate or fix on their own.
Tadge answered: Several of us on the Corvette team learned a lot from researching this answer. We have known about the problem and technical folks were developing a solution before we heard from customers or got asked the question on the forum.
Most people think of time as a sort of universal constant, like a metronome clicking off the seconds with perfect regularity. Einstein is deservedly famous for showing that time is not constant, it is relative to the speed of the observer. I am not saying the Corvette is so fast that clocks run slower in the car (although that is true to a very small extent), but bringing this up to highlight the fact that are many ways to measure time.
What does this have to do with the PDR loosing 2 seconds seemingly at random? The answer lies in the coordination of different global time systems. Corvette’s PDR used GPS (Global Positioning System) to determine the location of the car on track. GPS uses extremely accurate clocks to measure the time it takes signals (traveling at the speed of light, 186,000 miles per second) to travel the distance between the vehicle and several satellites orbiting the earth. Knowing the distance to the satellites allows the system to triangulate and calculate an accurate position for the car. The clock system the GPS uses is known as UTC (Temps universel coordonné) and is based on a series of super-accurate atomic clocks around the world. Unfortunately, the world we live in is not as stable as the atomic clocks. Much of the world operates on solar time which is based on the rotation of the earth. The rotation of the earth varies over time but is on the general trend of slowing down. Periodically, these two time measurement systems fall out of sync and an adjustment has to be made. Every time your Corvette starts, the PDR system looks to see if an adjustment has been made through the GPS. Since the PDR software was created 2 seconds have been added to sync the clocks (June 30, 2015 and June 30, 2012). These adjustments to the UTC time are managed through the addition of “leap seconds”. Leap seconds are analogous to leap days added February 29 every 4 years to keep our calendars sync’d with the earth’s orbit around the sun.
When the PDR was created the UTC time adjustment was broadcast through the GPS system every 10 seconds, meaning almost immediately after vehicle start, the data was available to bring the clock setting up to date (With on-board processing time, the worst case was 10 minutes). In December of 2015, that update cadence was slowed to every 2 hours, vastly increasing the probability that an update could occur as someone is timing a lap. When the system updates while timing a lap the result is the loss of exactly 2 seconds. This explains why customers are seeing this occasionally in the field. We do have a solution for 2017 and the good news is that it is backwards compatible to all prior PDR-equipped vehicles. The software update should be available this Summer. Although it will reduce the likelihood of getting the time loss by orders of magnitude, there will still be a very small chance it could happen again depending on when the time systems get updated.
I have tried to describe this situation in layman’s terms. International time keeping is actually quite a complex subject. Anyone interested in more detail can find lots of info on-line.
Don't know how they are fixing the problem, but it looks like their problem is a bit more fundamental. They are using the wrong clock.
They shouldn't be using UTC time or any other "wall clock" for lap timing. It doesn't matter what time of day it is, never mind leap seconds or anything else. They need a linear time source that measures relative time accurately and has a good enough resolution (1 ms is probably good enough for this). I have a tough time believing that the system doesn't have one (probably has multiple).
This is such basic stuff it really worries me. Guess we should just be glad that the people that did the PDR didn't do the engine controller.
I disagree fully with all of your comments. The PDR is more than just a simple lap timer and it is mostly (if not completely) based on GPS satellites. Without a proper sync with the satellites: speed, bearing, altitude, and most of all location will not be determined accurately. Personally, I'm glad he gave us the technical details of what is causing the issues versus... "We know about and are working on it, corporate speak." As a software engineer you should understand really weird corner cases do exist and unfortunately some times they aren't found until after release.
Honestly, it is sad how members on this forum continue to doubt/bash the chief engineering of the corvette program even though he freely takes time out of his schedule to gives us a peek behind the curtain.
Don't know how they are fixing the problem, but it looks like their problem is a bit more fundamental. They are using the wrong clock.
They shouldn't be using UTC time or any other "wall clock" for lap timing. It doesn't matter what time of day it is, never mind leap seconds or anything else. They need a linear time source that measures relative time accurately and has a good enough resolution (1 ms is probably good enough for this). I have a tough time believing that the system doesn't have one (probably has multiple).
This is such basic stuff it really worries me. Guess we should just be glad that the people that did the PDR didn't do the engine controller.
Don't know how they are fixing the problem, but it looks like their problem is a bit more fundamental. They are using the wrong clock.
They shouldn't be using UTC time or any other "wall clock" for lap timing. It doesn't matter what time of day it is, never mind leap seconds or anything else. They need a linear time source that measures relative time accurately and has a good enough resolution (1 ms is probably good enough for this). I have a tough time believing that the system doesn't have one (probably has multiple).
This is such basic stuff it really worries me. Guess we should just be glad that the people that did the PDR didn't do the engine controller.
The easy way would be to figure the frames per second of the PDR system, and then interpolate how many frames shot in video session to calculate the lap time. Or of course you could replicate the technology of a 1990s timex.
Don't know how they are fixing the problem, but it looks like their problem is a bit more fundamental. They are using the wrong clock.
They shouldn't be using UTC time or any other "wall clock" for lap timing. It doesn't matter what time of day it is, never mind leap seconds or anything else. They need a linear time source that measures relative time accurately and has a good enough resolution (1 ms is probably good enough for this). I have a tough time believing that the system doesn't have one (probably has multiple).
This is such basic stuff it really worries me. Guess we should just be glad that the people that did the PDR didn't do the engine controller.
I disagree fully with all of your comments. The PDR is more than just a simple lap timer and it is mostly (if not completely) based on GPS satellites. Without a proper sync with the satellites: speed, bearing, altitude, and most of all location will not be determined accurately. Personally, I'm glad he gave us the technical details of what is causing the issues versus... "We know about and are working on it, corporate speak." As a software engineer you should understand really weird corner cases do exist and unfortunately some times they aren't found until after release.
Honestly, it is sad how members on this forum continue to doubt/bash the chief engineering of the corvette program even though he freely takes time out of his schedule to gives us a peek behind the curtain.
I disagree fully with all of your comments. The PDR is more than just a simple lap timer and it is mostly (if not completely) based on GPS satellites. Without a proper sync with the satellites: speed, bearing, altitude, and most of all location will not be determined accurately. Personally, I'm glad he gave us the technical details of what is causing the issues versus... "We know about and are working on it, corporate speak." As a software engineer you should understand really weird corner cases do exist and unfortunately some times they aren't found until after release.
Honestly, it is sad how members on this forum continue to doubt/bash the chief engineering of the corvette program even though he freely takes time out of his schedule to gives us a peek behind the curtain.
Excuse me, what does the lap time have to do with GPS coordinates? You use the GPS time for the location and you use linear time for the lap timer. You also use that sync'd wall clock from the GPS for things like file timestamps.
"Honestly, it's sad how members on this forum" with no knowledge at all shoot down what other people say. I've got 30+ years experience designing and building these kinds of systems for Medical, defense, and communications applications. i know EXACTLY what I'm talking about. I'd bet I know more about it than Tadge does since this is not his area of expertise.
And FYI, I wasn't "bashing" Tadge, I was bashing whomever built the PDR, and rightfully so. Add the clock issue to the video quality and the lack of some obvious features, and it's pretty obvious it wasn't done very well. Neither was the whole "Infotainment System" for that matter.
Excuse me, what does the lap time have to do with GPS coordinates? You use the GPS time for the location and you use linear time for the lap timer. You also use that sync'd wall clock from the GPS for things like file timestamps.
I did not design the PDR system but this is my engineering opinion, deduced from experience. Without using a transponder based timing system GPS is the next logical way. I partially agree with running a linear timer for the lap but you still have the issue of the car potentially being out of sync with the satellites overhead. This is turn could return an inaccurate reading of when the vehicle crosses start finish and/or produce anomalies in its perceived path. I'm not really following your last sentence. The issue has nothing to do with file timestamps but the accuracy of the time & location determined by the system.
Originally Posted by Jay_Davis
"Honestly, it's sad how members on this forum" with no knowledge at all shoot down what other people say. I've got 30+ years experience designing and building these kinds of systems for Medical, defense, and communications applications. i know EXACTLY what I'm talking about. I'd bet I know more about it than Tadge does since this is not his area of expertise.
My words were harsh and yes they were directed at you. Now thinking more about it was wrong for me to say that on a public forum to a person I don't know. I apologize, but let me say this. I don't have 30+ years of experience but I do have a masters in engineer and I've spent time working for an aerospace company as a hardware designer before my current job. I get that you feel that know EXACTLY what you talking about... but with respect to the PDR system how can you honestly make that statement without knowing: the design constraints, development timeline, personnel involved, and most of all budget?
Originally Posted by Jay_Davis
And FYI, I wasn't "bashing" Tadge, I was bashing whomever built the PDR, and rightfully so. Add the clock issue to the video quality and the lack of some obvious features, and it's pretty obvious it wasn't done very well. Neither was the whole "Infotainment System" for that matter.
Cosworth did the PDR recorder, and its not perfect by any means but to say it was't done very well is a bit of a stretch. Its an amazing system and the amount of good information it gives is astonishing. I've recently had the opportunity to dive into the details of Aim Solo's Race Studio Analysis software. I can say without a doubt the Cosworth Toolbox is a much better system overall (not considering the glitch of course ). Just to replicate the information the Toolbox produces would easily cost $3K or more and the software would NOT be as user friendly.
FYI: I'm now a performance engineer and data analysis is my specialty. For the last two years my hobby has been making/refining my own low budget track data acquisition system. Here's a screen shot from one of my videos.
Jay, I think he just keyed on the real problem which is pretty common on this forum, which is, with a few swipes of the keyboard, members seem to feel they have the simple fix for a problem which evades a team of engineers. As TruthB points out, without knowing the design constraints, timelines, budget and compromises in place, you really are hardpressed to have a solution in 3 sentences.
I think Tadge pretty clearly states why the situation exists, and I'm sure they have all worked to have the best resolution to the issue possible. Let's let them do that and appreciate their effort. Corvette delivers SO much, for so little cost...just the fact that Tadge answers these questions...all of it is pretty unprecedented in the car industry.
Don't know how they are fixing the problem, but it looks like their problem is a bit more fundamental. They are using the wrong clock.
They shouldn't be using UTC time or any other "wall clock" for lap timing. It doesn't matter what time of day it is, never mind leap seconds or anything else. They need a linear time source that measures relative time accurately and has a good enough resolution (1 ms is probably good enough for this). I have a tough time believing that the system doesn't have one (probably has multiple).
This is such basic stuff it really worries me. Guess we should just be glad that the people that did the PDR didn't do the engine controller.
I agree... it's a very easy fix, just start counting as soon as the PDR recording starts with no need to reference anything else.
I disagree fully with all of your comments. The PDR is more than just a simple lap timer and it is mostly (if not completely) based on GPS satellites. Without a proper sync with the satellites: speed, bearing, altitude, and most of all location will not be determined accurately. Personally, I'm glad he gave us the technical details of what is causing the issues versus... "We know about and are working on it, corporate speak." As a software engineer you should understand really weird corner cases do exist and unfortunately some times they aren't found until after release.
Honestly, it is sad how members on this forum continue to doubt/bash the chief engineering of the corvette program even though he freely takes time out of his schedule to gives us a peek behind the curtain.
You can use GPS for everything except for the lap timer, which has no excuse to not be accurate 100% of the time with no anomalies.
Edit - and it's an understandable bug, but still a very easy fix.
Last edited by slickstick; 05-08-2016 at 11:21 PM.
I did not design the PDR system but this is my engineering opinion, deduced from experience. Without using a transponder based timing system GPS is the next logical way. I partially agree with running a linear timer for the lap but you still have the issue of the car potentially being out of sync with the satellites overhead. This is turn could return an inaccurate reading of when the vehicle crosses start finish and/or produce anomalies in its perceived path. I'm not really following your last sentence. The issue has nothing to do with file timestamps but the accuracy of the time & location determined by the system.
My words were harsh and yes they were directed at you. Now thinking more about it was wrong for me to say that on a public forum to a person I don't know. I apologize, but let me say this. I don't have 30+ years of experience but I do have a masters in engineer and I've spent time working for an aerospace company as a hardware designer before my current job. I get that you feel that know EXACTLY what you talking about... but with respect to the PDR system how can you honestly make that statement without knowing: the design constraints, development timeline, personnel involved, and most of all budget?
Cosworth did the PDR recorder, and its not perfect by any means but to say it was't done very well is a bit of a stretch. Its an amazing system and the amount of good information it gives is astonishing. I've recently had the opportunity to dive into the details of Aim Solo's Race Studio Analysis software. I can say without a doubt the Cosworth Toolbox is a much better system overall (not considering the glitch of course ). Just to replicate the information the Toolbox produces would easily cost $3K or more and the software would NOT be as user friendly.
FYI: I'm now a performance engineer and data analysis is my specialty. For the last two years my hobby has been making/refining my own low budget track data acquisition system. Here's a screen shot from one of my videos.
Data analysis may be your specialty, but obviously real time software isn't. I stand by my statements. Tracking the lap times the way they did is just dumb and there's no excuse for it. Don't know if its a hardware goof (no clock provided to software) or a software goof, but its pretty basic.
As for as how good the system is, this is not rocket science. It's basic data collection with audio & video recording stored in a file. The only intelligence it really has is the using the GPS data to figure out the track, which isn't that complicated either. The video quality doesn't even match that of a cheap phone camera, even accounting for the effects of the over-compression they are doing. So no, this was not done well.
Your answer is invisible/moot to the person responsible for you leaving your comment
[QUOTE=truth.b;1592167246]I disagree fully with all of your comments. The PDR is more than just a simple lap timer and it is mostly (if not completely) based on GPS satellites. Without a proper sync with the satellites: speed, bearing, altitude, and most of all location will not be determined accurately. Personally, I'm glad he gave us the technical details of what is causing the issues versus... "We know about and are working on it, corporate speak." As a software engineer you should understand really weird corner cases do exist and unfortunately some times they aren't found until after release.
Honestly, it is sad how members on this forum continue to doubt/bash the chief engineering of the corvette program even though he freely takes time out of his schedule to gives us a peek behind the curtain.[/QUOTE Il give ya few do’s and don’ts: I give full permission to use this writing to help build you a since of manners. That when properly utilized will get you a lot further in life and best of all its free to use these techniques. #1...Don't bite the hand the feeds. If someone is an engineer from the manufacture he more likely knows more than your average car enthusiast. Sometimes the everyday driver can move a known issue a long quicker if say you are getting good video and sound of an issue and forward to the proper person working that issue. For the most part the guy building the cars knows plenty more. I’m not talking about the 1 guy who works the assemble line and puts in the same one part all day. I am talking about the forward thinkers and doers at the plant. On another note: forums like this help the engineers greatly. Look at all the feedback in real time. (FREE for them)...As we speak our current new vehicles have known issues and the engineers just don't know that exact moment they will start creating problems that we start to notice and/trigger a sensor. Forums such is this give the engineers timetables that have ever existed. They can then discuss with the board members (bean counters) about when to maybe offer a recall or if they can wait a little longer. Although my goal with this short post was to say thanks to the poster for sticking up for the engineer that volunteers his time but also put a little perspective into situations like this. Oh and Im a rambler a talker. Sorry.. No offense if your reply back is something like "man you are long winded. Ill finish reading your comment later over a 6 pack".
Another hobby I have acquired is helping other save a little time. So to the members who are to google search the word moot that I used in the title I am referring to the "matter of no practical value or importance". Usually used as [moot point] is more common in modern American English.
Data analysis may be your specialty, but obviously real time software isn't. I stand by my statements. Tracking the lap times the way they did is just dumb and there's no excuse for it. Don't know if its a hardware goof (no clock provided to software) or a software goof, but its pretty basic.
As for as how good the system is, this is not rocket science. It's basic data collection with audio & video recording stored in a file. The only intelligence it really has is the using the GPS data to figure out the track, which isn't that complicated either. The video quality doesn't even match that of a cheap phone camera, even accounting for the effects of the over-compression they are doing. So no, this was not done well.
You're still making very specific statements despite your lack of information. Your opinions are based on assumptions and not fact, stand by your statements and I shall with mind. The only thing we can loosely agree on is the video resolution/quality isn't as good as consumer level options. But once again without knowing the R&D detail, the timeline, and the budget NO ONE can know for sure why certain decisions had to be made. Maybe they based the camera on the racing industry standard (720P), maybe higher resolutions cameras couldn't meet cost & packaging... Who' knows
The fact is the Cosworth system (when sans glitch ) is the best in the world when compared to any other OEM. You may feel that it is not but I would like see you provide an example of a better offering from any other manufacture.
A little perspective:
The following videos are Porsche's Track Precision App (991 GT3 only via iPhone) and two V-Box video recordings
The Porsche App defaults to the phone's resolution and obviously the resulting video is directly correlated to the users phone mount as well as other variables
Of the current 4 products V-Box sells only 1 has 1080P capabilities, the other 3 are 720P only
As a side note AiM's SmartyCamHD is only 720P as well, but their cameras resolution visibility looks better than everyone else.
I love how people keep trying to make excuses for this. I don't care what the reason was. If the engine blew up after 5000 miles all the time because they didn't budget enough money to design it properly, its still an inexcusable problem.
I also don't care what other manufacturers do. Just because their's are not great doesn't mean that's the standard to be matched.
Here's a hint to all: Tadge doesn't need defending. This is not an attack on him. If he's a good engineer, and it seems like he is, I suspect he would think this kind of work is an inexcusable as I do. He may not have a lot of control over the development of the PDR, just like he probably doesn't for the whole infotainment system (which is also horrible).
Cosworth, the company that made the PDR, is also tuning the Mustang V8 to be used in the upcoming TVR rebirth. I think they are some of the best in the industry at making and tuning engines and ECUs so the PDR must have been a small project for them.
No further input except working with video and overlapping is a huge resource hog. Going to 1080P would have required some faster hardware, you can be sure of that.
This could just be a small mistake for a big company.
Cosworth, the company that made the PDR, is also tuning the Mustang V8 to be used in the upcoming TVR rebirth. I think they are some of the best in the industry at making and tuning engines and ECUs so the PDR must have been a small project for them.
No further input except working with video and overlapping is a huge resource hog. Going to 1080P would have required some faster hardware, you can be sure of that.
This could just be a small mistake for a big company.
For all we know they outsourced the project.
1080p isn't really necessary, just less compression and better color calibration. I don't think we know what sensor they are using in the camera, so a "cheap camera" may not even be a problem.
Every timer in the car is based on the "master clock" of the car (usually the radio, but now whoever "owns" the GPS).
So linear time isn't a concept the car is aware of because all linear time is versus the clock master! So if the master changes, anything linear time based does as well.
You could do time off the pulses of the clock signal in a micro, but that's even more inaccurate than the master clock.
Every timer in the car is based on the "master clock" of the car (usually the radio, but now whoever "owns" the GPS).
So linear time isn't a concept the car is aware of because all linear time is versus the clock master! So if the master changes, anything linear time based does as well.
You could do time off the pulses of the clock signal in a micro, but that's even more inaccurate than the master clock.
Sorry, nope. Do you really think the engine timing (never mind a ton of other stuff in the car) is off the radio/GPS clock?
I don't know what spec they targeted for the lap timer in terms of resolution and accuracy, but does anyone think that it would need better than a resolution of 1 ms with an accuracy of += 1 ms over 10 minutes? That would seem fine to me (probably better than necessary) and not what I would consider a tough requirement for a clock source.
Sorry, nope. Do you really think the engine timing (never mind a ton of other stuff in the car) is off the radio/GPS clock?
I don't know what spec they targeted for the lap timer in terms of resolution and accuracy, but does anyone think that it would need better than a resolution of 1 ms with an accuracy of += 1 ms over 10 minutes? That would seem fine to me (probably better than necessary) and not what I would consider a tough requirement for a clock source.
Dude your "Sorry/Nope" is so hilarious I nearly fell out of my chair.
Engine timing is not based on a clock. And yes, everything else in the car that is a timer is based on the "master clock"
You do understand there is "internal module time" versus "human time" Things like task list, and such are all run at "module time" (your engine timing example above falls into that). This timing over the long term is extremely inaccurate versus GPS (but as a short duration relative time it's fine). It's also only used when you don't need to track something longer than a few loops.
Global Real Time is always broadcast on the CAN bus and anything you want to link back to a clock or share between multiple modules uses it. For example all timestamps on fault codes use the "master clock"
I mean really, did you actually think engine timing uses a "timer," it doesn't it uses a ECU loop time and an algorithm. So please, try again.
Dude your "Sorry/Nope" is so hilarious I nearly fell out of my chair.
Engine timing is not based on a clock. And yes, everything else in the car that is a timer is based on the "master clock"
You do understand there is "internal module time" versus "human time" Things like task list, and such are all run at "module time" (your engine timing example above falls into that). This timing over the long term is extremely inaccurate versus GPS (but as a short duration relative time it's fine). It's also only used when you don't need to track something longer than a few loops.
Global Real Time is always broadcast on the CAN bus and anything you want to link back to a clock or share between multiple modules uses it. For example all timestamps on fault codes use the "master clock"
I mean really, did you actually think engine timing uses a "timer," it doesn't it uses a ECU loop time and an algorithm. So please, try again.
No point in arguing. You guys are obviously experts.
I've actually used the same CPU's GM has used for engines for other applications. But no, I must have no idea about their clock and timing capabilities. Give me a break.
FYI: You still don't get the difference in clocks. Then again, apparently neither did the people that built the PDR.
05-06-2016, 01:57 PM
[ANSWERED] PDR Fix and Improvements
Or of course you could replicate the technology of a 1990s timex.
I can say without a doubt the Cosworth Toolbox is a much better system overall (not considering the glitch of course 
). Just to replicate the information the Toolbox produces would easily cost $3K or more and the software would NOT be as user friendly.
You're still making very specific statements despite your lack of information. Your opinions are based on assumptions and not fact, stand by your statements and I shall with mind. The only thing we can loosely agree on is the video resolution/quality isn't as good as consumer level options. But once again without knowing the R&D detail, the timeline, and the budget NO ONE can know for sure why certain decisions had to be made. Maybe they based the camera on the racing industry standard (720P), maybe higher resolutions cameras couldn't meet cost & packaging... Who' knows 
