jeepguy553

Just a thought and I am sure someone has tried this before. A friend and I were wondering how difficult it would be to stream data from WinALDL or TunerPro RT into MS Excel in real time. We are playing around with the idea of real-time tuning of a C3 ECM using an automated process that would stream data from WinALDL or TunerPro into a pre-formatted spreadsheet. This would likely work best while emulating so that changes could be seen as the engine is running.
Any suggestions?

derf

I guess I'm the "other half" of this consortium.

I'm not only thinking of streaming data between apps, I'm looking for something more ambitious in the long run. I'd like to write an application that can read the ALDL directly, run some (convergent) tuning equations based on what it reads and talk directly to a PROM emulator in real time. No other applications in the way.

I do have several years of experience writing real time embedded software doing big math so that part doesn't scare me. I just need a couple of things: a) advice on the best place to find the comm specs and protocols for ALDL readers and the common PROM simulators; b) time and motivation to crank out the code; c) someone more familiar than I am with the engine control equations and how they interact based on the sensor data (or a good book that talks about them); d) someone who knows the ALDL readers and PROM simulators inside and out so I can bounce ideas off them.

The idea would be to have a windows based application that had a few control buttons and some real time status indidators. One would only have to buy the ALDL cable, the PROM simulator, plug them in and tweak the controls to tune while driving down the road (or sitting on a dyno). Once a good tune is found, an image can then be burnt to a PROM and the prom put in the ECM.

That's the idea anyway. And it's not much more developed at this point. I have the ECM maps so I can make sense out of them fairly easily. I just haven't started cranking out any designs yet. (It doesn't help that my engine is still on a stand and not yet in my Jeep so I don't have anything to work with in the garage yet.)

derf

Ok, I'm digging through most of the stickied posts with resource links. It's going to take me a while to digest it all. If anyone wants to chime in with advice, espeically with advanced topics that might be beyond shade tree mechanic levels, by all means do so.

AlexJH

I think the source to Craig's software is available, and there is also Freescan if you are looking for ALDL streams. I'd be interested in helping with this, but I'm busy with some hacs, and <A HREF="http://wasabi.dynu.com:8080/wiki/index.php/EcmEdit">EcmEdit</A>. I want to get those projects out of the way before I start any others.

Alex

derf

Thanks for the info. I may pitch in on that EcmEdit and help debug it. The best way to learn is to roll up your sleeves and help out someone else who knows what they are doing.

While I'm a good software engineer, I'm still a novice when it comes to engine control. I'm looking at 3-4 months minimum of digesting information and learning about the complexities of engine calibration. Besides, I need to get my engine into the Jeep and get it back on the road so I have my own working test bed and that's going to take 6 more months.

The rough plan is to develop a nice C++ program on windoze and Linux to do this on-the-fly calabration of the proms. I want to make it modular so it will work with a variety of proms. I figure there has to be a way to monitor all the sensors to recalibrate the tables in the PROM on the fly given a baseline map for a starting point. I'm betting it's easier to do that big math on fast laptops. The 8 bit controllers on some of these ECMs aren't really fast enough to do that level of calibration. Besides, they don't really have a way to update their own PROM tables without serious hacks.

So if you have ideas and want to pitch in, I'd welcome the help. I may try starting an email list (or even a small forum site) to share data, plans and discussions for whoever wants to pitch in.

But like I say, I'm just starting to get my feet wet. It's going to take a few months to ramp up to the point where we come up with the basic outline for the program design.

Mangus

ftp://diy-efi.org/pub/gmecm/ALDLstuff.zip

Just about every GM OBDI ALDL spec is there. Have at it.

Mangus

I'd think this would be nearly impossible (you aren't going to get an ECM to burn a chip in-socket - or at least not in a way that everyone can use easily). I think the best way to go about this is to do the real time tuning by way of an emulator (Romulator, AutoProm, Ostrich, Prominator Pro).

AlexJH

I'm a linux weenie.

Feel free to use my Wiki site: http://wasabi.dynu.com:8080/wiki/index.php/Main_Page

derf

What I'd really like to do is be able to drive that emulation hardware from my app so I didn't have to go through theirs. Having a complete self contained application would make automating the tweaking that much easier.

Oh, and thanks for the link. That will really help.

Mangus

Yes, you'd want to drive the emulation hardware in your own app (rather than through mine). See the Romulator web site. They list the protocol for communication. The Prominator is a little more difficult to interface with, being parallel and all (Bill!).

derf

I'm actually a fan of designing my own operating system. I've done that a few times for custom embedded avionics systems. They weren't complex but they sure did do real time better than any general purpose OS I ever used.

I've been using Linux since kernel 1.2.7 off and on. I know a lot of DIY tuners are also Linux geeks so the program has to be available for them. However, a Windoze version would appeal to a broad segment of the population too. I've done cross platform development (NT and Linux) for device drivers before so this shouldn't be too much of a challenge, especially if we design it to be modular. It's not too hard to swap out the comm modules and the calls to create and run the window interface if it's designed to do that from the begining.

Cool. I'll dig into that for a while.

derf

Cool. I'll start with the Romulator then.


Man, I really am going to have to start some kind of web site/blog/forum to get all this organized.

I think I'm going to start with a manual system where all the streaming data shows up and you can manually tweak everything in the same app. I'll use that to get the interfaces debugged and working. Then I'll start adding the "self tuning" portions. That seems to be a good rough heading to start out on...

Mangus

Yeah, you'll probably want to do that. What you propose is certainly not simple, nor will it be quick (regardless of your programming talent). Go for it. DIY-PROM'ers love innovation! :-D

derf

I never expected this to be quick, that's for sure. I'm a good programmer but not that good. And I have a lot to learn about engine control before I can make good headway into this project. It doesn't matter how good of a programmer you are if you don't know the subject you're programming on.

Mangus

Feel free to ask (me) if you need help. I've been known to write a line or two of code (some even directly related to what you're talking about).

derf

Cool. I've written a couple of lines myself but flight controls and displays aren't the same as engine controls by a long shot.



And to think, I got started on this idea about 6 months ago when a buddy of mine said off hand "carburetors suck off road, you should adapt a GM TBI system to your engine"...

JPrevost

<-- been working on Autotune for over a year on and off. I've got all the code done for the fueling and am now working on the romulator integration side. Once I put the code together I should have an autotune up and running in real-time. It's pretty advanced if I might say so myself. There is code that will calculate your "normal engine temp" and do all of the CTS, IAT, voltage, etc. compensation tables. I've even got AE code but that hasn't been tested yet on the bench. I've already got a good plan for the AE code and it shouldn't be too difficult with lockers... impossible with the c3 ALDL .
Once the fueling works and checks out okay I'll move into the spark advance and economy code. Right now I only have 1 EGT and 1 CHT sensor. I'd like to get at least 4 of each for obvious reasons. The spark stuff is tricky and I haven't a fool proof plan on how to code it yet. Stage 1 would probably be just looking at the knock counters but I fear that won't be enough. The fuel economy will be difficult because I don't have a fuel flow meter, I'll have to come up with a "value" that will be derived from MAP, pulse width, CHT, EGT, and AFR. Too bad I couldn't find a TBI flow bencher that would clean my injectors let alone run them at varied pressures and pulse widths to chart fuel flow .

I suggest you guys do your own code from scratch. I'm riding solo on this one since I seem to be alone with the lockers and TBI. The slower ALDL rate will limit you to nothing more than a smoother closed loop . If the speedreader comes out I'm sure I could adapt my software to doing the complicated stuff .

jeepguy553

derf, remember I have an AutoPROM and we can use that for the interface. I also have all those ALDL defs that Mangus linked to in his post. If you do get that blog forum or email list up and running, let me know and I'll get in on the fray too.

derf

I'm going to look for a good linux based hosting company this weekend and maybe take a stab at getting up a home page with a few links and some kind of forum software.

pstallbaumer

Hey Derf:

Where are you at on this standalone VE autotuner application for Windows? Are you planning to use the ROMulator for the first rev?

thanks-
Philip

robertf

thats why Java is your friend

I know this is an old thread that was recently resurected, but this link helped me figure out how to read 160 baud at higher serial port rates.

http://www.techedge.com.au/vehicle/a.../160serial.htm

Mangus

How do you read 160 baud at higher rates? The ECM will only output at 160 baud. You'd have to speed up the ECM's output before you can read anything any faster.

robertf

try setting a serial port to 160, usually it won't happen and that is why you need to read at higher rates. And those serial port adapters that most laptops require are even more picky about what speed you set them to.

to get it to work you sample the data at a higher speed, (2400,9600,etc), once 8 bits are recieved at the higher speed(which is less than the time it takes for the 160 baud stream to finish its stop bit) it waits for the stop bit and start bit from the 160 baud stream.

Then you look at the timing of the 160 baud stream vs the higher rate and at whichever moment the ecm bit was sent you read the bit that corresponds to that moment from your sampled 9600 baud byte and its your 1 or 0

Mangus

Oh, yes, you need to read at 2400 or 4800 (for USB). Sorry, I misunderstood what you were trying to say.

yager

jeepguy533, any progress on your project?

MonteCarSlow

Serious hacks? I beg to differ. It's quite trivial in my opinion...