2014 Mazda 3

[Stevn3]

Anyone had any success with Bosch CDR Kit download of a 2014 Mazda 3 via desktop or a pin rewire to trick it into another Mazda and read the EEPROM

[R.Botter]

Yes, the 2014 Mazda3 is supported by the Bosch CDR Tool for data retrieval both DLC and direct to module. Why, particularly for litigation, would one want to "trick" a module into anything? There are a number of references to "spoofing" and how that's really bad idea, particularly for litigation. But since the Mazda3 airbag computer data is accessible using the Bosch Tool, why would we want to do anything that would cast doubt on the retrieved data?

[Stevn3]

Thanks Ralph but its not reading the ACM with Bosch CDR Tool in either option or the correct. Have tried others as a back up to no avail. In Australia we have to use spoofing for Mazda all the time, so that is a familiar concept for us. It's beyond its use for litigation as dashcam is damning enough. The tricking it is the curious nature of me without having to locate the wiring schematics and figure it out myself. End story, regardless of all proper Bosch CDR options and abilities, still not reading (its not damaged)

[Rusty Haight]

It's not reading because that module is not supported in Oz. In the Help file, notice the Market Code is "1" which means "US and Canada."

No matter how many times someone has told you spoofing is "ok," without some specific additional information, it is not. No matter how many times you may have got away with it, it's still the wrong approach without information specifically from the OEM. THE, the VERY reason some vehicles won't download in markets outside of those specified in the Help file is the OEMs won't support them in those regions and, BECAUSE people insist on spoofing, the OEMs have gone on to disable the software ID for some modules where those modules are used in markets outside those designated. I suspect that's the case with your Mazda3.

But let's say you continue down that path spoofing VINs, at some point, some smart lawyer on the other side will blow up this section of the Bosch CDR Tool Help file in the largest typeface possible and offer it as an exhibit in your cross-examination where...

Attempts made to retrieve data from vehicles built for markets the CDR Tool does not support by entering a VIN from a market it is built for (VIN spoofing) may result in inaccurate CDR report data translations and possibly incorrect or erroneous retrieval of data from the ECU. (-emphasis added because it should be...)

Spoofing can result in incorrect translation where the VIN is used to tell the CDR Software (a) what module it expects to talk to and (b) then how to translate that data into a data translation report. Consider in the Chrysler Coverage Notes where...

The User Entered VIN must match the VIN stored in the ACM. If it does not match, the CDR tool will retrieve EDR data but only include hexadecimal data in the CDR report.

Why do you suppose they'd take the time to do something like that if spoofing a VIN was "ok?"

Here, where you were taught it's ok to spoof - and it is not - you don't seem to have been taught the process in the CDR Tool software which would then explain WHY spoofing (1) may not work, (2) is at least dangerous and (3) at worst, just the wrong thing to do. The process, within the CDR Tool software is generally like this:

1. You select a BRAND in the software. At this step, this, generally, tells the CDR Tool software it's going to "talk" to a Ford not a Mercedes, for example.

2. You enter a VIN (or retrieve one from the engine computer, NOT the ACM), and...

2.a The CDR Tool software looks to see if the VIN format is correct: the "Valid VIN" check - meaning, for North American Vehicles, the check digit works for the remaining VIN digits/sequence. One can disable the "Valid VIN" check in the CDR Tool software and while that may be a good idea outside North America, especially for litigation in North America, it is not. This is also addressed in the CDR Tool Help file...

Vehicle Coverage and Non-supported Vehicles
The CDR program is setup to check the VIN entered by the end user against the list of accessible (covered) vehicles found in this Help file and checks to make sure it’s a "real" VIN meaning, in part, there weren’t any mistyped letters., After the VIN is entered the CDR program determines which type of air bag module is being readout. If the vehicle is not supported, after entering the VIN the end user will be warned by the program by way of a pop up box indicating "Vehicle not supported". A "real VIN" from a non-supported vehicle may be entered in the program and, in some instances, may pass the "real VIN" test not generating the warning but, because it is still not a supported vehicle, the end user will not be able to complete communications with or a readout from the ACM, ROS or PCM. (sic)

2.b The VIN is recognized as a "valid VIN" or we bypass the VIN check and the next step is: is the entered VIN an excluded VIN? Some OEMs, a good example is Ford, will specifically exclude a VIN sequence that identifies a vehicle they are not going to support. In another example, the VIN for a Land Rover might be recognized as a "valid VIN" but, since Land Rover (or Jag) are not supported by the Bosch tool, the software would return a "vehicle is not presently supported or incorrect brand selected" message. In either example, Ford or LR, the message is not a license to "spoof" a VIN and see if you get data whether or not it seems to have been "successful" in the past. And we're back to where...

Attempts made to retrieve data from vehicles built for markets the CDR Tool does not support by entering a VIN from a market it is built for (VIN spoofing) may result in inaccurate CDR report data translations and possibly incorrect or erroneous retrieval of data from the ECU.

Unless an OEM says "use this VIN for testing or as a substitute VIN for this reason," spoofing can return incorrectly translated data.

3. Assuming you get past the VIN aspect of the system checks, the next thing that has to happen is the CDR Tool Software has to "handshake" with the ACM. It would look something like this:

CDR Software: "Hi, I'm the Bosch CDR Tool software here's my ID, who are you?"

ACM: "Hey, I'm an ACM (or FCM, or ROS, etc) and my SoftWare ID (SWID) is $46 42 4D"

Then the CDR Tool software looks at a database to see if the returned SWID is on the "ok to retrieve data from" list. If it is, then the CDR Tool Software and ACM starts communicating and exchanging data and check values and we retrieve whatever the CDR Tool software is supposed to get from the ACM. But we haven't got to the translation part.

In the case of the Mazda3, I suspect they're not getting past the SWID check and no matter what VIN or cable or direct-to-chip wiring one tries, there won't be any data retrieved and if there was binary data, it wouldn't be something the CDR Tool software could translate so: no data translation report.

Look at how Toyota or Mitsubishi do the VIN/SWID thing. For Toyota, you can enter a frame number (an option for vehicles outside North America where the North American VIN structure isn't a requirement). Enter the frame number as all "0s" - it doesn't matter. It doesn't matter because (a) you selected Toyota (Lexus, Scion...) as the BRAND and (b) the CDR Tool software will try to communicate with the ACM as a Toyota-type module and then (c) go through the handshake which, for Toyota, is THE important step.

The SWID will identify the Toyota module type and part number and the module type and part number will (a) drive retrieval and (b) more importantly, drive translation into a data translation report. Some SWIDs specifically identify a Toyota module that does NOT have an EDR functionality and, when that happens, we see a dialog box in the CDR Tool software GUI that tells us as much. But once the data IS retrieved, then the CDR Tool software uses the ID/Part number to complete the data translation report. In that case, the VIN isn't important - other than to affirmatively identify that THAT data came from THAT car based on THAT VIN for litigation.

The point is: Toyota allows global retrieval of most of their modules and so to get around mistranslating data, they rely on the module ID not a VIN. Other OEMs rely on the VIN AND the SWID. Older systems rely on the VIN alone and that's where you can get into trouble with a potential bad translation (see above passages from the Help file). BUT, because the OEMs don't want spoofing, more are going in the direction that we see with, for example, Toyota and, I'm pretty sure in your case, the newer Mazda. It's not reading because that module is not supported and VIN spoofing, because it is a bad idea, is becoming less and less "effective."

[Stevn3]

Rusty I appreciate your reply, despite the patronising way its written. If this is the case, and I will follow up further with colleagues and any issue with Mazda, then Australia is effectively screwed with Mazda. Since the inception of Bosch CDR Tool 'surrogate' VINs have always, and I mean always, had to be used for Mazda. And given that Mazda is in the top 5 common makes on the Australia roads, there's an issue...

Again thank you for your response.

[Rusty Haight]

I didn't see patronizing, I saw information and explanation. What did I miss?

Point out one part of what I wrote that wasn't true, how you perceive it is up to you. If you don't like that I pointed out that you're not following the best practice laid out in writing in the software you're using, or that the OEMs don't endorse spoofing, that's on you.

The fact remains that the OEMs are working against spoofing and if the EDR component is "off" in OZ it's likely because of the improper practice of spoofing which can't be endorsed no matter how you feel about it.

[R.Botter]

The way I see it the value of the Forum is it gives us researchable information whether or not the recipient likes the results seems like it's sort of up to them but the reasoning and background information is where the value is.

[lelellelel]

Hi! Sorry to include myself into the conversation but I saw this thread and couldn't help to wander if you could help me. Long story short, we are the family of a victim of a crash. The victim was on a bike, going home from work, and the car involved was a mazda 6 from 2010 for European market. My in-law flew at least a distance of 60m and was killed on the spot. He was 43.

We, his family, are totally new to the Crash reconstruction world, and automobile world, to be honest. I don't even drive. So sorry for dumb questions, french accent and/or inaccuracy.
But we are super invested and want to prove that the guy was driving way above speed limit. He went free on the first trial, because of inconsistencies found in the process of data recovering, as you described. We have the Hexadecimal data, but the police nor the experts thought it was worth the try to send them to Mazda. New trial is in TWO WEEKS.

So, interestingly, this old model of mazda already had an EDR / ACM.
Experts were able to connect to it through CDR using an NorthAmerican/Canadian VIN for a mazda 6 2012 (n° 1YVH8CB5C5M33044), using Crash Data Retrieval Tool 19.4.1. Serial number was correct. Connecting with Electronic Control Unit was not possible, even with the right cable.
The ACM recorded two completed events with no Airbag deployment in either case.

As you described before, it obviously contained errors:
For both events, the data is the same for the seat belt status, and Occupant Size Classification, Front Passenger, stating that both seat belts were attached, and the occupant is 'not an adult'.
Our first issue is that on what we believe to be the event of the deadly crash, event nº2, it was not real: the driver was alone.
This data is really messing with the credibility of the experts reports.

On the other hand, Ignition cycles are consistent with circumstances, and the following parameters are different from event nº1 to event nº2:
Maximum Delta-V, Longitudinal (MPH (km/h))
Time, Maximum Delta-V, Longitudinal (msec)
Maximum Delta-V, Lateral MPH [km/h))
Time, Maximum Delta-V, Lateral (msec)
Time, Maximum Delta-V, Resultant (msec)
Time from Event 1ot 2(sec)

Sure enough, the main interest of the EDR are the speeds and what we have is, at -0,5s:

Event nº1
32MPH / 52km/h engine throttle 21% full

Event nº2
80MPH [129] km/h, engine throttle 49% full

So my question is, is it possible that the SYSTEM STATUS is not accurate but the speed is?
From Airbag Module Data Limitations:
•

Restraints Control Module Recorded Vehicle Forward Velocity Change reflects the change in forward velocity that the sensing system experienced from the point of algorithm wake up. It is not the speed the vehicle was traveling before the event. Note that the vehicle speed is recorded separately five seconds prior to algorithm wake up. This data should be examined in conjunction with other available physical evidence from the vehicle and scene when assessing occupant or vehicle forward velocity change.

Airbag Module Data Sources:
Event recorded data are collected either INTERNALLY or EXTERNALLY to the RCM.
INTERNAL DATA is measured, calculated, and stored internally, sensors external to the RCM include the following:
- The Driver and Passenger Belt Switch Circuits are wired directly to the RCM.
- The Driver's Seat Track Position Switch Circuit is wired directly to the RCM
- The Side Impact Sensors are located on the side of vehicle and are wired directly to the RCM.
- The Occupant Classification Sensor is located in the front passenger seat and are wired directly to the RCM.
- Front impact sensor is located at the front of vehicle and are wired directly to the RCM.
EXTERNAL DATA recorded by the RCM are data collected from the vehicle communication network from various sources such as Powertrain Control Module, Brake Module, etc.

Is it possible that the speed data are collected separately from the system status? Where can we find the wiring, and demonstrate they are separated, or a similiar case with a mazda 6 2010?
I just want to justify the speed and the speed alone.

The guy who killed him is now driving a Ford mustang shelby.
please help

[Rusty Haight]

First, the VIN used doesn't come back as a real North American VIN. The NHTSA VIN database reports it as a possible 2005 Mazda but also reports: "5 - VIN has errors in few positions; 6 - Incomplete VIN; 14 - Unable to provide information for some of the characters in the VIN, based on the manufacturer submission.; 400 - Invalid Characters Present" Either way, there are no 2005 Mazdas supported by the CDR tool. The bottom line is that after the brand selection, a near random set of characters was used as "a VIN" and, unless it was disabled, the warning dialog that this was "Not a Valid VIN" was ignored to move on to ultimately retrieve data from an airbag control module the software was not designed to retrieve data from so really, there should be no surprise that:

"This data is really messing with the credibility of the experts reports."

The software used, Crash Data Retrieval Tool version 19.4.1, is very, very out-of-date. Going back to the "Important Notice" on the top of the first page of the report, even if they used the older version to RETRIEVE data, it should be opened for translation in the newest version. And then one would wonder if it would still be translated the same way, assuming it was translated at all.

You gave us a glimpse of the data and correctly pointed out that "This data should be examined in conjunction with other available physical evidence from the vehicle and scene when assessing occupant or vehicle forward velocity change." which, in context, sould be interpreted to apply to the delta-V not the pre-crash data, however, most associate it with ALL the data. Looking at the last of the pre-crash alone is insufficient, "this data" either means, in context the delta-V or it means ALL the data in the translation report, not just the last of the pre-crash data.

But if you're asking, since there is the pre-crash speed, is it separate from the "System Status" data. It is, however, just because it does come from a different source computer in the car doesn't mean (a) it was captured the same way as it might have been in a properly supported module or that (b) it was later translated as it would have been for a supported module. Frankly, it might have been, but as the warning from the Data Limitations points out, just having translated data isn't enough. Each individual element has to make sense in the context of the crash.

So my question is, is it possible that the SYSTEM STATUS is not accurate but the speed is?

Maybe...but also maybe not. Many would rephrase the question as: "if this element is inaccurate, how can you say any of the others are accurate?" Apparently, there was "some" data in the module; "some" data appears to have been retrieved. Perhaps someone is using an out-of-date version of the software to circumvent later restrictions Mazda (or another manufacturer) has Bosch include to prevent this sort of thing. I don't have enough to go on here to say for sure. With VIN spoofing, you can't know what element or elements are accurate or inaccurate without testing THAT kind of vehicle in a controlled situation with control devices to establish what and how a given data element is recorded and then comparing what was retrieved and then translated against the control instrumentation and then explaining why some elements are translated correctly and other are not (if that's the case). If that hasn't been done, honestly, ALL of this data should be considered unreliable.

Each data element is, yes, individual. That said, they can be individually right or individually wrong. Digital data is binary: 1's and 0's. As such, digital data, by virtue of its binary nature, is either right or wrong: 1 or 0.

"Right or wrong" applies to how each individual element is calculated in a source module in the car...
right or wrong applies to how each individual element is communicated with the ACM...
right or wrong applies to how each individual element is captured by the ACM...
right or wrong applies to how each individual element is recorded by the ACM, and then, and here's the kicker:
right or wrong applies to how each individual element is translated by the CDR Tool software.

Every one of those steps have to be addressed when trying to use otherwise unsupported data no matter what country we're in. Just to say "we used some numbers and called it a VIN and then we got "some data" so that should be enough" is not enough.

I'm sorry for the loss of your family member but the police - no matter what country or what hemisphere we're in - have a duty to remember that they have the power to deprive people of their liberty, their freedom, their money, their way of life and that power has to be used fairly and judiciously. The concepts of fairness or evenhandedness dictate that we cannot fabricate "evidence" to prove a crime, we should be looking for the evidence of a crime as well as that which may be exculpatory. Spoofing a VIN is tantamount to making up what potentially becomes evidence and can't be allowed without extraordinary measures to prove its validity. Just because it's been done doesn't make it right.

From your post, I take it this was a pedestrian impact. I would be interested to know what the translated and reported delta-V was and was that consistent with a pedestrian impact? If not, this "data" - right or wrong - may have come from some completely separate event. In the context of the crash, I'd be interested in the speed limit where the crash took place. The distance you gave - 60m - is presumably from impact to rest, something known as "throw distance." As a rough estimate across a variety of different equations to find impact speed relative to throw distance, that works out to about 50-60mph (80-97km/h) as an impact speed which is, of course, considerably less than the one data point at 80mph you offered from the retrieved data. A "normal" pedestrian throw analysis approach to demonstrating the speed of the Mazda should be considered far more reliable than spoofed and unverified data retrieved from an unsupported airbag control module (assuming the throw distance is reasonably accurate). The difference is the throw distance analysis is the product of repeatable testing. Simply spoofing a "VIN" to get "some data" without underlying testing to verify its reliability as described has not.

[lelellelel]

Hello Rusty!

It's a Bike vs Car accident.
We completely agree with you, my bad for not explaining better that the two experts did two complete documents with a lot more analisis that only the CDR.
The experts never use the CDR alone, and all have examined the site or at least the bike and the car.

First, the VIN used doesn't come back as a real North American VIN. The NHTSA VIN database reports it as a possible 2005 Mazda but also reports: "5 - VIN has errors in few positions; 6 - Incomplete VIN; 14 - Unable to provide information for some of the characters in the VIN, based on the manufacturer submission.; 400 - Invalid Characters Present" Either way, there are no 2005 Mazdas supported by the CDR tool. The bottom line is that after the brand selection, a near random set of characters was used as "a VIN" and, unless it was disabled, the warning dialog that this was "Not a Valid VIN" was ignored to move on to ultimately retrieve data from an airbag control module the software was not designed to retrieve data from so really, there should be no surprise that:

My bad again, I copied it wrong:
1YVHZ8CB5C5M33044

The test were conducted:

• Expert nº1 in 2019 with a Crash Data Retrieval Tool 17.10.- established 127km/h and 15km/h for the bike. He did on-site measurements, 6 days after. Marks were visibles.
  V-Crash to reconstruct the scene.

• Expert nº2 in 2020 with Crash Data Retrieval Tool 19.4.1, he did on-site measurements with no marks on the road.
  Pc-crash to reconstruct the scene.

Both had the correct VIN for the vehicule, which is not supported by CDR. They used the VIN above, and another one who gave the same results, in both expertises.
Some sources mentionned that it could be an OEM protocol, i don't know where to confirm this info.

The problem is they get two very different results. The first one stated that 127km/h is correct, throw distance is 83m, the other one said it was between 51,5-61,5MPH (83-99km/h), and the throw was 60m. The car was parked in the middle of the road some 170-200m away. Expert nº2 his stating the same as you, data doesn't look very trustable, though he doesn't look either since he did a CDR introductory course certification AFTER doing his report on this case. From your results on the throw, I imagine you used the Searle formula which Expert nº2. One comment from other sources on that is that he didn't add the bike speed, is that correct/consistent with his results? Anyway he checked the possible scenari on pc-crash and the only way to have the bike between the impact and theb

They never say in their analisis if they considered him using the breaks after the impact. One witness saw him use his breaks, but after the impact. His windshield was completely shattered so he had to stop at some point.

At first we thought it was an accident, and we weren't even that mad about the driver. But after the EDR data + circumstances analisis from the first expert, which stated that the EDR recorded speed (127km/h) was consistent with his crash reconstruction, I admit we heavily reconsidered the compassion we felt at first for the driver. Also he will not have ANY CONSEQUENCES for his actions, even if he is recognized guilty on the second trial. The most he can get are months of probation, and maybe a fine. He's never ever going to jail. The only option is that he kills somebody else which is not something we wished for. He's already been free of charge once and he is living his best life for now.

Anyways, what we want is a certain understanding of the truth, not to fabricate evidence. It's our way of healing. What we are trying here is to be objective about the data, and understand how experts interpreted it because we already spotted a BIG error on the investigation and we became super suspicious of everybody's work and conclusions. As a matter of fact, the police and the experts stated that the backlight was off and it wasn't. They also said that this light being off was the cause of the accident, not the speed. But the light was on, as proved in pictures published by the press, so it had to be the speed. Or He wasn't looking at the road. We sticked to the speed thing His phone showed no activity at the time of the crash.

So thank you so much for explaining and we noted that 'spoofing' is not accurate enough to determinate the circumstances of the accident:

It's actually a Mountain bike vs Mazda 6 crash. At the moment of the crash, the victim was almost arriving after a 14km long road from work to home, he was just 2km away.
From the testimonies and his bike training, we know that he was biking at an approximative speed of 25-30km/h, so 15,5-18,6MPH.The bike was cut in 3 pieces, the rear wheel had been crushed, and the saddle and its support was detached from the bike frame, the bike frame tubes were cut bu the impact. Unfortunately, some cars drove on the bike parts so their final position doesn't give us much info. I wonder why they took the time to analize the bike and gave no conclusion more than 'it had been damaged'.

All the experts agreed that the marks on the car suggest an impact right at the back of the bike, they used a clock marking 12h type of drawing to explain it, which i'm sure you are familiar with, and give a code: 12FCAN2.

SPEED LIMIT
It was a straight road with two lines on this side, one on the opposite. They were big trees on the side, every 5-20 m which was the case on this side of the road, but neither the body or the car didn't touch any. They went straight ahead. The speed limit was 90km/h - 56MPH. But for this young driver (it's a different driving license with only 6 pts instead of 12) in france, the speed limit is a little less, 80km/h - 49,7MPH. He was 1min / 500m from home and started accelerating up to 129km/h - 80,1MPH, at -0.5.s. At this speed, if the data are correct, he is goign at 49km/h above his speed limit. For reference, at 50km/h, it is directly considered a crime.

ROAD CONDITION
It was at night, the road was a little bit wet because it rained that day but it wasn't raining anymore.

DELTA-V
This is beyond my understanding so if you could explain what i'm seeing it would be very helpful
I attached them in this post.

I will be super pleased to hear your comments about this case!

[Rusty Haight]

A lot to unwrap here...

(snip)
Both had the correct VIN for the vehicule, which is not supported by CDR. They used the VIN above, and another one who gave the same results, in both expertises.
Some sources mentionned that it could be an OEM protocol, i don't know where to confirm this info.

Whoever said this is wrong. Nothing more complicated than that. There is NO OEM protocol for VIN spoofing (other than in a narrowly defined testing process and surely not for litigation). I would reiterate this from the Bosch software:

Attempts made to retrieve data from vehicles built for markets the CDR Tool does not support by entering a VIN from a market it is built for (VIN spoofing) may result in inaccurate CDR report data translations and possibly incorrect or erroneous retrieval of data from the ECU. (-emphasis added because it should be...)

Downloads aren't "test" in the context of conducting an independent, instrumented test to validate the data retrieved. The data could be right, could be wrong, as I said: binary, 1's and 0's. Who is going to be able to explain the factual basis for whether or not the retrieved and translated data is correct. No one, short of someone from Mazda, is in the position to do that unless the ran separate documented, comparative tests.

(snip)The problem is they get two very different results. The first one stated that 127km/h is correct, throw distance is 83m, the other one said it was between 51,5-61,5MPH (83-99km/h), and the throw was 60m. The car was parked in the middle of the road some 170-200m away. Expert nº2 his stating the same as you, data doesn't look very trustable, though he doesn't look either since he did a CDR introductory course certification AFTER doing his report on this case. From your results on the throw, I imagine you used the Searle formula which Expert nº2. One comment from other sources on that is that he didn't add the bike speed, is that correct/consistent with his results?

I used more than the Searle equation. Using the Searle equation alone is a good start but the Searle model is one of several to apply to ped and bike crashes. But to just use the Searle model since it appears that's what the experts did here, the range of impact speeds across 262ft (80m) would be 60 to 72mph (97 to 116km/h) which is "closer" to the reported speed in your translated data set. But the other expert has the throw distance as 60m gives us 52-62mph (84-100 km/h). While both are over the speed limit, why the difference? You have to ask, could one be based on a distance chosen to better "fit" the retrieved/translated data? In other words, making the input fit the expected (desired?) answer? What we'd have to know as what is the real basis for the different throw distances? Across the larger range of some 28 variations of pedestrian/cyclist-related equations, the average speed calculated is 60 mph (97 km/h) and the range of speeds is from a low of 42mph to a high of 68mph (68 km/h to 109km/h). The Searle equation results fit within that group.

But let's say the data is fine, let's ignore the indisputable fact that the translation is, on its face, unreliable, and let's adopt that, somehow, the data met all the tests (I listed above) and was retrieved without issue. If the last reported speed in the data is 79mph (127 km/h) and the service brake state is "OFF" within that last half second, the car would seemingly have to have lost as much as 19mph (in less than half a second) to get down to close to 60mph as a function of either throw distance with braking that appears to have come on VERY close to or after impact. That's a lot to lose with no apparent pre-crash braking. Sure, there was reportedly braking at some point given there were reportedly tire marks but that seems like it was after the crash. So, based on the translated pre-crash speed, can we say that the car, by just taking the driver's foot off the accelerator, slowed by that much? Does that consideration square with the reported data? So, then we say the speed's ok, but all the other data points are not ok and, what's our basis for that?

Let's consider the delta-V. You asked for an explanation. "Delta" means change. Velocity - in whatever units, is speed and direction. If I have speed alone, that's a scalar or simple magnitude: "how fast?" Velocity means "how fast and in what direction?" So applied here, the delta-V means "how much was the speed either reduced or increased and in what direction?" The data you have shows that whatever this car hit slowed the car front-toward-rear (negative longitudinal delta-V) by -2km/h (-1mph). BUT it also shows that there was a lateral component of -1km/h (-0.6mph) which means it was acting right-to-left.

The first question someone always has to answer using reliably retrieved EDR data is: is this data from the crash we're working on? IF we adopt this is then it represents a car that ran up behind the cyclist, they're both going the same direction, BUT there's a right-to-left component to the overall delta-V which means, mathematically, that this wasn't a 12 o'clock straight-up impact, the impact acted more like it was coming from 1 o'clock (where 12 is simply straight ahead). Does that alignment fit the crash?

The appearance and magnitude of the longitudinal acceleration COULD be from a pedestrian/cyclist impact; it's low, fairly flat, but that doesn't explain a lateral component. So, IF the data was translated correctly using the spoof - which is not a foregone certainty - then the crash recorded is also not a plain in-line crash and the angle, no matter how slight, would have to be explained against the car damage or actual on-road alignment and then the reason for the significant difference in speed between the sample within the last half second before the module woke up and that calculated based on scene data. Even IF the data is to be considered reliable, there are too many things about it that leave it open to question.

[Jeksona27]

Hello,
I'm tried to readout CDR info from US Mazda CX5 2020 – JM3KFBCM7L0790653, device can read the vin from the vehicle but doesn't go further. it there somothing like putting can in diagsnostic mode or opening hood like on VW? any ideas? thanks

[Rusty Haight]

If the CDR Tool software can read the VIN from the vehicle, it's reading it from the engine computer NOT the airbag control module. "Not going further" is a little vague. What specific error dialog box are you seeing after you have done what next step?

[Jeksona27]

When you press "Collect Airbag Control Module Data" software says "No Interface" at the right buttom corner. It just happens on only all Mazda Models

[Rusty Haight]

"No Interface" has nothing to do with the car type, that means your laptop is not connected to the CANPlus interface. In fact, that error would show up before you try to collect data if you were to initiate the "check communication with the interface" mode.

The connection diagram would look like: Laptop - TO - INTERFACE - TO module (or through car to module). At each step, there's the potential for an error message. The error message you indicate is not vehicle or module-specific, it's interface-specific. You need to solve the computer-to-interface disconnect which usually means a comm port error as it relates to the CANPlus interface.

[Jeksona27]

With the same computer setup works an intended on all other Brands. I can share video indicating a problem, here is the link https://drive.google.com/file/d/1gsBbqt ... drive_link

[Rusty Haight]

Dribbling out information makes getting to the answer a little slower...

The video helps, it's not the car, not the manufacturer and not the airbag control module. As I previously noted, the software is looking for the CANPlus interface. In your video, you are not using the right interface. Look at the Help listing for this vehicle:

Help file listing for Mazda

You can get the VIN from the engine computer with ANY interface but trying to talk to the ACM requires the proper interface. The proper interface for this ACM is the CANPlus interface module. You're trying to use the CDR900 BUT the software is looking for the CANPlus to talk to the ACM.

The CANPlus requires a com port to function. Assuming you connect with the CANPlus, the software first looks for a connection to the CANPlus. If it doesn't see it, you get the error message noted: "no interface" because you have the wrong interface attached to the computer.

Try again with CANPlus.

[Jeksona27]

Thank you very much for your help!!! really appreciate that!!