fiestaturbo.com

[sailorbob]

Taken from a post, of today, from the http://www.eectuning.org forum;

The Pegasus is a realtime emulator with trace and some RAM shadowing capability, all built into a module about the size of a regular J3 chip module. I've had it kicking around for a couple years in various forms, an early version used NVSRAM. You could think of it as an Ostrich2.0 and FordEmu rolled into one package like an F3. Just a mini USB (or Bluetooth) going back to the PC. Various projects have kept me sidetracked, but I'm committed to drive this thing to completion in short order.

I've got prototypes on the bench, working in vehicle as well. With some of the newer EEC boxes, we face a pretty steep challenge with respect to timing events on the bus which allow enough of a window to read/write without disturbing things. I've found segments on the order of 300 nS or so, and I can carry out all of the write cycles and such directly from the CPLD on a trigger basis when certain windows open up, but the CPLD I'm using is just chock full right now. Between the regular J3 logic, all the PC-side / micro-moderated read/writes, trace capabilities, and smartwindowing for the write timing, there's nothing left for some other fancy stuff I have in mind.

So, with that being said, I'm shifting gears a little bit. I've got some decent architecture already for a full parallel-ram-banked 16-bit emulator that is totally bumpless for the LS1/28F400/800 applications. Borrowing some lessons learned from that experience, as well as many of the protocols, I'm fast-tracking a newer design for the Pegasus that will give much more headroom for feature creep. With dual 512k SRAMs, 288 macrocells of logic, and a good firmware foundation to start with, I think this will be the lead horse in very short order.

By having full access to both RAM banks, having extra room in the memory space, and plenty of room in the logic array, we should be able to shadow all kinds of content out to the module and access it at any time without any disturbance whatsoever. The same goes for the reads and writes to 'rom' on the banks. Having the full dual architecture allows me to synchronize all access and switching at the logic level.

Having this sort of additional architecture will drive the unit cost up a bit, but I think it's the right thing to do. Most of what I've been fighting recently is trying to cram the features I want onto the chipsets I'd chosen previously. Now, the limit will be knowing when to stop adding.

The unit will be command-compatible with the Ostrich 2.0 in terms of read/write/trace, so all the work that Clint, Paul, and others are doing will dovetail nicely. That along with solid RAM shadowing, as well as code patches to the EEC to externalize values of interest in structured, accessible, and contiguous fashion, should give folks what they want in terms of functionality.

Anyways, that's the lowdown inside scoop. Hope that helps. Target pricing is definitely sub-$300 retail. I'm really hoping to have the development work completed by the end of next month (March) and have units available for people that would be interested in April.

This has been in the pipeline for a while but is getting closer by the looks of it It promises pretty much to be the ultimate in eec emulator and datalogger.

EDIT: Changed web page link to a quote
EDIT: Changed title from 'on it's way.....' to 'available'

[Ollybee]

You need to be a member.

[sailorbob]

Hmm, you didn't used to need to be, but the forum has been suffering from too much spam recently and one of the moderators has been taking steps to reduce this and this is probably one of the things they have changed. I have copied the important bit and added it my first post.

[Ollybee]

[Ollybee]

Ok. Bob, fancy a translation of all that, I don't understand. What's purpose other than data logging?

[sailorbob]

In a nut shell;

Datalogging - any parameter the eec uses will be dataloggable, if it's stored in ram you will be able to log it.

Emulation - real time tuning of the eec, any parameter stored in the eec's rom can be altered whilst the engine's running.

Trace - allows you to snoop on an area of rom to look for the program accessing it.

Emulation has been around for a while, e.g. using Moates Ostrich, Tweecer or EEC Tuner but datalogging was limited with the EEC Tuner, quirky with the Tweecer and not possible with the Ostrich. If Craig manages to stick to his target price this is a major saving over the cost of the other devices. We will just need the software to catch up

[jammy86]

woohoo moates doing ford stuff

A mate of mine has been using moates stuff for some time now. He's a good chap is craig.

JAmes.

[sailorbob]

Craig's been doing stuff for Fords for a couple or so years now but never had a datalogging solution. I've been holding off buying a Tweecer waiting for this.

[sailorbob]

It's been almost a year but here's the latest information posted today

Craig Moates wrote:
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

[jammy86]

Just as I've decided to ditch the EEC-IV. Well a few months after

JAmes.

[sailorbob]

It's looking very good My eec-iv datalogging patch code has been tested (by others) and 49 parameters have been datalogged at a 15 mSec update rate, far faster than the update rate of the ecu at high rpm. Apparently the rate of the hard disk to accept the data prevented even faster speeds being achieved Since a practical rate for datalogging is 50 mSecs though this is academic and just for fun to see where the limits are

[sailorbob]

These have been shipping for a a couple of weeks now, mine arrived yesterday It's a very neat and compact board, looking forward to getting it plugged into an eec.

[jammy86]

Let me know how you get on with it.

JAmes.

[sailorbob]

Forgot to mention, currently it's priced at $249 so with shipping it costs about £200 (excl VAT and customs charges) at the current exchange rates.

[sailorbob]

Bench tested the QH with a DEWY ecu today. All seemed good, did a ram trace and I could see various timers running and the stack being used

A couple of pictures;


The Quarterhorse itself


And as fitted to the DEWY ecu

[fil2efly]

Just been reading though a load of posts regarding EECiV ecus and the products offerd at http://www.moates.net and i must say im realy intrested.

Have you (or anyone else ) has sucsess of remaping a eeciv ecu though the use of this "Quarterhorse"? Iv been tempted for a long time to go for a megasquirt or the like to squeese every bit out of the 2.0L in my fiesta however in the light of these products being avalible id be very intrested in seeing what they have to offer. Plus i realy like the idea of having switchable maps.

Also would it be posible to transplant maps from one ECU to another? aka the map from my DESK ecu to say a ENVY ecu?

[sailorbob]

Lots of people have had success at using the QH, mainly in the 'States with several hundred units sold.

If the hardware is correct then you can run the code form one ecu on another (see ecu-program-map-differences-updated-20-08-05-vt110061/).

[fil2efly]

cool thanks