Just ordered my USB/ALDL cable from Moates and ordered a wideband AFR off Amazon (AEM UEGO with Bosch LSU 4.9).

My plan is to run this software on my Macbook Pro (Running Windows 10 via Boot Camp), so we will see how deep the compatability hole will go.

If it fails, I have extra ECMs and two older laptops floating around. So I'll be the guinea pig. But so far im into this about $260. $90 for the cable package shipped and $170 for the wideband. I can weld in my own bung. I will document my adventures as I go along.

I've been running a mail order tune on my car since the motor was rebuilt, cammed, headers, yada yada and its never been... 100%. Weird idle issues. Suddenly dies. Pings under load in high gear on highway. Any who, moving forward now, time to tune with a wideband, and eventually get it on a dyno.

Steveo: Any clarification or information about wiring the wideband to pin D27? I'd be curious to know more about that. It's location?

 

So I built this cable exactly how this video shows.
Is anyone else having issues connecting to their ecm with eehack with this style of cable. Scan9495 seems to be working fine. I can connect and even see data coming thru. But for whatever reason EEhack will not connect. FYI , Com ports are set up correctly and Ive changed the latency done to 1. Any ideas guys?

 

@J-13gtp, go into Device Manager and ensure you have the COM port actually set to how EEHack is looking for it. Hard to tell without more information what else your problem could be. What version windows are you running? I know from my research and recent experience with the FTDI chipset you have to install the serial bus and the serial port using their drivers on the website. Once I did that, no issues

Quick update though for everyone else. Thoroughly satisfied with my investment in my Moates cable (ALDU1) and with the work that has been put into EEHack and Scan9495.

I hooked up today. Took me about 45 minutes to get all the software installed and the drivers set up correctly for the cable. No major issues, just patience is key.

Plugged in my Moates USB ALDL cable into the 1994 Pontiac Firebird and the other end into my MacBook Pro running Windows 10 via Boot Camp. I was concerned about compatibility issues to say the least. Fear not, it worked on the first try.

Scan9495 worked flawlessly. I was able to pull my DTCs (which I previously thought I didn't have any but seems I'll be replacing my 19th opti soon, Code 16). I pulled an SIR code (Driver initiator circuit open - thinking clockspring) and I pulled an ABS code (RF excessive wheel speed variation, maybe a bearing, not sure). Everything scanned on first try.

Then EEHack. Masterful for sure. Easy to install, loaded up and picked my initial settings. Was able to have some fun taking over the fans or forcing the idle to adjust to different RPMs. But in a more useful purpose, I was able to read the bin from my ECU on the first try. It's a mail order from a programmer to remain nameless, but its so rich itll make your eyes cry. One issue I had was I couldn't read all the labels for the check boxes or other controls so I didn't get to fully explore. Its hard to tell if this is an EEHack problem, but I suspect its more an issue of running it on a MacBook Pro with Retina display. Maybe steveo_ can recommend a quick fix. Purely cosmetic though. I will say this, a super nice touch, steveo_ put tooltips on virtually every single control or toggle so even though I couldn't read the label, when you hover over it a box will come up and I had a basic understanding of what clicking on it would do. Kudos!

TunerPro opened up the bin that EEHack downloaded without issue. I used the XDF file provided by Steveo_. Still working my way through all the tables and flags.

I didn't get a chance to drive with this rig set up but when I do, I expect it will be awesome.

I will post some screenshots and datalogs soon, and I'll keep it focussed on EEHack since thats why we have this thread to begin with. In the future I plan on datalogging a little, I'll write up how to hook up a wideband to EEHack (I bought an AEM UEGO) and any other interesting finds I discover.

Steveo_, I'd be interested in beta testing, you can PM me.

 

I'm using windows vista, so that could be a issue. However the com port settings are correct and both drivers have been installed. I could have what they call a cloned chip which Ive read sometimes has issues. I'm using the latest drivers from http://www.ftdichip.com/. The FTDI chip seems to be receiving. I could very well have a bad chip that doesn't transmit back the ecm.

Does scan 9495 even require a transmit signal to run the program or does it use what is only received from the ECM.

Just trying to figure out if I have a hardware or software problem.

 

So it seems your issue is the reason I ended up ponying up the cash for a Moates cable. I did look into making my own cable fairly extensively and concluded I wanted it to be as easy and problem-free as possible, so opted out of doing such. I too read horror story after horror story here and other places about homebrew cables frying PCMs and etc.

I would start simple in your case. Verify all your solder connections are good. Then verify pinouts are correct. Verify you have a proper ground at your ALDL and make sure that all your software on your PC is not preventing the USB port from communicating. I downloaded a small program called caffeine that simulates a keypress every 59 seconds and keeps your computer from sleeping, etc.

If you don't believe it is a hardware issue, I would try a different computer to validate or start messing with the software and drivers. A very brief serach on Moates support turned up this document you may or may not find useful. http://static.moates.net/manuals/Dri...ationVista.pdf

http://support.moates.net/ is essentially a knowledge base for this type of setup and discusses (their) hardware and software at length and provides troubleshooting.

I'm not sure if Scan9495 needs a transmit signal.

 

that's something i've always struggled with ; people with non-standard DPI settings. i wrote this thing for 72dpi on windows, some people trying it with linux or on 100+dpi tables have had similar issues.

it's really due to how QT does font sizing (super portable but super annoying). it kinda expects your entire UI to be able to scale itself, but i've designed everything on a fixed layout.

i thought i'd gone and fixed most of the font size issues so it's at least livable, but if you could screenshot any particular problem areas, i'll try to help out there ...

sure does!

this ecm doesn't spit useful data out on its own (none of the 8192 baud gm ecms do), you have to make a request for each 'packet' of data.

the rx and tx lines need to be tied together. a proper serial 'echo' needs to happen on the bus, when you transmit data, it needs to come back on the RX line.

all the lt1 scan tools fundamentally request data in a similar way, but i believe scan9495 simply discards that data, relying on timing, whereas eehack actually ensures it matches the outgoing data before moving on, requiring proper serialization of request, echo, response.. this is so it can detect if there's an issue with a device on the bus writing over the serial stream and 'start over', a behavior which comes in handy on a half duplex shared serial bus with no flow control whatsoever.

however this presents cases where a really shitty serial interface, werido driver, or some bad cabling will kinda work in scan9495 but not eehack.. and i wont change that behavior.. 99% of the time this ends up being the cable's fault.

i see some resistors and diode stuff going on there. i've never seen any of that before on any normal aldl cable. how about just tie the wires together and see how that works out for you?

any beta versions are posted on my site, they're public, discussion of betas is done on gearhead-efi.com. it's also open source, and on github, so you could monitor the commit log or even get a copy of qt creator and attempt to contribute code or fixes. ui modifications are stupid easy. right now i don't do a lot of active development on it unless requested...

 

Main Menu (unadjusted DPI)


Auxillary Screens (unadjusted DPI)


Fixed! (adjusted DPI to 72)

Quick update: Screen scaling feature in Windows 10 was set to 150% with a resolution of 2560 x 1600. Changed it to 100% with resolution of 1920 x 1200. Problem solved. Graphs look right and can read all labels.

 

For people with DIY cables that don't seem to work, I came across this which might provide some insight as to why the cables aren't working.


TL;DR - FTDI has incorporated code into their drivers that bricks and renders useless non-authentic and counterfeit chips.

 

Sooo.... I have good news and bad news.

Good news! FTDI finally worked. Switched to a XP machine, loaded latest drivers from FTDI website and was finally able to connect to the ecm.

BAD news! Using eehack I decided to use the test cable function. After a couple of tries of which each passed I decided to go ahead and reflash the ecm. Several errors and retries later I decided it wasn't going to happen. Now I have a bricked ecm.

I'm sure the cable is the weak link here and not the software or drivers. So now I have to either buy a programmer for the chips or find some one who can reflash the Intel chips.

Anyone got a flash chip programmer?

 

the tunercat guy appears to have a rig that can reprogram them in place. i think it's fairly affordable.

sorry it got bricked, i'd never try flashing on a rig that hasn't been proven... but always sucks.

i usually like to tell people to try winflash first, eehack's flash tool is nice if you're doing a ton of reprogramming since it's super fast for small changes, but i'm the first to admit that winflash is more mature, and eehack tries to do quite a bit of stuff.

it's also hard to test my flashing software since it always worked 100% for me.

i even built it so you should be able to temporarily lose the serial connection (knock the cable out or whatever) during flash and it'll keep going when it's regained. it tries to restart the flashing routine no matter what. during the programming routine the ECM is executing code entirely from RAM, so technically as long as that control loop isn't broken, it should always be able to erase and try again.. thing is the control loop does break sometimes on errors for whatever reason, then the ecm simply stops responding.

one theory i've heard recently is that serial timing can suffer due to certain processor sleep states during programming, as eehack doesn't take a lot of CPU time during that procedure. windows is pretty shoddy at realtime stuff, and timing is certainly critical. it's possible that keeping the cpu working harder might help a bit. i do notice that winflash takes quite a bit of cpu.... i've often wondered if doing a bunch of random math in a lower priority thread might keep timing tight and lower the occurrences of flashes gone wrong?

 

Dang. I was kinda hoping that Steveo had a programmer. Its ok, I went into this knowing that bricking the ecm was a good possibility. I'm already looking at a Willem programmer to take care of the chips. I haven't emailed tunercats yet to see what the cost of flashing just the chips is or even if they allow that sort of thing. The plan right know is to add chip sockets to the ecu boards so quick changes can be made without desoldering chips every time.

I have been rolling the idea around in my head about offering my services to repair ecm's that were bricked during a flash, that is if I buy the programmer.

 

anyone?

 

yeah a cheap willem programmer will do the trick. if you de-solder carefully you can certainly re-use the chips as well..

 

getting accurate wideband scaling through the 5v inputs on the ecm can be tricky, hell it can be almost impossible.

one problem is that the inputs aren't truly linear, and their linearity can vary depending on what's plugged into them.

with the LC-1 (which i'd borrowed from a friend a long time ago) i found i had to use the software for the wideband to define a custom, narrow output range.. lets say 9:1 to 16:1 or something.

i found that gave me accuracy to +/-0.1 in 'the range where accuracy really matters' (12.5:1 to 15.1)

you still have to 'trim' the equation so the log matches the gauge display, that's why i put that feature in... also difficult because both are kind of jumpy.

what i found best for trimming is to kill the engine dead at like 1500rpm, which usually gives you a fairly constant display of some kind of value, as the exhaust is nice and full.

of course, if you want perfect accuracy with a particular brand of wideband, you'll want to build me a list of points, wideband output voltage vs logged raw value, and i can turn that into a table or formula and build it into eehack for all to enjoy. i planned to do this myself, but when it was pointed out that different widebands can cause different curvatures, i realized that without every brand of wideband on my desk it wasn't going to happen.

 

Just purchased ALDL USB cable. Is this what I need ^^ for software for my Computer?

 

Yes. It is.

 

and tunerpro (just regular tunerpro, not RT)

and the EEX xdf (on the same site as eehack)

 

Have had a few hours of logging with with program now. What an application! Awesome, awesome, awesome. Easy to use. ZERO connectivity issues (Running Windows 10 on a 2012 MBP retina in boot camp, connecting to car via a Moates ALDL1 USB cable).

Got my AEM wideband installed. Gauge is in and ran the 0-5vdc analog output to pin D27. Opened up EEhack and changed the setting for wideband datalogging. Flawless. Worked the first try! So now wideband is logging with everything else as well.

Really liking the analysis procedures that the Analyzer portion of the program provides.

If I must offer any criticism, which is hard to do on a free app, it would be more flexibility and UI improvements in the graphing screen. I use that screen ALOT for working out kinks. Things I would love to see:

1) Ability to scale the y-axis or set those parameters easily directly on screen or possibly even have an auto-y function. For example, wideband y scale gives everything from 0 - 24, but really I am looking at a much smaller area than that and I would want to set it to 12 - 16 or something else.
2) Custom major/minor gridlines would be nice. Custom colors too perhaps?
3) The ability to tooltip on a datapoint. I know some DAQ software ive used in the past you could hover over a data point in a graph, and a tool tip would appear giving you the data for that specific point. For this app, if you could hover over a point in the graph and have it tell you the actual value at that point via tooltip would be great instead of having to double click on the graph at that point, and then go back to the data log screen.
4) Ability to choose how many graphs. Most of the time I would be ok with one really large graph as opposed to the stacked dual graphs. This coupled with ability to scale the y axis would be perfection
5) Ability to export data as CSV, maybe excel. Not sure if its a hard ask but my mail order guy is asking for datamaster or freescan, so not sure if there is a standard datalogging format where this app can export to those formats or vice versa.

This software is really polished and has come a long way from when I first started using it. MAJOR PROPS to steveo and his assistants for this software. They really deserve some praise for the time and effort it has taken to develop this software FOR FREE! Consider giving them a donation guys if you partake in the goods.

 

thanks for the great feedback,

i know the graphing isnt perfect.

scaling in the graph can be done in the definition file (easily modified in your favorite spreadsheet program). i realize this sucks but will fix your particular issue

instead of per point tooltips, double click your data point to jump to it, and see all the data you want in the dashboard or individual message tabs

it does export csv format, see the export csv button in each tab of message data. everyone seems to miss that. it has to be message-specific, the rest of eehack deals with multiple messages a bit more smoothly.

this csv data can be used in my trimalyzer tool too (better in some ways and worse in others)

 

First I'm hearing of this software, will try it this weekend.