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.
Here goes info from LR web site: "This latest generation of the M-Tune has some software and hardware enhancements that make it even better then ever. With Open Maps and Tables for example, now anyone with a EEPROM burner, or Ostrich Emulator can tune the DME's maps & tables with this new generation chipboard. With 2 times as often ignition timing calculations, MAF and MAP sensor sampling 2-1/2 times as fast, logging rate increases by 27%, barometric reads on start up, expanded FQS range for fueling percentage changes, and over 56 available maps and fabricated satin black power coated aluminum plumbing... you can see this latest M-Tune offered by Lindsey Racing has set the bench mark very high."
This will make the odd data exposed by OBD+. Now, we don't want to begin a war on this... Will look deeper on my side. Will try to create a map from LR tables on a Ftech bin file... Thanks to Ostrich2 !
The OBD+ system is completely independent of the installed chip or chipboard. The specific chip that is installed has no control over the flywheel sensor circuit other than to "arm" it to trigger on the the next TDC mark event. Because of this, changing the chip (be it Rogue Tuning, Linsey Racing or Vitesse Racing) should have no effect on flywheel sensor the data that OBD+ reads out. That said, a third party program could decide to only arm the TDC reference every other flywheel rotation. This would cause the OBD+ system to double count the total number flywheel teeth. After the engine starts you could actually disconnect the Mark Flywheel Sensor and the engine will run entirely off the RPM flywheel sensor, so in theory this could be done. As for why you would want do do this I could not venture a guess, but engineers generally have their reasons. If this is the case, I can add a configuration setting to account for this.
One way to test this for sure is to install a stock chip and see if the OBD+ system counts the correct number of teeth. I don't see anything wrong in the code, so my guess is it will read correctly.
The OBD+ system is completely independent of the installed chip or chipboard. The specific chip that is installed has no control over the flywheel sensor circuit other than to "arm" it to trigger on the the next TDC mark event. Because of this, changing the chip (be it Rogue Tuning, Linsey Racing or Vitesse Racing) should have no effect on flywheel sensor the data that OBD+ reads out. That said, a third party program could decide to only arm the TDC reference every other flywheel rotation. This would cause the OBD+ system to double count the total number flywheel teeth. After the engine starts you could actually disconnect the Mark Flywheel Sensor and the engine will run entirely off the RPM flywheel sensor, so in theory this could be done. As for why you would want do do this I could not venture a guess, but engineers generally have their reasons. If this is the case, I can add a configuration setting to account for this.
One way to test this for sure is to install a stock chip and see if the OBD+ system counts the correct number of teeth. I don't see anything wrong in the code, so my guess is it will read correctly.
- Joe
Happy 4th of July !
If you look at my video, I do switch from your bin to LR bin. LR makes OBD+ to display double counts. I will run a test with your chip (I lost the original somewhere) . I don't like to change chips often on boards as this might damage the socket, Ostrich2 is a perfect EEPROM emulation tool. I was able to look at the difference between your bin to LR's and there are a lot. Note that Ostrich chnages the code on the fly. No need to reset the ECU.
I also have that vehicule type that shows "unknown" since the beginning... Could this be a problem with the switch ?
I will do a live test in my car to have more realistic data on this. Having 2 laptops in my car is quit chalenging considering the free room I have .
If you look at my video, I do switch from your bin to LR bin. LR makes OBD+ to display double counts. I will run a test with your chip (I lost the original somewhere) . I don't like to change chips often on boards as this might damage the socket, Ostrich2 is a perfect EEPROM emulation tool. I was able to look at the difference between your bin to LR's and there are a lot. Note that Ostrich chnages the code on the fly. No need to reset the ECU.
I also have that vehicule type that shows "unknown" since the beginning... Could this be a problem with the switch ?
I will do a live test in my car to have more realistic data on this. Having 2 laptops in my car is quit chalenging considering the free room I have .
Thanks,
Charles
Hi Charles,
Sorry, I did not see the video until just now. No need to swap in the chips, you already proved the theory I had in the video by swapping the binaries using your Ostrich/TunerPro setup. I definitely agree, based on what you are able to do with it, the Ostrich/TunerPro is very powerful. However, don't forget to give credit to Josh over at Rogue Tuning. Without his efforts, skill and generosity in creating the free DIY setup for TunerPro the Ostrich programmer would be useless on the 944.
This issue is really not a any kind "fault" in the Lindsey Racing code, this is only a problem now because the OBD+ system is monitoring the signals. One could debate over whether or not is necessary to resync the TDC position on every engine rotation, but this point would be purely academic. The fact is they did it, it works and there are countless Lindsey Racing chips out there. From my perspective, the only course of action is for me to update my software/firmware to be compatible with how Lindsey Racing implemented their flywheel sensor schema. I will start working on an update now and let you know when I have something for you to test.
If you look at my video, I do switch from your bin to LR bin. LR makes OBD+ to display double counts. I will run a test with your chip (I lost the original somewhere) . I don't like to change chips often on boards as this might damage the socket, Ostrich2 is a perfect EEPROM emulation tool. I was able to look at the difference between your bin to LR's and there are a lot. Note that Ostrich chnages the code on the fly. No need to reset the ECU.
I also have that vehicule type that shows "unknown" since the beginning... Could this be a problem with the switch ?
I will do a live test in my car to have more realistic data on this. Having 2 laptops in my car is quit chalenging considering the free room I have .
Thanks,
Charles
Hi Charles,
Just an FYI from your previous video:
For the OBD+ parameter "Vehicle", this a part of the Automated Flywheel Diagnostics feature and is based entirely on the number of teeth counted on the flywheel starter ring by the RPM Flywheel sensor. There is no relationship to the "Ignition Mode" selection switch on the SPORT DME.
Sorry, I did not see the video until just now. No need to swap in the chips, you already proved the theory I had in the video by swapping the binaries using your Ostrich/TunerPro. I definitely agree, based on what you are able to do with it, the Ostrich/TunerPro setup is very powerful. However don't forget to give credit to Josh over at Rogue Tuning. Without his efforts, skill and generosity in creating the free DIY setup for TunerPro the Ostrich programmer would be useless on the 944.
This issue is really not a any kind "fault" in the Lindsey Racing code, this is only a problem now because the OBD+ system is monitoring the signals. One could debate over whether or not is necessary to resync the TDC position on every engine rotation, but this point would be purely academic. The fact is they did it, it works and there are countless Lindsey Racing chips out there. From my perspective, the only course of action is for me to update my software/firmware to be compatible with how Lindsey Racing implemented their flywheel sensor schema. I will start working on an update now and let you know when I have something for you to test.
- Joe
Hello Joe,
Ok, will consider double tooth counts as normal.
Dave Lindsey took over Josh work as he was looking very busy with his growing family (info from web channels... Might not be the case). But using all these tools are excellent ! I still have issues with rough idle and other unstable engine status. My mechanic asked me to review all wiring on both KLR and ECU. My ingectors are 80 lbs/hr... According to my mechanic, this is to much.
I still have that vehicle type "Unknown" ... Problem with the switch ?
For the OBD+ parameter "Vehicle", this a part of the Automated Flywheel Diagnostics feature and is based entirely on the number of teeth counted on the flywheel starter ring by the RPM Flywheel sensor. There is no relationship to the "Ignition Mode" selection switch on the SPORT DME.
Regards,
- Joe
Ok,
Thanks, will look at this with a stock bin file in Ostrich2. This will eliminate the reference sensors from my test list.
I have a bunch of test to run... Excluding MAP sensor, looking for bad grounds, bad connections, etc... So much to eliminate.
Pressure leak is out of the list since last year, I pushed 20PSI from the MAF, no leak at all. All pressure in the cylinders are 155 to 165 PSI.... Looks fine to me...
The main update is not too exciting. It has a new firmware updater to support a different microcontroller due to the global chip shortage. This new firmware updater is not dependent on the mfc120.dll, so installing the Microsoft Visual C++ 2013 Redistributable (x86) should no longer be necessary.
More relevant to you, this release also has a firmware update that "might" fix the Flywheel Sensor issue with Lindsey Racing chips, but I have only tested it on a stock program. Go ahead and install it, then allow the firmware to be updated. Hopefully everything works as it should.
The main update is not too exciting. It has a new firmware updater to support a different microcontroller due to the global chip shortage. This new firmware updater is not dependent on the mfc120.dll, so installing the Microsoft Visual C++ 2013 Redistributable (x86) should no longer be necessary.
More relevant to you, this release also has a firmware update that "might" fix the Flywheel Sensor issue with Lindsey Racing chips, but I have only tested it on a stock program. Go ahead and install it, then allow the firmware to be updated. Hopefully everything works as it should.
-Joe
Ok,
I installed it and upgraded the firmware. Will give you some news on the LR flywheel sensor.
I just pushed v0.11.153 to the website, it has a beta version of the Live Sensor Graphs for everyone to check out! For the moment, only four sensors are displayed and they cannot be changed. The next phase is to allow completely arbitrary selection of up to four sensors. Below is a screenshot I just took while revving the engine on my 944:
I just pushed FocusOBD v0.12.155 to the website. This update adds a scaled Engine Coolant Temperature Sensor (ECT) in both Fahrenheit and Celsius. You can select your preferred units in the Setting Tab (Gear Icon) in the "Units" group.
Note that this new feature will not work with Beta OBD+ modules. If you still have a Beta OBD+, please send it in for a free upgrade.
Engine Coolant Temperature now Scaled to °F or °C. User selectable °F or °C in setting tab.
I just pushed FocusOBD v0.12.155 to the website. This update adds a scaled Engine Coolant Temperature Sensor (ECT) in both Fahrenheit and Celsius. You can select your preferred units in the Setting Tab (Gear Icon) in the "Units" group.
Note that this new feature will not work with Beta OBD+ modules. If you still have a Beta OBD+, please send it in for a free upgrade.
Engine Coolant Temperature now Scaled to °F or °C. User selectable °F or °C in setting tab.
I have another update, this time I scaled the Intake Air Temperature sensor (IAT). Like the ECT (Engine Coolant Temperature) sensor, you can select the units in Fahrenheit or Celsius.
This is a big step forward to supporting MAF sensors! I now have the math equation to change the factory IAT voltage into SI units and back again. On the math side of things, I now have 3 of 5 equations I required to move into bench testing.
Here is a screen shot of the new scaled IAT sensor:
07-04-2021, 11:11 PM
.
