[recharged95]

Hard problem: was live KOER maf curve tuning, somewhere the bin got corrupted and got the continuous fuel pump priming problem. Reloaded an prior bin that works and still got the priming problem. Verified bin, ok. Rebooted windows, same result (continuous priming).

Frustrated, I ran verify bin one more time (TunerProRT), accidentally pulled the USB cable moving my laptop during verify. Somehow that fixed the pump priming problem, loads bins fine, primes fine (?). But now both hegos are malfunctioning (starts switching 0<->0.2 then goes and holds at 1.2, LAMBSE shoots to 18.1) and car stalls after idling for >10sec. Did I blow my QH up or fry my HEGOs? What could have caused it (car was running fine on older bin)?

[recharged95]

ok, removed the QH and pulled battery to rest everything. So far it appears to be acting ok. But think I blew one o2 sensor: hego ds (top) appears to not be switching (hego ps appears to be ok, not maxed). not sure why though as prior day's datalog showed a lot more switching behavior in both hegos:

badtune.JPG (83.78 KiB) Viewed 15992 times

[cgrey8]

I can't say I've ever had a problem with a QH not responding after disconnecting the USB. However I can't say I've ever done so during a tune-write. But I can imagine if I had done so, the state of the QH MIGHT be in an unknown state. What I would not expect is that the QH is completely non-responsive. The only two possibilities I can think of that might would cause this presentation are the mode selection gets lost. Mode selection is done on the hardware tab of BE. That's where you tell the QH whether you are running a single-bank, 2-bank, or 4-bank tune. I would think if that got lost, it would be just a matter of re-selecting the proper mode, and rewriting your tune(s) to the QH.

The other problem that used to exist is a vulnerability that would actually overwrite the firmware programming in the QH. See when we write tunes, we are not actually changing the programming in the QH. The QH code being executed is receiving the data and understands to place it in memory where BE is telling it to. However there evidently is/was a way for Moates to actually update the firmware over the wire by sending programming commands to the QH that would instruct it to erase/overwrite its programming with new programming. Well, when BE goes awry OR the data being sent gets garbled and gets interpreted as the commands for reprogramming, the QH can erase itself. At that point, the QH is bricked. The only thing that will recover it is to be reprogrammed. I've only had this happen once. And when Craig received my QH, he was confused as to how this happened, but he said once he rewrote the firmware, the hardware was in perfect running order. What I don't know is if he's updated the firmware to use a more complex programming sequence. The more complex, statistically, the less likely garbled coms will get interpreted as the reprogramming sequence.

This obviously wasn't what happened to you as you were able to get coms back on your QH. So it's possible you've found some new way to get the QH to tie its shoe laces together? Or you just fiddled with it until you got it to respond the way you expected.

What's unlikely is mishandling on the QH causing sensor failures. Either it's a coincidence, or some event occurred that just happened to damage both your HEGO and caused problems with your QH. The only thing that comes to mind is possibly a capacitor blowing inside your EEC, which is not unheard of. Although I can't say I've ever heard of anybody associate a blown capacitor with sensors going bad OR disruptions to their tuning device...but anything's possible. So it might be worth taking the cover off your EEC and looking for bulged or obviously leaking caps. If you find any, replace them.

Here's what you'd be looking for:



If you do find damage, but it's not a capacitor, it's some other component, then start a new thread and post pictures of what you see. I'm sure others on the forum here will recognize the component and be able to tell you what to search for in order to find a proper replacement.

[recharged95]

Thanks, it's a SN95 computer--only 2 caps, both looked good.
Cleaned the hego wires, checked the output volts/resistance, replaced the HEGOs, looks a lot better (switching now)

Screenshot from 2020-09-07 13-40-56.png (309.61 KiB) Viewed 15849 times

Still not sure why the old HEGOs (2yrs old) failed. Only had maybe 12K on them, then again swapped my H pipe recently back to the stock for smog testing--maybe they got contaminated.

[cgrey8]

That's surprising that BOTH HEGOs would go bad at the same time. Either something happened to both of them (both exposed to leaded gas or some HEGO-damaging chemical while in storage), or the problem that affected the first ones is a common problem that simply does affect both at the same time (i.e. shared sensor line wasn't making a good connection and the act of replacing them jiggled the harness enough to make the connection better).

Regardless as long as it's working, I don't guess it really matters. But I do hate those problems where you don't learn what caused the problem until it happens again. Hopefully it doesn't, and if it is related to some exposure during storage, it may not happen again.

[recharged95]

thanks for the replies, update--looks like it's a QH issue. I've been able to repeat this 3 times over the last 2 months.

1. Car sits for days (thanks covid?!@#)
2. KOEO ok, no error codes, won't start or WOT start and runs like crap, eventually stalls.
3. run verify bin and fails, download to file, do a diff and found only unknowns (see photo)
4. retry KOEO and now fuel pump runs continuously (somehow downloading to file triggers a corrupt bin???)
5. disconnect batt for 30min, upload exact same bin, KOEO ok, car starts, idles fine.
6. let car sit for a few days, repeat...

Possible to get a corrupt bin but still pass KOEO?

Figured a short would immediately corrupt the bin and I see it by step 2. It would suspect the backup batt, but the QH coin cell is ~2yrs old (v1.6fw, self converted it to a cr2032 coin-cell holder, had a solder-on orig). Going to check it as well as ask Moates.

bin-diff.jpg (33.73 KiB) Viewed 14797 times

[motorhead1991]

My first guess would be the battery, as I've seen that firsthand before.

What I've also seen, and actually recorded in the link below, is a surefire way to corrupt the bin. I don't know if it's a quirk with the Ranger ECUs or something in the QH programming but it works on a 98 ECU as well as the 90 seen here.

Key off corruption

[jsa]

I had a QH fail in a strange way with similar behaviour. At 1st it would corrupt for no apparent reason once in a blue moon, then it became more regular until it was more or less corrupt straight after writing. Problem was not the QH battery. Replaced QH and all is well.

[recharged95]

Yeah, talking with moates support. Seems to be consistent now, corrupts within 2 days. My battery to the gnd pin on the board is 2.995-3V depending on temps, so can't be that. On Wed, cleaned contacts/everything, burned my tune, car started up idled fine for 3min. Shut it own. Today, started up--corrupted bin.

Next up is if there's a short in the EEC wiring, so I removed the QH and letting it sit til Sun and see if it corrupts.

[recharged95]

+update -- Replaced QH with my old EEC-tuner/Shiftmaster chip copied over hex values (what a PITA...since old EEC-T out of date in its cbaza.dat) and started right up, idled fine, though had a "sharp hiccup at around 60 secs and a temp of 110-120F (weird, almost stalled, maybe a CL switch over value is wrong?, maybe hegos not warming up fast enough?). Nice the eec-t still works after sitting for 8 years in the file cabinet.

Had the QH sit standalone over the weekend w/a loaded tune (verified ok in Tunerpro), checked yesterday evening: corrupted bin. Being sent back for diagnosis--they noticed from my bin files a lot of corruption,