Kirby@PCMTec

Request duly noted.

This was a guide I wrote as an example of how it *could* be done. its not the way it must be done. we expect every shop to come up with their own preference based on the car type, fuel system type, packaging etc. The key part is that you have a compatible Flex to CAN converter, that is configured correctly and is connected to the correct can-bus so we can receive the messages at the PCM.

Just a note for anyone that is interested in this and runs off and buys a ECA-2 from Zeitronics. You will also need to buy their serial cable adapter (and a RS232 port or USB to RS232 Adapter) for a one time programming of the CAN ID of the device. AEM make an acceptable OBD sandwich plate that just breaks out the can-bus - this is suitable in this case because we source the power from the fuse tap in the above document. When they went from PFI (Gen2) to DFI+PFI (Gen3) there was a big behind the scenes change, not just in hardware. The Gen2 fuel model was more-or-less in-house code, which had been progressively built up since probably the EEC-V days - but realistically has a lot in common with the CopperheadB Gen1s. In some parts of the assembler we can see similarities or variables that we even had here in the "Australian" PCM's from 20 years ago. Gen3 represents a huge departure in the fuel/spark model as to implement this Ford started to use, what appears to be, somewhat "off-the-shelf" software models provided by Bosch, which means all new parameters and tables, and the code is quite different - as is the order of execution. Effort has been made on Fords' part (probably to save the sanity of the calibrators there) to create tables which somewhat align in function to the old PFI tables, in name etc, but the way we identify them they look completely different to us hence the different ID's.

Its not that straightfoward, they probably are in the template them because technically they "exist" in the calibration, and our tools detect and map them. But just because they exist - doesn't mean they are actually used in the code. If its fuel or spark in Gen2 > Gen3 there is alot of "leftover" code that exists but is never used - its why they are probably zeroed out. There seems to be significant differences in the flex implementations between the f150 and mustang. Honestly, the best option is to disable the ford flex logic and use ours from CustomOS - its about 100x easier.

@bankyf it is auF61902 - "PFI injector offset temp. modifier" as it only applies to the PFI system. Temperature sites are the same, but for some reason we have its unit set to temperature (Celcius) and for it to display correctly the Z data type must be set to Celcius (if you've globally changed to freedom units - it might not display correctly - there seems to be another display bug here I need to look into). make sure its set to deg C in the context menu: Looks like Slope Compensation (auF61903) is similar (and set to 1.0x across the board) I've made a note - and I will fix this shortly (but I am going to have to ask the template team) - I am sure there is some weird data-type conversion that our automated tools have messed up. I think we have said it a thousand times, we have something like 100k parameters in the database, we rely on automatic tools to find and categorise these in every OS. And then we loop back and manually fix it, but it can be slow going - threads like this definitely help us identify "parameters of interest" Teach a man to fish part: 1) Make sure development parameters are turned on 2) I searched for the terms "injector temp" 3) Because its a gen 3 there are two fuel systems in play (DFI and PFI) so the PFI terms were of immediate interest to me. 4) then I looked for tables that had a similar axis and worked back: NB: I suspect the other two terms "Injector Offset Correction as a Function of Temperature" auF30313 might be from the Gen2 (PFI only) code which still exists in the PCM and *may* not be used, or may be additional Ford modifiers ontop of the bosch sub-system for fuel injection. Cheers and have a great weekend.

From memory these are workshop only MIDs'

Hey Guys, Just a quick note to say sorry for all the spam and subsequent spam notifications on the forum. Someone decided to give us alot of grief on pcmtec.com signup - just to post nonsense on the forum - often quicker than we can delete it. We keep making changes, but sometimes they are still sneaking through. Bear with us - we will fix it. Cheers Guys

Hey @Austen Did Roland's advice help? did increasing the decimals fix your issue. I will check and see if we can add a default in for that level. Thanks

Hey Guys, We have just deployed our brand new support portal. It links together several services that have previously been separated. This will improve support for everyone. Available via support.pcmtec.com (and all associated links) Change Log: You can now login using your pcmtec.com login! New searchable knowledge base, which combines our FAQ, User guides and forum articles (we are growing this slowly) New ticket form for submitting tickets New portal for viewing all your ticket history ever (we will be bringing over historical tickets in the future) Please check it out feedback (and patience if there are any issues) is always appreciated. Cheers

Hey Guys, As I go through renaming and brushing up my technical German, here are the parameters that are particularly related to "Fußpunktadaption" (e.g. base adaptation). Temperature: Upper - ZF00026 Lower - ZF00027 Current - (Fuß > Base) - so Base current, TID: 001022 Upper - ZF00326 Lower - ZF00327 ZF01002 - Adaptable Base Current Torque: Upper - ZF02213 Lower - ZF02214 TCC/Turbine Speed: Upper - ZF02441 Lower - ZF02442 RPM: ZF03892 - Maximum permissible control deviation Time parameters of interest: ZF03229 - Time in which to adapt (possible drive time, or limit of running adaption) ZF03230 - Preparation time for soothing (possible hysteresis or settling time) ZF03231 - Time for switching on the switch point (possible drive time?) ZF03113 - Load free must be passed (possible timer for an idle time before/after adaption) TID of interest: TID002456 - Status value of the base point adaptation (so maybe a status flag of adapted/not adapted) TID000916 - Flag of the setpoint being applied (I think this might be a flag for "adaption in progress") TID002212 - Adaption Time Counter (possible relation to the timers above) TID002481 - counter adaptations (possible number of adaptation cycles performed) TID002482 - counter TCC activations For guys playing around with this, might be worth having a look at some of these TIDs and see if we can gleam anything.

The real testament will be getting to a stable adaptation value (over say 100km) then resetting it again, and doing a similar cycle and seeing if you adapt to similar numbers again...

And this has survived a power cycle with ZF02859 set to 2? Would be interested to know how much time/driving is required to see other values start to populate.

Sorry this is my bad. I recently did an update on the website and this page was not updated correctly. It's all fixed now. Downloads page is only available to registered customers who have purchased a products, this page now contains that information. As @Roland@pcmtec mentioned, the demo is no longer available.

Like all things there is lots of ways to skin a cat, the best thing about the CHT method (which we discussed in the office) - was that you can stage it, and by default the first stage adds a bunch of fuel - adding cooling and reducing your power. In the event of a entire LoS of oil pressure or fuel pressure a straight engine kill might be useful, but it might also be incredibly dangerous depending on what speed/gear/corner you are turning.

Hi Everyone, It's come to our attention that @2X044 was having some issues progressing and accessing these parameters because they were not available outside of the Workshop Edition. The staff here at PCMTec HQ is impressed with the progress so far and to keep this project moving and assist in bringing this idea and product to market we have upgraded @2X044's PCMTec account to One Car Workshop. We are happy to support the work they are doing and the possibility of bringing something really useful to the community. Keep up the good work!

I think at the end of the day, if you are getting to a point where you are wanting to force a shutdown - a high temperature gauge is probably not a bad thing to snap your attention. I will look and see if I can find out how the CHT is calculated and if there is any hysteresis term we could adjust.

Yeah I already have renamed it and updated the description. Next time there is an update it will be under "Miscellaneous" in the editor.

So we had an interesting ABS issue come up recently with two sperate cars. Basically there appears to be a FG build in the wild which what I would call a "Police Special". Apart from the normal police enables, this has a very particular strategy and ABS config. 1) The engine is a 'normal' FG engine build 2) ABS is set to F6 / Force 6 - 4Pot (19-01-01) 3) Unclear if the car was fit with the larger 4-pot or not at build time. 4) Strategy is HAEDLG7 - we have only ever seen it on these "ex police" vehicles. Problem being is that this particular strategy also needed the upgrade to the HAAE4 strategy for our CustomOS. When you did this - the ABS would fault. Essentially the ABS then became aware that the car was not using a F6 Strategy (or in this case, this special police hybrid). The upgrade to a F6 strategy was off the cards due to the engine differences (engine, turbo, injectors) without a whole bunch of time spent copying parameters and giving it a run on the dyno to be sure. So how do you fix it? The first option is to reset the ABS unit to the standard XR6T variant (19-06-01), but if you are running the larger brakes (4pot or 6pot) this is not ideal because it will not be using the appropriate ABS calibration for that package, additionally this requires FORSCAN and knowledge on how to use it. Second option is to figure out how the ABS knew that the PCM was not a "F6" PCM. We knew this was being communicated from the PCM somehow, but we had yet to identify a parameter in the PCM (if any) which was identifying this difference. Well due to the excellent work of @jakka351 and some time spent comparing stock files in PCMTec, we landed on the following information: - In the engine configuration frame that is sent on CAN, along with cylinder count, displacement, also contains a "peak engine torque" value. - Some anecdotal information said that for a Ford this value was always 0x82, and for a FPV this value was always a 0x8A - Doing some in-depth compares between known F6 strategies and normal strategies as well as the information on this CAN message led us to the parameter : auF12105: "Engine peak torque for SCP". This is a development parameter, and therefore only in Workshop Edition. Current Understanding is as Follows: Essentially this parameter is "130" (0x82) on all normal strategies - be it I6, V8 or otherwise. and "138" (0x8A) on all the F6 / FPV strategies. The name and allocation in the CAN frame is a misnomer, its not actually peak torque value. (I will look at renaming this in our database in the future for clarity.) When we set this value to 138 in the normal strategy with the F6 ABS, the error was cleared and we were able to proceed with MultiTune on the car, without having to change the ABS setting back to XR6T. Why is this important? Well first off it shows us the value of some of these development parameters that we continue to explore and learn about, but more importantly, it means that if you are doing a brake upgrade on a non-FPV car, you can now run the ABS in the correct setting for that brake package and ensure you don't get any warning lights / ABS no bueno. Cheers

Using those parameters above you can really manipulate the whole setup, I wouldn't think emulation shouldn't be a problem. Likewise in your original spec: 1x 0-10k variable resistance (to ground) would be a sufficient output driver to the CHT input on the PCM - because the original input is just an NTC (so ADC with some fixed pullup) you don't really need to worry about input impedance or anything - your variable resistance output could be a pretty straightforward design. You can also adjust auF1316 to be linear or whatever curve you output, which is similar to the way we approach using the rear O2 for flex input. While switching works (e.g. pull low, or via another resistor to land in the right region), you miss potentially being able to use the "three-step" warning which is set by those parameters (E.g.): -Temperature Light On -Temperature Light Flashing + Fuel Adding -Engine shutdown (after 15s) Then you could potentially determine your warning type based on input and decide how you want it to interact with the end user. E.g. Fuel pressure straight away into fuel adding mode to try and prevent lean-out and shutdown in the case of a FP failure Warning only if you have a low meth level or meth controller fault @hjtrbo's idea of manipulating the flex input is not a bad one, you could also use just "dual map" with switch input. But again this is not for BlackOak (BA) PCM's which don't have a rear-O2. I think if someone developed this product and had a use case for adding some custom logic in CustomOS for a simple map switch based on some parameter config for a failsafe map, we would give it real consideration to add in development. The Falcons using factory PCM's have needed something like this hardware for a long time, so we are happy to support it because it is complimentary to what PCMTec does...

Ah cool to see someone finally working on this! @2X044, not sure what toolchain you are using for the feather. But if you are looking for something a bit cheaper/flexible with integrated CAN check out the ESP-32. This has a SJA1000 on silicon, so the addition of a cheap tranciever will have you up and running in no time. The added benefit is you can use the inbuilt wi-fi to host a simple website for configuration. Being able to easily change config without special tools or complexity is the real important part of the solution. If you don't want to use IDF, the Arduino shim layer is probably sufficient for the level of complexity you are after. You should be able to implement the failsafe with a minimal amount of hardware. You would need one 0-5V ADC channel for a 100psi fuel pressure sensor, one resistance based input for the existing CHT. A single resistance output to emulate the signal back to the PCM (depend on the full scale resistance of the OEM CHT - or if you can determine the internal pullup in the PCM modify the curve to however you need). auF1361 is the calibration curve for the standard CHT in ADC counts. (10 bit) auF1544 is the set point which will illuminate the warning light (engine hot) auF1870 is the set point (degF) to start dumping in fuel for cooling e.g. CHT CRITICAL. (warning light should start flashing) auF11960 is the timer after which CHT CRITICAL is entered that the engine will shutdown with a CEL (never tested this) auF10259 is the set point above auF1870 where a sensor failure is determined (e.g. non plausible). So you can't just peg the sensor to say 0v without potentially tripping this value. Basically you want to emulate an input to the EOT pin which provides a temperature above auF1870 and below auF1870+auF10259 (or change these to suitable values). Then the logic in your device is: if fuel pressure < threshold, for some time then set CHT emulation output to some value to trigger FMEM else set CHT emulation output to CHT reading input Keep going, the market is totally ready for this product + whatever other features you could include.

yep saw this in your uploaded log, oddity...but its being fixed now. Thanks for bringing it to our attention.

Hi Rob. I have responded to your support ticket, but I need the editor logfiles, not the datalog files. If you could please send them via the help menu. Thanks

That is interesting. From memory MID36175 is in us not ms, so I think the value you are seeing there *might* be out by a factor of x1000. Could be an equation issue.... can you please go Help > Upload files to support > Upload editor log files to support from a logging session that is looking at this channel. Can you compare this value to MID36178 (Bank1 Injector Pulse width) and send me another screenshot to support@pcmtec.com?

MID42591 is injector duty expressed as an absolute value (0.0>1.0) you can convert it to a percent, by disconnecting your session (press vehicle), then you can change the units from absolute to %, then reconnect to the car (press vehicle button again). Also have a look at MID42654, this will tell you if the PCM is commanding the injectors above 100% and you are clipping.