Jump to content

jdniss

Members
  • Posts

    52
  • Joined

  • Days Won

    1

Everything posted by jdniss

  1. Just to cover this off - my issue is now fixed - re-running the ECCS Sync and dialed timing offset again on the G4+ got the car back to a better running state; I then replaced both the fuel filter and fuel pressure regulator - was only getting 25psi at the rail - regulator looked to be blocked with old E85 "gummy" contaminants that must not have burnt off during short cold starts.
  2. Someone commented in another thread that it's likely to suit WiFi support on the G5 Voodoo; Given the firmware is now utilized on the non-WiFi based G4X line too, there really needs to be an update to allow selectable Connection type.. Literally just noticed this as I'm typing: Never though to click this option - the old G4+ / G4X software was to select a specific COM Port.. Hopefully the USB option both suppresses the connection prompt, fixes the annoying popup and reduces the constant graphical bugs.
  3. Must be the day for bugs, Software decided it no longer wanted to connect to the ECU - just cycled the prompt - haven't seen behavior like this yet. ECU Connect Failure.mp4
  4. Yep same issue here switching from KPA -> PSI and vice versa, on occasion causes the same graphical bugs - however it's wildly inconsistent - I can't replicate it back-to-back.. On the topic of weird bugs and behavior, I got this one just now - couldn't remember if I'd run the Nissan Opto 360 ECCS test when I swapped from G4+ to G4X, so I thought I'd give the procedure a go.. Nope - impossible to gather a Trigger Scope - software has bugged out and crashed 4 times in a row now, same error every time.
  5. Yeah sorry, white 5V output - I confused the colours In the the old car, the G4+ trigger offset on my SR20 was -100 with a Falling trigger, on the same car the G4X trigger offset with the same engine was -85 with a Falling trigger - took me a while to work why the car was so "lazy" after the G4X upgrade
  6. @CodySoFine looks like the crank timing is off by 15° ? PLMS state 5th mark from the left https://www.plmsdevelopments.com/index.php/sr20-stuff/sr20-setup-tips
  7. S15 SR20DET service manual states the following, in blue: I've had a non-X Series AEM UEGO Wideband also wired into AN V1 and the reported PCLink AFR numbers were fairly far off the gauge values using AEM's recommended Lambda calibration numbers - even rewiring the ground wire directly to the ECU - until I re-calibrated the voltage numbers in PCLink. The AEM UEGO X-Series RS232 Serial reported values in PCLink were even further off compared to the gauge, based on the existing configuration available - to the point I jump straight to CANBus based comms with that gauge instead - not sure whether the AEM calibrations are just inconsistent.. I'm in a similar situation to you - poorly running, rich running SR20 despite various troubleshooting; I can literally plug the old PowerFC back in with no changes and the car runs perfect as it always did, so I must have a timing or Software config issue somewhere in the Link I've yet to determine - I'll be following this topic with interest.
  8. Hi @Adamw, any news on this issue from the Devs at Link? Thanks
  9. It only briefly hits the idle control for half a second until the MAP lockout prevents it engaging again, though the car already looks to be on the way to shutting off because Crank Enrichment has dropped from its 80% to a 32% Post-Start Enrichment value. Possibly the Post Start/Warm Enrichment values need some fairly large tweaking to keep the thing running until you can sort out Main Fuel, or you need to add a fair bit to that Idle area on the Main Fuel table so that the Cold Start values aren't doing so much of the work. Also it looks like the Idle Control likely won't engage again proving the MAP drops below it's lockout - as throttle position is still hovering about 2% higher than the 1% lockout.
  10. It could be the "radiator" fan - similar to that found on an S15 that activates once the air con is triggered..? https://skylinespares.com.au/product/nissan-skyline-r33-gts-gtst-ac-fan-assembly/ While it doesn't sit on the AC Condenser, the factory ECU (on an S15) activates it for both aircon condensor cooling, and in "overheating" scenario's as a cooling fan above a certain temperature threshold; Could be the same for an R33? - probably just pinned/configured in the Link as an AUX Engine Fan 2 or 3? Something like this @BlakeR33? Slightly off topic - although both a JDM S15 and ADM delivered S15 have these condenser fans, and both have 2x 30AMP relays to control the fan - in an ADM S15 the fan is dual staged Hi/Low by the factory ECU; On a Link NS15+/X Plugin ECU, both of these relays on Pins 9 and 10 are controlled by the same AUX1 output - so there's a fairly large power draw when ever the aircon or "overheating" circuit kicks in - I believe this matches a JDM S15 that doesn't have a dual stage OEM radiator fan. I suspect the suggested fix in the ADM S15 scenario would be to wire 1 of the 30AMP relays to its own pin on the NS15 Plugin to allow both Hi/Low fan control @Adamw? Thanks (S15 ADM manual below ~ I don't have an R33 manual available)
  11. @Adamw, could the issue be machine resource headroom related? The issue occurs far more frequently if I wind up RAM / Memory usage past 80% prior to opening the PCLink software - as soon as a map is loaded and 'Offline' is clicked - the graphical issues are immediate if the RAM usage is already at or past 80% - I don't even need to close the overlay before the issue occurs, unlike prior occurrences (below). Repeating the same process under 40% RAM Usage, the issue occurs far less frequently - in some instances I have to repeat the process multiple times in order for the graphical issues to occur. There's 32Gb of RAM on this Desktop machine - so depending on daily usage, there may always be a fairly large buffer of RAM in reserve for PCLink to remain stable; Whereas the Laptop only has 8Gb of RAM, so it's fairly constrained in comparison, even before PCLink is loaded - possibly leading to the issue occurring more frequently than would be on the Desktop. While these errors may not be exactly what you are looking for, maybe they'll help one of the Devs at Link: Thanks
  12. Hey Adam, see attached. Desktop - reproduced issue during manual "Search for ECU" open/close with a loaded pclx file Laptop - reproduced issue during USB disconnect/reconnect & "Search for ECU" auto open/close DxDiag_Desktop.txtDxDiag_Laptop.txt
  13. It seems to be related to the "Search for ECU" overlay that pops up after an ungraceful USB disconnect. If I power the car onto IGN - connect laptop - load up G5 software - search, connect to ECU and read map data - gracefully 'Offline' the ECU via the toggle in the top right, it's all happy.. I can do this until the cows come home, no issues. If i repeat the same process but forcefully rip out the USB cable instead of using the 'Offline' toggle - the software panics, throws the 1019 LINK_NOT_RESPONDING error - then on on re-connection the graphical bugs start. Which would likely hold true for instances where I'm PC logging and stop in a parking lot - shut car off - return to car and start again. G5 PCLink always wants to "Search for ECU" in this scenario, as I'm pretty unlikely to gracefully 'Offline' the USB connection manually in PCLink prior to shutting the car off - the graphical bugs are immediate ~ which kind of defeats the purpose of "Auto-Connect" currently. In the G4X world - likely where there wasn't provision for upcoming WiFi connections - the "Search for ECU" overlay wasn't a thing, you could shut the car off / on again during a single logging session, and the log would continue endlessly until you manually stopped it; In the G4+ Software a new log would start from ECU power on, but at least the "Auto Connect" function held true. I'll try and replicate the problem on the desktop from my initial post and come back with any findings. EDIT: It just happened on the Desktop.. The action of clicking the "Offline / Online" button - letting the "Search for ECU" overlay pop up and hitting "Cancel" - started the graphical issues on a pre-loaded .pclr file. To reproduce on a Desktop: Load G5 Software - press Cancel on "Search for ECU" prompt overload - Open an existing PCLX file - press Offline in top right corner - press Cancel to "Search for ECU" prompt - graphical issues start. Thanks
  14. It might be worth raising an issue either on the MeatPi GitHub Page: https://github.com/meatpiHQ/mpUSB-CAN/issues Or ask the developer the question in the MeatPi Discord server; he's been pretty helpful on both fronts when I was troubleshooting issues with firmware on the WiCAN. Whether the device is intended to be used in the scenario you describe or not, if the developer can clarify either way, he can update the documentation to suit. It certainly reads like it should be compatible - though maybe that's because the documentation isn't specific enough.
  15. The engine was at operating temperature once CLL enabled and started incrementing values into the LTFT table. If LTFT values can only be populated via enabled CLL trim - presumably once the engine is up to operating temperature and warmup has decayed away - it's counter productive to pull warmup fuel via LTFT even before CLL is enabled, as the help file leans toward. Warmup is tuned, that isn't the issue - LTFT being enabled by default regardless of ECT, unless locked out - is. Thanks for confirming. I suspect these LTFT 'Disable Input' parameters below will mimic the CLL lockout parameters? Is there any way to directly link a GP Output to LTFT 'Disable Input'? - I can't select one from the list.. Or do I have to go via a Virtual AUX as below? Thanks
  16. Noticed this morning LTFT ignores the Startup Lockout that CLL abides by as well. The only way I can think of configuring the same lockout, is via a Virtual AUX bound to a GP Output with applicable conditions.. Though this is a waste of either input/output, to then lock out a trim that should internally handled within the CLL / LTFT function. In an extreme case; if the VE map was so bad that LTFT was allowed to pull 40% and save the values - by the time the vehicle was started again you have a scenario where the LTFT pulls so much fuel prior to warm-up or CLL lockouts, that the vehicle would barely idle. Haltech gets around this with a "Long Term Trim Minimum Temperature" option. Similarly during a "sensor failure" - unplugging the Lambda sensor - CLL is disabled, however LTFT values are still applied in the G5 software. Looking at Haltech NSP again, Haltech workaround this issue with a "Long Term Fuel Trim Rich Bias" that allows a richer target than the current configured Target AFR - in the event the CLL/LTFT system fails. Hopefully some of these options can be considered for a later version of the G5 Firmware. Thanks.
  17. jdniss

    Search for ECU prompt

    Yep same thing here - the older software would happily just auto-connect - if you'd selected the option in Preferences. Even with auto-connect enabled in G5, this prompt still shows, and then I still have to manually refresh the ECU list, select the ECU, and press 'OK' to the prompt - agreed, its annoying - and what purpose is it intending to serve..?
  18. Scaling is already at 100% unfortunately. Never experienced the issue on PCLink G4+ or G4X on the same system - leads me to believe the issue is solely related to PCLink G5 software.
  19. Hi, Unsure if this is intentional or not - is the Long Term Fuel Trim table supposed to ignore the Closed Loop Lockout parameters it's based on? I've only just enabled LTFT and found that below the CLL ECT lockout, LTFT table values are being applied - it's effectively fighting against the Warm Up Enrichment values until the CLL lockout value is exceeded. Or is there a setting I've missed? PC Link G5 v7.2.3411 on G4X Thanks
  20. Hi, I've had a few weird instances of UI graphical bugs within PCLink G5 where random tables overlap with each other, some resulted in Runtime crashes as well. Unsure if unique to my usage/hardware configuration, or a common issue worth investigating. Win10 Pro 22H2, AMD Ryzen CPU, AMD GPU. Machine still has PCLink G4+ and PCLink G4X software installed due to various ECU's being tuned. PCLink G5 - v7.2.3411 PCLink G4x - v6.23.15 PCLink G4+ - v5.6.8.3669 Thanks
  21. Isn't an "RS-Enthalpy tune" just a hardware modification and re-flash of the original Nissan factory ECU? Similar to a Nistune "daughterboard" installation and re-flash. Assuming the factory ECU loom still exists - you could replace the factory Nissan flashed "RS-Enthalpy" ECU directly with a Link G4X Plugin https://dealers.linkecu.com/NS15X_2?quantity=1 Or if the Monsoon G4X has already been purchased, either make a patch loom to go from Nissan ECU Header -> Monsoon with: Wiring Specialties 64pin kit: https://www.wiringspecialties.com/sr20dets131.html and Link 'A Loom short' https://dealers.linkecu.com/0LA_?quantity=1 Or cut the Nissan ECU header off at the end, and terminate directly into a Link 'A Loom short' for the Monsoon G4X
  22. Hi, Issue is fixed now - changed jumpers back to all horizontal - whatever the backfeed issue was - is gone; All 4x coils test and fire as expected, same with all 4x injectors. Car starts and runs as per normal. Not entirely sure what the issue was as I can no longer replicate it in any prior configuration. Anyway, all fixed. Thanks for the help @Adamw, @KennyJ
  23. Hi, Bit of an update here; I've flipped the jumper settings from all horizontal to all vertical as per the manual - and the "retains 12V with key off issue", has gone away. However I've now noticed I only have coils #1 & #2 - test fails on coils #3 & #4; This was tested with factory coils including OEM igniter - though I noticed coil #4 was getting hot. Also tested separately with aftermarket coils (Toyota Yaris Denso coils) including an igniter bypass - no change - test fails on coils #3 & #4. Validated the offending coils are OK on a known working output ~ coil #1. The "retains 12V with key off issue" comes back if I leave coils #3 and #4 disconnected. The Yaris coils work with the outgoing PowerFC, so I don't believe that sub loom or coils are bad. I flipped Jumpers J1 + J2 horizontal and switched pins 2 & 3 as cited in "Known Issues" - still no change on coils 3 & 4. The G4+ / G4X NS15 pin-outs match the 180sx J4 ECU pin-outs I have, so I'm a little stumped. Pin #1 - Coil 1 Pin #3 - Coil 2 Pin #5 - Coil 3 Pin #25 - Coil 4 Thanks
  24. The injector flow in Injector Setup is configured or 0cc/min rather than say 480cc/min, 740cc/min, 1000cc/min, etc SR20 here configured for Trigger offset of -85 on G4X, the trigger offset in the map is 0. Might be worth getting a timing light out to check base timing while cranking to confirm any Trigger offsets required.
  25. I've done the same as @ROB-80E - the custom Realdash CAN config XML suitable for a G4X I have is saved to Dropbox, along with the RealDash *.rd file as well; I just load both into the Windows version of RealDash - make the changes, save the file - import back into Tablet version of RealDash. The exported Android dash doesn't scale particularly well into Windows RealDash App - there doesn't seem to be a resolution scale option inside RealDash, but its easier than making changes via touch on a phone/tablet. I've got odd problems with RealDash polling the 4G connection for CAN info, rather than the dedicated WiFi connection if both WiFi/4G are enabled at once, though that's easily solved by turning off 4G for 2 seconds. Confirmed RealDash + MeatPi WiCAN-USB adapter works on both G4X with G5 firmware, as well as G4+ with latest firmware. However there are substantial differences in Link CAN parameters between both generation of ECU, if you are intending to switch between both.
×
×
  • Create New...