Help with building your Speeduino, installing it, getting it to run etc.
User avatar
By PSIG
#43535
Settings are super-important. People respond poorly if you lie to them, and the same is true for Speeduino. Poor or incorrect settings (including calibrations) must be reasonably accurate. Correct the ones that are not, and establish correct settings for those not yet set.

I see some sympathetic cycling of other functions, but your GammaE is cycling from ~65% to ~ 78%, along with your Gego +/- 20% every 2 seconds or so. I'd be looking there. Diagnostics (tuning) involves reviewing clues, and creating more clues if necessary. Perhaps change one thing to see what it affects, e.g., turn-off ego corrections in order to see how it responds. What changed? Why is it different?

I call this type of cycling "hunting", as it is hunting for stability on an unstable edge or slope somewhere, for the current control settings. Without being specific for this particular example; it could be unstable due to ignition timing transitions, lean-surging, etc. Likewise, it may not be a tune condition, but a control condition. For example, excessive EGO control can induce swings (cycling) in fueling as it goes too far or too quickly in corrections, then is forced to swing again in recovery. Tame your control authority. Soften your response time or allowed %, etc. Stuff like that.

Corrections should stabilize the tune (if it's a good tune), but also provide valuable information of what the system needs. What is it the engine telling you by its response? What is Speeduino telling you by its corrections? We would rather not use corrections to beat it into submission, but rather use responses to guide us (the tuner) toward what the engine either wants or away from what it does not like. BTW, your Spark Table and AFR Table are critical info for diagnostics but did not import with the tune, so I'm assuming some stuff here, and therefore only making general suggestions. That's OK, as general direction and concepts are more important to tuning in the long term. Rock on!

David
By nwalk7800
#43539
Understood, I set all the settings a year ago and forgot what I did. This brings up a question though. How do I go about updating my tune to the latest version of the firmware?

The GammaE cycling is caused almost entirely by Gego. You can see it following right behind the AFR as if it's trying to correct it. Either way, there doesn't seem to be enough change in the PW and duty cycle to cause the sudden jump in AFR. That's what makes me thing hardware. I will try turning off Gego as I can see the potential over correction you mention.

I don't know why the AFR table doesn't show up in the tune, but I don't control spark.
User avatar
By PSIG
#43557
Seeing your Current_Tune label, and assuming some things, I'd like to suggest a tactic that may free you in your tuning. Use multiple labeled tunes. This is me, but may give you ideas that can free your tuning flow. The concept is to have multiple tunes that allow you to do crazy experiments, anytime you like, yet go right back where you were.

I begin with a basic startup tune, that has as many settings done as well as possible by calculation or good guesswork. I call this (example) my startup tune, and label it as <project name> STARTUP, e.g., XYZ1000_STARTUP. Once running and warmed, and some general direction is found, I save it as a new tune XYZ1000_Last_Good. This tune will be my base tune and safety net. It is always the best tune I have for the project at this point. If I get into trouble, I just load the Last_Good tune and I'm back to exactly where I was.

From here, I can experiment with tests, calling my current tune something descriptive such as XYZ1000_All_Corr_OFF, or XYZ1000_WUE_Test, or whatever I'm doing. If I'm making progress, and results are better, I can save it at any point as my Last_Good tune. If I'm still working on it and have to go to work, I load Last_Good, and drive to work. After work I load XYZ1000_WUE_Test (or whatever I was doing) and continue immediately from there. When I'm done improving WUE, I update Last_Good and delete the WUE experimental tune. On to the next task.

I hope this helps, and is one huge advantage to having the ability to run multiple switchable tunes, and recover to a known point at any time with a few clicks. Enjoy experimenting (even crazy stuff), and learning from the results, relaxing and knowing you're always able to "get back home".
8-)
David
By nwalk7800
#63450
It's been a while, but I'm back. I've hit a wall again with ignition. I'm using an HEI 4 pin with a VR conditioner, diagram attached.

If I watch the timing with a test light sometimes the it's steady, sometimes it jumps all over the place, and sometimes it just doesn't spark at all.

I used an o-scope to watch the reluctor and ignition signals right at the IDC connector {board .4.3c) and it looks like sometimes Speeduino just isn't triggering the spark. I thought it might be caused by the running dwell being too long so I shortened it to 1ms and tried again, but still see the same thing. Is the running dwell a maximum? So it can still use a shorter dwell at higher rpm?

I also used the composite logger to look at the tooth counter. It doesn't look like it's missing any triggers from the reluctor, but I'm not sure I'm reading it right.

I included the tune, a log, and a tooth log in the zip. I don't know how useful the tooth log is, but...

If the past is any indicator I'm sure I'm doing something obvious wrong. Any help is very much appreciated.
Attachments
(189.45 KiB) Downloaded 2621 times
Ignition-Wiring.jpg
Ignition-Wiring.jpg (30.68 KiB) Viewed 3149 times
3.5ms.jpg
3.5ms.jpg (118.09 KiB) Viewed 3149 times
1ms.jpg
1ms.jpg (125.26 KiB) Viewed 3149 times
User avatar
By PSIG
#63454
Did you post the correct files? The tooth log wouldn't load without repair. Your VE Table looks perhaps corrupted. From your 'scope images; when you take a look at it, set your Trigger Edge to Falling, and re-set your Trigger Angle with a timing light. It will not be zero. Take another log (and 'scope trace image if possible) and post with the tune in another ZIP file.

Oddly, your run-log shows zero sync loss with the ugly tooth log (if that's the right file). :? If no joy, you may want to run EEPROM_clear.ino on the Mega and start your tune over with reloaded firmware on a new TS project, just to clear the cobwebs. Begin with the standard Base Tune, and enter the values you know are correct.
By punisher454
#63460
ImageIve never seen a 4-pim HEIi module used that way. I'm not sure that'll work right. I think you would be better off using a 7 or 8 pin module which is designed for computer control.
And as far as 7 pin modules go, the ones that come in distributors are for a VR sensor, and the ones mounted extenally like on a Vortec use a hall sensor ( I think). Also there is a difference in the two versions of the distributor type modules, the ones that come in some vehicles (pickups and astro vans) have a built-in retard curve.
You can find info about the "lspark latency" settings used in the ECM's that used those modules at thirdgen.org in the diy prom forum.
the 8-pin module works the same as the 7-pin and use a better waterproof connector. 7-pin modules are found in large cap HEI's and 8-pin modules are in the small cap HEI's
https://wiki.speeduino.com/en/configuration/GM_Module

Also I know the is a speeduino forum, but the following link has some very good info about using the GM modules with a megasquirt, most of whats on this page will apply here too.
http://megasquirt.free.fr/sources/MS/ma ... pinHEI.htm
Attachments
heis2.gif
heis2.gif (19.37 KiB) Viewed 3080 times
By apollard
#63468
I’ve used the 4 pin on many vehicles, but all vr applications. I agree that it will not trigger consistently with a hall signal ( like the speedy puts out). It needs a full zero crossing to trigger consistently.

I’d use an 8 pin for the watertight connection. Be sure to use heat transfer compound and a large aluminum sink.

Edit: a search turned up some links adapting the 4 pin to points applications. So it might fire on hall despite the tech info. Also, many aftermarket modules use different electronics so could trigger on hall signals. But given the possible issues, I’d still use a module designed for computer control.
By nwalk7800
#63475
PSIG wrote: Sat Jun 10, 2023 9:55 pm Did you post the correct files? The tooth log wouldn't load without repair. Your VE Table looks perhaps corrupted.
I'm not sure what happened to the tooth log. Here's another one that seems to be ok. My VE Table is just a mess in this tune. I noticed I had a dud injector and it's gonna require some reworking.
PSIG wrote: Sat Jun 10, 2023 9:55 pm From your 'scope images; when you take a look at it, set your Trigger Edge to Falling, and re-set your Trigger Angle with a timing light. It will not be zero.
I forgot I had changed the Trigger Edge to Falling as a test. It didn't seem to make a difference. I changed it back to Rising for this round. It's tough to find the correct Trigger Angle when the timing's jumping all over the place, but I previously just turned the distributor until the timing light showed what the Speeduino thought it was. I thought that made sense. I've since put my vacuum and mechanical advance back in, which is why I have the timing fixed at 0 in the tune.
punisher454 wrote:ImageIve never seen a 4-pim HEIi module used that way...
apollard wrote:I’ve used the 4 pin on many vehicles, but all vr applications....
I've seen some other folks using it with some success here and on the MegaSquirt forums. It's my stock setup, so I'm hoping I can get it to work. If not, I think the 7 pin will fit in the stock distributor.

Thanks to everyone for taking the time to help me out.
Attachments
(85.32 KiB) Downloaded 2617 times
FallingEdge.jpg
FallingEdge.jpg (87.13 KiB) Viewed 3017 times
(84.07 KiB) Downloaded 2645 times
User avatar
By PSIG
#63477
I would treat the two issues separately. VR input signal from the distributor reluctor is one issue, getting it cleanly into the ECM for processing. IGN1 output to the GM 4-pin to drive the coil is a separate issue. Let's deal with the input and a clean tooth log first.

Your input signal appears to be good on your scope images. However, your tooth logger appears that Speeduino is internally seeing a very choppy square wave. Somewhere between your VR reluctor signal at the distributor and the processor, the signal appears to be corrupted.

I wold ask that you take 'scope images at several locations to hopefully find the failure point for the trigger signal. 'Scope:
  1. VR signal at distributor connector
  2. VR signal at ECM input terminal
  3. VR signal at PCB signal conditioner input
  4. Signal output at signal conditioner
  5. Signal input on Mega pin
  6. IGN1 signal output at board terminal
Be sure to observe the same polarity of your probes as you test. I see your last VR signal image is reversed. ;) Keep them all same-same.

Sorry for the homework, but I can't see from here where the signal goes bad. What are you using for a signal conditioner? Please be specific.
  • 1
  • 3
  • 4
  • 5
  • 6
  • 7
blitzbox

Me too. I got the bootloader on there with succ[…]

Maybe try in english.....

J35a4 Triggers

Hello, Working on J35A4. Would like to have/con[…]

Torque reduction request for AT

I probably have burnt Arduino pin 51,I changed the[…]

Still can't find what you're looking for?