Roland@pcmtec

What is your oil and coolant temp reading?

Yes what Bill said. The run fully independent cam timing. Some strategies don't implement overlap at low rpm to assist spool though, this is something your tuner can address. Not all tuners are aware of this. If anyone is on a PC they can confirm if your stock file commands overlap from 1500 to 3500. I'm fairly sure HACCKGA doesn't implement it for example. I'm not sure why Ford did it on some cars and not others. Afaik all the FGs do it and they run 33 deg overlap, the BFs that do run overlap are only 20 deg. Likely due to the different turbos.

FYI we wrote a program to dump the scalars from every single strategy in our database. Out of the 1700 files that have auF21158 (Brazil OBD logic switch) all of them have brazil mode disabled.. I spoke to Oz tuning and there was no flex fuel mustangs ever sold in Brazil, there was also no F150s ever sold in Brazil until this year (the 23/24 model). Everything else in brazil was an import. So the brazil switch was likely a development item that was never actually put into production. It may not be complete or function as described. I did get a Brazilian strategy though JR3A-14C204-BDH and the following scalar is different to the others. High Ethanol setpoint where ethanol is stable enough to run brazil OBD2 auF21159,0.87 auF21160,0.33 (low setpoint) The next closest FSJJ5 strategy is JR3A-14C204-VJ which has auF21159 = 0.9 and the low setpoint as 0.30 like every other Mustang. Some F150s and other vehicles have it set to 0. Comparing JR3A-14C204-BDH to JR3A-14C204-VJ shows a huge number of DTC codes disabled. Eg almost all the O2 sensor codes are disabled from the factory. The active exhaust is also a lot louder. Basically it looks like a very "loose" calibration in regards to emissions and noise compliance which makes sense being Brazil does not have the same design regulations as the US.

Yes it does work very similarly. However the Mustang has DIDs (typically a much smaller data structure) and you can pack more into a single request. If they were all bytes (this would be unlikely but it is the best case scenario) you get 7x16 = 112 rapid packet high speed items you can log, this is as you get 7 bytes per slot and 16 slots, most DIDs are 1 or 2 bytes, some are 4, almost all DMRs are 4 bytes (higher resolution). We are adding the generic DIDs to the Datalogging soon. These are a small generic subset and there will be approximately 300 of them. You can mix these DIDs with normal DMRs. So things like RPM/ECT/EOT etc you can use the DID version to speed up datalogging of other items. Our default layout will be updated to optimise this. We also looked at dynamic datalogging rates for the single rate polling. Eg if something doesn't change very fast (ECT etc) then you don't need to poll it very often. As such we could make buckets of slow/medium/fast where if you had 9 DMRs, 3 fast, 3 medium and 3 slow they would be polled in the following order (an approximation of how it would work). slow1 medium1 medium2 fast1 fast2 fast3 slow2 medium2 medium3 fast3 fast1 fast2 slow3 We would then dynamically adjust certain values like EOT/ECT to be slow as they do not change often (based on some magic algorithm), or set good defaults so that you get an optimal logging experience. In the mean time we recommend you create several logging layouts, one for each task and only log the minimum number of items required to ensure fast logging rates. We have multiple default layout files, most of these can be trimmed substantially to increase poll rates depending on what you are doing If you create good layout files and want to share them I'm sure this would be greatly appreciated by others. We could even include them in the editor by default.

The IO is assigned by the RTOS which is not writeable. You need to change the PCM or be the first to experiment with a BDM and try and clone the Rtos from a different PCM

We want to test the actual flex logic itself primarily so this would still be very useful. We can tweak the firmware based on feedback from users. So the first ones to use it will get dibs on what they want changed.

Are you seeing a torque error when it occurs? I can find the MID related to this if you can't.

Absolutely. It has a fully adjustable interpolation curve, not just for spark but literally any table your want, your could raise your idle rpm, desensitise knock, remove fuel, etc etc. Have a look at our falcon flex fuel guide. The mustang version works very similarly. @Kirby@PCMTecis in the process of writing up documentation for the public release.

We will let you guys know. Do your have the ability to wire up and install as per the following instructions? edit: Please contact support for the flex fuel install guide.

@engineermike I'd love to get you to try out the proper can bus flex fuel system if you have time to wire it up. Would you be interested in giving it a go?

Also E85 vs 98 tends to "crackle" differently. So if you have a flex fuel/dual fuel tune, you want less spark retard on the 98 tune as it tends to be louder due to the flame speed being faster.

Can you give me some MIDs or auF IDs related to items that you have modified? I can then trace what they are linked to in the assembler and hopefully give you some hints

We are rolling it out to single users on a case by case basis. I have analysed the assembler code for a gen2 mustang and these tables have been calibrated out by Ford and are never accessed by the code. If any other software has mapped them you can try putting silly number like 10000000 in there to prove it. As we generate our templates by analysing the code and what tables/scalars are accessed we can accurately determine if a table is accessed or not and as such not display it. Other packages do not do this as they often map templates by hand. Eg auF79238 BLD ACT MUL flex fuel is not used. Instead auF31016 is used SPARK MOD ACT MULTI For convenience here are the tables that are used in a gen 2 Mustang vs an F150 with flex fuel enabled. These IDs will get better more consistent names shortly. auf79238 BLD ACT MUL flex fuel -> auF31016 PARK MOD ACT MULTI auF79239 Engine coolant temp spark modifier -> auF31020 Spark multiplier for borderline ECT modifier auF79240 BDL Flex Fuel -> This is hard coded as 0 at all times in the code auF79241 BDL Flex Fuel Multiplier -> This is hard coded as 1.0 at all times in the code Interestingly the equivalent to these tables in the 18+ Mustangs appears to be calibrated in. edit: I saw you mentioned quite a few other IDs in your ticket. I've only checked auf79238 -> auf79241 however I suspect the rest are all covered under the same FFV logic which is calibrated out. If you want to be 100% sure if these tables should exist or not load up any FSGP1 calibration (a Gen2 Mustang), this is our master base calibration we have mapped by hand and has 100% of tables and scalars mapped.

We currently support many Roush and Whipple strategies. As these strategies are custom operating system and not from Ford we must source these files from the customer to add support to the editor, as such you may have to send in a stock read before you can license/edit your vehicle. If you have a Whipple tuned vehicle that is not supported you will see the following dialog. Please press yes to send this file to support which will automatically create a support ticket so we are notified. Then please return your vehicle to stock using the Tomahawk (Whipple) or ProCal (Roush), do a full read with our software and send that file in also. For Ford Racing calibration such as control packs, please send this in the same way. If you cannot get a stock read we can still most likely add support for your operating system, however CustomOS and return to stock support will not be available. This means you will not see the blue/red colours in the navigator indicating when something is changed from stock, you will see grey/orange instead (orange means different from when the file was read). Any non stock supported aftermarket operating systems that we do not have a stock file for will not show up in the stock file repository, they will however be supported. Please note that some Roush strategies from 15-17 obfuscate the spark tables, you will see values like 0.00000000003455 degrees of spark, then you'll see that the spark multiplier has been set from 1 to 1,302,460,202,604 etc. You can manually multiply the spark tables back so you can get normal numbers. As of 30-11-23 the following Ford Racing, Whipple and Roush Strategies are supported. If the Roush/Whipple designators are incorrect please let us know. This post stemmed from the original discussion here. We monitor our forums more regularly so please continue any discussion here instead to get faster responses. Any support/tech requests please use our support portal as we do not guarantee to answer any support requests via the forums https://support.pcmtec.com https://www.mustang6g.com/forums/threads/pcmtec.190584/page-7#post-3847905

Could you post a bit more detail on what specifically the problem is and what you want to log? Also the strategy and operating system of the vehicle.

Fyi I am going overseas for a week. If I get time I will dig this up otherwise when I get back I will find it for you. Handy tip, only works for scalars but go to calibration tools - > View all scalars. Ctrl a, Ctrl c (might take a minute on a slow pc) then open excel and Ctrl v. You can then search and filter for values. Use the bulk change units to ensure your units match those of the other software you are using. You can find all sorts of interesting limits this way. We may even add a search function where you can paste a table in and it will find all tables that contain a subset of those values to assist with this in the future. @Zhuojian@pcmtec@Zhuojian@PCMTEC @Scott@pcmtec@Scott@PCMTEC this would make for a fun side project. @Kirby@PCMTec if you have time next week before me see if you can help locate this table for @bankyf

Which operating system is this? I will find the table ID for you. If you can screenshot the table you are talking about in HP also we can verify against that for you. Then we can ensure it's categorised better so it's easier to find. Alternatively you can simply read out an already modified tune and it will show in red in the navigator and you can find it categorically 100% that way. Do you have a tuned file read with pcmtec you can upload showing this table changed?

It's not possible to do an actual spark cut. But you can do silly things like -90 deg of timing.

Yes but that probably isn't the full answer. Lots of things won't work.

As Puffwagon said. Alternatively help -> about. You can also do help - > View licenses to see what you have spent your credits on. Every time you restart the editor/license a file it does a credit resync and template/stock file update also (or you can do it manually via the resync option).

It looks like it was disabled as there was confusion with people not knowing to connect to the PCM and TCM separately. Now the datalogger automatically connects to the PCM+TCM in one go. As a result of us combining the connect functionality you cannot click the TCM connect button without an OEM PCM being detected. Haltech did originally propose to emulate a PCM for use with our software, but they did not decide to go ahead with this so we did not implement it. You'll have to use something else to datalog the TCM. Or tie the stock PCM back in on the CAN network, I'm not sure how that will go but it might work. Being as we don't charge credits for the ZF licensing/datalogging, we are not likely to make any changes here. There might be some hacks to get the TCM button to show up, like connecting to a PCM+TCM on the bench and then hot swapping it, or maybe trying to open a PCM file and use the table trace function. If this works it is not by design, rather a bug that might work.

I have seen this on some calibrations before. Does having turbo logic switched on/off make any difference? Are you getting any DTC codes logged?

You should be able to datalog the TCM separately by clicking the trans button in the datalogger. You wouldn't be the first to do this.

What is the problem with datalogging?

Write some software first to send UDS commands to do simple things like read VIN or memory via address first.