Roland@pcmtec

We aren't actively developing any new firmware for the Falcon anymore. It would be possible but it would be at a huge cost which we couldn't justify. Using the built in torque reduction as you found is your best bet. You can adjust how much spark retard is commanded as well via the torque requestors, min spark ratio for torque retard and finally the min spark clip.

Can you try pressing the + button to increase the decimals. Or alternatively check what the units are, it may be set to seconds with not enough decimal places. Set it to milliseconds with 2 decimal places and you should see a meaningful number.

Base spark is MBT + any emissions or other adders. It will use the lowest value of all the different sources from MBT, BLK etc + the adders. Basically you can assume this is using MBT when it says base. Check auF2727 "Base spark retard for NVH", there are also a few emissions tables that subtract spark, these can come into play in some calibrations (Most have them zero'd). If these adders are active then it will likely report the source as base. It can also report base spark when coming out of oscillation control, eg if you stab the throttle in first gear it will trim the spark to try and avoid driveline shuffle. It will then ramp back out of this mode. You might have seen tip in/tip out as the spark source prior to it saying base. The intermediate value you can datalog for the various spark sources are. MID90840 Spark Base MID91036 Spark MBT MID91051 Spark Base for NVH (noise vibration harmonics) MID90837 Spark Base for Anti Fouling (zero'd out in all cals I've seen) Also have a read of this if you haven't seen it before.

You can also visit the calibration list in the workshop edition to open/compare stock files that way.

It is not official policy but if you make a genuine mistake when licensing we have been known to refund credits on a case by case basis, especially if its for the same PCM. Eg if you license the F6 file and find its completely incompatible with your PCM hardware for some reason etc. Reach out to https://www.pcmtec.com/contactus and put a ticket in if you need to.

Fuel pump control I would imagine is the best place to start, you can modify the duty cycle table and limits.

Just for reference did you have to change any scalars to prevent a limp mode due to excessive torque converter slip? I had a look for another customer and the scalars that looked like they would assist with allowing a high slip ratio were the following (don't have the descriptions handy). ZF20435 ZF04082 ZF04084

We recommend the DLP 8 channel analog input cable. You can then wire in analog inputs and scale them using equations. Canbus based datalogging is something we have wanted to do for a long time but resources haven't permitted it. We are working on a canbus based flex fuel device for the newer Fords, as part of this we may add datalogging for other CAN IDs.

440 is tiny why are you running them? Why not just scale them yourself using a scatterplot?

Try them all! You could also contact ZF directly as well. They might share it with you (the adaption procedure)

Have 5 years of prior programming experience and either a bachelors in computer science or engineering. Most of us have 15+ years experience writing software. Darryl started in the 80s and you could say he has 40+ You actually don't need to know anything about cars to do most of what we do. Definitely helps if you do though!

@Kirby@PCMTec is going to work on giving those parameters some decent names and descriptions shortly as well.

Unfortunately Matt has moved on to another job so datalogger development will likely be halted until we can afford more employees. We will continue to fix bugs however there won't be any new major features in the short term.

Yes this must be done. This was a great find by hjtrbo. There are a few other scalers as well that set other ranges, however I assume they are there for good reason. The learning algorithm will expect temperatures to be within a certain spec. I suspect you could lower it to say 10 just as a test though. Absolutely brilliant work guys! Let us know how long it takes to re-learn with the temperature threshold set lower.

I did a bit of search and I reckon the following scalars might reset the learned data ZF02841 Prevent the deleting of the Adaptation data by the initial start (ON=1, OFF=0) ZF02859 Switch for activation of the EEPROM data handling EE_SPIEGEL 0=OFF, 1=ONLY START, 2=ON These likely are how fast it can learn ZF01162 Maximum permisisible change of the adaption value (mbar) ZF01162 Maximum permisisible change of the adaption value (timer) TSF I think is time ZF03011 Lower limit of TSF adaptation value for the clutch 0=A....4=E ZF03010 Upper limit of TSF adaptation value for the clutch 0=A....4=E PF I believe is pressure ZF02971 Upper limit of PF Adaptation value for the clutch 0=A ... 4=E ZF02972 Lower limit of PF Adaptation value for the clutch 0=A ... 4=E ZF02886 Switch for activating/deactivating the shift pressure adaptation, valid for CRC adaptation 0=Off, 1=On, 2=On+Initialization ZF02863 Switch to activate/deactivate the flare adaptation 0=Off, 1=On, 2=On+Initialization ZF02842 Switch to enable modification of shift adaptation depending upon stroke adaptation Then there are all of these They use adaptation and adaption interchangeably. Loads of stuff you could play with here.

8R29-7J105-DF_TCM_with BF serial.tec Try this. You'll need to license it as well. Enable recovery mode when flashing and it should stop the warning about mismatched OS etc. Note that I had to do this manually, the editor normally blocks you from merging the serial in (for good reason). The trans should go into limp mode once that file is in, I'd power cycle everything, then put the correct file back in using recovery mode and then check the adaption values.

@Billthat file you attached is that with the serial of the TCM you are trying to flashing? If not can you send the licensed TCM file you are using currently in the bench PCM and I'll make a file with the wrong calibration in it but the same serial, that is all you really need to do to make it flash.

Yes just doing a recovery write should fix anything.

Just the calibration which causes the OS to freak out and go into bootloader mode (due to OS and Cal mismatch). Usually this corrupts the KAM as different operating systems align the KAM memory differently, then after recovery the KAM is reset (this happens in the new Ford PCMs). This is a hacky way to do it but it might work. I don't like to give guarantees, but back in the day we allowed it (not on purpose) and it was always recoverable. Worst case the whole OS/Cal can be recovered via KLine and one of the guys with the ZF flashing software.

Attach your file here and I will give it a go.

I think there is a bypass for that. It will "brick" the tcm but it will recover just fine. I think we allow editing the part number on 3.00 also (there is no good reason to do this except for what we are trying here) If you do recovery mode flash with the ZF without licensing the file it should prompt to auromeege the serial. I think it will slip the part number and go on.

One that's worth a shot is flashing a BF strategy into an FG or vice versa then putting the original os back. In most modern Fords they reset the KAM when that happens.

Yep so check these values. Then try and "reset" them. Then datalog again and they should be back to 0 before you start the car, then they will slowly learn back to what they were before. There are various adders for how fast it can learn forwards and backwards. It doesnt really make sense for a clutch to get better, hence why when you put a new box in they dont like to unlearn the wear. I'm sure there are some PID gains you could adjust to speed up how fast it learns in the reverse direction.

Ignore will hide any cells with a cell count < "samples". Filter will drop any samples from the bucket where the standard deviation is outside of "std dev". Standard deviation is very useful to determine if you have highly non correlated or bad data. It is also great for filtering out noise due to transient data or slow logging rates. I did a write up on it here a long time ago. https://forum.hptuners.com/showthread.php?58174-Custom-graphing-software-for-logging-fuel-trims-and-recalculating-speed-density-maps Basically the short of it is your Z data should be highly correlated with your X and Y data, eg all the values collected are roughly the same, eg the min/max are very close together. If you had 1000 samples within a specific cell, all are roughly 0->0.1 and then 20 random samples is 1000 due to a sensor fault, the 1000 would have a huge standard deviation and the value would be dropped. This would also be excluded from the average value calculation. https://en.wikipedia.org/wiki/Standard_deviation The number at the bottom is the standard deviation. So if you want to drop transient data from your log and only use the steady state data you might use a tight standard deviation of 1. If you want the extreme min/maxs you might go as high as 3.

If someone in SA loans me a ZF falcon with high kms and a box that is heavily worn for a week I will figure it out. Until then we need sometime in the community to datalog the adaption values that hjtrbo found, try the various suggestions and report back. I've never tried but it might be possible for us to directly write to the dmrs used for adaption. I suspect they will be overwritten by kam on startup though.