Roland@pcmtec

The Gauge units are actually correct by the way. My Mustang reads 450mmHG at idle on the factory dash. Ford incorrectly use their units internally for MAP in all their vehicles. Obviously there is not positive pressure in the manifold at idle, its a partial vacuum, however Ford don't believe in negative numbers for MAP, so it is what it is. 540mmHg is 10.4 psi, -4.25 psig In the Falcon they use inHg as the default raw units for boost (IBP) and MAP. In their raw unadulterated form if you datalog these values you will see 10inHG or 5psi on the map sensor at idle, and 0 psi on the boost sensor (as its on the compressor outlet). Once on boost you will see 8psi (on a stock car) IBP and 22.7 psi on the MAP sensor. As this doesn't really make sense (but it does to Ford and still does to this day) we have since fudged the raw units of the MAP sensor to pretend that the native units are InHga, this means you'll see a negative value on your map sensor when in vacuum. Beware however that every single table in the editor that references the map sensor does not have negative numbers, so whilst it may make more sense in the datalogger, you'll now have to add 14.7psi or 101.325 kpa to any MAP referenced table (or change your datalogger units to be psia/inHGa and compare them to psi/inHG. Boost is not affected as this has always read what you see on an oldschool analog boost gauge, it also doesn't read negative due to where it is positioned. So we have just changed this so you will see -4psi at idle on the MAP sensor when selecting PSI, however if you need to reference this against a MAP referenced table (there aren't that may) you need to change the units to PSIA/inHGA. This might make you happier, but I guarantee it will confuse someone else who goes "why does my custom VE table start at 0 inHG/0kPa). You can't win here. If we get complaints or confusion about this we may change it back so that you will never see a negative MAP value. There isn't really a correct answer here and it is not possible to please everyone. Here is how your datalog will look now if you take a new one today. Just for fun, we left all the other DMRs alone in the Mustang so they match what you see on the dash and other dataloggers. MID57543 is is shared on the Mustang/Falcon. MID42519/MID02776 are not we are keeping these in the true ford spirit of "no negative numbers" with their raw native units as inHG (despite it not actually being inHG).

The best way to get any issues address is via support. Matt and Kirby no longer work for us, so most of your messages will not be read here or actioned. We have a laundry list longer than anything you have raised of improvements. Now I will be extremely frank here, the problem is not that we are unaware of bugs/issues/inefficiencies, it is that we do not have any resources to resolve them. The Falcon stopped being manufactured in volume in the late 2010s as such the Falcon product will no longer be updated beyond bug fixes as it is bordering on 20+ years old for many of the vehicles. If we were to continue developing/focusing on the Falcon, PCMTEC would cease to exist in a very short period of time. Simply look at companies like Nistune etc who focussed on one model of vehicle and did not move on, they all are now working part time or not at all. The suggestion about going to a workshop and watching their workflow is exactly what we do. Every 6-12 months we send 3 people to a workshop for a day with a modified car, return it to stock, then film the tuner tuning the car recording everything they do, all issues, workflow, bugs etc. These visits provide a list of items that could never be completed in their entirety; however we can resolve the low hanging fruit and any major bugs. These visits are done soley for the Mustang/Tricore platform however in 2022 (the last datalogger update) we did do a Falcon visit. For example the out of memory issues (this caused serious issues that could not be left unaddresed), we spent 12 months sourcing a new cable (OBDX) and an entirely new hardware version created (the OBDX FT with FEPS) as we requested it and spent many weeks back and forth resolving driver issues. We then spent a large amount of time creating a 64 bit editor/logger which was backwards compatible with x86 cables and machines. This resolved a huge number of issues with the Editor and Datalogger. Our statistics showed a huge 10 fold decrease in the number of crashes and shutdowns, bringing the number below 1%. The performance also increased dramatically. Next major issue, categorisation, naming, units, equations. With over 200,000 parameters we had to spend 12 months building an internal tool to do this efficiently, not to mention finding staff who can actually use the tools and have time to do so. The issues you bring up are real and acknowledged, however we simply do not have the resources to re-work the datalogger. The datalogger is a free product which cost in excess of $300,000 to develop. Software is incredibly time consuming, difficult and hard to build. We are a small team with a budget approximately 1% of HPTuners/SCT. They have 100s of developers, we have 3. They also have a 10 year head start on development (and revenue from a market 15x that of ours). For PCMTEC to continue to grow and exist as a company we must innovate in a larger market, eg the Tricore platform that is Global, Australia and the Falcon is a tiny market and it does not bring in enough revenue to fund a team to build software at scale like other companies do. The goal which is now partially realised is to fund more developers to address issues you have raised and build out loss leader features (eg the datalogger which is free) along with innovating a platform which a greater number of users use and is still being built and developed by the OEMs. The reception of this product has been phenomenal and we have a order of magnitude of users who can benefit from our Tricore CustomOS. Another other reason the datalogger is not at the top of the list is it is simply not used by our largest customers who do remote tuning via XCAL/NGauge/MyCal etc. They don't use the competitions software either, they use products like megalog viewer with CSVs and various other products. We must cater to those who are paying the bills and who will allow PCMTEC to grow and exist into the future. We have spent 1000s of hours working with customers to improve their workflow, many of our larger customers can produce a tune in under 5 minutes, then do revisions in 10-15 minutes maximum. This includes building a multi tune slot tune, using parameter templates, reviewing datalogs and many other features. This is what drives what we work on. For example the Tricore MultiTune wizard and parameter file system was wire-framed almost exclusively by Lund Racing, they received exclusive access for a period of time as a result and now everyone can benefit from it. If you find a bug that is reproducible (opposed to a feature/workflow request) please submit it to support. Workflow requests are also appreciated, however they need to be something that the majority would use. The video is great by the way, I just do not have anyone who I can assign it to at this stage. If it is an easy fix it will be addressed. We however absolutely do not want to break anything as a result of changing code that has been set in stone for close to 2 years now. So a 10 minute fix can become a 2-3 weeks R&D exercise due to QA and testing.

It looks like the only issue is the checkboxes are being deselected when you re-load the layout. If you can raise a support ticket for this that may be a simple fix when people are free'd up to look at it. Once checked all of the items retain the order and chart position from the TLO file.

Here are the Gen2 Whipple/Roush/FRP files we have in our stock database. You can view these via calibration tools -> Tricore calibration list. We do have a one or two FRP files for road vehicles, however I can't tell you exactly which ones these are as this information is not stored in the file.

Log Boost, MAP, RPM and load and you'll easily see if there is noise/oscillations on the signal. If it is bad enough you'll see the torque source go into OSC which is oscillation control, eg for manual cars where people stab the throttle in first gear causing the car to buck around. It will pull spark in the inverse direction to attempt to smooth the torque out. You can also see this with small turbo's that spool excessively fast.

There are offline and online sessions. If you load a layout then load a previously saved log, it will use the layout from the old log. As your new layout may lack the parameters from the old layout so it doesn't make sense to load it in most cases. Layout are designed to be created and saved when online and logging a car, not when offline. There is red text that says playback mode and online (I think) these are completely different sessions. Don't expect them to retain each other's sessions. Otherwise someone could send you a mustang log and it would wipe your falcon layout which would drive you mad.

Save a layout when you are live logging and see if that works as expected. If not raise a support ticket with the steps youve taken.

Yes what Puff said. The Z axis output is inferred load (the y axis of tuning correction) and the Z axis output of tuning correction is a multiplier to the speed density slope table. Effectively it will fudge the VE for a given throttle/rpm position to account for reversion/oscillations or any other variances in airflow that are due to mechanical characteristics. They should never be more than 5-10% at an absolute maximum. Any more suggests a mechanical issue, eg lack of fuel or poor pipework placement, unequal runners causing oscillations at certain frequencies etc. This is covered in more detail here

In the workshop edition we provide a full list of all strategies which you can compare. We also include common values so you can easily tell what is turbo/supercharged. The different injector slopes and average max load spark are dead give aways it is a turbo, along with the turbo logic switch being turned on.

Depends if the calibration was given a decent budget or not. If not it may be worse. Only real way is on a Dyno and with knock sensors Fairly sure you have picked a turbo tune also. This is not comparable at all. I highly recommend against willy nilly copying parameters or tunes. It will end badly.

Just for reference here is the Alpha N correction map. in a B series vehicle. Note that the axis is Inferred load, not actual load (as that would cause an infinite loop due to load being calculated via speed density). The inferred load is then calculated via this table. Obviously on a Turbo car your MAP (and hence load) is not static for a given TPS/RPM unless engine load/speed and practically everything else is static, so this is going to be highly inaccurate during transients and especially on turbo applications. Essentially a fail safe and a fudge factor for pressure drop across the TB/oscillations/reversion due to cam angles. Primitive and why Ford moved away from this in the Tricore platform (US vehicles 11+) where they model a delta pressure across the TB instead and blend the MAF signal with the estimated MAP/Speed Density calculation.

There is an inferred MAF value based on TPS and load. It is like alpha-N, very primitive and highly inaccurate for boosted applications in anything but steady state. Basically used when the MAP fails as as last resort. It is also where the inferred load value in the "Tuning Correction" table comes from, it is an alpha-N correction table. You can actually tune an NA vehicle with ITBs with no MAP sensor via these tables if you wanted to.

Yes we now have beta support for the later model ST and Ford RS Focus. This includes 15-17 ST and 15-18 RS. We also support F150 15-20, Ford Explorer, Maverick, Bronco, Taurus and many other models. PCMTec Vehicle Support - PCMTec. Support

Talk to custom machine works.

The scaling should be identical however if you've gone from NA to turbo you'll need to tweak the speed density due to increased back pressure.

Here you go. Appreciate your patience waiting for this, this is the first time I've had time to read the forums in a while (Christmas holidays lol), if you put a support ticket in and link the forum thread we will get onto these faster next time for you. Gen 2 15-17s (These use AD° / Count not pedal % FYI) auF46414 Automatically upshift at revlimit switch. auF46405 Upshifting allowed in SST when the pedal AD count is greater than this value Gen 3 18+ (These use pedal %) auF66680 Automatically upshift at revlimit switch auF67388 Upshifting allowed in SST when the pedal AD count is greater than this value These will get new descriptions with the next template update and recategorised so they are easier to find. Please keep these coming, we have over 130,000 parameters to categorise and currently we do it based on a "usage metric" eg how often people change a parameter. These are both relatively high in the list and would have gotten done reasonably soon, however if people ask we will do it as soon as possible. Also someone has done some hard work here mapping ECM IDs to auF IDs. They have some done some of the common ones, obviously the Gen2 and Gen3 are very different with the 6R80 vs the 10R80 so they have different IDs though. https://www.mustang6g.com/forums/threads/pcmtec.190584/post-3865944

This doesn't answer your question but it might help assist you with how the HDFX system works. This is a stock 18+ GT showing how the mapped points track. (I used megalog viewer HD for the pretty graphs) I also recommend using the following views instead of the individual tables as you can see everything on one screen

I missed this. The logic is still there as far as I know, it just does not work very well from what we have been told from various tuners (eg the process to get it to lock properly is confusing for many end users and it can lock on the wrong content). We highly recommend utilising our user flex logic instead, or ultimately using a flex fuel sensor. This will mean instant 0°C cold starts and that your extra timing is added immediately. You don't have to worry about it learning the wrong content and adding too much/too little timing and relying on the knock sensors.

Load is calculated via speed density. So your speed density slope and offset tables will need adjusting to suit the engines new VE. Being an NA motor with higher compression you are going to read more airmass (and hence load) at a given MAP pressure . Or you have a have the map sensor offset flipped (turbo logic negates the offset for some odd reason). Do you have a turbo cal or the turbo logic switch enabled?

Take your intake off and check the physical throttle. I've seen ones with holes drilled in them before. That or the usual oily gunk. Also smoke test your intake with the throttle open. If you have a leak post TB you will get issues, you can also diagnose this by abnormally low ignition timing (as the pcm is trying to correct for the airleak). Edit :you have cams. Cams reduce VE and require more throttle for the same torque. You usually need to tune the IPC tables to allow for more throttle for a given air mass or tune the speed density to account for the decreased VE at low throttle/rpm.

We've been told there a hard coded limit of 3.0 load in the Ford Focus. After some reading of the code we've found two limits that can occur in the Ford Focus. There is "MAF Sensor Saturation" (also used for MAP), and FSC "Fail safe cooling limit" along with several others. We believe you could simply calibrate this out using the following table. There is then a blended load limit from the following 3 tables. The following table then enables load limiting for various sources. You could disable the load limit some of these sources by entering a 0. 0 = Predicated Load 1 = LSPI 2 = Max Load 3 = Launch 4 = Popcorn 5 = Wastegate DC 6 = Injector DC 7 = Lambda 8 = FSC 9 = Turbo overspeed Finally if you don't wish to disable the load limit you may be able to use the load limit offsets defined here: ID Name Value auF50796 Predicted max load adder 0.3 auF50797 Predicted max load adder 2 0 These have not been tested however would be good starting points for anyone tuning a Ford Focus with a large turbo. If custom patching is required to bypass this limit then it is something we could look into.

There will be a PCMTEC interview coming out on the podcast in February sometime. Lots of random technical topics, you guys may find it interesting.

Flex fuel parameter files.zip Attached is a set of parameter files which include the default Ford OEM FFV tables and scalars. Simply untick "values" and press load/append on the base alt tune. You will then see many tables and scalars added You will find that you can simplify your flex fuel logic dramatically by removing many of these and only adding the required tables. Once you have completed building your flex logic in the wizard you will see new copies of the tables located here. These will be active in all tunes unless you have specified the same table/scalar in a tune slot. The PCM will then interpolate between the values in Base Fuel and High Fuel Tune 1 depending on ethanol content. Note: We have included an example 18 GT parameter file with the fueling tables used for cold start (please do not import the actual values as they will likely not be suitable for your vehicle), you can then add tables to add spark eg spark modifiers or simply use the cylinder pressure limit tables. Eg if the car is primarily going to be run on E85 you may be happy to simply use E85 torque and MBT tables and cap the spark via the max cylinder pressure spark limit. If you are going to be using various blends between E40-E70 you would likely want to add torque and MBT modifiers so that you get the maximum power without any torque errors at partial ethanol blends. e85 cold start parameters.xml

PCMTec Global CustomOS FlexFuel Select Reference Guide For CAN-Bus Connected Flex Fuel Sensor and CustomOS Configuration The guide contains the BOM and installation reference guide for the PCMTEC CANBus Flex Fuel System. To obtain access to the guide please contact support with your vehicle information https://support.pcmtec.com This guide is written for a RHD 18+ Gen 3 Mustang, however the general installation on Gen 2, LHD/RHD, Explorer, Focus, Maverick etc is the same. You will simply need to find an appropriate location to install the sensor. You also do not have to use a OBD sandwitch plate and could simply wire directly into the HS1 CANBus network, we recommend utilizing a fuse tap at a minimum to easily disable the ECA2 if you hard wire directly into the CAN network. 2022+ vehicles with an SDLC will need to wire in behind the SDLC directly to the HS1 CANBus network. We recommend utilising a fuel bypass for all return style fuel systems to ensure no flow restriction or interference with the fuel pressure regulation. On a return style system for lower power applications a bypass is not required but still recommended. Example of a fuel bypass for the flex fuel sensor. Example of a pre-wired kit for a RHD vehicle. Example of a fuse tap installed to ensure the ECA2 only draws power when the vehicle accessories are on. Example location of installation on the strut tower. Video guide of how to use the Custom OS Wizard to build your own custom flex fuel logic. Setup Notes: There is delay/lag logic to lag the canbus ethanol signal to allow purging of the fuel lines post filter. Under CustomOS in the datalogger you will see ethanol raw and ethanol. If the engine is not running you will only see ethanol raw update. Once you start the engine it will slowly increase the ethanol to the measured value over approximately 5 minutes with the default filter. If you wish to remove this filter (eg you have a return style fuel system) you can increase this value up to 1.0 (no filtering). ID Name Value auF100050 Flex Fuel High Pass Filter 0.005 However if you have a returnless system we recommend that you leave the lagged signal enabled and simply run the engine, this will ensure that spark is not added until the fuel lines/direct injection pump have been fully purged. The STFT will ensure that any fueling error is taken care of during this period. We found when testing on an 18 GT (with stock fuel system and DI) it takes approximately 10 minutes to purge the lines at idle, when driving it is purged within less than 1-2 minutes. We recommend that the first 10 minutes after a refill you do not drive WOT. Note that the lag only occurs when the ethanol signal is increasing, when decreasing it drops back instantly to ensure that ignition timing is dropped to the 93 level immediately. Alternatively you can simply unplug the canbus sensor (putting it into an error state) and manually set the ethanol content via the cruise control buttons using the following logic: Engine off Cruise control On Cancel (tune select) Cancel (ethanol select) +/- to select ethanol on the speedo. You can do this if you know the lines have already been purged. Then plug the sensor back in, this will manually disable the lagging of the sensor for that fill. PCMTEC Flex Fuel Logic vs OEM You can also piggy back off the OEM flex logic if you already have an OEM inferred flex fuel tune you want to use as a base. Note that we have not exclusively tested this method and recommend utilising the wizard to build your own custom logic with only the tables you require as this methodology has been tested on 100s of vehicles successfully.

We need someone with programming/scripting experience along with automotive nomenclature. It is a hard one to fill.