Leaderboard

These kind of back end tasks take up a lot of our time. So if it seems like we are sitting around with our feet up, trust us, everyone is working overtime on the following: Support Resolving the out of memory issues due to 32bit J2534 driver by adding support for a new cable (OBDX FT) Overseas support (f150, Mustang, Bronco, Explorer, Maverick etc). Special shout out to the workshops who have supported us from day one. Without you we wouldn't exist and problems like this would not get fixed. We really are indebted to you (you know who you are) hence the huge 64bit update to improve your work flow. Please don't hold back, negative or positive feedback is always welcome.

Hey all, one for the home brew guys. Making a little tool that connects up to your rear o2 sensor and sweeps 0-1V over 256 DAC steps (resolution 4mV ). The idea is you set up a flex fuel OS, set up a map pair you’d like to dial in. A good example is cam shafts. In 98 fuel intake cam, set all -10°, E85 set all to 50°, then load the engine up and sweep from 0 to 1V to find the optimal angle for the map cell you’re working in. Sweep time is adjustable and there is a manual mode. All settings are saved to flash so you’re not having to re-set up the tool every power cycle. The code is written in C using Microchips MPLAB X IDE. Definitely possible to port to Arduino with a little bit of effort and care. Project folder attached. Handy little bit of gold in the LCD code, made a function that scrolls 1 line of text whilst keeping the other line fixed. Software is done and tested on a development board. The final board layout and component BOM are the next steps. Downloads if you want to play along… IDE https://ww1.microchip.com/downloads/en/DeviceDoc/MPLABX-v5.35-windows-installer.exe Compiler https://ww1.microchip.com/downloads/aemDocuments/documents/DEV/ProductDocuments/SoftwareTools/xc8-v2.41-full-install-windows-x64-installer.exe MCC Plugin https://ww1.microchip.com/downloads/en/DeviceDoc/com-microchip-mcc-4.0.2.zip Source code (spacing weird, tabs vs spaces interpretation issues when github gets it, looks fine on my machine) hjtrbo/Map-Sweeper (github.com)

Update: Board designs have been sent out to the fab house. Looking at about 4 weeks to get the prototype up and running. Found a nicer case with rubber grips.

If you set a 50rpm breakpoint it would work. Eg normal timing at 6000 rpm and -70 at 6050 rpm. Then as soon as the torque drops off it will drop rpm, hit normal timing and effectively bounce around between that 50 rpm hysterisis. We do similar things with anti lag and stall converters, find the max slip rpm and set the spark retard to start exactly at that point. It works like a P only control loop and is actually a very simple and effective method to control torque. You can do the same with cam timing/fueling as well. Eg at 6000 -> 6050 go from 0.8 (or whatever lambda you are running) to 0.6. We are trialling a proper spark cut also. @Darryl@pcmtec is adding it as one last present for the Falcon Custom OS this year. I believe it is already working as a proof of concept, it just needs generalising across all OSIDs. Tuners will hate us for adding it, but I know you guys will love it. Just beware, this will break engines if you aren't careful, ignition cut can cause valve float and backfires through the intake inducing pre-ignition/bent rods. Your valve train needs to be upgraded to sustain it.

Some CAD spam for the fiends out there. Added CAN-BUS hardware to future proof, no software support at this stage. Next iteration will be to add an aerial and enable the transistor radio function. Plan to get the layouts off to the board house for fabbing shortly. No idea on ETA just yet, next week I'm adding in the functionality to support GM Gen 4 / Gen 5 (VE, VF, Camaro, Cadillac etc) vehicles as their flex fuel sensor is frequency based and is easily implemented with just plain old vanilla HP Tuners. If they don't have a physical flex sensor, they would need to buy the ECM wiring kit from a third party (e.g. $110 from Ultimate Conversion Wiring in Australia). I'll need a couple of testers at some point if any one is interested... I also will be testing it on my own car. No technical reason why it couldn't be left permanently connected either. Have your tune setup so the box functions effectively as an on the fly variable engine power output box, mild to wild incremented at up to 256 steps lol... It's going to be small, the enclosure measures 105 mm x 65 mm x 30 mm. And could be made smaller again if I could be bothered hand soldering surface mount components and changed out the LCD for an OLED.

With respect to your original post, it's tuner locked fella! Forscan 'might' be able to do a recovery write to it, but you will lose your tune. Get in touch with Brett at Custom Machine Works. He will refuse to unlock PCMTEC tunes, however I'm not sure of his position on HP / SCT unlocks. Whatever the situation, at the least he can return it to stock so you can get on with tuning.

Sorry, everyone. I've been a bit all over the place. Not sure I even know what a car is anymore 😒 Here is a prototype excel workbook (it has macros/VBA, so you'll need to allow them). The first tab shows the calculated final spark, plus the BLK and MBT tables (after adjustment). You have some sliders on the right where you can change the ECT, Lambda, and IAT. There is a colour code picker, so you can choose to colour code the table by the spark source, highest to lowest values etc. If you want different colours, change the background colour of the Colour Picker cells and cycle the selector. The second tab shows how you might paste in a log output and see how changing the spark tables affects the calculated spark (the example data was taken from cruise while logging pretty much everything i.e. it's not great). The cool thing is that you could change your tables and see exactly where the spark "should" change. Just be aware of the Spark Source (I've included a table for what the numbers mean). Spark sources other than 1/2 could be wildly different. The other tabs are where you can copy in your tables from PCMTEC. It's not an elegant solution, but it works. I haven't extensively tested it or verified there aren't stupid mistakes in there (it would be worth knowing whether MBT - ECT adjustment is correct, or if it should be additive...). It would be worth generating some high quality logged data and seeing what it looks like. Then refine the model or extend to additional tables/modifiers. Spark_sim.xlsm

im still playing around with it, so will keep updating. this is NOT ok for the motor what so ever! 20231013_160130.mp4

Well holy fuck, tried the new Forscan Beta with module programming recovery mode. She bloody worked!!! My PCM is back alive and ready to roll. Caveat is you need to buy the 1 year license at $21AUD, the extended trial license won't let you do it.

It's part of what a community is about, helping each other.

I looked at your log and it shows you are out of injector. It could be that you're out of pump and have kept adding fuel into the SD tables which has maxed out the injectors. Depending on which parts you have on hand will decide what you do. You should verify the fuel pressure as it will tell you whether the pump is out. If the pump is fine you need more injector, if the pump is out you need a better pump. If the problem persists after replacing a pump that is out, you need more injector. To verify fuel pressure you can chuck a fitting into the fuel feed, if your car is all stock then perhaps between the fuel filter and the steel pipe or even in the quick connect fitting to the fuel rail. You could run the return line into a jerry can and if it stops coming out when the car is going flat out on the dyno, it's safe to say the pump is out. There are more ways to do it, that's just a couple of ideas. Also you should be targeting around 13:1 or possibly mid 13s for na on E85, same applies to 98, you will be losing heaps of power running it into the 11s. Where it makes the most power is where you set it. You don't keep it rich for safety, that only applies to turbo cars. To keep things safe, you set the timing where it should be to prevent knock, which isn't applicable with na and E85. Even a 1000+hp turbo car will want to run around 12.3:1 on E85. I looked at your timing curve and it is more suited to 98 octane. With E85 you can add timing until it stops making power. You might find the opposite happens at very low rpm, it might actually prefer a bit less than stock. For this reason you don't just add a global 6 degrees, although you certainly could. Anyhow there's something to think about, check the fuel filter too/first, as they tend to block up after a couple of days when you first switch over to E85.

Making the most of nothing else to do and really starting to kick this thing in the guts. Have pulled cables, stopped and started in weird places, closed com ports externally and other weird stuff to try and crash it. I reckon I've caught most or maybe all of the bugs in it now. Hoping to have this version finished shortly which will be uploaded to github. Caveats: You need a DLP plugged in. Requires virtual com port software e.g Eltima Virtual Serial Port Driver. Project is still in test bench stage.

Schematic is done. Board layout during the week. Have included hardware support for can bus.

Changing it at low load is a waste of fuel imo. You want your car to use frig all fuel when tootling around but when you floor it you don't care. FYI you'll use about 20% more fuel for no gain if you change it in the low load areas. When you log it, you can see what load numbers it uses through the rpm range and at various throttle positions. It'll be along the 0.9 and 1.0 lines mostly at WOT. While you're logging, see what it is at 100kph cruise. It'll be around 0.4 load mostly. Even 50% tps will have around 0.8 load. Have a look at the most aggressive part of the WOT cam timing. It's easy to spot cos instead of positive numbers, it'll have negative numbers up to about 3000rpm or whatever. Copy this entire row and paste it to 0.8 load, up to the highest load point. Using this very simple method you'll have the extra acceleration that advancing the cam timing provides, while still keeping stock fuel economy at cruise. As far as testing the outcome you either put it on a real dyno or use virtual dyno. You'll feel it anyway, it makes quite a considerable difference to how the car drives. Something to keep in mind is this raises cylinder pressure at lower rpm so will tolerate less ign timing, but this isn't an issue when the knock sensors are switched on. Needless to say you have to run your car on 98 to realize power gains, anything less will have the knock sensors pulling timing non stop.

Started on a basic GUI. I need to do a final check on the CAN comms with the ESP32 S3 and I will get some PCBs made for testing the boost control side of things.

Howdy folks I've noticed that changing the speed density maps to richen the afr also changes the load, even tho the boost level remains the same. Obviously this changes many other things that are load dependant such as ignition timing, trans pressures etc, when we're just trying to change the afr. I can see why the load might change, as we're actually adjusting the airflow numbers, not fuel delivery numbers, which changes the afr as a by product. I've tuned a couple of cars which have had the fuel pump running out. Adding fuel to the SD map will keep the injectors open longer which in turn will richen the afr, despite the fuel pressure falling. This is only an interim fix and you can't rely on a failing pump to deliver constantly predictable fuel pressure. I started this topic to ask a question that I worked out the answer for as I typed it out. Rather than delete it, I may as well post it to help others that run into the same scenario.

The following will set your active exhaust to be fully open in "track" mode at all time except for quiet mode. In an 18+ GT this will set your exhaust flaps to be fully open (eg track mode) at all times except when "quiet mode" is selected on the dash. This will mean on the street you will only meet noise regulations when in quiet mode. 1 is "quiet" mode. I set it to still open the valve at WOT and high RPM. Map 2,3,4,5,6,7 set to 1.0 at all times Map 8, 9 and 10 leave as stock (0) We are not sure if these are ever used, so we simply left them at their default of 0 at all times). These may be FMEM tables or not referenced, there is an array that tells the PCM which map is to be used when, however this is chained via several what appear to be automatically generated code blocks which is difficult to follow. Trial and error is the quickest way to determine which map is which in this case. This guide may not be suitable for newer vehicles. However is is confirmed as correct on RHD 18+ GT 5.0 Mustangs. To be sure if it will work on your vehicle compare the stock values of these tables in any FSJJD calibration against your own, if the tables that are all 0 or 1 are the same, then the configuration is likely identical to yours.

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.

Yep that's more than likely what the issue is. You can try bumping up the pressure but the bush ain't gonna get any better.

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.

My wife said i could turbo her rav4 at end of warranty... That must be soon.. maybe she needs a whirly boi n noise maker

Ima buy my wife an external gate for xmas and if she complains ima show her this post

Kind of off topic but you might find it interesting regarding leaving E85 sitting in your tank for long periods of time. For fun (not really, I was lazy) I left E85 in a tank for 6 months. The E content increased from E85 to E87 over that time which indicates how much was was absorbed. You could work it out exactly (assuming the water dissolved into the fuel which it should below 20% water content). You can do this via the dielectric constant (how a flex sensor works) Dielectric constant of water = 80 Dielectric constant of E100 = 25.3 Dielectric constant of E0 (gasoline) = 2 Dielectric constant of E85 = 0.85*25.3 + 0.15*2 = 21.805 Dielectric constant of E87 = 0.87*25.3 + 0.13*2= 22.271 Assuming 1% of the "E87" was water you get =((0.85-(0.01/2))*25.3)+(((0.15-(0.01/2)*2)+(0.01*80))) = 22.3185 I think this maths is correct. Anyway you can see that a small amount of water can substantially change the E content reading Lets say you somehow absorbed 6% water, you get a DI of 25.636 which is above E100 and would clip the sensor and read E100 This is all at a temperature of 20°C

Missed the 3D in HP Tuners so threw together a very basic app to generate a 3D graph from a data table. Utilised the open source Graph3D c# library. Handles data with or without axis headers. Editor3D: A Windows.Forms Render Control with interactive 3D Editor in C# - CodeProject PCMTEC 3D Viewer.zip

I'm guessing Forscan don't read the serial for the license check which is why it succeeds. Unfortunately not something we can turn off otherwise it would be abused and revenue down the drain in seconds.

Trial and error is the best approach. You can add overlap at redline if you want however you risk a backfire through the intake with severely retarded ignition timing.

That's basically an ignition cut

https://github.com/jakka351/FG-Falcon/blob/master/BigFalconSheet.xlsx Uncensored.

Changed the torque converter with a spare one and problem fixed. Suspect there is a seal/O ring inside the converter that is leaking so I will send it off to be cut open and repaired

now do NOT go this hard with the neg spark haha this was me being a dick head and playing, ill post a vid of how it sounds

Any local mechanic will wire in a wideband and hook it up to a controller under your dash with a fuse tap for less than a few hundred. Imo I'd simply pay someone to do it for you if you aren't feeling confident. Make sure they pick a fuse that's only on when the car is running.

That's great mate. You need the paid licence to get access to the beta area of the forum to get the download link for 2.4.8beta but yes, recovery mode works well. It took a few emails, sending debug data to the FORScan team in 2.4.7.test builds to get it working properly with the vLinker FS & J2534 devices. There were a few service procedure interrupted errors, resulting in no communication with the PCM, but they got there in the end. I had another tool I could use to recover the PCM, so it was ready to try again when another test build was provided. So far, I've only had 1 PCM sent to me that I haven't been able to properly recover using FORScan or return to stock. The PCM wouldn't communicate in car with any scan tools, HP or read using PCMtec recovery mode. I wasn't going to licence it to try writing to it. It was an ABU-244 BA turbo PCM, that would recover using FORScan over & over. Once recovered, it would then read with HP, PCMtec & FORScan. Give it half hour to an hour of being connected on the bench & it wouldn't communicate again. Leave it disconnected for a few hours & it could be recovered again using FORScan but kept losing COMMS over time. Not a FORScan issue but a hardware issue. It'd been sent for repairs twice & sent back after being supposedly being repaired, prior to being sent to me. A replacement PCM was installed & that solved the problem. There's a few other things you can do with FORScan PCM programming, that are pretty handy, if you have the Ford calibration files & spend a bit of time to work out a few workarounds.

Can confirm 0-7 is cylinders 1 to 8 in a v8 and yes mine runs slightly leaner on one side, but it's the drivers side that does so since air flow is less obstructed to it, i changed 0-3 to 1.02 to correct.

I made progress but not solved yet. The question in my mind was, is the EOT value causing this or the actual EOT? Someone else had the idea to "fool" it to believe a different temp to see if the problem followed the temp reported to the PCM or the actual temp. I found auf60084 and learned if you put a smaller value in, it will report lower EOT. When I did this, I found the "VCT disabled" issue tracked with the actual oil temp, not the inferred temp. In other words, after the engine oil was good and hot it did not have the issue even if the reported EOT was 150 or below. Therefore, it's not some EOT vs XYZ table in the calibration doing it. It leads me to conclude the problem is physical in nature and the PCM is seeing something it doesn't like and disables VCT as FMEM of sorts. Being a physical problem, I've compared a ton of logs and observed that the cam angle, angle error, and phaser duty cycle do not seem to correlate to the disabled issue. I'm thinking in the direction of cam-to-crank reluctor diagnostics but can't get my head around how this might be affected by oil temp or viscosity when the phaser and solenoid seem to be working properly at the time.

You really are good to us puff. 😉🍻

BF has fully independent VCT

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.

Yes, use the calibration merge function & just copy the VIN from the na file to the turbo file

@Stephe A turbo car and an NA car are doing the same thing when decelerating. Yes it will work with an NA vehicle.

Central data parameters, things such as Vin, axle ratio and tire size supplied by the bcm during a pcm/bcm resync. The calibration is going to have min and max acceptable values defined in a couple locations, these need to have a large enough window for whatever the bcm is set to prior to the resync.

You know it. I don't know much about the can-bus flex fuel setup PCMTEC have worked out for tri-core??? Perhaps later on I might be able to get a hold of the relevant can id and message construct to be able to put my sweep data out onto the bus. Hardware wise it's supported, but would need a major firmware update from my end. Perhaps a conversation with Roland down the track...

The way the Australian non-Mustang Coyotes are controlled is different than the Mustang Coyote. That method won’t work on the Mustang. You’ll need to use the distance tables and the distance table indexes to command a mapped point that has overlap at idle. I have seen people have success using mapped point 10, which is -20 intake and 0 exhaust. You’ll need to add mapped point 10 to the optimal stability index and then command it in the idle rpm and load range via the optimal stability distance table. If you play with the scaling in the rpm columns in the distance table you can get it to go back to normal cam timing as soon as you go over 1000rpm. Additionally you may need to change the max load for optimal stability. There’s a table for that, and it’s probably not scaled well for this. I’d re-scale the rpm axis so you have 1000-1100rpm defined and then set those, and any lower rpm, cells to 0.3. You will likely have to bump up the idle speed to 800-900rpm. You’ll also probably have to play with MBT spark for mapped point 10 in the idle range to get the chop you want. Idle reserve torque is another area that might need attention There may be a few other tweaks required to get it working exactly how you want, but that should get you on track.

Thanks for the links. Chip is a 8k word 8 bit PIC micro running at 16MHz. It doesn't have native CAN support but I have in a past project bit bashed a CAN MCP2515 transceiver using SPI to communicate with a LINK ECU to pull data out for a custom dash which went really well. If I get bored I can bring those source files into the project and integrate. Chip memory usage is at 82% 😬, but I know I could get that down with some optimisation and compiler tweaks.

@Kirby@PCMTec an update for auF12105 The values for auF12105, shown at the far right for (Ford/FPV Switch) 130=FG XR6T, BF & FG V8 FPV. 138=BF, F6X & FG 4.0 FPV. The auF12105 values I've found for other variants are as per below which isn't correctly reflected in the parameter description auF12105 isn't found when searched in FGX Sprint UEAA or UEAB. I wasn't able to find a BF manual 3V file but could have missed one when filtering.

There is now a built in feature when flashing a vehicle where it will auto merge the serial at flash time(if the serial doesn't match) and prompt you to relicense. Saves a bit of time.

Howdy mate that will be a sick build when it's all done. Yes you want to read the tune before you get modding so you have it as a backup. You will want to have a look at some stock super8 files so you get an idea of the difference between them and the na file. If you cant access them I'll pull my finger out and post up a few. What I would start with is getting a wideband permanently installed so you see what the car does in day to day driving. You may want to have one for each bank for the extra data and safety that provides. You will need a dlp8 to get the afr data into the datalog, there is info on the forum about it. You will need a set of knock ears, they are vital for getting the timing correct on 98 octane. Boosted engines, especially stock ones, break fairly easily when they have detonation. When you get to using E85 a dyno will show you where the tune is showing diminishing returns. You will want a fuel pressure gauge that can feed the data into the datalog. You can see when a pump is running out if you have experience but it's a no brainer to have the data there to see if the pressure is falling off. You'll need to get reading about all the stuff, there's a lot of info that goes into tuning, haha all those mechanical parts do things for reasons and we need to know as much as possible! Anyhow there's that, should give you some idea of what's involved at the start.

You can find workshop manuals here>>>>> Workshop Manuals - AFF Technical Resources (fordforums.com.au) Look at section 418-00 Module Communication Network

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