From what I read, 1987 and 1988 4 cylinder Fieros use 8192 Baud on pin M. Does the Fiero just spit out data on pin M (one way) or does it have to be commanded (two way)?
I have read both because just about all the ALDL functionality has been convoluted over the years. People often speak in general terms when it comes to 8192, but on the Fiero it may have just spit out data. At one point I read that the data come out as human readable text.
I know in later years 8192 was two ways comms, but the Fiero was the first to use it and the Fiero ECUs were unique only to Fieros. So it is possible they were one way.
I have spoken with some guys that make adapters but I get conflicting info among them.
Does anyone in the Forum know for sure if the Fiero 8192 ALDL data was just one way, or does it use two way comms?
One suggested TunerPro, but you need a few conversion files to use it. And it doesn't even come with the files, you either have find them somewhere or reverse engineer them yourself.
So, I may have to borrow a 1987 or 1988 4 cyl ECM to figure this out. But if anyone has any direct knowledge of what I am asking, I would appreciate it.
One suggested TunerPro, but you need a few conversion files to use it. And it doesn't even come with the files, you either have find them somewhere or reverse engineer them yourself.
From what I read, 1987 and 1988 4 cylinder Fieros use 8192 Baud on pin M. Does the Fiero just spit out data on pin M (one way) or does it have to be commanded (two way)?
I have read both because just about all the ALDL functionality has been convoluted over the years. People often speak in general terms when it comes to 8192, but on the Fiero it may have just spit out data. At one point I read that the data come out as human readable text.
I know in later years 8192 was two ways comms, but the Fiero was the first to use it and the Fiero ECUs were unique only to Fieros. So it is possible they were one way.
I have spoken with some guys that make adapters but I get conflicting info among them.
Does anyone in the Forum know for sure if the Fiero 8192 ALDL data was just one way, or does it use two way comms?
One suggested TunerPro, but you need a few conversion files to use it. And it doesn't even come with the files, you either have find them somewhere or reverse engineer them yourself.
So, I may have to borrow a 1987 or 1988 4 cyl ECM to figure this out. But if anyone has any direct knowledge of what I am asking, I would appreciate it.
I don't know how much I can add to this that would be at all valuable, but I know that people refer to 8192 as the baud, but that's not defining the Baud Rate. As an old BBSer, the baud rate for the Fiero ECM is an excruciatingly slow 160 bytes per second, from the data output. That's quite bad, but the speed at which the ECM actually communicates with the sensors and such, is actually a lot quicker. 8192 actually refers to the UART chipset from what I understand.
I could be wrong, but I think the data feed is only uni-directional. OBD2 is definitely bi-directional, but not OBD1 (someone correct me if I'm wrong). I do know that you can easily reflash the PROMs... one of my buddies used to do this on an old 286 laptop, but it's much easier now with USB and a Temu / AliExpress chip flasher. You have to wipe it by blasting the chip's window with UV light. You have to pull the sticker off the ECM and hit it with a UV light and it will wipe it... takes a while though. But there may be a way better way to do all this. I hope someone else responds with better info.
EDIT: Sorry... I didn't see that FieroSound had responded...
[This message has been edited by 82-T/A [At Work] (edited 05-05-2025).]
My GUI currently only supports Fiero 1986-1988 V6 ECMs. I have been getting a lot of call to support all the stock Fiero V6 and IL4 ECMs.
I am in the process of borrowing a Fiero 1985 V6 ECM. That will leave just 3 different IL4 ECMs left for me to support. The 1987-1988 IL4 ECM uses pin M which is called 8192 Baud (in a common terms). The other two use the 160 Baud which I just need to verify with existing code.
My GUI supports only Fieros as it was design especially for Fieros. It doesn't need XDF or bin files or anything a user has to hunt down. My GUI will support all stock Fieros from 1984 to 1988 right from the downloaded GUI... taking out a lot of the guess work from other tools.
My Adapter will be modified to support pin M 8192 data. Right now the Adapter only handles pin E for 160 Baud Data.
My Adapter currently can set all 4 ALDL Modes via GUI control - no jumpers or switches. My Adapter also includes a Bannana Jack to test the Fuel Pump and a multi-color Status LED. The USB cable is integrated into the cable. If you add the SES signal to pin D of your Fiero's ALDL Connector, the Adapter and GUI can also read Error Codes for you... no need to count flashes, the GUI can do that for you. And it can Monitor the AFR cycling. I don't think there is another GUI and Adapter out there that does all that. Because I am a single source for the entire tool, hardware and software, I take suggestions from my users, so the tool is always improving and evolving. The GUI and updates are free for download. You don't even need the Adapter as the GUI comes with a recording file 'CS_Morning_Commute.txt' that you can play back to get the feel of the GUI before buying the Adapter. Recordings are in a simple data stream in text format that is easy to share via email. I also offer free consultations for my users. So far I have received high praise for it.
[This message has been edited by Romsk (edited 05-05-2025).]
Pin E is unidirectional. That is why the 10K resistor is needed. It activates the data output. And if you noticed the data outputs about once per second with the resistor in place. And as you know the resistor alters the advance and the idle speed.
The 87-88 Iron Duke ECM uses pin M. It is bidirectional. My notes state the 10k resistor is still needed. GM later dropped the 10k resistor completely but apparently in 87 they were still figuring things out.
When you transmit on the link, you will of course get exactly what you transmitted right back. You need to ignore what is transmitted.
You will send in hex F0 56 01 B9 - The ECM will reply with a multi byte response. I will be referring to the bytes using hex. Then in that byte you need to decode the data much the same as you did with the 7170 ECM
So for example the O2 sensor reading is byte 0E . All 8 bits of that byte are the value of the O2 sensor
The TPS is byte 07 and again it's an 8 bit value
The SES indicators are in bytes 02 to 04 and all are just a single bit.
If you fire up TunerPro RT, load the .adx file for the 87-88 Iron Duke ECM and then go to ADX editor, it will spell out all of the values you are looking for.
While most of the data translates to the actual value by a multiplication factor, not all does. For the ones that translate to the data by a factor, that is indicated in the .adx data. For the data that doesn't there are look up tables to convert the data to an actual number.
ADX files are definition files for scanning data streams
BIN files are the actual data burned on the PROM
XDF files are definition files much like ADX files but for the BIN file. By using the XDF file you can see what the data in the BIN file actually means. TunerPro RT when in the BIN file edit section allows you to see what is programmed, and allows you to alter the program. So for example lets say you want a target idle of 800 RPM instead of 1,000 RPM. You could do that. Then you would save the BIN file, and then burn it to an EPROM and insert it in your ECM.
The 2732A EPROMs that are in Fiero ECMs are a pain to get to program correctly. Plus they have to be erased with a UV light. Most "used" ones fail to program correctly. So what I have done is made an adapter board that allows a 27SF512 chip to be used in a socket that then plugs into the board. I sell them here if you are interested.
Actually 8192 is indeed the baud rate. Yes, a very unusual baud rate. The nice thing about the 8192 is it is quick enough to be "real time". Not the jerky, once a second update movement you get with the 130 baud.
If anyone does a 7730 ECM update it also is 8192 baud, so it scans much nicer and the idle and advance are not affected by scanning.
So I guess I do need the bin file too. But I have no intention of "tweaking" the settings. That is bit cumbersome as you actually have to burn new PROMS.
I just want to be able to read and decode the commanded data that can come across the pin M data.
So to figure out how pin M works, I will need: TunerPro RT The ADX file for the Fiero 87-88 Iron Duke It's associated BIn File Then TunerPro RT can uses those files to show me the commands to send (in hex), what values come back (in hex), and how to convert them into units (by conversion factor or table)... got it.
I agree, some bytes are a simple conversion factor: like RPM which is 25 units per LSbit. Some are tables: Like CTS which are based on Thermistor curves. In my GUI, I don't have tables for the CTS, IAT Sensor, or the MAP Sensor. I took those sensors and plotted out a few points over their ranges. Then I did polynomial curve fits and created functions that takes the raw value and applies those coefficients to a 3rd order equation and it returns the units. It only take a couple of microseconds to calculate. It uses much less memory than lookup tables. But if the ADX files has lookup tables I may just do a curve fit on those as well.
My GUI won't use the ADX files directly. I will convert the data in them to DLLs that the GUI will load as it's respected ECM is selected. This way, users won't need to hunt down ADX and BIN files, the DLLs come with the GUI, all the user has to do is select the desired ECM Model number and my code does the rest. I am only interested in Fieros, so there are only 5 ECMs... I have the 1227170 DLL done, 4 more to go... 3 are 160 baud (which I understand well) and 1 for the 8192 baud.
For scanning the only thing needed along with TunerPro RT is the .adx file.
With TunerPro RT, once you load the .adx file for the 87-88 Fiero 2.5 you can read in technical english the parameters it uses to activate and receive the data stream.
After activating TunerPro RT and waiting past the nag screen go to Acquisition - Load Definition File - 1987 - 88 2.5 Fiero $48.ADX
Then with the proper cable attached you have to tell TunerPro RT where it is. Tools - Preferences - Data Acquistion/Emulation - and in the box to the LEFT (Data Aquisition and Logging) make sure the top box says Interface type USE PLUG IN and then hit Configure Plug In Component
Select the COM port your computer assigned your cable. Typically this is COM3 but it might be different depending on how many COM devices you have used with your computer.
As a test (only works with bi-directional cables) hit TEST FOR VALID INTERFACE USING SETTINGS and see if it passes. As a test the program will send a byte out on transmit and look for it to be returned on receive.
Assuming this is all working close the dialog boxes and then with the vehicle connected and key on (engine on or off) hit the "left & right" arrow icon and the laptop should make contact with the ecm and start scanning. A status box on the bottom, the fourth one over should change from yellow DA NOT CONNECTED to pink CONNECTING and then to blue CONNECTED.
Bottom status boxes 1 and 2 are for an emulation function, which you are not using. So ignore the fact that status box number 2 says HARDWARE NOT FOUND. That is talking about the emulation hardware.
Now back to the top tool bar - A few icons to the right of the double left right arrow is a speedo icon and a sprial topped notebook icon. The speedo icon is used to display a programmable dash function. The notepad icon is to display the real time data inputs along with the error codes. You will have to resize these screens to see all the data.
========== With the data flow off - you can view and if you want, edit the .adx file. Acquisition - Edit Defintion will get you there.
Under COMMANDS - see TRANSMIT STREAM SEND - That is what is sent to activate the single stream of data
Then the data stream will reply
And then you send it again and receive again. And again. and again. That is how it works with the bi-directional.
Under VALUES is where how to decode the data stream
BITMAPS are the CEL codes
There is only one look up table - for temp - well two one in F and one in C
Just like there was no WW1. Just "The Great War". Then when the next great war came along the Great War was renamed to WW1.
GM called the data stream ALDL - Assembly Line Data Link. It is now colloquially known as OBD1. Well technically GM OBD1. Ford had their own OBD1. And so did Mopar and all the others. TunerPro only works with GM OBD1 (and anyone who did use GM ECMs)
There is a guy who wrote a scan version of TunerPro RT for Android. He chose to use the same .adx file definitions. It's ALDLdroid
The .adx files are more from end users than from the author of TunerPro RT.
So lets say you used the .adx files just as is and adapted to them. And then you included all the .adx files on your install disk. Not just the Fiero ones, but all of them. Then the user could select the vehicle by selecting the needed .adx file. And now your program works for all of the vehicles listed that have .adx files.
Thanks for all the tips, that helps a lot. It looks like I will have to buy TunerPro RT to learn what is in the ADX files. Ok, no need for BINs, but that does pique my interest into what is in the PROMS.
So, ALDL is sometimes called OBD-I due to the "WWI Naming Effect", got it.
My GUI is really only for the Fiero. I could write an ADX interpreter for it and that would open it up to hundreds of models of vehicles. But here is the rub, I also offer free consultations on hunting down Fiero issues... if folks that, say, own a BMW, I would not be able to help them. Besides, I dont like BMWs... I am a Mercedes-Benz man - I love my SLK280; I am springing it from its winter cage this weekend. Also, the guages on my GUI look like the Fiero dashboard. I would have to make it more generic. I read TunerPro RT is over 100K lines of code. My GUI is only 33K lines of code so far.
The saga: The tool started out 10 years ago. I was bored so I slapped together a simple application just to display the ALDL data in hex. My first adapter was for RS-232 and was based on the homemade cables that are common on the web. I didn't like "fooling" the UART in my PC with ALDL pulses looking like ASCII characters as pseudo RS-232 frames, it was creating comms errors and just like my code compiles with zero errors and zero warnings, I don't like errors operationally. So, I used a Parallax P-Stamp to measure the ALDL pulse widths and sent proper data to my serial port as ASCII '1's and '0's - no errors. That adapter had a knob on it to set the 4 ALDL modes using open/10K/3.9K/short. So, I expanded the GUI for fun. I wrote it all in National Instruments LabWindows/CVI because Microsoft's Visual Studio can be quirky at times. CVI is a more robust tool and used in the Aerospace and Defense industry. I posted a download for my GUI on my minimalist website, and included drawings on how to make the Adapters. One issue with my GUI back then is that it dropped every other ALDL frame. This was because while I was displaying data I didn't grab the next frame in the background. So, I made the comms routine multi-threaded and now while I display one frame, the next is being grabbed in the background. I had a whopping 3 users world wide! The P-Stamp was about $72 dollars at the time, so I switched to an Arduino UNO which was only $23. But I was getting e-mails from my users if I could make the new Adapters for them. The box to hold an Ardunio was costly, so I went to an Adafruit Trinket M0 (smaller than a P-Stamp) and is only $9. I sold a couple of those Adapters at cost for around $54 in order as I need it pricing - my idea was keep it low cost to my fellow Fiero followers. Because the Trinket is 3.3V I/O, I had to have a tiny circuit board with Zener Diode Limiters to protect the I/O pins. I was selling about one every 6 months. The circuit boards were hand wired proto boards, not a lot of circuitry, but still slow to build. I found JLCPCB in Hong Kong and they made PCBs for me at 33 cents each (with shipping factored in for lots of 25) and they 3D printed my ALDL connector backshells for about $3 each (with shipping for lots of 25) very high quality - they look like they were injected molded after they sand blast them. This made assembling the Adapters a breeze. The new circuit board can now select the ALDL Mode via comms to the Trinket. Since the Trinket has a Dotstar multi-color LED on it, I display that on my Adapter for status (a soda straw/hot glue light tube that looks like a standard LED outside the case). The ALDL connector on Fieros have a pin to power up the Fuel Pump so I added a jack for that. I had 2 I/O left on the Trinket so I use them for the SES and Shift signals (if the user wants to add those wires to the ALDL Connector in their car). If wired in the car, my GUI and Adapter can read the Error Codes for you! I let the computer count the SES flashes and light up LEDs in the GUI as to which EC is set. But if you go old school and count the flashes yourself, you still use the GUI to look them up. Then you can left click on an LED and you get a pop-up with more info on that error code and what to look for in the Fiero.
At this point I was selling about 1 a month (still at cost). The Fiero Store caught wind of it and we made a deal to sell my adapters through them. They insisted that I stop building them for cost and add in my time for labor and profit. I did, but kept it all very modest. Now I am selling about 10 per month retail. But no good deed goes unpunished... the 'Tariff War' is increasing the cost. But at least I can now go with US companies (if they stay tariff competitive) for my PCBs and 3D printed backshells.
So, expand this beyond Fieros? No thanks, I have my hands full right now (laugh). This was only supposed to be a hobby.
[This message has been edited by Romsk (edited 05-08-2025).]
My GUI now reads in a DLL (that works sort of like a ADX file, but a direct library code - its very fast and efficient) for the 1227170 ECM. It contains all the info the GUI needs to read/convert/and display the ALDL data for that ECM. I have tables in the DLL for: Rally (Normal) Mode Data Rally Mode Flags Test (DMALDL, DMFACT, and DMDIAG) Mode Data Test Mode Flags Error Codes Polynomial Coefficients to Calculate Non-Linear curves: IAT, CTS, MAP
Right now my GUI has interactive help on all the Status and Malfunction Flags, as well as Error Codes. I think I may expand the DLLs to include that text in the DLLs if it differs much among the Fiero ECMs.
A DLL for each of the Fiero ECMs (5 in all) will be included with the GUI - when I figure out their comms.
I simulated using the GUI at 8192 baud and my text display was faster than that frame rate! But when I added in updating the graphical gauges, it slowed down.
I am going to add a feature where you can select (a la cart) which overhead functions to disable so you can get true real time at 8ms per frame display that my GUI can handle. Of course the more you turn on, the slower the update rate, but 8192 baud data will still be pretty smooth even with everything turned on.
Overhead: Saving data to a recording file Displaying the data as text Doing just the two above can keep up with the 8192 baud data with plenty of time to spare.
Less important in real time (can still be viewed on playback): Updating the Guages in the GUI Updating the Performance Curve Display Updating the Knock Counting (there are no knock counters on Fiero - I estimate them only) Updating the Status and Malfunction LEDs in the GUI Updating the Air/Fuel block display Updating the O2 Sensor response curve Updating the Graph.
Even with everything enabled, I still expect a better than 10 frames per second update rate in 8192 baud.
But when driving (where you shouldn't watch the GUI anyway), the Capture button (instead of Record) just records data with nothing else being displayed (not even text). So you can take it on a long drive (your assistant can mark the recording with events as you drive), and then play it all back to see how the ECM is working.
I hope to have the 1985 V6 ECM in my hands next week. It's only 160 baud, so it's easy to keep up with the data even with everything enabled.
[This message has been edited by Romsk (edited 05-11-2025).]
I just borrowed a 1985 2.8L V6 MPFI ECM. It has all the same pin outs as the 1986 to 1988 2.8L V6 MPFI ECM, except the 'TCC OR SHIFT' signal is on pin A2 instead of A7.
I plugged it into my ECM test fixture and the ALDL Data looks identical to the later V6 ECM version. The Rally/Fuel Consumption data in NORM Mode is different as it was premilinary for all Fieros as it was never offered, so that is what it is.
If the 1985 ECM used all the same sensors as the 1896-1988 ECM, then I am all set to support the 1985 V6 ECM in my GUI. If any sensors are different, I just need to add in new conversion factors/polynomial coefficients for those sensors. I think I read somewhere this ECM has an input for a Knock Detector (which was not used on Fieros) but none of the unused ECM pins were shown on the wiring diagram I have for it.
Does anyone know which of the 5 Fiero stock ECMs have a Knock Detector input?
So it looks like I am close to have all Fiero V6 ECMs covered in my GUI... 3 more (IL4 ECMs) to go.
