TunerPro User Forum

I have as Ostrich 2.0 that I am attempting to use, without luck. I ran it daily in my CIS ecu, emulating a 27C256. I'm now trying to use it to emulate a 27C512. The target ECU is a 93 Mercedes HFM, which is a bosch motronic 3.4

Before pulling the emulator from the CIS module, I figured I'd revisit the code one last time after not looking at it for a few years. Using a newer laptop than I originally tuned it with, I could not get data tracing working. It would only very occasionally trace a single cell, if at all, in maps I know were active. It would upload and download to the emulator no problem. When I originally installed the emulator into this CIS module, it data traced just fine, but I was using an older laptop. Frustrated, I pulled the emulator and burned a chip to replace it.

I installed the emulator into my HFM module. I loaded the proper file and the car will not start. I reinstalled the 27c512 and confirmed that it will run with the original chip. The loaded binary is the same as the chip, so there's no chance of a checksum problem. I have uploaded the bin and then downloaded it to confirm they match, and they do. So I can say with confidence that I have loaded a good bin and confirmed that it does load. Also, the hardware outside of the emulator is ok.

Since it wouldn't datatrace in the CIS, I attempted to use the older laptop to see if it would behave differently. Tuner Pro on the old laptop would not accept the XDF I have created due to being made with a newer version of Tuner Pro, so dead in the water. I can not say with certainty that it isnt a laptop issue. I'm also wondering if the newer version of Tuner Pro has issues with the Ostrich..? Barring either of those scenarios, what steps should I take to diagnose the issue? So far I have only checked the coin cell battery onboard and it reads just a smidge below 3V. With it opened up, I checked for corrosion and any other physical damage with none being obvious.

Any and all help is appreciated. This ECU has no support that I have been able to find, getting the emulator working will be huge for developing the XDF and tuning it.

From the wayback machine for Moates.net

Introduction
Many of our products have physical switches on them to change device behavior. Unfortunately, we’ve noticed quite a few problems related to these switches. Over time, sometimes switches fail to behave as you would expect them to. We suspect this is due to oxidation on the contacts, dust or another slow-acting cause.

Affected Devices
These devices use the switches which are known to have issues:

AutoProm / APU1
Ostrich2
ALDU1

Solution
Fortunately, the solution to switch glitching is really easy. Sliding the switch back and forth vigorously 5-10 times has been successful in restoring normal operation.

Also
Performance Tip
For better performance, we recommend decreasing the “latency timer” to 1ms on your FTDI device.

This can be done by entering your Device Manager then going to Ports (COM & LPT)->USB Serial Port (COMX)->Right-Click->Properties->Port Settings->Advanced->Latency Timer

also a bunch of information on driver installation here:

https://web.archive.org/web/20221004092 ... tallation/

Also info on chip sizes here:

https://web.archive.org/web/20221123081 ... -overview/

Thank you so much for the reply. I followed the links down a rabbit hole and found a test where Craig recommended writing to the ostrich and then reading it with an eprom reader. Kinda on the nose but it hadn't occurred to me. So I wrote my file with Tuner Pro and then read the ostrich with my Wilhelm GQ4x4. The programmer read it just fine as a generic 27c512. I popped in the original chip and tried to verify the read. It didn't verify! I did a clean read of the chip and compared it to my saved version that I have been attempting to write. The files did not match. I don't know if it was a bum read originally or if I accidentally saved something in an editor when I shouldn't have. Regardless, I've found a good reason why it wasn't working. Hopefully I'll get a chance to test it again over the holiday weekend.

Remember that TunerPro has a difference tool. You can load 2 files and compare them to see where they are different. Sometimes a poor connection on one leg in the eprom burner (dust) can cause issues.

Had a chance to try again. I loaded the correct file, and wiped the 24/28/32 switches back and forth a bunch, and gave it a go. Unfortunately, no joy. Its still dead in the water. Pulling the ostrich back out to swap the chip in, I managed to bend a pin, and it didn't straighten. Doh! I have 28 pin dip sockets, but not the nice machined ones like what came with the Ostrich. I'll get a couple ordered in.

I have seen talk of needing to use a "demon reset utility" to regain functionality. Is anyone familiar with that? What exactly does the utility do, and would this be a situation that would be appropriate to use it? Lastly, if so where would I find it?

Occasionally it will give me an error about the filesize when trying to up or down load my bin suggesting "bank 8" Restarting tuner pro gets it back functional to where it will up/down load I've tried several of the banks, obviously without luck. Can somebody clarify what bank selection really does? I don't remember ever futzing with it getting it set up in my CIS ecu.

Any other ideas? I'm thinking to try to install it back into my CIS ecu to see if it will work there. Pinpointing whether its the ECU or the Ostrich, is a starting point.

I found this very specific test for the Ostrich2 - might be worth a try.

https://web.archive.org/web/20220625232 ... g-ostrich/

Dumb question but have you replaced the internal battery in the Ostrich? I know they are supposed to last a long time but back when I was using mine, I remember having to replace the battery.

The battery isn't something that can just be "replaced" like a flashlight.

Takes a bit of work and some mods, but it's relatively easy.

https://www.thirdgen.org/forums/diy-pro ... ement.html

I haven't replaced it but I did check its voltage and it was something like 2.98V, which I figure as good for a 3V battery... unless I'm wrong.

3v is correct. Its a CR032.

But simply putting a voltmeter on it doesn't necessarily tell you it's good.

I found a webpage that had the Demon Reset utility download available. It connected and ran the utility just fine. Loaded the binary again and still no joy. This weekend I'll try to get it swapped back into the old CIS ecu to see if it works there.

I got a chance to install the ostrich in my spare CIS ecu and try it out in the daily driver. Things aren't looking good for the Ostrich. I made sure the baud rate and latency were right and still no data tracing. Also noted that a lot of the time download from the Ostrich would fail and it would show gibberish as well as some uploads resulting in a high idle, which I'm pretty sure is the result of a corrupted binary file. To remedy this a fresh upload was required. I think CIS is more forgiving in that it can run without the ecu where with the HFM can have one byte corrupt and result in a no start.

I'm thinking my next step is to replace the Ostrich battery. Other than that, it would seem replacing it is the eventual resolution. Anybody have one for sale, hell even for rent at this point would be extremely helpful?

ECU tuning from scratch isn't for those willing to easily accept defeat. Out of ideas for simple solutions, I bought a cheapo ebay logic analyzer. I soldered 90 degree pin headers to the back side of the eprom socket and set about logging the result. With the original chip in place, it was churning bits as long there was memory to log it. Repeating the test with the Ostrich shows periodic dead spots in the data.
The pic is way zoomed out, and there is quite a bit of data before the resets. Zoomed in you can see two data lines seem suspiciously lacking activity. Even zoomed out in the pic, you can see the holes in the green and pink channels. Since the Ostrich will verify in my eprom reader I have to assume it is ok, and the ECU just needs a stronger and or less noisy signal. My plan at this point is to fabricate a cable that is just long enough. 3 to 4 inches should do.

Supplies came in to make a new cable! Glad I ordered enough pieces to do several because I F-ed up a couple connectors before I got it right. The real pisser is that I had to order 25ft of cable to make one 4 inches long. If someone needs a cable, hit me up. I should be able to try it out tomorrow evening. I did verify the file with my eprom reader so I'm confident I got the cable assembled right. Fingers crossed this fixes the problem.

Success!!!!!!!!!!!!!!!!!!!!!

Plugged in my testing ECU with the ostrich connected using my new short cable. Engine fired right up. After a round of self high fives, I grabbed a usb cable and connected it to the laptop. Opened the XDF and relevant bin to find that data tracing is working too!!!

This is a huge win and is going to allow me to develop a tune for this ECU! Thanks to all who replied!

My joy was short lived. I went to drive the car at lunch today and the test ECU was again dead in the water. I had uploaded a bin with a modified part throttle ignition timing table. It uploaded the bin without protest but upon cycling the key and trying to start, no joy.

The up side is that I know that it is possible to run this ECU off of the emulator, as well as data trace it. I was able to data trace the drive to work this morning and determine that the part load ign. table uses throttle angle as the Y axis. It was great to make progress pretty much immediately. Now I'm back to having to pull the emulator and try to verify it in my eprom reader, as well as swap the original chip to make sure the ECU hasn't DANG! the bed. If only it wasn't a PITA to unplug and plug in these modules.

I spent most of the day yesterday futzing with this thing. The logic analyzer was showing me the same resetting pattern as I was getting previously. After trying everything I could think of, I made another, slightly shorter cable. It still didn't work but I was now getting a lot of random noise instead of the resetting. Knowing that changing the physical interface was changing the problem I looked at the next component in line... the eprom socket. I went ahead and desoldered the socket from the ECU. This one was a bigger pain than any others Ive done but eventually I got it off, and easily enough, a new one soldered on. I grabbed my eprom as I figured this would be the better test to make sure I didn't damage the board and got the socket soldered properly. In my haste I mounted the eprom upside down, which I realized when it wouldn't start the car. After correcting the issue it seems clear I killed the eprom chip. With nothing left to lose, I mounted the Ostrich. It fired right up! I grabbed my laptop and data traced about 100 maps, until my laptop battery got low. It is now clear that the longer legs of the eprom chip made better engagement than any of the socket adapters I tried.

I admire your perseverance and problem solving skills. Hopefully your posts may help others with similar issues.

Hey, Thanks. I learned a few things along the way as well. The logic analyzer was less than 10$ and not only did it help diagnose the problem, I also used it to to analyze the diagnostic k-line with a scan tool connected to id the RAM address of RPM, coolant temp, throttle position, and air mass. Their RAM addresses also correlate to the map axis they represent. Very handy for revealing this ECUs secrets.