Trakus at Aqueduct

[Tom]

Do a vector analysis and calculate the horse's displacement; it cannot be done from the Equibase/DRF data.

Oh my, I will have to find a way to live without it then.
Competence is the quality of the product to put out.
When your product is incorrect or missing, I call that incompetence.

Trakus has a lot of potential, but potential ain't real life.

[Cratos]

Originally Posted by cj

Santa Anita data in Equibase charts is from Trakus. Trakus has a ton of potential. They just don't have much QA, particularly since Pat Cummings left.

What is strange is neither you or Tom identified a failure mode due to the Trakus process.

Also in the product development process Quality is designed in and not added on ; the V&V performed by QA/QC is against a spec from engineering that is typically customer driven.


I am quite sure Trakus doesn't make their physical chips and their software is implemented into them.

Given that Trakus integrated its technology into an existing physical structure their EMC by any objective measure is damn good.

[cj]

Originally Posted by Cratos

What is strange is neither you or Tom identified a failure mode due to the Trakus process.

Also in the product development process Quality is designed in and not added on ; the V&V performed by QA/QC is against a spec from engineering that is typically customer driven.


I am quite sure Trakus doesn't make their physical chips and their software is implemented into them.

Given that Trakus integrated its technology into an existing physical structure their EMC by any objective measure is damn good.

None of which explains why they miss so many errors. The sub 21 quarter at Meydan in a 1600 meter race with no run up was one I mentioned. How is that not caught by even the most rudimentary quality control?

If you publish the data, you should take steps to ensure accuracy. Period.

[Cratos]

Originally Posted by cj

None of which explains why they miss so many errors. The sub 21 quarter at Meydan in a 1600 meter race with no run up was one I mentioned. How is that not caught by even the most rudimentary quality control?

If you publish the data, you should take steps to ensure accuracy. Period.

It is apparent from reading your posts that analytics is not your strong suit.

A timing metric wouldn't be the QA/QC function; what should be investigated is "cause" and not "effect." If the timing was wrong at Meydan then it probably was a system miscue, but if it was within in the system's acceptable accuracy metric the system is qualitative.

Having worked in two of the most quality driven regulated environments in the world in aerospace and medical devices I don't become alarm by ridiculous claims like yours.

Trakus provide data for 17 racetracks worldwide and to the best of my knowledge I haven't read or heard of a ground-swell complaint about their data.

Therefore if you have a bona-fide issue with the quality of their data, I would suggest that you contact either Jim Conant or Rob Griffin; both are VPs with responsibility for Engineering and Product Development at Trakus.

If they don't respond then go straight to Bob McCarthy the CEO who have an EE at the Masters level and attended the Sloan School from my Alma mater, MIT.

[Tom]

A timing metric wouldn't be the QA/QC function; what should be investigated is "cause" and not "effect." If the timing was wrong at Meydan then it probably was a system miscue, but if it was within in the system's acceptable accuracy metric the system is qualitative.

Apparently, the real world is not your strong suit.
It is the PRODUCT, not the PROCESS that matters.
What you do makes zero difference if your product is flawed. Trakus's product if frequently flawed, ie, dead wrong.

Would you defend the process of food processing if you ate a bad steak and got Mad Cow?

[cj]

Originally Posted by Cratos

It is apparent from reading your posts that analytics is not your strong suit.

A timing metric wouldn't be the QA/QC function; what should be investigated is "cause" and not "effect." If the timing was wrong at Meydan then it probably was a system miscue, but if it was within in the system's acceptable accuracy metric the system is qualitative.

Having worked in two of the most quality driven regulated environments in the world in aerospace and medical devices I don't become alarm by ridiculous claims like yours.

Trakus provide data for 17 racetracks worldwide and to the best of my knowledge I haven't read or heard of a ground-swell complaint about their data.

Therefore if you have a bona-fide issue with the quality of their data, I would suggest that you contact either Jim Conant or Rob Griffin; both are VPs with responsibility for Engineering and Product Development at Trakus.

If they don't respond then go straight to Bob McCarthy the CEO who have an EE at the Masters level and attended the Sloan School from my Alma mater, MIT.

Call it what you like, those bad times should be caught every time. If those times were within the accuracy metric then whoever wrote the metric doesn't know horse racing.

[classhandicapper]

Despite the things that may still need some work, I'm always disappointed when I'm doing my trip and bias notes and it's not for a Trakus track.

[cj]

Originally Posted by classhandicapper

Despite the things that may still need some work, I'm always disappointed when I'm doing my trip and bias notes and it's not for a Trakus track.

I like it too despite the issues at times. It is a good tool.

[steveb]

Originally Posted by Cratos

It is apparent from reading your posts that analytics is not your strong suit.

A timing metric wouldn't be the QA/QC function; what should be investigated is "cause" and not "effect." If the timing was wrong at Meydan then it probably was a system miscue, but if it was within in the system's acceptable accuracy metric the system is qualitative.

Having worked in two of the most quality driven regulated environments in the world in aerospace and medical devices I don't become alarm by ridiculous claims like yours.

Trakus provide data for 17 racetracks worldwide and to the best of my knowledge I haven't read or heard of a ground-swell complaint about their data.

Therefore if you have a bona-fide issue with the quality of their data, I would suggest that you contact either Jim Conant or Rob Griffin; both are VPs with responsibility for Engineering and Product Development at Trakus.

If they don't respond then go straight to Bob McCarthy the CEO who have an EE at the Masters level and attended the Sloan School from my Alma mater, MIT.

most of the above is double dutch to me, but would you care to comment on the below?

i was really keen to use trakus for singapore racing for a group i was once helping, and was in the midst of doing some research, when for some reason i went back to trakus site to check something.
what i was not ready for was what i actually saw.....
this was NOT an isolated example i later discovered.
the headings are mine, the data is all trakus.
one set of numbers was grabbed several weeks before the other set.
how could one possibly trust the info in light of that??
it is old, and it is possible they have lifted their game since, but when i saw that i immediately stopped what i was doing.

I decided to remove the attachment, as I am not sure I am allowed to post the Trakus data i have for this particular race.
if you want a look PM me.
I also decided to go to Trakus and again check this particular race.
Amazingly, it is different again.
That is 3 versions of data for the same race!

[Tom]

That is 3 versions of data for the same race!

Oh, I see.
The pick three?

[Cratos]

Originally Posted by steveb

most of the above is double dutch to me, but would you care to comment on the below?

i was really keen to use trakus for singapore racing for a group i was once helping, and was in the midst of doing some research, when for some reason i went back to trakus site to check something.
what i was not ready for was what i actually saw.....
this was NOT an isolated example i later discovered.
the headings are mine, the data is all trakus.
one set of numbers was grabbed several weeks before the other set.
how could one possibly trust the info in light of that??
it is old, and it is possible they have lifted their game since, but when i saw that i immediately stopped what i was doing.

I decided to remove the attachment, as I am not sure I am allowed to post the Trakus data i have for this particular race.
if you want a look PM me.
I also decided to go to Trakus and again check this particular race.
Amazingly, it is different again.
That is 3 versions of data for the same race!

Steve, I will send you a PM because i am curious to see the Trakus problem you experienced.

[Cratos]

I think this thread is about horseracing and not about the QA/QC methodology.

However I do want say that an inferior process will yield an inferior PRODUCT.

Yes, it is the product that irritates the customer, but it is the "bad" process which produces the bad product and should be corrected; and that is the real world.

Therefore if Trakus "PRODUCT" is bad (and I don't believe that it Is) then their "PROCESS" should be corrected which I don't believe needs any more correcting other than ongoing maintenance.

[steveb]

Originally Posted by Cratos

Steve, I will send you a PM because i am curious to see the Trakus problem you experienced.

i guess you decided that you did not want to know?
if you are a user and a staunch defender of trakus, then it is logical to assume you have historical data on your computers in some format.
why don't you check some of the older, and compare with what it says now?

as i am writing this reply, i am rereading what you said here.
i did not experience any problems as such, the problems are all theirs.

any other interested parties are welcome to this file too.
it just shows the differences, between 2 different instances, of retrieved trakus data.
every field has differences, sometimes big ones.
an example of each 100 metre section time for one horse

100-8.68-8.11
200-5.82-5.85
300-5.97-5.94
400-6.06-6.06
500-6.06-6.06
600-6.17-6.17
700-6.32-6.29
800-6.17-6.20
900-6.00-6.06
1000-5.97-6.14
1100-6.00-6.17
1200-6.08-6.26
1300-6.08-6.08
1400-6.08-6.08
1500-6.23-6.23
1600-6.55-6.55


that is for the winner and its sections(both of them!) add to something a lot different than the overall winning time which was 100.11

how can one defend that?

[Tom]

how can one defend that?

Wait for it............

[Cratos]

Originally Posted by steveb

i guess you decided that you did not want to know?
if you are a user and a staunch defender of trakus, then it is logical to assume you have historical data on your computers in some format.
why don't you check some of the older, and compare with what it says now?

as i am writing this reply, i am rereading what you said here.
i did not experience any problems as such, the problems are all theirs.

any other interested parties are welcome to this file too.
it just shows the differences, between 2 different instances, of retrieved trakus data.
every field has differences, sometimes big ones.
an example of each 100 metre section time for one horse

100-8.68-8.11
200-5.82-5.85
300-5.97-5.94
400-6.06-6.06
500-6.06-6.06
600-6.17-6.17
700-6.32-6.29
800-6.17-6.20
900-6.00-6.06
1000-5.97-6.14
1100-6.00-6.17
1200-6.08-6.26
1300-6.08-6.08
1400-6.08-6.08
1500-6.23-6.23
1600-6.55-6.55


that is for the winner and its sections(both of them!) add to something a lot different than the overall winning time which was 100.11

how can one defend that?

Steve,
You are incorrect; I didn't decide not to send you a PM.

I travel a lot and I access this forum via my cellphone, but for whatever reason I cannot open my PMs on my phone.

I should be home tomorrow and I will try from my computer.