Adamw

Attach the tune and a PC Log. Your trigger scope shows some teeth on the trigger wheel arte either damaged or magnetised or something, but Im not sure if that is the only problem without seeing a log.

It looks like you have a wiring issue, most of the time that you push the set switch it interrupts the cruise on switch signal.

I suggest you contact CANChecked to get the correct info on the Aux message from the source. The PT website says the ID 0x640 needs to be transmitted at 100ms which is 10Hz and nowhere I have seen says the frame length must be 3, in fact most CAN devices cant even generate a 3 byte frame so I doubt that is correct info. Your G4+ set-up is using 10Hz and an 8 byte frame. The only thing different to the G4+ aux setup should be an offset of zero for G4X compared to -1 for G4+.

It is not a set up issue in realdash or the ECU, you have the wrong device that will not work with any aftermarket ecu I know of, it "talks" only in the dedicated realdash protocol, the format of the message is not user programmable like the recommended wican or seedstudio CAN device.

Your pic doesnt show any of the relevant channels, can you attach the actual log file.

If the stock TPS wiring is still there on AN Volt 3 then yes that would be the correct fix.

Stage 1 can be any DC you want, typically you have it as high as possible to reach target as quick as poss, but if you dont want that then fix it to something lower.

The LS1 sensor wont work with the LS2 58X trigger wheel. The LS1 sensor has two sensing elements internally that combine into a single output, it needs a special trigger wheel that is two wheels with different patterns stacked on top of each other. If the LS1 sensor gives a signal but the LS2 one doesnt, then that would suggest possibly the LS2 sensor is faulty - or there is an alignment issue internally.

For MAP you need a Volt input, for the temp you need a Temp input. Expansion 1 has 2 of each. If you are using their 12T wheel then you wont need an extra pull-up, the one built into the ECU will be fine. With 36 or more teeth then I would add an external pull up. 2.4Kohm, 1/4W connected between 12V and signal.

It looks like you possibly have more than 1V ground offset there, especially at higher RPM when that fuzz appears on the signal.

Are the DI pull-ups disabled in the DSS software? Set the multiplier to -1 and offset to 1 will invert the logic. You might have to ask CANChecked to confirm the ID and format of the receive message for the auxes, their current MCE18 manual doesnt even mention the CAN at all for these outputs. The PT Motorsport website does mention it but I noticed the transmit CAN on their website had some errors in it the other day so I have some doubts theirs is up to date. Also it looks like only version 0.8 and later boards have the aux outs so possibly you have an earlier one.

No that doesnt sound right. The J1850 is a coded signal, it would need a microcontroller to decode the incoming signals and make decisions on how the motor is controlled from those, I guess it could possibly use a 555 on the motor control side after a control command had been generated but it would be hard to imagine why when there is a microcontroller in there already.

The easiest would be with an expansion loom which has 5V, Sensor Gnd, AN Volt and AN temp inputs all in the one bundle. If you want to make do with existing wiring, then you could splice into 5V and ground at the TPS sensor, connect the MAP signal to AN Volt 2 in the airflow meter plug and the temp signal to old fuel temp sensor wire which I think is in the regulator.

This is how normalised mode works. With normalised mode the ecu is comparing the noise level of the current combustion event to the previous few "learnt" combustion events. If you are operating under reasonably stable conditions then suddenly increase load or RPM, then the first few combustion events at that new higher load will now be generating more noise than the previous events it is comparing to. So to account for this, when there is a sudden change in load or RPM (this is determined by the RPM/MAP/TPS delta level settings, then the threshold is increased by the "Threshold gain" for the number of cycles set in "Delta hold". With normalised mode you would usually have a "flat" threshold table, and the threshold should only need to step up for a short time when there is a significant change in load or RPM. You should not need to increase threshold with RPM or boost like your threshold table is, this suggests something is not right in the setup or possibly mechanical. I notice you have a 2.5L whereas our car was a 2.0 so possibly the knock frequency is not ideal. You could try it at 6,7 and say 13Khz to see if the noise levels look less erratic. Your ignition advance is quite low so I doubt there is knock, but it is a little odd that your cyl 4 knock level is mostly the one that is erratic. A quirk I found in our subaru was the sharp click from the AC clutch turning on/off in auto mode would cause a spike in knock level, I got around this by disabling knock for a few tenths of a second before the clutch switched on of off. I see that has caused 1 spike in your log but it is not your main issue, just something to keep in mind if you start seeing random spikes or retard.

I relise that since your post is in the G4X section. But what specific ECU? A Monsoon? Fury? Plug-in? If a plug-in, what model or part number?

You can vary the target with APS as you have set up. Set up the control so that it only moves into stage 2 when you are somewhere close to the minimum achievable "spring pressure boost". The lowest value anywhere in the target table should also be the same "minimum achievable spring pressure boost". In stage 2 the duty cycle will still mostly be coming from the wastegate DC table just like it did in openloop mode but with corrections added depending on how far off target you are. In stage 3 the actual DC value applied to the wastegate comes from "Base DC" + Proportional correction + Integral correction. If the base DC mode is set to "Stages 2-3" then the "Base DC" part is coming directly from the base DC table. If set to "Stage 2 only" then the "Base DC" part is fixed at the last base DC that was being commanded from the table when you left stage 2. I would suggest base DC mode "Stages 2-3" based on the shape of your base DC table. You have a big change in your base DC table between 5&6000RPM so likely closed loop will need to do less work with the variable base dc coming from the table through the whole rev range. I dont think I have ever needed to use the "Stage 2" base DC mode but I suspect there are applications where there is some other factor involved that causes the DC required to reach target quite variable, but once you are on target the control requires less variation.

Try the attached. I have set the trigger offset to 205, this could potentially be 360deg out, so if it doesnt start with this then try it at -155. 2jz 2000cc e85 precision 8685 turbo 1300hp 36-2.pclr

Can you explain the kaizen relay connection. Is it taking the place of the original ECCS relay? Is the low trigger connected to ecu pin 16?

Your scope capture shows the ecu is receiving the correct signal from the cam sensor on trigger 2 input, but it is receiving no signal from the crank sensor/trigger 1. Confirm the crank sensor is wired like below (different pinout to the cam sensor). This picture is looking into the sensor housing.

You had me confused for a minute but I forgot we had recently added the hall effect one. I was talking about our VR one: https://dealers.linkecu.com/CAS_3 I generally go for VR where I can due to the more simple wiring and better noise immunity. But if the threaded hall effect was easier then the 8V supply on pin A6 is a nice option for the power supply. If you went for a 60-2 wheel with that sensor then I would add a 1.8K pull-up resistor into the wiring, the 24-1 options wouldn't need the extra pull-up. I have cut directly onto the rubber mounted ring before where I haven't had much room to play with due to dry sump etc - with no apparent issues at the time. Im pretty sure many BMW's even do this from factory. I dont think the torsional vibration is enough to cause noticeable timing error, but you are right if the rubber bond ever failed then it could certainly cause an issue.

Then yes, the CAN JST would be suitable for making a CAN connection to the ECU. You will still have to connect the black/red wire tails to your own power source, and you will have to make the connection between the 4pin DTM on the CANJST and the AEM device.

J1850 is not CAN bus at all, it is an odd single-wire pulse width based protocol. Very few (or none) aftermarket ECU's have hardware or software to communicate in this method. The forum post you linked to has possibly added confusion as it starts off correct but halfway through several users start talking about CAN bus.

Your map is still using 1mbit so you wont need to change anything.

This is not a device im familiar with, but after a quick read I think that meatPi you have is really the wrong one, you should be using the "wiCAN" from what I can see. It appears the meatpi USB-Dual CAN only talks to realdash using the native "Realdash CAN" protocol which will be difficult for most ECU's to be able to generate as it requires a frame size minimum of 16bytes. Link and most other ecu's have a max of 8 bytes so I dont think it will work. The "Realdash CAN" protocol was really designed for custom devices like their old chassis control boxes to talk to the dash. The WiCAN device that looks very similar talks in a more typical format suitable for an ECU. You may want to bounce that off the meatpi guy as I may be interpreting some of that wrong, but that's how it reads to me.