aldl logger homemade cable

Hi all, I am putting together a TBI setup and doing some bench testing, but having issues with getting data logging connected in TunerPro. Other parts of the setup seem correct in terms of the ECM being powered and mostly functional: I can emulate on it successfully with Ostrich 2.0, I can fire spark and hear injectors pulse by turning the distributor, etc.

My setup: 7427 ECM marked as BJYL, Windows 10 (running as a virtual machine on my mac; more on this later), TunerPro V5, A217_0D_v250.adx file. I'm running a FT232RL USB chip with Tx and Rx soldered together and wired up to the serial data pin F9, and GND terminal wired to battery negative.

The issue: When attempting to connect data acquisition in tunerpro after selecting the adx, it remains stuck on "DA: Connecting...". I am able to see the USB device recognized in Windows and I've configured TunerPro for that Serial plug-in device. When I click the test button, it says "found and functional", but many times when I close and return to that window, the COM port will be in curly brackets {} and the test will fail. If I disconnect and reconnect the USB cord, VMWare asks me whether I want to use the device in Mac or Windows, I select windows, windows recognizes it, and then the TunerPro COM device will pass the test. The power LED is lit up solid and the Rx and Tx lights begin to flash on the FT232 chip after I click start data acquisition. This is actually the second FT232RL chip that I've tried. The first one apparently was not a genuine FTDI chip and so I purchased another and crossed my fingers, but they both have behaved the same. I updated the windows drivers to the newest FTDI driver and also tried going back to the older version I used to get the Moates Ostrich working. I've also edited the windows registry to alias the baud rate from 9600 to ~8192; I'm running out of ideas to try and resolve this.

At this point, I think it is the VMWare virtual windows that might be causing the issue, but I'm short of a windows laptop at the moment to test otherwise. Another option may be to try the ALDU1+CABL1 from Moates, but I'd like to hear if anyone has advice before I throw more money at this. Thanks again for your help.

Not that you can't make one and you sound tech savvy but time to get on with tuning. I'd pay the man and get one already made is my opinion. My cable has no lag and goes right to "DA Connected" when pulling data and yours sounds like it's only half working. But your probably right about mac to PC VMware causing issues and a pawnshop can help ya with a cheap PC as doesn't need much to run. Good Luck!

I would suspect the ecm is working. But I will also note that the ecm is built to provide spark and fuel through the analog hardware even if the code is not operational. The check engine light will confirm the code is ok and in use through an "on-off-on" cycle after ignition power is provided. On for 3-5 seconds, off for 3-5 seconds, then remains on until engine start or key off. Note the key should be off for at least 30 seconds before performing this test.

To be honest, I never had much luck with the 2 transistor cable, especialy when trying to adapt to USB. The two transistor cable only allows for TTL like signals (0 to a positive voltage) and most USB to serial adapter cables need full RS232 signals (+/-12V). I have had great success using the MAX232 IC based circuit.

To be honest though, I would get the Xtreme ALDL and CABL1 since it just plainly works, and is in a nice pacakage. Then you can be pretty much assured that the cable isn't the issue.

That being said, as 1project2many has suggested above, befoee doing anything else, make sure that the PCM is actually reading the MEMCAL/Ostrich, by observing the CEL function. Make sure you wait for around 10 seconds beteween key cycles though, since PCM needs to fully shut down before it will start a new run cycle and the CEL won't perform some checking if the key cycles are too quick.

Thanks for the suggestions. I tested the setup on a Windows laptop and it behaved the same so I think it is something else. I went ahead and ordered a ALDU1+CABL1 (I wondered about the Xtreme ALDL, but moates support pointed me toward the aldu1 for whatever reason when I reached out to them on another subject). In the meantime I've been working on the CEL. I hadn't realized I may've been fooled regarding ECM functionality by the analog hardware doing its thing; another reason to get logging working to know for sure. I decided to remove the ostrich and G1 adapter from the equation and suddenly I was able to connect to the data acquisition in TP. However, I was getting some "DA Data Errors" and the numbers were bouncing a bit like something wasn't right and TPS voltage didn't seem to react to my opening the throttle, so I stepped away to read up on the errors. Any suggestions on this? Also, going back to look at the wiring diagram, the ECM applies the ground to the CEL, correct? That should fix that problem. Thanks again for the help.

The ALDU1 IS the Xtreme ALDL, just one is the the name and the other is the part number...

As far as the glitchy data, it could be the ADX you're using, it may have the initial comms not quite setup right, or parts not defined correctly, etc.

There are probably more than a few ADXs for your ECM/PCM, especially if multiple masks are used in the same ECM/PCM. Sometimes the wrong ADX will "connect" but show bad data.

I pulled the codes:
21 tps high
23 mat sensor low
25 mat sensor high
52 system voltage high long test
54 fuel pump relay failure
55 pcm failure

So, I have a lot of work it would appear. First of all, could this be all wrong with the wrong adx file? If not, being a stock chip, how much of this is meaningful? I suspect my fuel pump wiring may be incorrect as I never heard the pump kick on when I had it plugged in. I don't have a MAT sensor as I believe it isn't necessary for my setup. "PCM Failure" and "system voltage high" definitely worry me. It can't be that the system voltage is high as I am bench testing from a battery that is right at around 12V on the multimeter. The messages should've been recently cleared when I had the battery disconnected to move things around. Any suggestions on where to start?

Well, scratch my last post. I should've kept playing with things because after selecting a different .adx everything looks much better, and the error codes are completely different and more reasonable...knock sensor, transmission stuff (I'll be running a manual), etc.

Awesome! Thanks again for the help. Now to start thinking about installing this thing in the jeep.

So as a note to anyone else this might help, my issue was in thinking the Ostrich would serve as a pass-through to the stock chip when I wasn't emulating. Looking at how the stock memcal attaches to the G1 adapter, its apparent that the
EPROM half of the memcal does not engage with the G1 adapter. As a result, the PCM wasn't getting a .bin/tune and the DA couldn't connect. After emulating a BJYL over the Ostrich, everything came to life on the DA side of things.