[Frit]

I like the Moates hardware, but honestly now I'm doubtful about the Pegasus. I've got a bunch of guys that where waiting on the Pegasus to come out including myself, but alot of them now are saying screw it and going to buy the Tweecer RT instead because they can't wait any longer. Thats about 20 people that I know of.

I wish vendors wouldn't advertise something coming soon until its actually the truth .

Sorry ,just ranting.

Frit

[svojohn]

I feel the same, other than I already have the Tweecer RT.

Their website:

"New products in the pipeline for public release within the next month (September):

- Pegasus: Full dual RAM bank emulator for Fords through 2004. Bumpless updates, RAM shadowing, pseudo-datalogging via trace, full data capture via RAM analysis. This one will be fun. Target price is $250."

[TROYR615]

DOES AYBODY KNOW WHATS THE DEAL WITH THE PEGASUS ETA?I AM THINKING I SHOULD GO AHEAD AND GET A TWEECER!TIRED OF WAITING!MY CAR WILL HARDLY RUN

[86GT]

The last i heard was that Craig had to re design the package to fit inside one of the EEC Vs. It was a little to big. This was about two weeks ago.

[StangLx93]

i may be partial to moates products, yeah the waiting sucks but atleast you know he's not rushing things through so you know your getting a quailty product, im an impatient person, but you cant buy a piece of mind.

[Craig Moates]

Ok folks,

Everyone is asking, and I've been sorely remiss in keeping quiet. We've had our heads down taking care of all the standard 'life' stuff and getting this new product polished up and ready.

New project name: QuarterHorse
(someone else wanted to use all of the mythological creatures / Dungeons and Dragons monsters, so I let them have the 'Pegasus' name for an unrelated offering to avoid confusion)

Status updates:
- In summary: 110% Success!
- Form factor adjusted to fit nicely in all the EEC-IV and V packages.
- Datalogging on the A9L/A9P advanced significantly. Both bench testing and in-vehicle completed.
- Most data can be picked up WITHOUT CODE PATCHES, and the rest can be harvested with some minor register shuffling.
- Several custom code patches were implemented successfully during testing to move values around, pull ADC directly, render internal timers/counters, etc.
- Thanks to Paul Booth for helping me get my head around the 8061 stuff. Thanks to others too, but Paul's the man!
- Performed live datalogging at 500+ frames per second, ALL data in external RAM is shadowed accurately. Internal registers can be (and have been) remapped as visible with patches if necessary.
- Simplified protocols for high throughput and easy legacy compatibility updates.
- Details to follow for you software architects out there, but look forward to an instruction set that has been streamlined.
- 100% nondisruptive realtime updates, you can upload entire binaries back and forth / over and over without disturbing vehicle operation at all.
- We're digging into the BMD0 strategy (Marauder test vehicle) to flesh out the EEC-V datalogging at similar data rates if not faster.
- We're actually polling the EEC_IV stuff faster than it updates internally (see spreadsheet). Maybe the EEC-V will keep up with us? Nah.

Future 'nice to have' Features not available for introductory release but (possibly) to be added later (will likely incur additional cost and require bench update by sending it in):
- Multiple binary loading for EEC-IV, possibly EEC-V also.
- Remote breakout box accessory device for black-box logging capabilities, data display, remote switching, ADC channels, Bluetooth, etc.
- EEC-read capabilities to read 'stock' ECU contents like the F2E or EECSucka-type devices.

Production and distribution status:
- Rare species! Three units in existence: one has been in the field with Jody at DP-Tuner for months doing emulation on the Powerstrokes, one is in my hands, and one is on its way to Paul Booth for delivery on Wednesday.
- 10 new boards are in hand, to be completed for further field testing and development this week: There's a short list of folks who have helped and have one of these coming to them. You know who you are, so no need to ask. You'll be getting your units within 2-3 weeks from now, software guys obviously get priority.
- First 50-100 full production units are to be completed and available by February. I'm serious this time, no more schedule stretching!
- Pricing will be $249 initially, not to exceed $295 later on. Available from http://www.moates.net

Here's your data preview:
http://www.moates.net/zips/testa9l.zip (watch out, it's 8 megabytes unzipped!)

It's just under a minute's worth of data, but there are almost 150,000 datapoints (5 parameters HEGO1/HEGO2/RPM/MAF/TPS at around 500 frames/sec). There's loads of optimization still available, theoretical limits are much faster. But again, we're hitting the parameters faster than the EEC can keep us posted, so we're well into the overkill zone on much of this. And that's where I want to be.

What will you possibly do with all of this data? That's up to you, it's your vehicle!

Hope this helps,
Craig

[cgrey8]

Hopefully Clint and sailorbob will be able to get their hands on one of these so they can get BE updated to support it. At that point, I'm sure this will end the reign of the TwEECer RT for GUFx, CBAZA, and whatever other strats are decently supported in BE.

Craig, question for you...can you download this device with, say, a GUFB BIN and have it correctly execute on a GUF1 (A9P) EEC? You can't do that with the TwEECer, although from previous conversations with you, it seems you can do that with your Moates chips. I suspect the problem is the TwEECer doesn't immediately "take control" of the MBus and thus it is letting the ROM execute just long enough to establish the stack in RAM. And flipping to another strat after the processor has already started executing just doesn't work...at least not flawlessly. I'm just curious if you've tested that you can, indeed, put a GUFB A9L or X3Z tune in the Quarterhorse while it is installed on a GUF1 A9P or GUFA A9S EEC.

[Craig Moates]

Howdy,

Yes, I did testing with A9P code on an A9L box in-vehicle (A9P car) and it was fine. This is opposite of what you suggest, but the inverse should hold as well. Sensor data was actually in the same place for the most part in RAM. Calibration parameters of course are not. This device boots up faster than the EEC and everything is ready to go at power-up, so there shouldn't be any issues.

There should also be no incompatibility or problematic issues with PATS etc.

Clint's on the short list, no worries.

No need to end the reign of whatever is out there, plenty of good options already. This is just a different animal entirely.

-Craig

[86GT]

Wow cool

I am anxious to see it in action.

[Cougar5.0]

Interesting.

[cherrybomber22]

woooo!! cant wait for this one more question tho what widebands will be compatible with this any or is there some specific i may need

i have an aem that has a 0-5v output am i going to need another one?

[cgrey8]

I would expect WBs to work exactly like they always have. If you wire it into the EVP, then BE will scale it as it would coming from the TwEECer. If it is wired to a DataQ, then again it has nothing to do with the tuner/datalogger.

[86GT]

I would believe Chris is right.

[cherrybomber22]

what kinda time table are we looking at before BE can support the 1/4 horse

i am counting my pennies already so i can get it lol....

but would like to use it with BE since i am very familiar with it and its the shiznit



not being an ass or any thing guys just wondering

[Craig Moates]

First 50-100 full production units are to be completed and available by February.

I'm sure Clint will have it all integrated by then, he will probably have his unit by next weekend to play with.

[cherrybomber22]

awesome i know that the 1/4 horse will be compatible with tuner pro RT and EECEDTR but haven't used either one so i guess thats while i am partial to use it with BE but hey if BE ain't ready when it is released then no biggie i will just use another software till it is good to go

[cgrey8]

Being I have a TwEECer in my daily driver, I can datalog and test BE for code updates twice a day going to and from work and have frequently helped test and debug pre-release versions of BE to make sure whatever new feature is solid before Clint releases it. Quite often Clint will work LATE into the night getting some feature ready for me to test. I'll test it the next morning. Report my findings and quite often, he'll have another version for me to test on the way home.

Since the addition of QuaterHorse (QH) support is such an important and huge addition to BE and the Ford tuning community, I was hoping to get one of the early QHs to help Clint test and debug BE with so BE could get up to speed faster and ready for public consumption by Feb. But it doesn't look like that will happen. Hopefully with Clint having his own to work with, he'll have enough sorted out by then that by the time the QH releases, BE will be stable enough for public use. It's just unfortunate that I don't really "need" the QH at this point in my tune. My tune is quite stable and mature with only very few tweaks being applied as I "catch" things happening I don't like. And to do those things, the TwEECer RT works just fine. So my only real incentives in getting the QH would be to help with BE dubugging and just to get some hands-on experience with the latest-n-greatest new thing so I could help answer questions about it as they arise here on the forum.

[Craig Moates]

Don't worry Chris, you're on the short list too right along with Clint. Derek's on there as well ;^).

[cgrey8]

I assumed I wasn't. Just let me know when I need to send payment.

Clint, let me know when you got something for me to test.

The #1 thing that will be an absolute luxury over the TwEECer is the ability to write a single parameter change without "hiccuping" the EEC. I'd find that extremely useful just for what I do, but I have to believe having that ability is a MAJOR time saver sitting on a dyno.

[86GT]

I think i have BE ready for some initial tests on my own test bench. I am almost positive that I have the reading and writing down pat. I just need to play with the live update and the logging. I have done some of the preliminary coding, so it should not take to long. The biggest challenge for me is to keep all functionality working with all other hardware without breaking something. Like chris said I will be getting him copies of pre releases of BE to help test with.

My goal is to not change any of the common layout of BE. I want the new hardware to be seamless to end user. All you will have to do is enable the MOATES on the hardware tab.

[Cougar5.0]

I'm interested in the logging capabilities - it would be nice to have some reliable data above 5500 RPM or so - currently the data is spotty at best and makes tuning the top end (especially at the track) somewhat of a crap-shoot.

[cgrey8]

I expect the QH will be able to return values faster than the TwEECer can because the QH will have a mirror image of what is actually running in RAM vs the TwEECer which relies on the EEC to relay key values to it. Some values will still need to be relayed, but they'll only be the values in the internal EEC registers. All other values like the LAMBSEs, MAF, Spark Adv, etc will be as up to date as the EEC is. The catch is the EEC's own background loop runs very slowly at the high RPMs with or without the datalogging patch code overhead...and target AFRs and Spark Adv target values are calculated via the background loop. The good news is the datalogging patch code overhead required for the QH is MUCH less invasive than the TwEECer's patch code is. That should help EEC background loop performance.

[86GT]

Chris summed it up best. The only thing I can add is the fewer the payload parameter you select that are in the address range of 0x00 and 0xFF will speed up the background loop of the EEC.

[cgrey8]

The UI challenge will be communicating to the user which parameters are "free" and which ones require datalogging "assistance" and thus have an EEC performance hit. The good news is on GUFx defs, there's only about 15-16 things you might want to datalog from the internal registers. The rest are all things external in the EEC's RAM where the QH can access directly. The newer EEC-V era EECs will be the ones with potentially 30 or so parameters from the register space. But if that's all it is, then that's STILL easier on the EEC than the 32-byte TwEECer patch code is currently.

Once I get some time on the QH and BE, I'll write up an FAQ documenting the pros and cons of the TwEECer vs Quarterhorse so people can make an informed decision as to which direction they want to go. There are already some things I can comment on, but by far there are more pros on the side of the Quarterhorse side than the TwEECer. But like you might expect, there are some things the TwEECer has over the Quarterhorse. But for the difference in price, I don't think the TwEECer brings nearly enough to the table to be a competitive option.

[Cougar5.0]

Thanks Chris, I'll be looking forward to your write-up.

[cherrybomber22]

woot woot ill be looking forward to it as well cant wait thanks every one

[cgrey8]

I have a new Installation doc with pictures in the FAQ. We don't yet have the QH working in BE flawlessly yet. There are BE and QH updates to go. Clint's on BE and is working those out, but finding all the firmware issues in the QH is taking a bit of trial-n-error...and just beating it up. Craig's to get us beta testers QH updates in the next day or so.

Again, BE gets up and running. I'll be able to make a much better article on the Pros and Cons of the QH vs the TwEECer RT.

[dsblk93gt]

Very interested in seeing how this works out...

[Foxfan88]

looks awesome, the super fast datalogging is going to help out alot for the WOT tuning. and the fast BIN changes without hiccups is going to rock also. should make for some quick accurate tuning.

one thing i havent heard about yet on the QH, maybe i overread it somewhere, but are will limited to one tune on the EEC or will we have some sort of switch box for multiple tunes like the tweecer has??

[cgrey8]

In the preliminary stage, there'll only be support for 1 tune. However I believe it is on Craig's to-do list to get a 2nd tune into the QH if that's possible. But based on the memory size of the QH, there's no way you can get more than 2 tunes into the QH and keep the QH behavior generic between single bank and 4-bank EECs.