Roland@pcmtec
-
Posts
2,341 -
Joined
-
Last visited
-
Days Won
468
Content Type
Profiles
Forums
Events
Posts posted by Roland@pcmtec
-
-
The raw assembly is:
map in inches of mercury = map slope(ayF0037) * map voltage + map offset (auf0038)
eg map (inHG) = 15.983 * 0v + 0.4864 = 0.4864 inHg
Yeah it is absolute referenced, but Fords equation has a + not a subtract hence its a positive number.
Then for the boost sensor they use the opposite and you get a negative number (it caps at zero due to location). But Ford define both as inHG.
IBP (inHG) = 15.983 * 0v - 0.4864 = -0.4864 inHg
If Ford had done it correctly they would have set MAP as inHGa and IBP as inHG but they didn't. Then to confuse everyone they use inHG for the desired boost table, but they also use inHG for all MAP referenced tables.
2 minutes ago, hjtrbo said:That's fine. I'm my simple little head boost = map - baro (0 floor). . Not sure if your earlier screen shot is in error with a 2ish psi gap. Perhaps I haven't put my earliest comment across correctly?
2psi pressure drop across the intercooler.
-
1
-
-
8 minutes ago, hjtrbo said:
I'm confused. Map is absolute referenced and boost is gauged referenced. We need those math channels
It is absolute referenced however its positive and all tables are positive. Look at the TMAP slope equation and the voltage input. The default units are inHG. However you only ever get a positive voltage, hence you only get positive numbers. The only way we can make it negative is by lying and saying that its inHga as the native raw units. Then when you select inHg or psi you'll see a negative number. It is not what Ford intended though.
-
On 1/22/2024 at 6:00 AM, hjtrbo said:
And has someone got confused with gauge pressure and absolute? Map channels are offset by baro when checking (wtf is) atmosphere. I.e. on the highway at 100km/h I'm 80kPa. If I select 'atmosphere' it reports 180kPa! It should be -20kPa.
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).
-
1
-
-
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.
-
1
-
-
On 1/19/2024 at 11:54 AM, Stephe said:
Ok, I get the theory behind what you said there, thankyou. To be able to get to the nitty gritty of poor pipework placement, does the datalogger have the ability to log something like that? Thanks
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.
-
1
-
-
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
-
1 hour ago, Andre34 said:
Ahh ok that makes sense. I had a feeling it was a turbo but I didn’t trust my knowledge enough. I saw on the stock file list that under “charged” it said no. Is there anywhere I can find a more accurate list of stock strategies and what they come out of or not really?
I’m trying to get away with a budget on this one so I’m not copying anything over that is too drastically different. One thing though is I still can’t get the shift fart from the zf even after making the zf trans torque limit tables more negative but that’s a different topic.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.
-
1
-
-
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.
-
2
-
-
On 1/16/2024 at 6:37 PM, Stephe said:
so too my knowledge the FG doesn't have a maf sensor but i saw a (MAF LEACKAGE) pid and thought ill log it and yer i have a value in my log. my question is where is it getting a value from if i dont have the maf
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.
-
2
-
-
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.
-
1
-
-
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.
-
1
-
-
On 7/24/2023 at 10:03 AM, K44 said:
I've been looking and cannot find these parameters. They are defined in HPT as ECM 6321 and ECM 6512
([ECM] 6321 - Trans Select Shift Auto Upshift Switch: Switch that determines if automatic upshifting when in SST mode is enabled)
([ECM] 6512 - Trans Upshift Minimum Pedal Position To Upshift In Select Shift: Above this pedal percent, upshifts will be allowed in select shift mode.)
Thanks
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
-
1
-
-
On 11/17/2023 at 7:34 AM, K44 said:
@ Rolland
Is there something in the 21 and newer Mustangs that disabled the flex logic?
Thanks
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.-
2
-
-
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.
-
2
-
HOWTO: Data Logging
in General HOWTO Guides
Posted
OBDX FT runs 64 bit mode. This generally makes the editor and datalogger run much faster and far more stable. It will log for 8 hours straight, if you don't like restarting software and leave the editor open for a week it will continue to run.
There have been no updates to the datalogger since this original thread was made (possibly a few bug fixes made there way in). Any improvements are side effects due to improvements in other parts of the software.
We have however continued to name and categorise DMRs, the actual back end software is unchanged though.
If you are tuning Falcons only I recommend using 2.xx as it includes a reduced template set (less memory and generally faster to connect and load).
3.xx. Is the same code base just with larger template and global name/description sets. This obviously adds overhead and will result in slightly reduced performance. It also has a mustang related features which are not enabled in 2.xx to lower the risk of new Mustang features breaking anything Falcon related.