OpenSource ECM Project
06-27-2010, 08:43 AM
#41
All: This post will contain no useful progress. But, thank you for the responses - exactly what I was hoping for. My posts may be infrequent as it will take me some time to chase down the info you've provided and digest it.
Please see response to S3 below regarding intent to be legal.
The project is large. It must probably proceed in stages, the holy grail being achieved only after development of necessary test fixtures/software/etc is done. Also, there are several different areas:
- Mechanical (connectors - where to purchase?, etc)
- Hardware (processor selection, speed, IO, memory. Gauge the capability of Nissan's h/w)
- Software monitoring (initial) and control (later)
- Software communication (Consult & OBDII)
- Development and testability tools, fixtures, etc.
Delacruz: All help is welcome if this gets off the ground.
Kevlo: Thank you for the helpful starting points.
S3: Of course I am a genius, I can't figure out why nobody else in my life seems to realize this... Regarding reinventing the wheel, if I waited to do something 100% original I'd die a very bored man. It bothers me that the ECM is so expensive and opaque, and since I plan to be driving my two 99 Maximas 10+ years from now (not at the same time, that's another project), I'd like to try to get more control over the process.
S3/4DSC: Regarding reverse engineering, this means many things. I am DEFINITELY NOT talking about disassembling, copying, and redistributing Nissan's IP. I am talking about a black-box emulation using characterization techniques, using clean-room development techniques, maybe bending things to my advantage with whatever "inside" information I can start with (basic things like processor, clock speed, other hardware, etc. used on Nissan's ECM).
SaithLinux: Exactly, RTL. Very useful IO suggestions! I think the USB/harness is top contender, don't know if USB with off the shelf serial adaptors would provide adequate/quicker solution.
FallenOne: Thanks for the support. Will check out the WRX and F-Series OS stuff in more detail.
Cruz/EsQ/Nismo: Thanks.
Please see response to S3 below regarding intent to be legal.
The project is large. It must probably proceed in stages, the holy grail being achieved only after development of necessary test fixtures/software/etc is done. Also, there are several different areas:
- Mechanical (connectors - where to purchase?, etc)
- Hardware (processor selection, speed, IO, memory. Gauge the capability of Nissan's h/w)
- Software monitoring (initial) and control (later)
- Software communication (Consult & OBDII)
- Development and testability tools, fixtures, etc.
Delacruz: All help is welcome if this gets off the ground.
Kevlo: Thank you for the helpful starting points.
S3: Of course I am a genius, I can't figure out why nobody else in my life seems to realize this... Regarding reinventing the wheel, if I waited to do something 100% original I'd die a very bored man. It bothers me that the ECM is so expensive and opaque, and since I plan to be driving my two 99 Maximas 10+ years from now (not at the same time, that's another project), I'd like to try to get more control over the process.
S3/4DSC: Regarding reverse engineering, this means many things. I am DEFINITELY NOT talking about disassembling, copying, and redistributing Nissan's IP. I am talking about a black-box emulation using characterization techniques, using clean-room development techniques, maybe bending things to my advantage with whatever "inside" information I can start with (basic things like processor, clock speed, other hardware, etc. used on Nissan's ECM).
SaithLinux: Exactly, RTL. Very useful IO suggestions! I think the USB/harness is top contender, don't know if USB with off the shelf serial adaptors would provide adequate/quicker solution.
FallenOne: Thanks for the support. Will check out the WRX and F-Series OS stuff in more detail.
Cruz/EsQ/Nismo: Thanks.
06-27-2010, 09:09 AM
#42
Those USB -> Parallel Port adapters are available. They are used heavily in the FTA Satellite Receiver scene, this would allow say someone on a newer laptop to be able to flash the FTA receiver using usb rather then having to lug a big desktop around. I can provide links and info should you request just have to look around some sites I used to frequent.
does anybody have stats on the ecu as far as processor, or amount of dedicated memory, or data trasfer rates? opperations per second even?
and just another question... is open loop essentialy an on the fly correction of air fuel mixture? i was just wondering to see if it would be possible to have the program written to always do a constant tune via the air fuel ratio, timing, etc. If that is possible, or atleast air fuel is, then maybe you could make it adapt to other changes like the timing and stuff... so instead of the car just running like crap it will fix its self when theres an issue...
n btw, sorry if im not techy or motor head enough for some of you. its just some things i was thinking about... maybe im two steps behind some of yall...
06-27-2010, 11:44 AM
#43
dirt cheap $3.49 shipped on ebay from Los Angeles not china. From what I read, Open loop is when it uses data from the oxygen sensors among other things to correct the Air-Fuel ratio to stoichiometric mixture which is 14.7.
http://cgi.ebay.com/USB-Female-25-Pa...item4cf01291b8
Last edited by EsQueue; 06-27-2010 at 12:29 PM.
06-27-2010, 03:14 PM
#45
Read it, he dissapeared for about a month and everyone decided to call BS on him. But hes still around, just not Here. You can message him on other forums though. Also, he updated like a month ago... So, he could still be working on it. Im sure he knows more than all of us combined at this point, The OP NEEDS to contact him as a refrence point.
06-28-2010, 04:28 AM
#46
You'll never be able to sense an analog signal with just a serial or parallel port. And you won't be able to drive the solenoids/motors/injectors/coils from them either. You will need to have some processing external to the main computer, and some sort of electronics "glue" between the low voltage processor and the relatively high voltage car electrical system.
I'm not trying to be rude, or to say that it can't be done, because it surely can. I'm just trying to get across the fact that if you don't know much about embedded processing and mixed signal interfaces then you are not going to have much success.
I'm not trying to be rude, or to say that it can't be done, because it surely can. I'm just trying to get across the fact that if you don't know much about embedded processing and mixed signal interfaces then you are not going to have much success.
06-28-2010, 07:10 AM
#47
06-28-2010, 08:10 AM
#48
Very cool idea, I see a couple doubters at the beginning of the thread and all I have to say is that.... a long long time ago, someone said lets go to the moon! And I'm sure back then everyone was like "yeah, maybe I will grow wings and fly too" but the point is, just about nothing is impossible with enough people working together and a strong enough dedication.
Looking forward to future results! Good luck!
Looking forward to future results! Good luck!
we could make the ecm on a hollywood set too! ...this guy thinks we went to the moon! lol!
06-28-2010, 08:38 AM
#49
Member
Thread Starter
Join Date: Jun 2010
Posts: 32
GENERAL RESPONSE
GENERAL RESPONSE
Hi. Thanks for all the valuable comments. I have skimmed most but haven't come close to digesting everything, so you may feel that I have missed the point of your comment(s). At the moment I am backlogged because the assistance is flowing faster than I can keep up.
This is a good thing - please continue.
I am trying to make my responses as clear as I can. This means I use a lot of words. Sorry for the lack of brevity that will follow.
I am adopting the abbreviation OSECM (open-source ECM) from now on for brevity.
I plan an approach of incremental development and simultaneous development of appropriate devices and test suites for simulation and unit/regression test. This implies an initial quantum leap: achieving basic (passive) connectivity so that incremental test and development progress can proceed. This involves a lot of boring legwork before any interesting stuff can happen. Please see messages to follow.
Warning: boring text follows, skip at will...
Some have asked about my background, so I will bore you with my personal info. Software engineer with experience with embedded systems of varying sizes. Worked on some large communication switches during the boom of the 90s (VxWorks and Linux), specialized in real-time high-performance coding (lots of assembly language, register scoreboarding, optimization, etc). Before that, PC BIOS (raw code, no OS). Since that, much smaller embedded devices (Linux). Also have a EE degree, can read specs and schematics very slowly, out of practice with actual circuit design. Armed with all of this, I am able to make stupid mistakes in a variety of areas and I know how to f*ck things up in a hurry.
Hi. Thanks for all the valuable comments. I have skimmed most but haven't come close to digesting everything, so you may feel that I have missed the point of your comment(s). At the moment I am backlogged because the assistance is flowing faster than I can keep up.
This is a good thing - please continue.
I am trying to make my responses as clear as I can. This means I use a lot of words. Sorry for the lack of brevity that will follow.
I am adopting the abbreviation OSECM (open-source ECM) from now on for brevity.
I plan an approach of incremental development and simultaneous development of appropriate devices and test suites for simulation and unit/regression test. This implies an initial quantum leap: achieving basic (passive) connectivity so that incremental test and development progress can proceed. This involves a lot of boring legwork before any interesting stuff can happen. Please see messages to follow.
Warning: boring text follows, skip at will...
Some have asked about my background, so I will bore you with my personal info. Software engineer with experience with embedded systems of varying sizes. Worked on some large communication switches during the boom of the 90s (VxWorks and Linux), specialized in real-time high-performance coding (lots of assembly language, register scoreboarding, optimization, etc). Before that, PC BIOS (raw code, no OS). Since that, much smaller embedded devices (Linux). Also have a EE degree, can read specs and schematics very slowly, out of practice with actual circuit design. Armed with all of this, I am able to make stupid mistakes in a variety of areas and I know how to f*ck things up in a hurry.
Last edited by mikey66; 06-28-2010 at 08:45 AM.
06-28-2010, 08:39 AM
#50
Member
Thread Starter
Join Date: Jun 2010
Posts: 32
CABLING - PLEASE HELP
CABLING - PLEASE HELP
First things first. This project cannot proceed without cabled accessibility to the entire ECM interface. This means tapping into the entire 104-pin ECM connector, probably in various cabling configurations depending on the particular development task at hand.
Embarassingly, I cannot find the appropriate connectors. The closest I have come is: Tyco Electronics MULTILOCK Impulmate Connector:
http://www.tycoelectronics.com/catal...10372/628?RQS=
*** I am going to pursue finding a Tyco sales rep that can help. This may take some time. If you have information that might expedite this process, please help! ***
The picture from the above link sure LOOKS like the connector, but I can't find any of the specs listed, in particular "Product Specification 108-5402".
I would like to obtain say 10 each of the male and female 104-pin connectors, as pictured above, if they're still available. This will allow the creation of (1) simple extension cable; (2) various Y-cables for passive probe/monitor, selective hijacking of signals, etc.; (3) creation of devices: the A32-substitute (a car simulator used for unit- and regression-testing of the OSECM); the OSECM itself; other tools as necessary.
Here are some depictions. The square brace indicates male/female direction of connections. A '+' indicates a junction (splice, y-connect, etc.).
EDIT: Screwed up already. The ECM plug contains the "male" connector (104 little pins), and the car-side connector provides the "female" receptacle. I have tried to fix the picture below. Anyway, the picture is of little value so just take everything I say with a grain of salt. New meaning: "... -] ..." indicates that the thing on the left is male, etc...
Basic connection:
CAR --- [- -- ECM
Snooper-connection:
CAR --- [- ----+--- ECM
First things first. This project cannot proceed without cabled accessibility to the entire ECM interface. This means tapping into the entire 104-pin ECM connector, probably in various cabling configurations depending on the particular development task at hand.
Embarassingly, I cannot find the appropriate connectors. The closest I have come is: Tyco Electronics MULTILOCK Impulmate Connector:
http://www.tycoelectronics.com/catal...10372/628?RQS=
*** I am going to pursue finding a Tyco sales rep that can help. This may take some time. If you have information that might expedite this process, please help! ***
The picture from the above link sure LOOKS like the connector, but I can't find any of the specs listed, in particular "Product Specification 108-5402".
I would like to obtain say 10 each of the male and female 104-pin connectors, as pictured above, if they're still available. This will allow the creation of (1) simple extension cable; (2) various Y-cables for passive probe/monitor, selective hijacking of signals, etc.; (3) creation of devices: the A32-substitute (a car simulator used for unit- and regression-testing of the OSECM); the OSECM itself; other tools as necessary.
Here are some depictions. The square brace indicates male/female direction of connections. A '+' indicates a junction (splice, y-connect, etc.).
EDIT: Screwed up already. The ECM plug contains the "male" connector (104 little pins), and the car-side connector provides the "female" receptacle. I have tried to fix the picture below. Anyway, the picture is of little value so just take everything I say with a grain of salt. New meaning: "... -] ..." indicates that the thing on the left is male, etc...
Basic connection:
CAR --- [- -- ECM
Snooper-connection:
CAR --- [- ----+--- ECM
|
+--- Snoooper (passive)
Last edited by mikey66; 06-28-2010 at 09:07 AM.
06-28-2010, 08:43 AM
#51
Member
Thread Starter
Join Date: Jun 2010
Posts: 32
HARDWARE SELECTION
HARDWARE SELECTION
Proposal: Atmel AVR32/NGW100 plus Atmel ATmega168/Arduino(s) (???)
Prerequisite: Solve CABLING problem!
I see the project unfolding on various fronts as hinted at in the CABLING message.
(1) A passive monitor used to snoop all ECM IO signals and characterize their function. I'll call this the "snooper". OBDII, Consult, and oscilloscope probing provide a starting point for this probing, but I suspect that ultimately we'll need direct access via the Snooper for more refined characterization under more powerful software control.
(2) A simulation fixture that (a) facilitates unit-test and regression-test suites; and (b)simulates the actual car. This exercises the OSECM. I want to be fairly certain that the device seems functional before I think of plugging it into a real car.
(3) The OSECM itself.
The goal is to use off-the-shelf stuff (at least initially), so that we'd be wiring and programming but not doing a ton of complex hardware design. I think this is achievable.
I am partial to the atmel AVR32 family because I have experience with it. In particular, Atmel sells the "NGW100" demo board which provides a decent starting point for this project. The NGW100 costs about $80 (and I already have a couple), enjoys excellent active support from Atmel, and has an active user group (avrfreaks.net)... I could eliminate a huge learning curve if I used the NGW100.
This could be augmented by one or more ATmega328 processors for the analog I/O stuff. These are pretty cheap and simple. The "Arduino" is a nice little board that employs the ATmega328.
An issue might be communication between the NGW100 and the Arduino(s). Worst case this can be handled with a simple brute force bit bang protocol.
Both NGW100 and Arduino boards can run off 12VDC.
Proposal: Atmel AVR32/NGW100 plus Atmel ATmega168/Arduino(s) (???)
Prerequisite: Solve CABLING problem!
I see the project unfolding on various fronts as hinted at in the CABLING message.
(1) A passive monitor used to snoop all ECM IO signals and characterize their function. I'll call this the "snooper". OBDII, Consult, and oscilloscope probing provide a starting point for this probing, but I suspect that ultimately we'll need direct access via the Snooper for more refined characterization under more powerful software control.
(2) A simulation fixture that (a) facilitates unit-test and regression-test suites; and (b)simulates the actual car. This exercises the OSECM. I want to be fairly certain that the device seems functional before I think of plugging it into a real car.
(3) The OSECM itself.
The goal is to use off-the-shelf stuff (at least initially), so that we'd be wiring and programming but not doing a ton of complex hardware design. I think this is achievable.
I am partial to the atmel AVR32 family because I have experience with it. In particular, Atmel sells the "NGW100" demo board which provides a decent starting point for this project. The NGW100 costs about $80 (and I already have a couple), enjoys excellent active support from Atmel, and has an active user group (avrfreaks.net)... I could eliminate a huge learning curve if I used the NGW100.
This could be augmented by one or more ATmega328 processors for the analog I/O stuff. These are pretty cheap and simple. The "Arduino" is a nice little board that employs the ATmega328.
An issue might be communication between the NGW100 and the Arduino(s). Worst case this can be handled with a simple brute force bit bang protocol.
Both NGW100 and Arduino boards can run off 12VDC.
Last edited by mikey66; 06-28-2010 at 09:11 AM.
06-28-2010, 08:43 AM
#52
Member
Thread Starter
Join Date: Jun 2010
Posts: 32
SOFTWARE
SOFTWARE
Proposal: Various Methods - this is very much up in the air.
Prerequisites: Solve CABLING problem, then select HARDWARE.
It seems beneficial to leverage Linux/GNU tools for development and simulation and test fixtures. I believe this will greatly accelerate development.
For the OSECM, however, I have my doubts about Linux, even RTLinux, mainly because it seems that it'll take too long to boot (Startup + U-Boot + Linux). Although there are methods of dealing with this, they're a lot of work and I don't like them. I would be anxious to hear input on this because it's not my strong suit.
The processing power we are talking about is probably overkill by orders of magnitude, so I'm not particularly worried about performance once bootup is complete.
That said, I think the OSECM could alternatively easily be run as a big polling loop or a much lighter-weight RTOS. (Support for Consult and OBDII protocols is a wrinkle, but I think this can be dealt with later.) This has the advantage of speed and maybe more predicatable response characteristics. The disadvantage is huge: a less rich development environment.
This requires more thought...
Proposal: Various Methods - this is very much up in the air.
Prerequisites: Solve CABLING problem, then select HARDWARE.
It seems beneficial to leverage Linux/GNU tools for development and simulation and test fixtures. I believe this will greatly accelerate development.
For the OSECM, however, I have my doubts about Linux, even RTLinux, mainly because it seems that it'll take too long to boot (Startup + U-Boot + Linux). Although there are methods of dealing with this, they're a lot of work and I don't like them. I would be anxious to hear input on this because it's not my strong suit.
The processing power we are talking about is probably overkill by orders of magnitude, so I'm not particularly worried about performance once bootup is complete.
That said, I think the OSECM could alternatively easily be run as a big polling loop or a much lighter-weight RTOS. (Support for Consult and OBDII protocols is a wrinkle, but I think this can be dealt with later.) This has the advantage of speed and maybe more predicatable response characteristics. The disadvantage is huge: a less rich development environment.
This requires more thought...
06-28-2010, 09:04 AM
#54
Embarassingly, I cannot find the appropriate connectors. The closest I have come is: Tyco Electronics MULTILOCK Impulmate Connector:
http://www.tycoelectronics.com/catal...10372/628?RQS=
http://www.tycoelectronics.com/catal...10372/628?RQS=
06-28-2010, 10:16 AM
#56
Hey Mikey66, need some ECM's and Engine Wiring Harness'? I might be abled to Help harvest some... Honestly i think i can donate Two sets (ECU and Harness both) But i would very much expect to see results if im going to do this! Also it would be Very much appreciated to have shipping paid for me.. Im sure it wouldn't be more than the cost of a flat rate box at the most..
A forewarning though is they will be untested and all Auto's from various years.
A forewarning though is they will be untested and all Auto's from various years.
06-29-2010, 09:34 AM
#57
Member
Thread Starter
Join Date: Jun 2010
Posts: 32
Hey Mikey66, need some ECM's and Engine Wiring Harness'? I might be abled to Help harvest some... Honestly i think i can donate Two sets (ECU and Harness both) But i would very much expect to see results if im going to do this! Also it would be Very much appreciated to have shipping paid for me.. Im sure it wouldn't be more than the cost of a flat rate box at the most..
A forewarning though is they will be untested and all Auto's from various years.
A forewarning though is they will be untested and all Auto's from various years.
No problem with the shipping and other misc costs. PM me and we can settle that.
Before you take your valuable time, I want to provide some honesty to consider:
- I cannot guarantee results, as I have never attempted this before.
- This is a part-time endeavor, so the results may trickle in more slowly than you or I would like.
- Results could mean many things. Today I am about 50% certain (that number is trending upwards) that I can eventually achieve the holy grail: to hook up hardware and write software capable of controlling the engine. Short of that, see below for mention of other kinds of "results".
Having made my disclaimers, I will add:
- I am very interested and committed to the project, and I would like to see it succeed. I am not going to get bored and give up on the project after a couple weeks.
- I will try to post regular progress updates.
- I am about 90% sure that I can eventually hook up and write passive monitoring software that could yield interesting results, for example data traces that rival (or perhaps exceed) the capabilities of the Consult interface.
So please consider all this, and if you are still willing to take the time to throw together the stuff you mentioned, your efforts would be very very greatly appreciated.
Thanks.
- Mike
07-05-2010, 09:02 PM
#59
So, heres a quick update to help with the forum interest in the project.
Here is a response to a message i sent to a member of a different forum who happens to be working in the tuning scene and who is also quite the programmer.
To anyone who would like to make contact with Dave please PM me.
Mikey66 on the otherhand has also begun to make progress on this.
Take these responses as you will but at this time nothing (even to my knowledge) is official.
I am currently working to source a few ECM's and some Cut wiring harnesses for Mike and Dave to play with.
Like i said this is not an official update, merely to stimulate the interest in this project.
Ryan
Here is a response to a message i sent to a member of a different forum who happens to be working in the tuning scene and who is also quite the programmer.
Originally Posted by EEGeek
Sent: Thu Jul 01, 2010 11:04 pm
From: EEGeek (not of this forum)
To: FallenOne
Hey, I read your message and will read up on the link you provided when I get a bit of free time. I don't own a Maxima but my Father in law does and my dad owned quite a few while I was growing up; they were his favorite cars.
Ripping the contents out of an ECM is different in each case since each make/model is engineered differently and with different protections. Most of the work I've done with tuning and writing tuning software leveraged "piggyback" units that simply sit in between the sensors and the ECU and lie to the ECU in order to force it to change it's behavior. The guy I work with also ended up cracking the Mazdaspeed vehicles' ECU and we ended up flashing new programming to fix small specific problems we were having, but we left the tuning to the piggyback unit. This allowed us to tune "on the fly" without having to wait for an ecu flash to update behavior. You may have seen this in my videos where I was able to turn up or down the turbo boost simply by using the volume wheel of the AVIC.
In any case, shoot whatever questions you have my way and I'll try to answer them or ask my ECU cracking friend Lou for you. His day job is for an org I can't mention... He knows his stuff.
Dave
From: EEGeek (not of this forum)
To: FallenOne
Hey, I read your message and will read up on the link you provided when I get a bit of free time. I don't own a Maxima but my Father in law does and my dad owned quite a few while I was growing up; they were his favorite cars.
Ripping the contents out of an ECM is different in each case since each make/model is engineered differently and with different protections. Most of the work I've done with tuning and writing tuning software leveraged "piggyback" units that simply sit in between the sensors and the ECU and lie to the ECU in order to force it to change it's behavior. The guy I work with also ended up cracking the Mazdaspeed vehicles' ECU and we ended up flashing new programming to fix small specific problems we were having, but we left the tuning to the piggyback unit. This allowed us to tune "on the fly" without having to wait for an ecu flash to update behavior. You may have seen this in my videos where I was able to turn up or down the turbo boost simply by using the volume wheel of the AVIC.
In any case, shoot whatever questions you have my way and I'll try to answer them or ask my ECU cracking friend Lou for you. His day job is for an org I can't mention... He knows his stuff.
Dave
Mikey66 on the otherhand has also begun to make progress on this.
Originally Posted by Mikey66
Hi. Thanks for following up with this - you and EEGeek definitely seem like key resources.
(This project could *eventually* be of interest to tuners, etc. because of the improved control it could give them. The 4G-Max is *possibly* just the proof-of-concept starting point. But I don't want to get too far ahead of myself...)
I am currently reading the 1999-Max EC service manual in detail, have some stuff on order, and planning to order some other stuff soon. I'm looking to shell out some $$$ for a better multimeter and a decent oscilloscope -- got to do careful research to make sure the money's will spent.
I have started on a document to collect information in a useful way for myself and everyone else. I hope to have the start of something interesting by next week.
Anyway, thanks for the interest and assistance. It'll take a little while to get some equipment and build some test fixtures, but then hopefully things will start to heat up.
I'll be in touch.
Thanks,
Mike
(This project could *eventually* be of interest to tuners, etc. because of the improved control it could give them. The 4G-Max is *possibly* just the proof-of-concept starting point. But I don't want to get too far ahead of myself...)
I am currently reading the 1999-Max EC service manual in detail, have some stuff on order, and planning to order some other stuff soon. I'm looking to shell out some $$$ for a better multimeter and a decent oscilloscope -- got to do careful research to make sure the money's will spent.
I have started on a document to collect information in a useful way for myself and everyone else. I hope to have the start of something interesting by next week.
Anyway, thanks for the interest and assistance. It'll take a little while to get some equipment and build some test fixtures, but then hopefully things will start to heat up.
I'll be in touch.
Thanks,
Mike
I am currently working to source a few ECM's and some Cut wiring harnesses for Mike and Dave to play with.
Like i said this is not an official update, merely to stimulate the interest in this project.
Ryan
07-05-2010, 10:49 PM
#60
So, heres a quick update to help with the forum interest in the project.
Here is a response to a message i sent to a member of a different forum who happens to be working in the tuning scene and who is also quite the programmer.
To anyone who would like to make contact with Dave please PM me.
Mikey66 on the otherhand has also begun to make progress on this.
Take these responses as you will but at this time nothing (even to my knowledge) is official.
I am currently working to source a few ECM's and some Cut wiring harnesses for Mike and Dave to play with.
Like i said this is not an official update, merely to stimulate the interest in this project.
Ryan
Here is a response to a message i sent to a member of a different forum who happens to be working in the tuning scene and who is also quite the programmer.
To anyone who would like to make contact with Dave please PM me.
Mikey66 on the otherhand has also begun to make progress on this.
Take these responses as you will but at this time nothing (even to my knowledge) is official.
I am currently working to source a few ECM's and some Cut wiring harnesses for Mike and Dave to play with.
Like i said this is not an official update, merely to stimulate the interest in this project.
Ryan
Thanks.
07-06-2010, 12:15 PM
#63
SOFTWARE
Proposal: Various Methods - this is very much up in the air.
Prerequisites: Solve CABLING problem, then select HARDWARE.
It seems beneficial to leverage Linux/GNU tools for development and simulation and test fixtures. I believe this will greatly accelerate development.
For the OSECM, however, I have my doubts about Linux, even RTLinux, mainly because it seems that it'll take too long to boot (Startup + U-Boot + Linux). Although there are methods of dealing with this, they're a lot of work and I don't like them. I would be anxious to hear input on this because it's not my strong suit.
The processing power we are talking about is probably overkill by orders of magnitude, so I'm not particularly worried about performance once bootup is complete.
That said, I think the OSECM could alternatively easily be run as a big polling loop or a much lighter-weight RTOS. (Support for Consult and OBDII protocols is a wrinkle, but I think this can be dealt with later.) This has the advantage of speed and maybe more predicatable response characteristics. The disadvantage is huge: a less rich development environment.
This requires more thought...
Proposal: Various Methods - this is very much up in the air.
Prerequisites: Solve CABLING problem, then select HARDWARE.
It seems beneficial to leverage Linux/GNU tools for development and simulation and test fixtures. I believe this will greatly accelerate development.
For the OSECM, however, I have my doubts about Linux, even RTLinux, mainly because it seems that it'll take too long to boot (Startup + U-Boot + Linux). Although there are methods of dealing with this, they're a lot of work and I don't like them. I would be anxious to hear input on this because it's not my strong suit.
The processing power we are talking about is probably overkill by orders of magnitude, so I'm not particularly worried about performance once bootup is complete.
That said, I think the OSECM could alternatively easily be run as a big polling loop or a much lighter-weight RTOS. (Support for Consult and OBDII protocols is a wrinkle, but I think this can be dealt with later.) This has the advantage of speed and maybe more predicatable response characteristics. The disadvantage is huge: a less rich development environment.
This requires more thought...
07-06-2010, 02:47 PM
#64
From my understanding Real Time Linux doesn't 'boot' like most systems - it's 'active' and fully running as soon as it's got power - unlike many versions of Linux (and for that matter most OSs) it doesn't seek things pre-boot. It starts it's loop of check/response, ie low a/f ratio - would be 'check' and 'responded' to immediately at powerup.
For example lets say that currently your are in the "closed loop" state. So you are messuring AFR but all of a sudden you get a signal from the crank sensor that triggers an interrupt to energize coil pack 1. So you have to take care of this time sensitive task of firing the coil because it has higher prority. Once that is taken care of, you can go back to messuring the AFR
In these systems the program itself is the OS and it takes care of system initialization and other taskes like dignostics as well as running the engine. In a more complex system, an RTOS may be needed because there is too much going on at once and the state machine that you would need to program would be prohibitively complex. But in either case, the system response would be in near real time, enableing control ofsomething like an engine.
07-13-2010, 10:21 AM
#65
Member
Thread Starter
Join Date: Jun 2010
Posts: 32
Update 13-July-2010
Edit: Fix obnoxious font.
CABLING (104-Pin Connector)
This has required some lengthy investigation and is proving to be a real pain.
The mating 104-pin connectors are made by Tyco Electronics. The part numbers are:
178079-1 : Cap Assy 104P (PCB)
178081-6 : Plug Assy 104P (Wires)
In other words, 178081-6 is the piece that all the wires from the car plug into, and 178079-1 is the piece that gets soldered into a PCB. When the ECM is removed from the car, 178079-1 goes with it and 178081-6 stays behind with the car.
The connectors are associated with various other parts, also from Tyco Electronics:
177653-2 : Bolt
178073-1 : Wire Cover
175265-1 : 040 Rec (S)
175268-1 : 070 Rec (S)
The first two items are the bolt and the cover familiar to anyone who has pulled his ECM. The second two are the receptacles that get crimped to the individual wires and then plugged into 178081-6. There is a special crimping tool, although I suspect any general-purpose tool will do; and there is another special tool to remove an individial receptacles, although I suspect this can be managed with a small pick and careful lock-picking techniques. The “040” and “070” refer to the pin sizes: 040 is for the smaller-sized pins on the 104-pin connector, and 070 is for the larger ones. The “S” refers to wire gauge, and I believe S-size will suffice for all the wires in the G4 Maxima. The receptacles are designed to crimp to stranded wires, which is a slight pain as solid wires would be easier to deal with when attaching to a prototype breadboard or similar.
Tyco Electronics' support has been quite responsive and helpful. The problem at this point is that Tyco Electronics sold in 2006 to TTM Technologies their PCB business. This means that you cannot get from Tyco Electronics a PCB that accepts 178079-1. I have contacted TTM but received no reply yet. Tyco Electronics provides drawings for the connector dimensions, so worst case a few prototype PCBs can be fabricated using these as the basis. But that's a pain and time consuming.
The alternative that has been suggested, harvesting ECMs from dead Maximas, is looking like a strong alternative.
Bottom line is that the connector issues are not fully resolved and I'm reluctant to get too far ahead of myself in other areas until they are.
HARDWARE
I don't yet know what processor the G4 Maxima uses. However, Atmel is a big player in automotive applications, they make good stuff and have decent support, there are lots of useful hobbyist groups for their various products, and I'm familiar with some of their other product lines. So Atmel it is.
Atmel has a whole product line dedicated to automotive applications. However, I'm planning to use other offerings. The one hitch is the issue of communication bus to talk to other computers in the Maxima, scan tools, etc. I am punting on this because it requires a whole other line of research. I don't see any theoretical reason why this can't be dealt with later.
An Italian company called Arduino, and various Asian clones such as Seeeduino (yes, that is how it's spelled), makes hobby boards featuring various Atmel microcontrollers. I am probably going to choose the “Arduino Mega” (or a clone) as a development and prototype board. It's got plenty of analog and digital IO and the processor and memory should be overkill. For prototyping, I plan to use the Seeeduino Mega.
SOFTWARE
The U-Boot/Linux mess just takes too long to boot. Adapting a familiar distribution, such as Atmel AVR32, to strip unneeded stuff, turn on real-time hooks, and then test test test, would take too long, plus it's only soft-real-time. Taking it to the next level and doing hard-real-time Linux would be worse. Some guys (MontaVista) have a Linux platform that boots in 1 second, but they removed almost everything, hacked whatever was left, and the solution is processor- and application-specific. At this point all the advantages of Linux are lost. No thank you.
So Linux is out.
Anyway, I think it's much easier to just write the whole thing using standalone code (no OS). Again, the communications for bus, OBD2, etc. worry me, but I'm punting.
For prototyping, I plan to use Arduino's simple but effective Init() + Loop() C-style framework.
Edit: Fix obnoxious font.
CABLING (104-Pin Connector)
This has required some lengthy investigation and is proving to be a real pain.
The mating 104-pin connectors are made by Tyco Electronics. The part numbers are:
178079-1 : Cap Assy 104P (PCB)
178081-6 : Plug Assy 104P (Wires)
In other words, 178081-6 is the piece that all the wires from the car plug into, and 178079-1 is the piece that gets soldered into a PCB. When the ECM is removed from the car, 178079-1 goes with it and 178081-6 stays behind with the car.
The connectors are associated with various other parts, also from Tyco Electronics:
177653-2 : Bolt
178073-1 : Wire Cover
175265-1 : 040 Rec (S)
175268-1 : 070 Rec (S)
The first two items are the bolt and the cover familiar to anyone who has pulled his ECM. The second two are the receptacles that get crimped to the individual wires and then plugged into 178081-6. There is a special crimping tool, although I suspect any general-purpose tool will do; and there is another special tool to remove an individial receptacles, although I suspect this can be managed with a small pick and careful lock-picking techniques. The “040” and “070” refer to the pin sizes: 040 is for the smaller-sized pins on the 104-pin connector, and 070 is for the larger ones. The “S” refers to wire gauge, and I believe S-size will suffice for all the wires in the G4 Maxima. The receptacles are designed to crimp to stranded wires, which is a slight pain as solid wires would be easier to deal with when attaching to a prototype breadboard or similar.
Tyco Electronics' support has been quite responsive and helpful. The problem at this point is that Tyco Electronics sold in 2006 to TTM Technologies their PCB business. This means that you cannot get from Tyco Electronics a PCB that accepts 178079-1. I have contacted TTM but received no reply yet. Tyco Electronics provides drawings for the connector dimensions, so worst case a few prototype PCBs can be fabricated using these as the basis. But that's a pain and time consuming.
The alternative that has been suggested, harvesting ECMs from dead Maximas, is looking like a strong alternative.
Bottom line is that the connector issues are not fully resolved and I'm reluctant to get too far ahead of myself in other areas until they are.
HARDWARE
I don't yet know what processor the G4 Maxima uses. However, Atmel is a big player in automotive applications, they make good stuff and have decent support, there are lots of useful hobbyist groups for their various products, and I'm familiar with some of their other product lines. So Atmel it is.
Atmel has a whole product line dedicated to automotive applications. However, I'm planning to use other offerings. The one hitch is the issue of communication bus to talk to other computers in the Maxima, scan tools, etc. I am punting on this because it requires a whole other line of research. I don't see any theoretical reason why this can't be dealt with later.
An Italian company called Arduino, and various Asian clones such as Seeeduino (yes, that is how it's spelled), makes hobby boards featuring various Atmel microcontrollers. I am probably going to choose the “Arduino Mega” (or a clone) as a development and prototype board. It's got plenty of analog and digital IO and the processor and memory should be overkill. For prototyping, I plan to use the Seeeduino Mega.
SOFTWARE
The U-Boot/Linux mess just takes too long to boot. Adapting a familiar distribution, such as Atmel AVR32, to strip unneeded stuff, turn on real-time hooks, and then test test test, would take too long, plus it's only soft-real-time. Taking it to the next level and doing hard-real-time Linux would be worse. Some guys (MontaVista) have a Linux platform that boots in 1 second, but they removed almost everything, hacked whatever was left, and the solution is processor- and application-specific. At this point all the advantages of Linux are lost. No thank you.
So Linux is out.
Anyway, I think it's much easier to just write the whole thing using standalone code (no OS). Again, the communications for bus, OBD2, etc. worry me, but I'm punting.
For prototyping, I plan to use Arduino's simple but effective Init() + Loop() C-style framework.
Last edited by mikey66; 07-13-2010 at 11:43 AM.
07-13-2010, 12:27 PM
#66
Mike, today i finally got a chance to go harvest 2 ECU's and their matching Wiring harness'. Just as a precaution i popped the VIN plate out of the window for them both. But now that i think about it, they could easily be mixed up.. Doh!
Hopefully tomorrow i can go grab another 2-3 ECM's. But out of curiosity, would an I30 ECM be of any interest to you?
Uploaded with ImageShack.us
Uploaded with ImageShack.us
i Would like everyone to meet B7 and XC, the first two to hopefully start a long line of Modded ECU's to come.
Hopefully tomorrow i can go grab another 2-3 ECM's. But out of curiosity, would an I30 ECM be of any interest to you?
Uploaded with ImageShack.us
Uploaded with ImageShack.us
i Would like everyone to meet B7 and XC, the first two to hopefully start a long line of Modded ECU's to come.
Last edited by FallenOne; 07-13-2010 at 04:40 PM.
07-13-2010, 12:56 PM
#67
Member
Thread Starter
Join Date: Jun 2010
Posts: 32
Yes. The reason is that the differences would be interesting. Comparing ECMs is a good trick to expedite reverse engineering.
2: Linux guys, don't abandon the cause...
Also, I should mention that nothing in the update posted earlier today is set in stone. Also, when I say "Linux is out", that means out for the initial scoping, reverse engineering, and prototyping work. Later on, having a Linux host would be valuable. One possibility (I think likely) would be a multiprocessor setup where the ATMega (e.g. Arduino mega) slave processor is up and running almost instantly and starts doing the grunt work like pulsing injectors, reading crankshaft position sensors, etc. In parallel, a bigger master processor running full Linux would take it's time and boot up in say 30 seconds or so. The master could then do stuff like present data communication interfaces, poll status from the slave, make "smart" decisions about drive-loop diagnostics and lighting the check-engine light accordingly, talk OBD2 (and Consult), etc.
07-18-2010, 09:17 AM
#69
Curious why you decided to go with a platform like the Ardruino instead of a straight AVR32 chip and one of their dev boards(EVK1101), with AVR32 Studio as the IDE. I would think that with the Arduino, there would be a lot to get in the way in terms of thier IDE and such. I'm not super familar with them but I know they are targeted at beginers, and that usually means not as powerful. There is such great support for AVR products at avrfreaks.net. Its the maxima.org of avr microcontrollers.
07-20-2010, 07:49 AM
#70
Member
Thread Starter
Join Date: Jun 2010
Posts: 32
Curious why you decided to go with a platform like the Ardruino instead of a straight AVR32 chip and one of their dev boards(EVK1101), with AVR32 Studio as the IDE. I would think that with the Arduino, there would be a lot to get in the way in terms of thier IDE and such. I'm not super familar with them but I know they are targeted at beginers, and that usually means not as powerful. There is such great support for AVR products at avrfreaks.net. Its the maxima.org of avr microcontrollers.
08-03-2010, 12:00 PM
#71
I dont know if you have it/has been pointed out/or is needed but this might help:
http://www.plmsdevelopments.com/diy_consult.htm
http://www.plmsdevelopments.com/file..._registers.pdf
One other thing, what is it about linux being slow to boot ? how slow is slow to you ?. I just hope the hardware can handle extra options as i see that having the engine management is one thing, but when we get that, i bet there will
be so many other little cool things that ppl will like to add to it that a basic "up-and-running" platform will be short. If its a fast x86 based (mini-itx?) it keep alot of people happy
can you imagine having wifi, connecting from an iphone, to turn on the engine/radio/alarm ?!?!?! OMFG. "My car has an ip address on the internet". That sounds great too
Sorry i, i just dont know anything about embedded and such, i can do C and bash, kind of, it helps.
http://www.plmsdevelopments.com/diy_consult.htm
http://www.plmsdevelopments.com/file..._registers.pdf
One other thing, what is it about linux being slow to boot ? how slow is slow to you ?. I just hope the hardware can handle extra options as i see that having the engine management is one thing, but when we get that, i bet there will
be so many other little cool things that ppl will like to add to it that a basic "up-and-running" platform will be short. If its a fast x86 based (mini-itx?) it keep alot of people happy
can you imagine having wifi, connecting from an iphone, to turn on the engine/radio/alarm ?!?!?! OMFG. "My car has an ip address on the internet". That sounds great too Sorry i, i just dont know anything about embedded and such, i can do C and bash, kind of, it helps.
Last edited by BlackMamba; 08-03-2010 at 12:04 PM.
08-03-2010, 12:04 PM
#72
![[s3]'s Avatar](data:image/svg+xml;utf8,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 50 50'><circle class='avatar-circle-default' fill='%23986ec4' cx='25px' cy='25px' r='20px'></circle><text class='avatar-text-default' x='49%' y='53%' fill='white' text-anchor='middle' alignment-baseline='middle'>[</text></svg>)
I dont know if you have it/has been pointed out/or is needed but this might help:
http://www.plmsdevelopments.com/diy_consult.htm
http://www.plmsdevelopments.com/file..._registers.pdf
One other thing, what is it about linux being slow to boot ? how slow is slow to you ?. I just hope the hardware can handle extra options as i see that having
the engine management is one thing, but when we get that, i bet there will
be so many other little cool things that ppl will add to it that a basic "up-and-running" platform will get short. If its a fast x86 based (mini-itx?) it keep alot
of people happy
Sorry i, i just dont know anything about embedded and such, i can do C and bash, kind of, it helps.
http://www.plmsdevelopments.com/diy_consult.htm
http://www.plmsdevelopments.com/file..._registers.pdf
One other thing, what is it about linux being slow to boot ? how slow is slow to you ?. I just hope the hardware can handle extra options as i see that having
the engine management is one thing, but when we get that, i bet there will
be so many other little cool things that ppl will add to it that a basic "up-and-running" platform will get short. If its a fast x86 based (mini-itx?) it keep alot
of people happy
Sorry i, i just dont know anything about embedded and such, i can do C and bash, kind of, it helps.
That is very helpful info, but probably not in this instance. Because consult interfaces have already been done by many many groups/people. (Conzult, Nistune, BikiROM etc)
We are looking at total replacement of the stock ECU from the ground up, with a tuning feature built in, amongst other nifty features.
I predict a prototype in 3 months or so.
Thread
Thread Starter
Forum
Replies
Last Post
Forge277
1st & 2nd Generation Maxima (1981-1984 and 1985-1988)
12
06-13-2016 09:26 PM