TwEECer RT vs Quarterhorse

[92BIGREDBEAST]

If there are some guy out there that want to learn how to tune there cars them selves here is some good things to know about two of the most popular self tuning chips! Check out the links below. These guys are brain-e-acts! Join up and start to enlighten your self!
EECTuning.org • Index page

EECTuning.org • View topic - TwEECer RT vs Quarterhorse



After working with the Quarterhorse, or QH for short, for a while and having some time to gather thoughts about all the various pros and cons of the QH vs the TwEECer RT, I've come to the following conclusions. For those that are looking to invest in a DIY tuning kit and just want to know simply which is the best, there's no doubt the QH is the superior hardware when compared to the TwEECer RT. But don't stop reading here. There are some issues with the QH that you need to be aware of before purchasing.

So without further adieu, here it is.

Pros of the QH

1. Price. You can buy a QH, licensed copy of BinaryEditor &EEC Analyzer software, and an LC-1 Controller with WB sensor costs about the same as the cost of just a new TwEECer RT.
2. Datalogging limits are much higher than the TwEECer. During beta tests, we never hit the limits on a GUFx (89-93 Mustang) EEC.
3. Datalogging speed is much greater
4. Engine is unaffected by tune/payload updates
5. Small form factor that resides mostly inside the EEC's case
6. Not as limited to the host EEC's strategy. As long as the host EEC can physically support the capabilities of the tune, the tune can be run on it via the QH.
   
   For example, GUFB-based tunes (e.g. A9L) can be run on a GUF1 EEC (e.g. A9P). However a CBAZA-based (e.g. J4J1) tune cannot run on a GUFx EEC because CBAZA EECs require more RAM than the GUFx EECs have available.
   
   Another example is a GURE-based tune requires a knock sensor by default and won't run correctly on a GUFB EEC because the hardware needed to read a knock sensor doesn't exist on the GUFx processors. Ford simply never stuffed the circuit board with those components. In fact, you can set a GURE and GUFx EEC side-by-side and see that the circuit board itself is identical, but some chip pads on the GUFx EEC are not populated, but are populated on the GURE.
7. EEC processor overhead for datalogging is much lower as compared to the TwEECer. This means more processor time is spent running the engine which will improve the max RPM the EEC will support.
8. The QH communication protocol is well documented by Moates to allow softwares like BinaryEditor to support all of the hardware's capabilities. The TwEECer communication protocol was reverse-engineered.
9. The Quarterhorse's memory is Static RAM vs Flash. This means the memory will never wear out no matter how many times you write to it.
10. Because the QH keeps a record of all writes to memory, BE has access to read out the entire KAMRF table. With the TwEECer, your datalogs must hit all possible RPM/Load conditions to get the KAMRF values. Also, datalog accounts of KAMRF values are not always reliable and up to date. A direct read of the memory values as they exist gives the most up-to-date info about what the Adaptive Learning strategy has learned.
11. Excellent seller support from Moates

Cons of the QH

1. Installation on older EECs can be intimidating for the average Joe. But it's not impossible by any means. There is a step-by-step installation guide in the FAQ section here to help with this.
2. The memory the tune is held in is battery-backed RAM vs Flash. That in-and-of itself is no big deal, but the battery is soldered to the QH and is not user-serviceable unless you have soldering skills. Typical life expectancy of lithium batteries on Static RAM is ~7-10 year range.
3. The QH, in its current state, cannot upload/read the stock tune from the host EEC. The TwEECer can. To do this with the QH requires additional Moates hardware to extract the host EEC's tune.
4. Supported EEC strategies are limited to those that BinaryEditor supports. I've heard that Paul Booth's EEC Editor has a growing selection as well. But I'm not familiar with his software or his definition offerings. The BinaryEditor supported list is growing, but unfortunately the list isn't nearly as extensive as the TwEECer. And some of the defs are independently licensed.

Pros of the TwEECer

1. Easy Installation
2. Free software to tune (CalEdit) and datalog (CalCon) with
3. TwEECer "supports" most Ford EEC strategies. I say "supports" very loosely.
4. Includes hardware to flip between 1 of 4 custom tunes and the stock tune on the fly. However the TwEECer cannot datalog with the stock tune.
5. Has the ability to upload the host EEC's stock tune

Cons of the TwEECer

1. It is expensive for the quality of the software, support, and lack of continued innovation
2. The CalEdit/CalCon software package is rarely updated with new features and bug fixes
3. The CalEdit/CalCon software package and many of its definitions have bugs that still are not fixed
4. The CalEdit/CalCon software package does not do datalog analysis. Users of the TwEECer still find they need to purchase EEC Analyzer to make heads or tails of their logs.
5. The TwEECer sits outside the EEC and sometimes causes fitment issues where the EEC will not fit completely into the stock location.
6. Tune writes cause the EEC to execute the stock tune. If your application can't run on the stock tune, this means the engine will most likely die if you write a tune/payload update.
7. You cannot run a tune of a different strategy than the host EEC with the TwEECer. For example you cannot run a GUFB-based tune on a GUF1 EEC.
8. Support from the developer is hit-n-miss when you have problems that can't be solved on the forum. Some users report no response. Others claim decent response.
9. The TwEECer uses Flash memory which means there is a finite number of times the memory can be written to. In the TwEECer's defense, nobody has ever reported that their TwEECer's Flash memory "wore out". But it is technically possible.