[SigEpBlue]

This is giving me wood just thinking about it. I can't wait to order.

[86GT]

It is getting closer. Craig and I have a few testers going at it. Craig has put together a nice piece of hardware and it works great. It is very fast, and so far we\\the testers have seen 33-35 parameters being logged at 50ms. I think we can get more at even a faster rate. BE has had some problems with the interface but most of those have been dealt with. The testers are now trying the live update features to see how that pans out.

One thing that is stilll in the development stage, is logging of parameters with addresses that are internal to the EEC CPU. Once BE is stable enough it will be post. All of the definition files will also need some attention too. Lastly I will need to test BE with all the different hardware to make sure I did not break something.

Moates F3
Moates Ostrich
Moates Quarterhorse
EEC Tuner
TwEECer RT

[2Shaker]

I haven't paid much attention to any of the "Moates" discussions and I don't really know what it is all about. Sounds like it's time to learn. As a TwEECer user what does it mean? Is it a chip that plugs on the EEC diagnostic port replacing the TwEECer? And what are the benefits?

[86GT]

To put it simply:

Benifits:
1) Faster polling.
2) Unlimited number of parameters to log
3) Live updates while engine running.
4) Smaller footprint for tighter spaces

Draw Backs:
1) Only one tune
2) Can not read factory tune

This is off the top of my head

[cgrey8]

You forgot the most important one. It's cheaper. A LOT cheaper.

[cgrey8]

You forgot the most important one. It's cheaper. A LOT cheaper.

[86GT]

I did not want to mention that only because I had no idea what Craig was going to price it at. I do remember he said it was going to be cheaper but that is it.

[cgrey8]

...- Pricing will be $249 initially, not to exceed $295 later on...

Once it releases, a person can get started DIY tuning for about the same cost as a TwEECer RT.

$250 Quarterhorse
$130 BE/EA (unless price has gone up)
$200 Innovate LC-1 & Sensor (optional)
$580 Total

I think the TwEECer RTs are selling new for $600 and are still selling used in the $350-450 range.

[Cougar5.0]

Hey Chris,

Nice write-up in the FAQ section!

I have a couple of questions:

1) Is the quality of data at higher RPMs better than what is achievable by the TwEECer? (I know the quantity is significantly higher.)

2) Host PC overhead. Since BE is the interface on the host PC, are you seeing similar CPU usage when using the QH at similar logging rates (equal # of parameters) as the TwEECer logging through BE?

[86GT]

Wes has tried the QH + BE on the CBAZA. He was able to log 49 parameter with less than 60% on the CPU at 15ms. I believe he had a 1.7ghz with 2 gig ram.

I have changed all of the timers in BE to use control timers vs windows form timers and I saw some better performance on the screen and more consistant log times. I can send you the most recent copy to see if it helps with the tweecer if you would like?

[cgrey8]

...1) Is the quality of data at higher RPMs better than what is achievable by the TwEECer? (I know the quantity is significantly higher.)

The quality problems with datalogging at high speed dealt with the background rate of execution. The higher the RPM, the less processor time there was to execute the background loop and thus things that are refreshed in the background loop start getting stale to the point that you see values repeating in multiple rows because BE is datalogging to the datalog file faster than the background loop is executing.

In the TwEECer, all payload items are an overhead on the EEC to have to deal with in the background loop. Add to that the TwEECer's payload logic is not optimized for background loop performance. It's optimized to get as many payload items as possible datalogged. However we don't have those same limitations in the QH. The main datalogging optimizations that I'm aware of are:

• All payload values the EEC stores in RAM are dataloggable by the QH without EEC code support. Thus you can datalog as many of the RAM-resident parameters as your laptop can handle with zero affect to the EEC's processor performance.
• The payload items that do require active EEC code support are EEC register-resident values. For those that don't know, an EEC register RAM space internal to the processor that is very high speed. Therefore the fetching of these register-resident values is very quick as compared to fetching the value across the MBus in the EEC's RAM.
• In the GUFx defs, there's far fewer things in the register-resident memory that you actually need which vastly reduces the payload overhead. If you just selected everything there is to datalog, you'd have somewhere around 19 bytes of payload for the QH datalogging code to handle. Compare that to the TwEECer's 32 bytes for a full payload compliment. However realistically, the average person is likely only going to care about RPM, ACT, ECT, TPS, TS, ISCDC, ISCFLG, & FLAGS1 (the OL/CL status amongst other things). That's 12 bytes max...less than 1/2 that of a full compliment on a TwEECer. And of course if you as the user just want to optimize the background loop as much as possible, you can reduce the payload to only RPM and ACT/ECT. That's only 4 bytes.
• Derek and I have devised a more efficient way to handle datalogging that reduces MBus activity even further. The code we've been using hinged off of the TwEECer code which as I said was not optimized for background loop efficiency. This new code is optimized for speed since payload limits are no longer an issue with the QH. I just got the payload and a version of BE to test it with a few minutes ago. So I'll give it a try tonight sometime.

...2) Host PC overhead. Since BE is the interface on the host PC, are you seeing similar CPU usage when using the QH at similar logging rates (equal # of parameters) as the TwEECer logging through BE?

The digital dashboard runs around 35-50% utilization but that's with a reasonable number of parameters which is around 40 or so datalogging at 50ms. But overall, I can't tell that it's any worse than with the TwEECer.

[Cougar5.0]

Thanks Chris, let me (us) know how the testing goes. Rev it as high as you can ;)

Clint - no need to send a copy of BE for me to look at - winter has sucked big time this year so my car won't be leaving the garage any time soon.

[86GT]

Cougar I know where you are going with this. If you reduce the parameter that you select to the bare minimum while at the track it should be able to hit the RPM levels that you need. Even Ford put a parameter in the scalars that represents the reliable PIP count. If Ford cam up with this then maybe that is the limit no matter what datalogging device we have connected.

In your case, RPM, ACT, ECT, TPS , FLAGS1 are the only parameters that are part of the CPU overhead. To get to the nuts and bolts, any parameter address that is in the range of 00-FF is going to take CPU time. All of the other parameters will not add any more CPU overhead than what is already there. I maybe generally over stating what you will need but I think you get the idea.

[Cougar5.0]

Cougar I know where you are going with this. If you reduce the parameter that you select to the bare minimum while at the track it should be able to hit the RPM levels that you need. Even Ford put a parameter in the scalars that represents the reliable PIP count. If Ford cam up with this then maybe that is the limit no matter what datalogging device we have connected.

In your case, RPM, ACT, ECT, TPS , FLAGS1 are the only parameters that are part of the CPU overhead. To get to the nuts and bolts, any parameter address that is in the range of 00-FF is going to take CPU time. All of the other parameters will not add any more CPU overhead than what is already there. I maybe generally over stating what you will need but I think you get the idea.

Well, those are "must have" parameters when datalogging. It seems that the only way to get more reliable data at high RPMs is to either increase the clock speed or offload some of the high priority parameters to the LM-1 (or DataQ). Since I originally logged with the LM-1 even before I bought a TwEECer, I still have the input cable hardwired to the pins on the ECU for ACT, ECT & TPS. I'll try the later again, but I've previously tried to reduce the # of parameters logged without any success, though I wasn't aware that those with addresses in the first byte were high priority.

[dsblk93gt]

The only thing I don't like about it is the install, all else looks like it is a winner for sure. Most people are going to be leaving it in one car though so thats not a big deal, I'd like the option of quick removal for install in another one of my cars to datalog.

[cgrey8]

Cougar5.0,
I've been trying to get you some info about the QH's background loop improvements, but things just get in the way. 1st time, BE was misbehaving and I found I was only datalogging at 100ms. I tried again tonight to datalog at 20ms to find the USB pipeline wasn't fat enough to carry all the other crap I had datalogging at the same time. I got lines in the datalog that were 20ms durations, but NONE of the values were updating that fast because the QH couldn't get one payload response to the TwEECer that fast. I'm assuming that means this laptop only has USB1.1 ports. I'd expect a laptop with USB2.0 ports to not have that problem.

So, next time I attempt this experiment, I'll pair my datalogging down to the bare minimum of just RPMs, Load, and the Background loop count. With only those 3 datalogging, BE should be able to get updates from the QH in 20ms increments. It just couldn't do it with each payload update containing a few dozen payload options...31 payload items to be exact. Note though this wasn't a limitation of the QH. It was a limitation of the USB getting updates to BE fast enough. It's always somethin'! But I am trying to get that info because I'm curious to know myself if there's any notable background loop improvement.


dsblk93gt,
I take it you read over the FAQ on installing it? Keep in mind, the newer EECs don't suffer from these same install interferences. The older EECs used bulkier parts. As Ford migrated towards surface mount components, all the interferences with bulky components went away. But for the older EECs, installation is rather annoying. Craig did mention that he's been able to poke his finger through and get most of those components out of the way enough without taking the case off. I'm not that brave, but evidently it can be done.

[dsblk93gt]

Cougar5.0,
I've been trying to get you some info about the QH's background loop improvements, but things just get in the way. 1st time, BE was misbehaving and I found I was only datalogging at 100ms. I tried again tonight to datalog at 20ms to find the USB pipeline wasn't fat enough to carry all the other crap I had datalogging at the same time. I got lines in the datalog that were 20ms durations, but NONE of the values were updating that fast because the QH couldn't get one payload response to the TwEECer that fast. I'm assuming that means this laptop only has USB1.1 ports. I'd expect a laptop with USB2.0 ports to not have that problem.

So, next time I attempt this experiment, I'll pair my datalogging down to the bare minimum of just RPMs, Load, and the Background loop count. With only those 3 datalogging, BE should be able to get updates from the QH in 20ms increments. It just couldn't do it with each payload update containing a few dozen payload options...31 payload items to be exact. Note though this wasn't a limitation of the QH. It was a limitation of the USB getting updates to BE fast enough. It's always somethin'! But I am trying to get that info because I'm curious to know myself if there's any notable background loop improvement.


dsblk93gt,
I take it you read over the FAQ on installing it? Keep in mind, the newer EECs don't suffer from these same install interferences. The older EECs used bulkier parts. As Ford migrated towards surface mount components, all the interferences with bulky components went away. But for the older EECs, installation is rather annoying. Craig did mention that he's been able to poke his finger through and get most of those components out of the way enough without taking the case off. I'm not that brave, but evidently it can be done.

Yep! I did read that. I mostly mess with the 89-95 Mustangs

[Foxfan88]

where is this FAQ on installing it??

[svojohn]

where is this FAQ on installing it??

viewtopic.php?p=67858#p67858

[Cougar5.0]

Cougar5.0,
I've been trying to get you some info about the QH's background loop improvements, but things just get in the way. 1st time, BE was misbehaving and I found I was only datalogging at 100ms. I tried again tonight to datalog at 20ms to find the USB pipeline wasn't fat enough to carry all the other crap I had datalogging at the same time. I got lines in the datalog that were 20ms durations, but NONE of the values were updating that fast because the QH couldn't get one payload response to the TwEECer that fast. I'm assuming that means this laptop only has USB1.1 ports. I'd expect a laptop with USB2.0 ports to not have that problem.

So, next time I attempt this experiment, I'll pair my datalogging down to the bare minimum of just RPMs, Load, and the Background loop count. With only those 3 datalogging, BE should be able to get updates from the QH in 20ms increments. It just couldn't do it with each payload update containing a few dozen payload options...31 payload items to be exact. Note though this wasn't a limitation of the QH. It was a limitation of the USB getting updates to BE fast enough. It's always somethin'! But I am trying to get that info because I'm curious to know myself if there's any notable background loop improvement.

Please keep us updated! I've kind of had it trying to guess what happened in datalogs that look like the below (250mS update rate from the ECU even though I was logging considerably faster - notice the AFR data from the DataQ updates much faster):

[stanger007]

I've had the QH on about twenty five vehicles so far, Fox and SN95. It has been working great - props to Clint and Craig both.

I had to kick in the super quick datalogging on a Fox with BOSS motor/16psi S-trim that was revving extremely fast on the dyno despite the loading being applied from the rollers - worked like a charm.

My time to dynotune an EEC-IV car has been cut substantially and I have been able to do a lot of "gee wonder what would happen" experiments with the realtime updating.

Also Clint's nifty KAMRF trick is a hoot.

Wes

[David Claflin]

Also Clint's nifty KAMRF trick is a hoot.

Wes

What is this about??

[86GT]

There is a new screen in BE that will display the KAMRF tables for both banks. It is nice because you can see what area in the Load/RPM range where the MAF is off. Obviously this is only going to be avaliable on the QH.

[2Shaker]

There is a new screen in BE that will display the KAMRF tables for both banks. It is nice because you can see what area in the Load/RPM range where the MAF is off. Obviously this is only going to be avaliable on the QH.

Can you say more, I didn't follow this comment. Am I not able to do this using TwEECer on CBAZA?

[86GT]

Currently the tweecer does not support this. Basically you can see the instantaneous KAMRF using CalCon or BE, but on the QH we can monitor the entire RAM. So now we can see all of the stored KAMRFs for both banks. Take look at FN1325. The KAMRFs are stored in two table like this. I will see if I can get a screen shot.

[stanger007]

I can snag one off my ride if you need a screenshot.

Wes

[86GT]

Sure that would be great

[stanger007]

Here's one of our early screenshots - I have a tricky setup with my O2 sensors - the two banks are not both learning at the same time.

This'll at least give ya an idea of what we're talking about.

Wes

[2Shaker]

ok, thanks. Hmmm, I think that would be very useful.

[svojohn]

That's sweeeeeeeeeeet! When do I get mine??