Adamw

I would probably keep alternator lamp as a separate incandescent bulb on the dash somewhere - or use a resistor in its place and get the dash charge light to work off battery voltage instead. We had another user fry a dash that was connected directly to the alt lamp circuit due to some odd occurrence that caused an alternator load dump. This doc here will give you an idea of the general warning lamp setup: https://www.aim-sportline.com/download/faqs/eng/hardware/sensors/mx_series/FAQ_Sensors_MXx12_StradaSpieIcone_100_eng.pdf

Yes as mentioned above this is a known problem at present, the updater tool is just reporting that mode status incorrectly. If you can connect to the ecu normally with PC link and see live data etc then the ECU is in normal mode.

I have been informed of your case in tech support. Unfortunately at this time we dont support floating point format for CAN output and I dont see anyway to generate the CANAerospace messages that the Skyview uses. I could put in a feature request to add a dedicated stream for this but the firmware team has a lot of work on at the moment so wouldnt be in the near future. From memory you can use hardwired inputs for most of the data you need? The old CRC32 option we used to offer in Vipec is different, that was used by some old Motec displays and is formatted more like a serial stream with all of the bytes in a single frame and a CRC on the end for error checking. Quite different than traditional CAN and no one uses it anymore.

Yeah in RB's I have seen as the optical sensor gets old the rise/fall time gets slow and this causes the width of the trigger 2 slots/windows to get shorter than they should be at high RPM. So for example the ecu may expect the longest trigger 2 slot to be 24 trigger 1 teeth wide - but at medium RPM it only covers 23 teeth, then at high RPM it drops to 22 teeth and the ecu is not happy. The ECU has a +/-1 tooth tolerance on the trigger 2 widths. One possible option would be the AEM 24slot disk. Start up will be slower, but the width of the slots no longer matters with this type of trigger pattern. https://www.aemelectronics.com/products/sensors-connectors-accessories/nissan-cam-angle-sensor-discs

Have you got the ECUmaster CAN tool or a PCAN/Kvaser tool for programming it?

Its a JST XA series. You will need a micro crimp tool to do an acceptable job on them.

Yeah that S7/8 plug-in has quite an unusual circuit on the AC request input that I dont fully understand. Can you try a 1K resistor connected between the AC request wire and ground.

No, it is just a limitation in their software/firmware. Possibly to stop ID clashes. But it tells you in the software if you assign a keypad to CAN2 all other CAN2 functions are disabled.

Yes a small USB hub should do it. Possibly some "USB OTG adapter" may work too, but I havent tried.

Note in G4X you can invert the logic on the PWM outputs using the "Active state" setting. So rather than work backwards like you had to in G4+, you could make it more intuitive with 0% being fan off and 100% being full speed.

They other future option if this becomes a more common issue is maybe we could just place a fake load resistor on the USB power pins to make the laptop happy but that would be a PCB update.

Those MRS pumps should work fine with just a "speedo out" aux or GP PWM. They are hard to find over here now but when they used to be popular this was a pretty common setup.

The stepper motor setting doesnt matter since you dont have a stepper motor, yours is a solenoid. The jerking/hunting effect is your overrun fuel cut bouncing on and off. The RPM hang would suggest the base position table hasnt been tuned. The only place in your log that idle control is working is for about 1 second at the very end when the car stops moving. The rest of the time you are above your idle speed control speed lockout. Will need to see a log with some actual idling in it to help much further with idle control.

Yeah your basic set up looks fine. One problem that needs fixing is the Y axis on your fuel tables is referencing the AN input voltage (it will only go to about 4.5V), you should be using the parameter "TP (Main)". I would also say you can likely make the fuel tables a little more simple than they are. I start with the bare minimum and only add extra rows/columns if I find when tuning interpolation between two cells isnt keeping things in control - then I will only add an extra row or column where it is needed. With no MAP reference you will probably find VE numbers around idle area much smaller - I often see around 30-40%. I also find charge temp approximation will be lower than a typical plenum type manifold. I have attached an example fuel table and charge temp table from the last ITB engine I done in modelled mode just for your interest. Charge Temp Approximation.lte ITB Fuel Table BAP load.lte

Yep, connect 5V and grounds together, 1 signal as TP main, 1 as TP sub - deosnt matter which.

There are but I cant give out a full pinout. So do you want to modify yourself?

A .pclr file is a map from an older G4+ ecu, you cant load a G4+ map into a G4X as they are too different. The best you can do is open the G4+ and G4X software up side by side and work or way down the settings tree manually copying the settings across. You can copy any tables across using the import/export tool, but most other stuff needs to be done manually.

I have seen this happen on some modern laptops with USB-C ports. What I think is happening is they have the USB port set up to operate in client mode by default. It must need to see load on the power pins for the port to be switched to host mode. Since our ECU's are powered by the car battery they dont use the USB power pins at all so the laptop cant detect a client has been connected. This is why if you plug in a USB hub (that takes a little power) the port is put in host mode and the ecu is detected ok. G4X should have entries in both categories, you can swap between serial comms mode (possibly less noise sensitive )and direct USB mode (a little faster) in the communication settings.

We have a VH45 manual in our library, do you know if they are the same. Connector looks like this:

We have just tested this on the bench and suspect the ecu is not always syncing correctly with this trigger pattern (or possibly the trigger settings I gave you arent right). The firmware team is investigating. Leave it with us for a bit and one of us will update you when the problem is confirmed.

It would need a dedicated firmware function to do this. Generally they look at crankshaft acceleration through a certain angle window and compare to the other cylinders over the same cycle. Some use a feed back signal from the ignition coil. You wouldnt be able to do it with user math as it needs to be synchronous, in our ECU's all synchronous calcs are done with a dedicated "eTPU". I doubt the subaru system works reliably as the 36-2-2-2 crank wheel is a bit too low resolution to start with and has some big patches of missing teeth which gives even less resolution. Maybe at cruise RPM it would work ok. Nearly all engines that do misfire detection well have a 60-2 crank wheel.

Only aux 9 & 10 drives the throttle motor. Aux 2 & 3 are nothing to do with e-throttle. It is the temperature of the throttle motor driver chip. Typically this would only happen if you are pushing the throttle against the mechanical stop for an extended period with high motor DC. A manual calibration of the TPS sensors so that 100% isnt hard against the mechanical stop would prevent this or change the max value in your target table to something like 98%.

Are you getting that error when doing the firmware update on the bench?

Yeah I cant really see an electrical path in your diagram that would keep the ecu powered up when that ign sw is off. The only logic I can come up with is one of the aux devices must still have 12V when ign is off somehow - is it possible one of the aux devices isnt powered by that chassis relay? There can sometimes be odd paths through other devices connected to the ign switch etc in some OEM wiring too.

Is it a s6 or s7/8 plug-in?