[cgrey8]

I started my tuning experience with a TwEECer back in 2006. When Craig got a Quarterhorse v1.2 (beta) to the point that it could be beta-tested, I immediately retired the TwEECer for a QH. However from its inception, I never trusted the coin-cell to last. Craig's claim was that the coin cell should last 8-10 years but my company used these same coin cells on our battery-backed SRAM and we found they didn't last near the 10 years promised. So I never trusted that.

As we worked out the issues, I bought a "release" version of the QH (v1.4). It wasn't until the battery went dead in that version that I sent both back for v1.6s. By then, many customers were starting to experience the dead-battery problem which got Craig to looking at the issue closer. He found a resistor was to low of a resistance and responsible for the excessive drain. And both of my v1.6s were supposed to have that mod. But last week, my v1.6 started dumping tunes. And I knew all too well what the cause was. So I thought, no big deal, just swap in the spare and send the bad one back. But before I did the swap, I thought I better check the battery on the spare. Turns out the spare's battery is even more dead than the one I was using. The one I pulled was just above 0.6v. The "spare" didn't even register 0.1v. So much for having a spare. Now I have 2 units to RMA back for dead batteries (both have soldered-on batteries).

Always Somethin'!!!!!!!

The good news is I believe he's updated the QH to have a user-replaceable battery now. That helps. But it still doesn't solve the problem of what do you do if your QH has dumped a tune when you aren't anywhere near your laptop to load a new one. I wish he would've just gone with MRAM back when I suggested it and never used battery-backed SRAM. But it is what it is.

Thank goodness I never sold my TwEECer. I plugged it up, loaded my latest tune into it, and I'm back in business. It'll take a few weeks for the QHs to get back. Since the tune is pretty solid at this point, I may just leave the TwEECer in there indefinitely since it appears to be far more reliable than a QH with a battery. Ever since I upgraded to the QH, I've been reluctant to go any distance without my laptop. Fortunately each time this has happened, I've had my laptop with me so it wasn't a big deal. Don't get me wrong, the QH is a superior tuner/datalogger. But that damn battery is its Achilles heel.

I believe he was looking into making an MRAM-based version of the QH, but I don't know what its availability is. If he has MRAM-based QHs for sale, I'd gladly trade in both of these for an MRAM-based one that doesn't require a battery.

Does anybody know the status of those? I'll poke around on his website when I go to fill out the RMA and see what I can find. But that'll have to wait until tomorrow.

[jsa]

Part of the upgrade to the user changeable coin cell is a link to the kam +5v. The coin cell is now redundancy for the +5v feed.

An app for USB OTG downloading of the QH would be a great backup as most take their phone everywhere.

I have a loaded j3 chip in the car just in case.

[cgrey8]

Part of the upgrade to the user changeable coin cell is a link to the kam +5v. The coin cell is now redundancy for the +5v feed...

I'm a little amazed that wasn't done to start with. But it's good to know this is a new mod that follows with user-replaceable battery. I'm sure this will make the coin cell last longer. And it puts the vulnerability of likely loosing tunes to only when you disconnect the car battery. Even a virtually dead battery that won't crank a car should still have enough voltage to hold the QH's SRAM up. It only takes 1v to maintain.

The removable coin cell also allows me to remove the battery in the spare so the spare doesn't have a dead battery if/when I ever need to use it.

...An app for USB OTG downloading of the QH would be a great backup as most take their phone everywhere...

For android devices, I'm betting that wouldn't be difficult at all to code up. If all it was expected to do was consume a BIN, be told which tune position to put it in and then write it. No fancy datalogging. No def file loading. Just write the tune. I don't know the Android App API, but just from a technical standpoint, that doesn't sound difficult at all.

Now what would be difficult is getting Clint to give up the key to decrypt *.beb files so they could be written. Given any such app would likely have to be open sourced, my guess is he's not going to give that up.

[jsa]

No need for the key to the beb format.

Just take the bin from the QH as a backup for latter use should it be required.

I recently read ios had caught up and that USB OTG was possible with some sort lightning to usb dongle.

In any case I'm on android but don't have the knowledge to knock up such an app.

Moates have a bluetooth interface for the qh, so the app could even be wireless.

[cgrey8]

They have a Bluetooth device for a QH? I'd buy that now so I don't have to plug in a USB adapter to access it. I'll ask about that when I fill out the RMA.

[jsa]

They have a Bluetooth device for a QH? I'd buy that now so I don't have to plug in a USB adapter to access it. I'll ask about that when I fill out the RMA.

Sure do, connects to the same place as the optoisolator.

They also have the superlogger for purchase. The brief on their site description raises more questions than answers. Superlogger on bluetooth has some merrit.

[jsa]

Part of the upgrade to the user changeable coin cell is a link to the kam +5v. The coin cell is now redundancy for the +5v feed...

I'm a little amazed that wasn't done to start with. But it's good to know this is a new mod that follows with user-replaceable battery. I'm sure this will make the coin cell last longer. And it puts the vulnerability of likely loosing tunes to only when you disconnect the car battery. Even a virtually dead battery that won't crank a car should still have enough voltage to hold the QH's SRAM up. It only takes 1v to maintain.
.

That would depend on what car battery volts the kam 5v regulator in the eec dropped out at, and to some extent the qh circuitry for selecting internal or external power.

[decipha]

the problem with MRAM is the price, the QH would become expensive to some

I believe the mram is the QH2, might wanna check with craig on that

[EDS50]

They have a Bluetooth device for a QH? I'd buy that now so I don't have to plug in a USB adapter to access it. I'll ask about that when I fill out the RMA.

I have the SuperLogger and Bluetooth interface and can datalog with Tunerview on my Android device. Pretty neat. I also keep and f3 chip with my current tune loaded and ready to installif the tune drops. I have the updated units from Craig with the removable battery. I only got a year out of them at the most since my car is constantly powered and sits with the battery switch off so I guess I will know by next summer whether the battery back up works any better.

[jsa]

As I understand it tunerview only supports 2 strategies.

Is Tunerview writing its own patchcode or relying on 3rd party software to write the patch in advance?

[EDS50]

I paid for the gufb stretegy license and works as Binary Editor does but not as advanced or in any relation to BE. I used it just as a dash monitor instead of having to look at the laptop while im driving. I can use my phone or my 8" tablet as a display which is nice. I dont really rely on the datalogging and its not capable of making tuning changes.

[jsa]

Neat way to get a small dash display.

The fragmented support of patches for logging is a real pain I think. Multiple vendors all with their own flavour. It seems to me it is holding back the whole eec logging/tuning market.

Decipha's recent post on his forum about standardising the logging addresses has some real merrit as a way forward for all involved.

Def writers could continue on their merry way with encrypted defs so long as they mapped payloads to a standardised address.

Then 3rd party developers could just poll the stanardised addresses for whatever app they develop. No need for piles of strategy dependant patch codes.

Straight away this opens up all strategies to more features for end users.

Def writers get a market for uses beyond logging to file on PC.

[cgrey8]

Maybe I missed something, but I'm not sure what you mean by standard addresses. It's my understanding that the payload info is very specific to the strategy, and the def writer can't change that. The def writer can only write the def to match the strategy as-is.

Early on, developers named the various parameters and dataloggable status values with both PID names and logical names. These names were derived from how Ford named them from strategy documents. However as strategies morphed, even Ford would change the names and PIDs to differentiate from previous versions that were similar-but-different in some way. So the def developers did the same. This made sense to the def developers as they were having to deal with a multitude of different strategies.

However as users, this got confusing when trying to take concepts they'd learned in one strategy to another. The basics remained the same (i.e. control of AFR, spark, and idle control), but how those things were managed under new/different states sometimes changed in non-obvious ways...like with the use of the failed MAF table even when the MAF was working. Other new concepts got added (OBD-II, trans control, emissions, EDIS/COP spark control, VVT/VCT, ABS, dash control, PATS, etc etc). With more information coming in and more things to control, it wasn't surprising that some of the basics and common concepts of engine management also changed to integrate the new I/O with the old.

The closest thing I've seen to date to standardizing this effort is MegaSquirt. And from what I understand, it's not done well. I don't know the details since I've never messed with a MS system or educated myself on its capabilities/limitations. But if standardization is to come about, I have to believe it will be done where the engine management software is customizable, not reverse-engineered as strategies are done today.

The more interesting news is embedded processors are getting ever more powerful. And the ability to make a One-EEC-fits-All solution is becoming not only possible but affordable. From a hardware aspect, I have no doubt that $300 in components could easily afford hardware with sufficient processing power, I/O types, & I/O resolution that it could replace ANY EEC out there today. Granted the hardware would have just as much unused I/O as used, if not more, for old GUFB-era applications. But the availability to monitor whatever kind of input there is OR control whatever kind of output there is makes the hardware powerful and flexible.

The hard part would be finding someone with the time, desire, skill, and expertise to write the firmware and corresponding software to be reliable and flexible enough to make this hardware able to control anything from a V16 diesel to a Wankel. Then making it easy for the average user to buy the hardware, an OEM adapter to work with their factory wiring harness, customize the software for their application, and monitor with ease...all while being able to sell it for a price people would be willing to pay AND would keep this person (or persons) motivated to maintain the project. When someone comes up with that, the world of EEC tuning will change. If I suddenly became rich enough I didn't have to work, this is a project I would LOVE to be apart of. But since I don't play the lottery, don't have any rich relatives to inherit from, and don't like dealing with "customers" enough to want to attempt my own business, such an endeavor will have to wait another 15-20 years if I'm the one to spawn it. Although if there are others out there in a better position to start, budget, manage, and market such a project, I'd gladly offer some firmware assistance to the effort. Although the firmware would need to be open sourced so as not to conflict with my current employer's contractual obligations for employment.

[jsa]

http://www.efidynotuning.com/forum/view ... =30&t=2086

Decipha is talking a base offset plus individual offset for each payload. The individual offset changes from payload to payload and strategy to strategy. End result is payloads are allways at a fixed address.

Sure, some strategies might have some bespoke log worthy PID's. They could be assigned a location after the common PID's.