The ‘Data trace’ feature of our emulators is probably one of the most misunderstood features.  Trace is intended to give you some idea of what portions of an emulated ROM are being used by the target system as a last resort when you don’t have a way of establishing communications for logging.  Trace is a feature supported only by the Ostrich 2.0 and RoadRunner (with latest firmware).  This article exists to document what Trace is, how it works, what it can do, what kind of limitations exist and how it can go wrong.

In order to understand how data trace works, it is necessary to understand the electrical signals used by a microcontroller in your ECU (or target system) to access RAM or ROM using parallel access.  There are many explanations of this out there but this one seemed decently concise.  It will also be necessary to understand the commands used to set up Trace and the mechanism that the emulator uses to gather and report data back to the PC, along with what happens to that data in the application running on the PC.  It will also be very helpful to understand TunerPro RT definition creation.

Bottom line: Trace is complicated, finicky, temperamental and is not designed to provide the same kind of steady, consistent data that can be obtained through communicating with the ECM using some form of data logging.  Our emulators were NOT designed from the ground up to provide 100% accurate address trace data and we do not expect them to be able to deliver that level of performance.

What Trace is and How it Works

Normal operation of the emulator is the PC sending commands to the Emulator to make changes to emulator memory, allowing changes in a “chip” to be made without having to stop, remove, reprogram and reinstall the chip.  The Emulator has a microcontroller which is responsible for receiving and processing commands from the PC and communicating with a memory controller.  In order to allow changes to be made without disturbing the target system, our emulators sneak updates from the PC in between accesses by the target system.  (If the target expects data too fast, glitches may occur caused by collisions between PC and target memory access.)

Trace allows an application that sends the specific appropriate setup commands to the emulator to monitor which addresses the target system accesses.  When trace is enabled, the microcontroller on the emulator starts querying the same memory controller used for realtime updates to see which addresses are queried by the target system.  In order to determine which memory is accessed, two main signals are monitored by the memory controller:

1. The address lines on the emulator, used by the target system to specify which data it wants to see
2. The !OE (Output Enable) and !CE(chip enable) pins, which are used by the target to control the timing of a data output request

After the control lines indicate memory access, the memory controller stores the last address used by the target system.  As fast as it can, the microcontroller retrieves the address information from the memory controller.  Addresses responses are always 3 bytes and take (minimum) 8 MCU clock cycles or around 0.6uS to retrieve from the memory controller.  Setup commands sent by the PC control how the Emulator handles each address retrieved from the memory controller.  It can either store/buffer, send to PC or ignore the received address and wait for another hit.  If you are curious, you can look at the setup command structure in our documentation.  It is possible to control the range of addresses which trigger a match, the number of address hits to gather before reporting to the PC, whether addresses are streamed continuously or reported once before returning to normal control, whether duplicate hits are reported multiple times or once, the format of responses in terms of number of bytes reported and more.

Our emulators communicate with the PC at 921,600 baud 8N1 over a FTDI USB-Serial connection.  This means that approximately 102,400 bytes can be transferred each second, and each byte takes about 10uS to send.  The system is bandwidth-limited because it can gather trace responses from the memory controller faster than it can supply them to the PC.

Software Support

At this point (April 2020) the only softwares that have implemented support for data trace that we know of are TunerPro RT and RenoVelo Domino.  Specific software support for the trace feature is REQUIRED.  An application that supports the realtime tuning / emulation features of our products (i.e. EmUtility) may NOT support trace at all.

While we do not develop it in house, TunerPro RT is our reference platform that we use internally for testing and product development.  There are two methods of using the Trace feature of a compatible emulator in TunerPro RT.

The Address Watch Utility: (Note: it is “greyed out” / unavailable in this screenshot because I didn’t have a compatible emulator plugged in)

Trace can also be invoked to watch individual tables: (again, “greyed out” / unavailable in this screenshot because I didn’t have a compatible emulator plugged in)

Looking at the control protocols, an example auto-generated “T” command sent by TunerPro RT to the emulator to set up trace after clicking the ‘A’ icon appears to be

"54 23 00 00 01 01 08 44 38 08 44 73 BC    /      T#.....D8.Ds."

• Control byte = 23: 0b00100011
• NO streaming
• report only windowed hits
• report all
• normal addr triggers
• relative addressing
• single hit buffers
• single byte address report
• windowed report (relative  vs. absolute address reports)

What can go wrong with Trace? / Limitations

I’m sure Trace sounds great, like the perfect solution for ECUs where limited communication is possible.  Unfortunately, there are many ways for trace to go wrong and not act like you might hope or expect it would.

1. Memory controller limitations: missed hits inside the emulator.  The memory controller does not buffer memory hits.  It only reports the last accessed address.  The speed at which the microcontroller queries the memory controller limits how many hits can be captured.  As discussed, it takes several MCU clock ticks do retrieve data from the memory controller. In ~0.6uS, at least 5x 100nS memory accesses can happen, all of which would be missed by the trace system.
2. Processing received addresses: missed hits inside the emulator.  It takes time (albeit a VERY short amount of time) for the microcontroller on the emulator to process address hits and decide what to do with them.  As it does not query the memory controller when deciding what to do with an address hit, this limits the speed at which it can query the memory controller and limits how many hits can be captured.
3. Bandwidth / PC: missed hits due to serial comms.  This bandwidth and latency limitation is inherent to the hardware design and will not change.  There is very limited bandwidth to communicate with a PC compared to the speed of memory access.  It takes around 10uSec to communincate the shortest format abbreviated address hit in streaming mode.  That means around 100 memory accesses (at 100ns) can occur (and be missed) by the target during the time it takes ONE Trace hit to be communicated with the PC.  Multiple byte responses (which will be necessary for larger monitor windows) will require 2 or 3 times as long for communication.  These are best-case figures, assuming streaming mode.  If a single response is sent followed by a new command setup, the latency of the process could be increased by a factor of 20 easily.  (Note: single response is the default monitoring scheme for TunerPro RT commands.)  If a large number of address hits are buffered and then bulk transferred, the latency between each hit is significantly decreased but the time to communicate with the PC is significantly increased, leading to a longer pause in between each group of responses.  Bottom line: serial communication limits the maximum potential address hit capability to a fraction of bus speed.
4. Addressing mix-ups: software/XDF.   Under XDF … Edit XDF info it is possible to specify chip size, offset parameters.  TunerPro uses the address of the table in the XDF for the start and stop addresses it sends as part of the Trace setup command.  The XDF setup parameters control the relative location of tables within TunerPro’s memory model.  These need to be specified in a way that the addresses TunerPro RT uses for representing the bin on your PC match how the Ostrich stores the bin in its memory.  The addresses matching allows TunerPro RT to match the Trace command responses it receives from the emulator with the correct bytes stored in PC memory and show you which bytes in a table are being accessed.  If the memory models differ, TunerPro RT will never show any bytes in the table being accessed because the responses to the Trace commands don’t match with the information it has in memory.
5. Memory Shadowing: target system behavior: “Shadowing” refers to the practice of an embedded system copying memory from one place to another before using it.  In many cases, slow flash or ROM chip memory is copied to faster RAM memory and then accessed in RAM during normal operation.  In this style of use, there are no ROM accesses to trigger Trace hits after the initial shadow.  While this does not often happen, it is controlled by the target system and is not under the control of our emulators.

Conclusion

Trace was a “nifty extra” added to our emulators because we could and figured it might be handy in some cases.  We did NOT design our emulators around being able to deliver completely accurate and precise address tracing.  We do not have any plans to improve the data Trace feature.  We do not have any plans to release an emulator that has better trace performance.  Our emulators were designed to take the place of a chip and allow realtime changes – this they do well.  Trace should be considered a “bonus feature.”  Do not rely on it to gather all the data needed to tune an ECU.

Emulation cables link our emulators to a target device.  The Ostrich, Ostrich2 and APU1 all use a similar style emulation cable.  The design of this cable has not changed in many years.  Four standard “shelf” cables are available:

• EMUC2818 is the standard cable supplied with the Ostrich, Ostrich2 and APU1 emulators.  It has a 28 pin chip side (“28″) and is 18” long (“18”) hence EMUC2818
• EMUC2806 is a shorter cable (6″) with a 28 pin chip socket.  It is useful for situations where there is interference with the standard length cable.
• EMUC3206 is a short (6″) cable with a 32 pin chip socket.  When used with an Ostrich2 it allows emulation of a 29F040 4Mbit EPROM.  Adapters can be used to change this to PLCC or other formats.  This cable is NOT compatible with the Ostrich 1, APU1 or ChipExtender – Ostrich2 ONLY!
• EMUC2836 is an extra-long (36″) cable with a 28 pin chip socket.  It is NOT for use with emulators.  This cable is only intended to be used with the ChipExtender product we sell.  Unpredictable results can happen when used with emulators.

The RoadRunner uses an alternative emulation cable which is incompatible with other devices.

Ostrich and APU1 Emulation cables

The Ostrich, Ostrich 2 and APU1 all use the same emulation cables.  These cables have a 0.1″ pitch rectangular connector on one end.  On the other end, a male chip connector is crimped.  Before shipping the cable, we install a machined-pin socket on the cable to protect the more fragile chip connector.

This is how one of the cables looks when we ship it:

As you can see, you can remove the 28 pin machined-pin socket on this cable if necessary:

Replacing a MP socket is much easier and cheaper than replacing a whole emulation cable!

RoadRunner Emulation cables

The roadrunner uses unique cables designed to connect RR hardware with a soldered-on POSOP44 pin header.  Typically, two of these cables must be connected back-to-back for proper operation.

More will follow.

Introduction / Identification

Ports and Connectivity

Software Support

As of 5/5/2014 software support is as follows:

Neptune: Full emulation+data+onboard (stable)
ecTune: Emulation+data (stable)
Crome: Emulation+data (some versions)

Please note that each Demon has a serial number – NepTune and eCtune both license a single copy of the software to a single Demon.  The exact procedure for this is different for each software package.

Datalogging Memory

Demon II units have 4Mbyte (32Mbit) memory.  This is enough for several hours of logging at full speed on all channels, with compression turned on.

Switching Between Software

You can now more easily switch among the different applications using our Config Utility for resetting the state of your Demon.

Indicator Lights

Light behavior on the Demon II is the same as the 1.9+ Demon firmware.

The red LED serves as a hardware status indicator and/or busy light.

• Red light on solid = not receiving power from the ECU: physical connection issue to ECU
• Red LED will blink when logging packets are being captured

The green LED is more of a data packet and status indicator light.  It typically behaves as follows:

• Solid green light when the Demon is powered on and all systems are go but no packets are being received
• Green light is off when the device is busy OR Demon is powered off
• Fast green blinks mean the Demon is receiving good datalogging packets from the ECU.

Troubleshooting:

• Red light onwith USB plugged in means the Demon is NOT receiving power from the ECU.
  • You will only see this condition when the Demon is being powered by USB
  • Check 28 pin socket bridge pins and connection
  • Check ECU CN2 – 4 pin port connection.  This is REQUIRED for proper Demon operation
• Green light off means no power to ECU.  Red on / green off is expected with no power.
• No lights at all when USB is plugged in generally is a fault condition.
  • Try removing the Demon from the ECU.  If the Red light comes on, check the chipping job and physical connections between the Demon and the ECU

Introduction / Identification

Software Support

As of 11/03/09 software support is as follows:
Neptune: Full emulation+data+onboard (release)
ecTune: Emulation+data (release)
Crome: Emulation+data (beta)
Please note that each Demon has a serial number – NepTune and eCtune both license a single copy of the software to a single Demon.  The exact procedure for this is different for each software package.

Datalogging Memory

The first production runs of Demons have 1 Mbyte memory for storing datalogging.  Current (starting around April 2010) production units have 4Mbyte memory.  Early production units can have their memory upgraded.  If you are interested in this service, purchase the Install Service item and note in the “Comments” field of your order that you would like the Demon memory upgrade.  You’ll have to send your Demon back to us – turnaround time is normally about 2 weeks.

Switching Between Software

You can now more easily switch among the different applications using our Config Utility for resetting the state of your Demon.

Indicator Lights (1.8 and older firmware)

The Demon has two LEDs to indicate its status, one red and one green.

The red LED serves as a hardware status indicator and/or busy light.  It can come on when:

• Demon is currently processing a command (upload/download/etc)
• Poor / nonexistent connection between Demon and ECU 28 pin socket.  (usual cause: faulty installation)
• Poor / nonexistent connection between Demon and ECU CN2 port.  (usual cause: cabling, cable backwards, faulty installation)
• Demon is powered via USB but there is no power to ECU
• NEPTUNE RTP ONLY: No serial communication between ECU and Demon
• Red LED will blink when onboard packets are being stored to memory

The green LED is more of a data packet and status indicator light.  It typically behaves as follows:

• Lights up solid green when the Demon is powered on
• Blinks when the Demon is communicating with the ECU (assuming data packets are configured correctly)
  • Fast blinking means data is flowing properly from ECU to Demon via CN2
  • Slow blinking likely means data timeout / incorrect connection/configuration

Indicator Lights (1.9 and newer firmware)

Light behavior has been changed in the new firmware.

The red LED serves as a hardware status indicator and/or busy light.

• Red light on solid = not receiving power from the ECU: physical connection issue to ECU
• Red LED will blink when logging packets are being captured

The green LED is more of a data packet and status indicator light.  It typically behaves as follows:

• Solid green light when the Demon is powered on and all systems are go but no packets are being received
• Green light is off when the device is busy OR Demon is powered off
• Fast green blinks mean the Demon is receiving good datalogging packets from the ECU.

Troubleshooting:

• Red light onwith USB plugged in means the Demon is NOT receiving power from the ECU.
  • You will only see this condition when the Demon is being powered by USB
  • Check 28 pin socket bridge pins and connection
  • Check ECU CN2 – 4 pin port connection.  This is REQUIRED for proper Demon operation
• Green light off means no power to ECU.  Red on / green off is expected with no power.
• No lights at all when USB is plugged in generally is a fault condition.
  • Try removing the Demon from the ECU.  If the Red light comes on, check the chipping job and physical connections between the Demon and the ECU

The RoadRunner is the only available full blown emulator for LS1 PCMs – unlike other “emulation” software, the entire contents of the flash is emulated Real-Time, not just certain maps.  It can also be used as a general purpose emulator in custom applications (Bosch Motronic, BMW, Miata, Nissan, …)  It is designed for PSOP44 chips like 28F200 28F400 28F800 29F400 29F800

Hardware Available

At this point, there are two (and a half) versions of RoadRunner you can buy:

1. A RoadRunner pre-installed in a rebuilt 12200411 GM LS1 ECM.  This is intended for all supported GM applications.

2. A RoadRunner “guts kit” containing just the raw circuit board, cables and hardware to mount the device in place of a 28Fx00 EPROM.  This is intended for all custom applications.  If you purchase the guts kit, you should specify whether you want a 512k (28F400) or 1024k (28F800) version. (we’re counting these two variants of the guts kit to get two and a half)

GM Compatibility

At this point (August 2009), there is only ONE officially supported target for the Roadrunner: the 12200411 (or just “411”) ECM.  The 12200411 is plug-and-play with ’99 and up Corvette LS-1’s (throttle-by-wire), ’99 and up Camaro/Firebird LS-1’s (cable-throttle), ’99-02ish Gen III Vortec trucks (cable throttle), ’00-02ish Gen III Vortec trucks (throttle-by-wire).  The 12200411 can also control 4L60E and 4L80E transmissions.   In case it wasn’t clear from the application list, the ‘0411 can control both drive-by-wire and drive by cable engines – pretty much any GM vehicle with a 24 tooth reluctor wheel(“24x”) is fair game for full sequential fuel and spark operation.  The ‘0411 can also be used to run 97-98 LS1s with minor rewiring or “green plug” 1024k PCM vehicles with slightly more extensive wiring changes.  It can also be used with a Van OS to run distributor applications with only a 4X reluctor.  The ‘0411 can also be used to run LTx/Gen2 retrofits with a custom conversion kit from EFI Connection.

Please note that the RR does *not* function identically to a “normal” PCM in terms of long term keep-alive memory.  When you turn the key off with a RR PCM, the PCM will reset every time.  If you need to pass emissions or do other functions that depend on this memory, you may have to use a normal PCM.

Later (LS2/LS3+) engines switched to a different style ECM (E40, E38, E67, E37, etc.) that is electrically incompatible with Roadrunner.  There will never be a RoadRunner for any late-model ECM.  Period.

Late model engines also switched to a different style crank trigger setup (58X / 60-2) that makes it impossible to use a LS1 ECM to run the engine.  People have succeeded in using a RoadRunner in a 411 ECM to run a late model engine by a combination of creative wiring changes and swapping the crankshaft reluctor to a 24 tooth unit.  This is not for the faint of heart.  We do not officially support this application so we can’t really assist you with this conversion, but again we’d recommend Mike at EFI Connection as a capable source for wiring and conversion needs.

Unsupported GM Applications

Previously, a Bluetooth option for Roadrunner was available.  This has been discontinued – it is no longer available.  There are no plans to offer this in the future.

Previously, there were Roadrunner versions available for LB7, 1024k PCMs and 98 PCMs.  All of these applications had issues which is why we no longer offer “ready to run” Roadrunner PCMs from these families.  These have been discontinued – we cannot guarantee that these applications will work fully.

Why did this happen?

• 97-98 LS1 Core PCMs are hard to find.  The 99-02 PCMs are superior and can be made to work in 98 applications with little effort.  If you’re bound and determined to use a RR in a 97-98 PCM, you could try this at your own risk but we strongly recommend conversion to an ‘0411 PCM.
• LB7 PCMs come in several flavors.  Early PCMs lacked a driver that later PCMs had, making them incompatible.  Also, RR equipped PCMs had a tendency to present an invalid VIN.  This did not appear to affect operation, but…  VATS was also sometimes a concern and may need to be disabled.  Combine these issues with the extremely limited supply of Core PCMs and we decided to no longer offer a “ready to go” LB7 Roadrunner.  For a TUNER, none of the issues on this platform should be a show stopper but we would recommend caution in a daily driver application.
• 03-08 1024K LS1 PCMs may all have 1024k of memory but they do NOT appear to be universally compatible.  During testing on an 05 Avalanche, there was a significant number of no-start conditions while using a stack of “random” 1024k PCMs fitted with a RoadRunner.  It was not determined whether this was due to differences in PCM hardware, The RoadRunner or another factor.  The decision was made not to offer a ready-to-go RoadRunner for vehicles requiring a 1024k PCM.

Getting an Unsupported RoadRunner

If after reading why we no longer offer a RoadRunner for a PCM you have and you still want to try it, there are options.  If you want to try one of these applications, you will need to either:

• Send us a Core ECM.  Order a RR Guts kit.  Order the RR Install service.  Receive the PCM you sent us back with a RoadRunner installed
• Order a RoadRunner Guts kit.  Install it yourself.

Please note that these applications are UNSUPPORTED meaning that if you have strange problems, we aren’t going to be rushing to revise the product in order to solve your issues.  These are intended for advanced users capable of troubleshooting and working independently.  Use at your own risk!

GM Software Compatibility

EFILive natively supports the RoadRunner.  In order to use it with EFI Live, you must purchase the Roadrunner license.  After purchasing the license, you can use the Roadrunner in any vehicle supported by the ECM.  You can tune as many RoadRunner equipped ECMs as you like – you do not need to buy additional licenses for additional RoadRunners.  If you want to flash a copy of the program in the Roadrunner into the vehicle’s original ECM, you can do this but standard EFI VIN or Stream licensing fees will apply.

TunerCAT OBD2 Tuner natively supports the RoadRunner.  Existing OBD2 Tuner customers can simply buy the RoadRunner upgrade.  There is a package that includes one definition file which is intended for people who want to use RoadRunner and TunerCAT to tune only one vehicle.  There is an add-on ***ONLY AVAILABLE FOR ROADRUNNER USERS*** that includes the WinFlash cable allowing you to reflash vehicles with TunerCAT.  There are also all-LS1 and all-supported-vehicles packages.  ***AGAIN, YOU MUST BUY ROADRUNNER HARDWARE TO BE ABLE TO BUY TUNERCAT OBD2 TUNER.  NO EXCEPTIONS.*** Updates for TunerCat Roadrunner users are available on the “Additional Links” section of the product page for RRTuner and WinFlash on our web store.  These links are updated to always point to the most recent version available.

Other Applications / Technical Specifications

The RoadRunner has been used successfully as a general purpose 16 bit data bus emulator for applications other than GM LS1.  (Bosch Motronic ME7.1 comes to mind.)   The RoadRunner uses the same FTDI USB-serial bridge as our other products, appearing as a COM port to the operating system.  It is designed to emulate a 28F800 (0r 28F400, 28F200, even 28F100) chip operating in 16 bit data bus mode.  The 28F800 is capable of presenting data in both 8 and 16 bit selectable modes, but the RoadRunner does not support this – 16 bit mode only.  The pinout of the RoadRunner is designed to match the pinout of these ICs – other 16 bit data bus chips could theoretically be emulated with creative cabling.  We have NOT performed extensive testing to determine the fastest access time for the Roadrunner, but we estimate that it is in the 65-80ns range.  90s is 100% safe.

The above picture illustrates the locations of pins 1 and 44 relative to the USB connector on the RoadRunner.

Full documentation for the protocols for talking to a Roadrunner for emulation and limited data trace are available on request. (They are very similar to the protocols used with the Ostrich 2.0 and our other devices but some minor differences exist.)  If you are interested in using the RoadRunner in a custom application, please contact us.  The hardware platform is a tried-and-tested 16 bit wide data bus EPROM emulation system available at a competitive price.

Specific Non-GM Application Usage Notes

The RR_on_BP5R write-up details fitting the RoadRunner emulator to the Miata BP5R (2000 1.8) ECU (Thanks James Holland!)  This ECU uses a 29F200 instead of the 28F400/800 the RR was designed for.

We have a byteswap board that allows the RR to fit inside the case of a ME7 Audi 2.7t ECM and performs an endian-swap for use with TunerPro RT on this platform.

Hardware Supported

Currently, the Demon 2 is the only supported hardware for Neptune.  We sell the Demon2+Neptune RTP setup.

Discontinued Hardware

If you have discontinued hardware, you can get current production hardware (Demon2) for half off with our trade-in program.  More details here.

The Demon (or “Demon 1”) is no longer in production and has been replaced by the Demon2.

Demon1 hardware

The original Neptune RTP board was designed by Moates.  It is no longer in production and has been replaced by the Demon2.

Original Neptune RTP Hardware

The Autoprom

The Autoprom was the first Moates device. It is a combination Emulator, Chip Burner and Datalogger.

Today you can buy these devices separately, however this package eliminates the need for 3 separate units.

Compatibility

As of writing this article, the only software known to be fully compatible with the Autoprom is TunerPro RT.  TunerCat OBD1 Tuner and TTS Datamaster support almost all of the AutoProm’s features.

If you plan on tuning Honda vehicles, purchase the Ostrich, Burn1, and HuLog separately or a Demon as there is no software for Hondas that supports the Autoprom and all of its features.

The Autoprom CANNOT be used to program F3 Ford chips using the FA nor can it be used to read Ford ECMs using the FE.  You will need to look at the Jaybird or BURN2/FA/FE combo for Ford vehicles.

The Autoprom does not work smoothly with 29F040 chips.  If you need to work with these chips, it is recommended that you purchase a BURN2.

The Autoprom should be compatible with almost all USB ports.  Its power consumption should be in the 100-150mA range.

Environmental Compatibility

The APU1 is NOT designed to be left in an engine bay!!!  It will fail prematurely if exposed to the heat of a bay.   It is designed for a maximum operating temperature of about 80C (175F).

The APU1 is NOT designed to be exposed to moisture!!!  It will fail prematurely if exposed to liquids.  It will fail prematurely from condensation inside its case.

If you are going to use the device in harsh environments, try to do so for short periods of time and then program a chip for long term use.  We recommend this in general but it is especially important in harsh environments.

Due to its internal battery constantly powering portions of the device, the APU1 can easily be ruined by condensation caused by sudden drops of temperature in humid environments.  Returning the device to a cool (~50-77F / 10-25C) , dry environment after exposure to high humidity before attempting to use again  is a very good idea.  Placing it in a sealed bag with dry rice or another desiccant can help if condensation is suspected.

Switch Positions

Real-Time Tuning / Emulation

1. Make sure car is in key-off position with no power to the ECM. Remove the ‘stock’ chip and install socket adapter (G1 or G2) if not already present. Remove any chip from the AutoProm ZIF socket!
2. Hook the 28-pin ribbon cable header to the ECM chip adapter socket. Make sure the ‘red’ wire points toward where the notch, or Pin1, would be on a chip normally going in the socket. The AutoProm will auto-select its power source from either the USB port or the ECM header.
3. Get your PC powered on with TunerPro or TunerCat loaded up. Hook USB cable up to the AutoProm and PC. Check the AutoProm switch positions along the backpanel. The innermost horizontal switch can be positioned either inboard (10k – used to select data initiation on older-model vehicles.  Try the other ‘open’ setting first!) or outboard (open A-B – almost everything else) depending on ECM requirements. The outer horizontal switch should be in the ‘towards the USB port’ position. (APU1 mode. Other position is passthrough mode, identical to ALDU1).
4. If you haven’t already loaded a file onto the AutoProm, you will get an SES light condition indicating bad PROM content. Now is the time to go ahead and initialize the AutoProm from the PC software (should be under ‘Emulation, Initialize’ option). Once initialized, load the desired binary file into the PC software and upload it to the AutoProm (option should be right next to the ‘Initialize’ button). You may want to select the ‘Verify’ option (in TunerPro) to ensure that the binary upload was successful. If you keyed the vehicle on without a valid binary loaded, you may need to cycle the key off for about 20 seconds to let the ECM reset.
5. At this point, you should have the AutoProm loaded with the desired binary file. The car should now respond as though a chip with the uploaded binary content is installed. If not, then there is an issue. Either the binary is corrupt or some other condition exists.
6. From the PC software, you can make on-the-fly changes in the BIN content and have those changes immediately transferred to the AutoProm and the car should respond accordingly. There are several options within the supporting PC software, such as ‘Checksum Disable’, ‘Upload Entire Tables’, ‘Update Checksum’, and ‘Keep Item Open’, etc., so read through the documentation and practice a little bit so you understand what is going on and what to select. Typically, checksum disable or update checksum should be selected. Use a setting of “AA at 08” for 28 pin applications, and “AA at 04” for 24 pin ECMs.
7. Have fun, and try not to burn anything up other than rubber and fuel!

Stand-Alone Datalogging

1. Hook the APU1 up to the PC USB port and place the outer horizontal switch in the standalone, ‘away from USB port’ position (toward outside). It doesn’t matter whether the AutoProm is connected to the ECM chip socket because it gets power for standalone data logging from the USB port.
2. Connect the ALDL cable to the car’s ALDL connection. Place the inner horizontal switch on the AutoProm backpanel in the proper position for your vehicle and mode desired: inboard=”10k across A-B”, outboard=”open between A-B”.
3. Load up your favorite datalogging program on the PC, such as “TunerPro”, “WinALDL”, or “TTS DataMaster”. You may need to select an ADS file to define your datastream if using TunerPro. Turn on the key and start logging data! To stop, just turn car off and disconnect hardware. Keep in mind that in this mode, the hardware will not be ‘detected’ like the AutoProm mode, and that you’ll need to specify which USB Serial Port number (hopefully COM3 or COM4) has been allocated to the port in the datalogging software preferences.

Simultaneous Emulation and Datalogging

1. Carry out the same steps described above in the sections on Emulation and Datalogging, except keep the outer horizontal switch in the ‘inboard / toward USB port’ position.
2. Use a simultaneous-supporting program such as TunerPro RT to perform simultaneous datalogging and real-time emulation/tuning. You should see results from changes to the binary on-the-fly right when you make them.

Chip Reading and Programming

1. Connect the AutoProm to the USB cable. The USB will supply the power.
2. Make sure the 28 pin ribbon cable used for emulation is UNPLUGGED from the unit. Unpredictable behavior can result from the APU1 being directly connected to a ECM using the emulation cable while burning chips.
3. Make sure that the switches on the AutoProm are set for AUTOPROM MODE (outer switch inwards, see above picture)
4. Place the target or source chip in the ZIF socket. Orientation is critical, and the chip should be placed with its notch or arrow facing toward the ZIF handle and toward the back panel of the AutoProm. The chip should be at the ‘bottom’ of the socket, such that any unused socket pin slots are closest to the handle or backplane.
5. Use a supporting software program, such as TunerPro or FlashBurn to pick read/write operation, file location and name, starting and ending addresses, any hex offsets, bank selection, or other characteristic of the read/write operation. Carry out desired program/read/verify steps as desired, and remove chip from socket.

APU1 Video introduction

There is a series of videos on our YouTube channel that also explain some of the basics. You can also consult the APU1 Troubleshooting guide if you’re having trouble.

APU1+Wideband+Datalog

On the back of the APU1 you will find a terminal block with 4x screw terminals. The one closest to the USB port is GND/Common, and the other 3 are for channels 1,2,3 respectively. If you have a wideband O2 with 0-5v outputs, it can be wired up to GND/CH1 and TunerPro can then present the ADC data along with the rest of the datastream when operating in AutoProm mode (this feature unavailable in pass-through mode). Configuring this is a little bit complicated and requires comfort with TunerPro RT, basic algebra and some patience.

This is a nice article written by Charles Woock on how to configure TunerPro RT to digest 0-5v inputs such as the LM1 and LC1. The values can be brought in through the APU1 via the APADC interface.  (Note: newer APU1s have the APADC interface built in as standard equipment) The tutorial explains how to set up the ADS file and render values such as AFR Air Fuel Ratio as part of your GM ALDL data stream.

Here’s the PDF file:

http://static.moates.net/zips/wideband_datalog_tunerpro_lm1.pdf

“First Edition” AutoPROMs

Very early editions of this unit feature a different switch configuration.

These units have a horizontal switch and a vertical switch.

For the horizontal switch, outbound is passthrough mode and inbound is APU1 mode.

The vertical switch has three positions.  It controls the behavior of the datalogging interface, much like the inner switch on newer models. 10k is the up position, open is the middle position, and short (check codes) is the down position.

These units also use a different style cable to connect the APU1 to the vehicle.  We no longer sell this style of cable.

Rest in Peace

The Ostrich 1.0, which has now been discontinued, was the first in the Ostrich line. Upon the creation of the first Moates product, the Autoprom (APU1) the team at Moates quickly realized the demand for separation of the Burner/Emulator/Datalogger combo.

As a result, the Ostrich 1.0 was born.

Early versions of the Ostrich 1.0 were very basic featuring only a black case.

Later versions of the Ostrich 1.0 featured a sticker with a very mean looking Ostrich.

Early revisions of the firmware used 115,200 baud rate. Later revisions (leading up to the Ostrich 2.0) were released featuring the 921,600 baud rate.

The meanest emulator known to man.

The release of the Ostrich 2.0 was the marking point for the next generation of Moates products. Along with a 75% size reduction, the Ostrich 2.0 also boasts many firmware advances. The Ostrich 2.0 connects to the host computer with a baud rate of 921,600bps, which is the fastest bit rate supported by standard RS-232.

In English, this means uploads, download and verifies happen in less than 2 seconds for most ROMs.

There are also some new features for developers available on the Ostrich. Features like ROM tracing, and window tracing allow developers to keep track of what addresses are being access within specific regions of the ROM. This is helpful for reverse engineering roms, and can also aid in datalogging ECUs with limited datalogging capability.

The following software packages are known to be compatible with the Ostrich 2.0:

• CROME

• Hondata (Note: Old “Stage” software before S300 only.  No S300 support)

• Neptune (Note: DEALER VERSION ONLY!!!  We do NOT sell Neptune software that works with the Ostrich.)

• eCtune

• BRE

• TurboEdit

• TunerPro

And many more…

To purchase the Ostrich 2.0, please see this item in our Online Store here

Environmental Compatibility

The Ostrich is NOT designed to be left in an engine bay!!!  It will fail prematurely if exposed to the heat of a bay.   It is designed for a maximum operating temperature of about 80C (175F).

The Ostrich is NOT designed to be exposed to moisture!!!  It will fail prematurely if exposed to liquids.  It will fail prematurely from condensation inside its case.

If you are going to use the Ostrich in harsh environments, try to do so for short periods of time and then program a chip for long term use.  We recommend this in general but it is especially important in harsh environments.

Due to its internal battery constantly powering portions of the device, the Ostrich can easily be ruined by condensation caused by sudden drops of temperature in humid environments.  Returning the Ostrich to a cool (~50-77F / 10-25C) , dry environment after exposure to high humidity before attempting to use again  is a very good idea.  Placing it in a sealed bag with dry rice or another desiccant can help if condensation is suspected.

Supported Targets – 24, 28, 32 pin 8 bit ROMs

The Ostrich is a general purpose emulator.  It can be used to emulate up to a 4 megabit ***8 bit*** EPROM.  It cannot be used to emulate 16 bit ROMs like the 28Fxxx.  The Ostrich 2.0  is available with DIP28, DIP32 cables.  The SocketBooster 1.0 is used with 24 pin applications.

• 27C32 (TBI GMs, Old Bosch Motronic) = 28 pin emulation cable, Socket Booster
• 27C64 (misc ECMs) = 28 pin emulation cable, Socket Booster
• 27C128 (misc ECUs) = 28 pin emulation cable
• 27C256 (misc ECUs) = 28 pin emulation cable
• 27C512 (misc ECUs = 28 pin emulation cable
• 27C010 (?) = 32 pin emulation cable
• 29F040 (?) = 32 pin emulation cable

We have NOT performed extensive testing to determine the fastest access time for the Ostrich2, but we estimate that it is in the 65-80ns range.  90s is 100% safe.

In cases where you have a PLCC package chip, you CAN use the Ostrich 2.0 but you need a DIP->PLCC adapter.  We do NOT sell these.  Logical systems seem to sell suitable adapters.

The SocketBooster and the Ostrich 2.0

The SocketBooster is never required when using the Ostrich 1.0 but it is required for most 27C32-based applications when using an Ostrich 2.0.  You can think of it as a signal amplifier for the Ostrich 2.0.  In most applications, the Ostrich 2.0 can produce a strong enough signal on its own.  If your ECU acts like it has a bad chip or no chip installed when using the Ostrich but the same program works as a chip, this could be a sign that your application needs a SocketBooster.  (It could also mean that your Ostrich is failing…)  You might ask, “well why don’t you use a SocketBooster all the time?”  Unfortunately, the SocketBooster interferes with the operation of the “trace” feature of the Ostrich.

This is a list of applications where we have found a SocketBooster to be ABSOLUTELY necessary:

• 86-93 GM TBI ECMs using a 24 pin 27C32 EPROM

This is a list of application where we have found a SocketBooster to be necessary in SOME cases:

• 90-93 Nissan Z32 8 bit ECUs, 90-93 Nissan R32 Skyline 8 bit ECUs.  (By extension, most 8 bit Nissan computers around this age)
• 90-94 Mitsubishi DSM ECUs

This is a list of applications where the SocketBooster is 100% NOT needed:

• 88-95 Honda ECUs
• 86-95 GM TPI “Memcal” style ECMs
• Nintendo NES and Gameboy
• All 32 pin applications

If you don’t see your ECM listed, email [email protected] with the particulars of your application.

About Emulation Bank Setting

Power Consumption

Ostrich Use with PLCC32 Targets

The Ostrich can be used with PLC32 targets, but we do not sell the necessary adapters.  In most cases, you will need to get the EMU3206 cable we sell so you are starting with a 32 pin DIP.  We have fund these vendors sell adapters that will work for emulation of PLCC32 targets:

• http://www.adapt-plus.com/products/adapters/prod_dipplcc.html
• http://www.logicalsys.com/
• http://www.adapters.com/

Making Your Own Cables

We recommend you buy a suitable cable from us.  You should not bother reading this section unless you understand how EPROM addressing works and you have a specific need that cannot be met with a cable we already sell.  This is not for beginners.  You are warned.

Parts can be found here (Page 106: PCI-24, PCI-28. PCI32, IDS-34)

The pinout of the Ostrich is more or less the same as the chips that it is designed to emulate, viewed from above.  The two switches define the possibilities – 24 pin(2732), 28pin (27C512) and 32pin (AM29F040).

A very important thing to note is that all pins are live in each mode, i.e. if you are using the Ostrich to emulate a 27C256 in 28 pin mode, you must make sure that the highest address pin (A15, pin 28) present on the 27C512 but missing on the 27C256 is in a defined state by using a pull up/down resistor.  Although the Ostrich has very weak internal pull-ups, allowing pins to float in an undefined state is likely to cause problems.  TunerPro RT and most software typically top-justifies bin files when uploading them to the Ostrich so generally pull UP resistors are going to be what you need.  If your target system has hard pull downs (ground) on “unused” address lines, you will have to either disconnect these lines from the target system and manually pull them high *OR* adjust where in the Ostrich’s memory bins are uploaded to.

In 32 pin mode, the Ostrich uses 32/34 pins with the same pin numbering scheme as a 29F040:

In 28 pin mode, the Ostrich uses 28/34 pin with the same pin numbering scheme as a 27C512:

In 24 pin mode, the Ostrich uses 24/34 pins with the same pin numbering scheme as a 2732:

Data Trace

The Data Trace feature of the Ostrich 2.0 allows you to observe which data in its memory is being accessed by the target system.  It’s a little more complicated than it sounds so there is a dedicated support page for the Trace Feature.

Firmware Updates

• The new version of Binary Editor 2010 requires QH firmware 1.6 or higher.Most firmware upgrades are bugfixes of one variety or another.  If you aren’t having trouble, chances are the bugs do not affect you.
• Most bugs affected the QH when operating in modes 3 and 4 (EECV)
• The latest firmware revision as of 2/11/10 (version 1.6) allows you to read the stock program from an ECM using the QuarterHorse.

Program Switching with QuarterHorse

Here are pictures which detail how the rotary switch is installed on the QuarterHorse. The kit comes with a length of no-clean solder, and it is very easy. Follow the pictures for guidance, and remember, this is ONLY for EEC-IV and not post-1995 EEC-V.

First, look at the connector part you received. It may or may not have had one of the 4 pins removed. If not, pull it out so that it is as shown.

Go ahead and use the no-clean solder that was supplied. Get one spot on the QH connector tinned up like it shows in the picture.
Now, hold the modified 4 (now 3) pin connector in place as shown, re-heating the solder so that the two pieces can be bonded together in the correct position.

Now, come in with the solder on the other 2 joints. Use a little extra for strength, but don’t go overboard. Re-heat and add solder to the first joint you started with here to ensure good connection.

Soldering work is now complete, so check fitment of the cable and look for straightness and orientation. Use the photo below for reference.

Here’s another angle showing solder joint details.

These are most of the parts (pin header shown unmodified) that come with the switch kit. Knob is also included (shown in 2nd picture below).

Here is what the completed switch / QH / knob assembly should look like:

This is a pretty simple installation. It basically overrides the BS0/BS3 lines (if you’re familiar with this terminology) at the EEC connector. Therefore, to repeat, this is NOT to be used on EEC-V applications.

NOTE: The QuarterHorse must be configured to use MODE 1 or the switch will NOT WORK.  As of the time of writing (Apr 2011) Binary Editor is the only software that supports Mode switching which means it is also the ONLY software that will currently work with the switcher module.

Switching Low Level Details

While in Mode1, there are 4 tunes available.  The following table explains the state of each pin while each tune in BE is active.  It matches the pin orientation of the header that is pictured above.

 

If you don’t want to use our switching kit but you do want to do switching, you need to understand how this state table works. The first thing to keep in mind is that all pins default to “1” or 5V unless you intervene – this is called “pulled up.” When you are figuring out what state the QH is going to be in, you must always assume any pins you haven’t specifically changed the state of will be “1.” A simple way of doing switching without our kit would be to solder a wire to the GND pin (by itself, above) and to the one next to it (BS0). If you were to put a toggle switch on this, you would be changing between Tune 0 (switch open) and Tune 3 (BS0 = GND)