Jeep SBEC PCM tuning (91-95)

Ok -- sounds like you are way ahead of me :)

Recently I made a custom y-pipe, and I added a second bung for a wide-band O2 sensor. It is current blocked up with a bolt.
 
Started creation of the logging routines.. just a update to show work is still progressing. Also templates are being added to the editor to facilitate easy ecm additions for new ecms as I receive them.
 
Heck yeah.

Data log is operational. That being said, there is integration to be done to make it user friendly to use. Presently, addresses are entered in hex code and dumped in hex to the screen in true test development style. If I had it my way, it will all be command line interface but that isn't very modern or user friendly.. grew up on terminals and linux.. no pics this time, not much to see except for some text screen. From what I have ID'd in the code I can watch MAP, TPS, CTS, IAT, RPM, switch states, etc.. now to merge it into the editor GUI and make it useful! it actually worked on the first test run.. :rockon::driver:
 
OK so I started a live data view window layout.. let me know what y'all think..



ldv.jpg
 
Relaid out the viewer, now the main screen shows one data set of points at one time for dead view of logs.. added individual graph windows that can be selected. (Need to add scales to them and labeling provisions).. next up, adding real-time logging and display for live data view.. once that is done, I'll integrate this into the editor and add auto recalibrate, injector rescaling & latency for injector changes, feature/option editing (antitheft included), and ability to set it up for different ecus, though that will need to be done by hand on a individual basis unless the code is similar to one already mapped. After that I will move onto finishing the board layout and produce some units for delivery after thorough testing to ensure that they perform properly. Oh and @GarageBuild I have a V8 zj flashable ecu here from a 94 or 95... Though for some reason it wouldn't run my inline six after flashing it with the i6 ROM... But it did flash. I saved the old bin from it so I can analyze a V8 to see if it's similar at all to the i6 stuff or if it's like the car code is, entirely different team wrote it.
 
Weekly update:
I am in the process of migrating the console flash & logging utility to a Windows based app dialog with status & interface configuration... That will enable me to merge the editor, the log viewer, and the programming/logging tool into one application so it is all just point and click. Once that is done, the editor will expand to be reconfigurable and enhanced to include settings for options,wb o2 will be added to the i6 ROM, then assisted fuel calibration algorithm will be added (along with a "Target table" that will specify the desired AFR).

Plugging along....
 
Updates: working on integrating the comms from the console application to the windows app.

Hardware kits/plans will not available as it uses a microcontroller that requires programming prior to installing the chip. Fully complete units will be available & sold when the software is bug free & 75% functional (read, program edit spark/fuel/alarm/etc).

Reasoning behind the hardware being closed is to eliminate issues over hardware not meshing with either the sbec or the computer. It's difficult enough to troubleshoot over the internet and I'm not going to make it harder by reusing the hardware & the software except if everything is uniform across the board.

Hopefully that makes sense to y'all.
 
Progress.. Ported my XJ head and wound up lean so was forced to accelerate development at least partly. Data logging is working (though it needs severe polishing, as you will see). Tuning is capable of adjusting fuel and spark.. I had an issue in the code where modifications were not saved. I fixed that and was able to fatten up fueling. Lots more to do and add and integrate before beta release ready, but its at a point where progress will seem slow because its integrating the separate tools ( presently, ProgCon, DataView, TestEditor are merging and becoming the final tool ). Binaries of the ecus will not be distributed with the tool, but the editor maps will be. Reasoning is that if you have the ECU, you have the binary already, you just need to download it. (and then I'm not distributing copyrighted material, only outside creations that give a map of said material that you own)

graphs.jpg


here you can see i rolled into the throttle from a stop, accelerated through 1->2->3 and let out, slowed down, then got back on it. elapsed time was probably 30 seconds. you can see there are no scales on the graphs and the height of the graphs are outside the bounding rectangles. also the hex address in the title is the address of the data in the ECU, and the pretty names are in the bottom right window, thats another thing that needs to be added in, is a pretty list to select log data from. in addition, the data is recorded by a separate program, which needs to be integrated.
 
Well, I had started a Windows gui app for the programming but it's not cooperating.. something about multi threading and the com port isn't jiving. I'm just going to modify progcon to launch from a command line, behind the scenes without any need for user input except in the gui editor and it's automatically take care of the programming. Grrr. Spent too much time screwing with trying to make it Windows based already. I'm a console guy at heart. At least the command line progcon works perfectly every time. I spent much time perfecting it to have to go back through it just because I want it to be shiny. At least the user won't have to deal with the console, except for to look at and see what it's doing. The console app will also be used for logging, and will be able to do real time, just have to pipe it into the other application. It'll be best all the way around. Actually I could pipe the console output to the window and you'd not know it was a console app running anyway.
 
Well, I got the programming part of Progcon ported over to a GUI app. Had some stupid bugs in it.. Like why the heck does windows change the current working directory when you select a file from a FileOpen dialog and open it with full path name? that was causing the command code files to not be loaded since it changed the CWD. Dumb. Also had issues trying to get the text to update the dialog box. Cured that by sending a windows message with the additional text.. but there was another issue with PostMessage vs SendMessage.. PostMessage posts and returns immediately. SendMessage waits for completion. Trouble with PostMessage is the memory was being changed before the update occurred. GAH. Stupid stupid bugs that took alot of time to figure out. :kaioken: But I got the app to work uploading a new ROM to my test ECU on the bench YAY. I'm getting there. :driver: BTW I had created a tune for my XJ but with a ZJ cal and couldnt figure out why my fan wasn't kicking on.. (ZJ do not have a electric fan, DUH!). so I flashed it back to a stock XJ cal and I couldn't believe the seat of pants power loss over 10-20% additional fuel for my ported head.. I need to fix that. Difference in the two cals was being able to push thru my 4wh disc and not. I couldnt believe that just porting the head would unleash that much additional power.


Teaser for the new graphical programming/data logging app that will get rolled into the editor and data viewer.. I need to fix the title where it says "this may take some time" to reflect its actually programming the PCM.

progammer.jpg


:rockon:
 
Next phase I'm working on is they live data view and integrating log/view in to the above program. I got the mouse to display the value for which it is on the graph left to right. Need to add scaling, and real world values to the raw data, as well as labels and axis names & prolly time instead of sample count. I guess having to have my foot up is good for something anyway. I'm looking for a Windows control that's like an Excel table if there's any programmers on here that needed something similar.. the bunch of 153 edit boxes needs to go do that way you can select cells and copy them between tables but I could just keep the boxes and add an import from another cal function.. probably be way easier though the table control would really clean up the editor interface.. been mulling over different options for the editor, mdi, sdi, tabbed dialog, also need to have a page for options for the cal... But here's the kicker, it's all got to load from a configuration file so that it can be reconfigured for each calibration (I have future plans and not every cal has everything in the same place, though most of the inline 6 cals I have are similar enough to use the same definition.. v8 is entirely different, and I'll bet good money it's closer to the v8 pick up truck cals on the same model years..) future plans after sbec is complete to target and do the same to jtec & ngc, at least until they began encrypting the raw binary image. Presently there are only 2-3 individuals/companies that offer tuning of sbec computers in the Jeep, so the release of this tool set will be monumental when it occurs in the near future. Sbec has too long been regarded as untuneable in the Jeep world. That will change with the release of the tool and interface.
 
yay. I found a control that will do what I want for the editor... It supports drop lists, text edits, copy and paste selections (for copying tables in and out of other calibrations) and reconfiguration on the fly. this will allow the editor to support multiple calibrations and editing of the cal without having to rewrite the dang thing for each one. once I have this merged into the editor, I will begin merging the programming/logging software into the editor along with the log viewer (as well as allowing live data view while recording the data). this might not look like much, but being able to embed buttons, edit boxes, drop down lists is a HUGE advance over the multiplicity of edit boxes I had. Like, being able to load a "template" with the values out of the calibration, and allowing the user to select values out of the drop box (Security=On/Off, Cruise low speed [mph]= 35, Cruise high speed[mph] = 85, separate tables for injector dwell, fuel hot, fuel cold, all that can be collapsed as well with the tree control) YES!! and I made some upgrades to the data graphing.. Data logs will also be time stamped with the run begin time & record the time of each data segment on the computer (down to the millisecond, so time between samples is visible.. plus I guess you could calculate G force based off the MPH from 0-X mph and the time in mS, as well as eighth/quarter mile time, not that most will use that function, other than for giggles [except maybe when i get my supercharged stroker going.. hehe]) the data viewer follows the mouse and displays the raw data (in future will be scaled to be the actual value, along with labels, but the table/grid control was a major major component I was missing keeping me from bringing these separate pieces together)

grid.jpg


graphs.jpg
 
a_kelley said:
yay. I found a control that will do what I want for the editor... It supports drop lists, text edits, copy and paste selections (for copying tables in and out of other calibrations) and reconfiguration on the fly. this will allow the editor to support multiple calibrations and editing of the cal without having to rewrite the dang thing for each one. once I have this merged into the editor, I will begin merging the programming/logging software into the editor along with the log viewer (as well as allowing live data view while recording the data). this might not look like much, but being able to embed buttons, edit boxes, drop down lists is a HUGE advance over the multiplicity of edit boxes I had. Like, being able to load a "template" with the values out of the calibration, and allowing the user to select values out of the drop box (Security=On/Off, Cruise low speed [mph]= 35, Cruise high speed[mph] = 85, separate tables for injector dwell, fuel hot, fuel cold, all that can be collapsed as well with the tree control) YES!! and I made some upgrades to the data graphing.. Data logs will also be time stamped with the run begin time & record the time of each data segment on the computer (down to the millisecond, so time between samples is visible.. plus I guess you could calculate G force based off the MPH from 0-X mph and the time in mS, as well as eighth/quarter mile time, not that most will use that function, other than for giggles [except maybe when i get my supercharged stroker going.. hehe]) the data viewer follows the mouse and displays the raw data (in future will be scaled to be the actual value, along with labels, but the table/grid control was a major major component I was missing keeping me from bringing these separate pieces together)

View attachment 274601

View attachment 274602
Click to expand...
Man, this is starting to look like something even my computer illiterate self could work with! Great work.
 
Ok so the editor needs a whole entire restructure and recode for it to work the way I want it to. Yes it somewhat works right now, but it won't give all the features I want it to have without doing everything by hand, which would suck to add another different calibration definition that uses different data structures... so... I leave this... a restructuring guide for the design of the new MultiDocumentInterface Editor/Logging/Programming utility. this will allow the live logging (recording at the same time, viewing optional), review/replay of datalogs, programming, dumping, editing the tables & code in the calibration (along with tracking time stamped changes, which could allow for a total difference, start to finish, of the tune for review purposes, along with showing data logs according to each tune by version/time stamp, or letting you undo that change you made that screwed everything up royally, instead of having to save tens hundreds of different copies, though that would not be a bad option if it automagically created a new file every save instead of tracking each change, but tracking each change will let you see each and every change and undo a single change later, even though it was 50 changes ago)... I am NOT saying that all these features will be in the first release or ever, but it will be designed to allow that to occur without redesigning the whole thing again. (as well as including backwards compatibility for importing saved calibrations or logs so that nothing is lost when a new version is released. this is easily done by planning ahead for future options and including a version number in the files, but i digress for those less computer inclined) So I will leave this ending with a layout of the new software diagram.. in excel. if you see something I missed, please do mention it, so I can add it in. (even though it may not happen for awhile)

app structure.jpg


The template will define the data in the calibration. The template will be composed of BinItems that define what the data means. The editor will embody each of the BinItems as a separate "view" of the calibration. So to add a definition to a cal, a new BinItem is added to the template and when it is opened, it will magically just appear in the tree view in the left half of the cal window. When clicked on, it will bring up the corresponding view(s) in the right pane(s), be it a graph, table, both, or whatever. Future future will include in editor code editing for those that needs the raw modification power of redesigning the cal, like for forced induction. Even though nobody might read this, it helps me to more fully understand what I am intending to do and see potential flaws. (my wife hates listening about coding, but heck, the dog would listen just as well, maybe better, he doesn't typically talk back.. unless he wants something that is.)
 
Well since I found the grid control I want, I decided to rewrite the editor from scratch as an object oriented multi doc interface. I can reuse the graphing for the 3d but the editing part is all new. Being object oriented makes it extendible to add new data types without reinventing everything. Each table or information is it's own object that's told to draw itself on the view using the documents data. This also lets me save all changes incrementally as they are made, allowing you to undo a step x steps ago. It's fun to me learning all these new coding methods. I've not seriously written any code since around '06. Granted, my compiler & tool set is similarly dated but it is was faster and has a much smaller foot print than anything new like .NET 2019. (Not sure that exists but you get my point). .net is huge and bloated. I don't like the point n click coding everything has devolved into. Anyway, I've got the 4/9 byte & 3d tables displaying, editing & saving through the grid control (think Excel).. now just need to move them into a MDI with ability to edit the template ( locations of data/tables, code segments, label the data & table values) and add in the programming function and it'll be ready to release into the wild, along with interfaces to make the program useful.
 
Getting closer, the tables load out of the bin file given location, can add and rearrange then in a tree control save and open, need to make the bit and byte editing code and it'll be ready to merge the programming code in.. also in future is adding in a internal code editor.. do it will be able to configure individual calibration and try to reuse templates.
 
Hello,
I just found this thread.
It is incredible.
I hope this post is not too off topic.
I'm wanting to get some help with my 1989 Shelby Dakota's SEMC. It seems that no one but me wants to keep the stock computer system working. I know this thread is about Mopar Jeeps SBEC computers. The are close with the SBEC being superior.
Basically I would like to build a bench test wiring set up that would allow me to pull the cals from my SEMC computers. I do not want to destroy my computers to get the Cal. With this I could burn new chips and socket other SEMC to be used in Shelby Dakota's.

If by any means I can accomplice this It would be fantastic if there were a way to be able to modify the program like this thread has been talking about. I know the SEMC arn't flashable but thats not what I'm trying to accomplish.

What I have found with some of the SEMC's is that some of the surface mounted computer chips have broken free from the board and were trapped under the plotting gel. This causes interment run problems. I will try to upload a picture.

Oh yea the Shelby Dakota computer was a limited run and different from a Ram computer. The Shelby Dakota's computer ran the electric fan and also had a tach, the Ram did not offer this .

Any help would be appreciated. Thank you.
 

Attachments

  • IMG_1731 (Medium)_LI.jpg
    IMG_1731 (Medium)_LI.jpg
    117 KB · Views: 506
I think it can be done. I'll have a look later. Did you try over @ turbo mopar ? They have a huge mass of info regarding SMEC.. smec is far older and slightly different from sbec, but similarish. I'd need a working smec to make a interface for it.
 
Thanks for the reply a_kelley
I have a post over at turbo dogde. Got some help over there. But they aren't so interested in V8 stuff.
With that info and other I have found I started working on getting things together to make an interface.
I have the boost button sci FDTI cable. I also have a 5v FDTI cable with out BB end. From this post I picked up that a ziner diode and capacter was used for the line protection. I also have a junk yard wiring harness. Also some computers.
 
turbo-dodge wont get you that far. post over on turbomopar. Those guys are definitely the SMEC experts!

Hope that helps!
 
Thanks Sev80 TurboMopar was some help. I was able to get my set up working and was able to pull the cals from the stock SMEC computers.

A-Kelly Do you think there is a way you can look at them and see if your program will modify them? I know little about how to do it.

Some things that interest me is that the Shelby and Sport SMEC had a computer driven Tach. Nothing else did. The Shelby Dakota also had computer controlled fans. No other SMEC had it.

Thanks again.
 
Back
Top