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

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.

Datalogging limits are much higher than the TwEECer. During beta tests, we never hit the limits on a GUFx (89-93 Mustang) EEC.

Datalogging speed is much greater

Engine is unaffected by tune/payload updates

Small form factor that resides mostly inside the EEC's case

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.

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.

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.

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.

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.

Excellent seller support from Moates

Cons of the QH

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.

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.

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.

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.

Cons of the TwEECer

It is expensive for the quality of the software, support, and lack of continued innovation

The CalEdit/CalCon software package is rarely updated with new features and bug fixes

The CalEdit/CalCon software package and many of its definitions have bugs that still are not fixed

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.

The TwEECer sits outside the EEC and sometimes causes fitment issues where the EEC will not fit completely into the stock location.

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.

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.

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.

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.

I will update this post as I think of new things and as conditions change.