Technical 6F/16F Cinque/Sei ECU Reader Project

Currently reading:
Technical 6F/16F Cinque/Sei ECU Reader Project

Joined
Mar 30, 2005
Messages
247
Points
134
Location
Caithness
arseofbox said:
Im working (not very hard) on a project to make a piece of software to read the contents of the 6F/ 16F (Cinq/ Sei) ECU...Ive just converted a fooking massive Italian document to find out how to interface the bugger

Any good with C++?

Jamieboy said:
Actually yes! Just finished my undergrad Hons. Degree in AI & Robotics - one of the main cores of which was software design in C++/builder. Also electronics design and manufacture - it's my comms knowledge that is poor :(

This would be my main worry - Fiat may use a proprietry beasty that would make it tough to speak to the ECU.

How sweet would a PC resident or hand-held, PIC based fault-code reader be?! If on the PC you could have a nice GUI, or an LCD if PIC based....

Maybe a collaborative project is possible with ourselves and other members?

Should we start a new thread on this?

Cheers,

Jamie


arseofbox said:
EXCELLENT!!! Just the Guy I need...:D

Fiat do use a proprietary reader / scanner, called the FLT. But thats no problem, as the document I have gives full details on how to communicate to it / interface and pull data out.

I think PIC's might be a bit hard, cos I was looking at getting a live data feed, and updating that every 500-600 msec.

Ive found a circuit to talk to it from the serial port...Its just a TTL level converter I think, and I also have a vague bit of pseudo code as I just brain-dumped the lot to paper one afternoon.

I have the file on my other computer...so I'll send it to you once I get back to that 'box...and that'll be monday / tuesday

arc said:
oooo, im liking the sounds of this :D

have a good read of the thread on the coupe forum Jamie

project-cinqy said:
so could this software be used from a laptop? and could it datalog? save a fortune in dyno testing if it can? Rpm curves would make shift light setting up a doddle!!

Jon.


Ok, here is a shiney nice new thread for this :)
 
project-cinqy said:
so could this software be used from a laptop? and could it datalog? save a fortune in dyno testing if it can? Rpm curves would make shift light setting up a doddle!!

Jon.

Hi Jon,

Depending on how willing the ECU is to divulge data, and how much of a pig it is to read we are looking at a few possibilities (in ascending order of complexity):

1. Fault code only - (I'd settle for this!) it would give us a code which we could presumably then translate into the source of the problem. This is the least resource intensive in terms of hardware, software or microcontroller or CPU speed.

2. Snapshot of engine parameters. If accessible, this would allow the registers which store the various sensor values to be read. These values would/could be updated fairly frequently.

3. Full, real-time data out. I suppose this is the 'Holy Grail' - if the ECU has this capability, this would allow a (hopefully low-lag) mirror of what the ECU is seeing and doing. Goes without saying the most resource-intensive hardware/software, not to mention any signal processsing *shudder.

These are of course speculative, if anyone knows what data-out capabilities, services or facilities these ECUs provide - post!

So to get back to your question, if we are looking at anything above option 1 (which I don't think necessitates a PC to do) - yeah, in theory, the software could be made to data-log, save peak values, show performance stats, and much more. It just depends on what you wanna do with the data out (and how long you wanna spend looking for missing semi-colons....)

My mate had a turbo'd Brookie Capri, which the previous owner designed and built a home-brew boost controller for, which took sensor readings and did all sorts of clever things! Incidentally - if anyone knows who now owns this car (Reggy started E666 *** ) Can't remember the rest (LOL - Capri of the devil!). I think my mate regrets selling it somewhat....

Anyway, so yeah, it all hinges on what is accessible through the data port.

Cheers, Jamie
 
Its very easy to get the ECU to spit out data.. All you have to is initialise communications, switch to an obscure baud rate then tell it what you want to see, it'll then spit the data out at you within a short time period (300msec timeout i think for parameters).

To read fault codes....well thats the seemingly easiest part. The ECU has 6 different error memories (3 RAM, 3 EEPROM) that it writes to dependant on the state of the error (eg: transient / permanent). What I want to do is be able to poll all of these memories independently (each bit of each memory corresponds to a different error) - as Ive had problems with transient errors not appearing when Ive gone for ECU Diag scans, and so the reader hasnt picked it up - but it would have been in the E2PROM memory, but their reader must only scan the RAM (blanked at each start-up and only written to when errors present).

Engine Parameters.....Theres a riduiculous amount of data that can be had out of it...the 16F ECU doc will detail all. Its all in the form of Hexadecimal numbers and all it needs in terms of formatting is feeding into equations (theyre given in the Tech Doc).

In terms of S/W structure, I was thinking integrate it into a series of self-contained modules to limit the amount of data recieved / sent so the CPU isnt over worked (my target system is a PII 300)
 
Heres the the document that Tom translated for those who want it.
 

Attachments

  • 16F Technical Information.pdf
    388.5 KB · Views: 6,859
Oldschool said:
This is what real tuning is about.
Who said tuning was involved?
I just want to be able to get ECU data and find error codes. Admittedly, the Data may well be used to tune the engine (via remapping), but theres no way it can be tuned directly through a computer, as its not OBD-II Compliant.

Once we have some way of getting the data for analysis purposes the fun can start.
 
Actually that is what you have to do! It is not me who invented ECUs. It does not matter whether you can do a real time tuning or not. If you want to get the best out of it or even want to go save you have to do it. Or why do you think that new cars on average require about 12000 man hours to programm an ECU that it can be considered safe for daily usage? I am not talking out of my backside. I have seen it too often.
And don't worry I have no time to show off. Believe me it did hurt when reality struck me at many a times.
 
Oldschool said:
Actually that is what you have to do! It is not me who invented ECUs. It does not matter whether you can do a real time tuning or not. If you want to get the best out of it or even want to go save you have to do it. Or why do you think that new cars on average require about 12000 man hours to programm an ECU that it can be considered safe for daily usage? I am not talking out of my backside. I have seen it too often.
And don't worry I have no time to show off. Believe me it did hurt when reality struck me at many a times.

I'm quite sure that you're right the rational approach says that its too difficult, but as I found out in developing my chip. The challenge and satisfaction in doing it is part of the reward, and everyone benefits as a result. Thats why people can buy a good remap for £40 rather than £200. Why discourage people from having a go at developing something new. You never know they may find a better way and everyone benefits.

All the best to the project, If I can help I will!!!

Regards,
Michael
 
Oldschool said:
Actually that is what you have to do! It is not me who invented ECUs. It does not matter whether you can do a real time tuning or not. If you want to get the best out of it or even want to go save you have to do it. Or why do you think that new cars on average require about 12000 man hours to programm an ECU that it can be considered safe for daily usage? I am not talking out of my backside. I have seen it too often.
And don't worry I have no time to show off. Believe me it did hurt when reality struck me at many a times.

Erm...am I the only person here who cant even remotely understand how ECU tuning has anything to do with our goals? We only want data out!. O-U-T Spells OUT!! Opposite of IN!!! :D :p

Thanks for your support Mick, I was hoping that the final product could help develop better chips by being able to collect car specific data :)
 
arseofbox said:
Thanks for your support Mick, I was hoping that the final product could help develop better chips by being able to collect car specific data :)

I looked on the coup site and saw the diagrams for the interface kit. Not sure if any would work with the 16F ECU. but if you can find a suitable schematic my mate that helped with the chip can almost certainly make up the interfaces,
Regards,
Mick
 
mckcrich said:
I looked on the coup site and saw the diagrams for the interface kit. Not sure if any would work with the 16F ECU. but if you can find a suitable schematic my mate that helped with the chip can almost certainly make up the interfaces,
Regards,
Mick

Excellent. All that circuit is is an optoisolated RS232 to TTL level converter, it just changes serial levels to 0-+5vDC, why wouldnt that work?
 
Did this thread fizzle out? My '99 Punto also uses the 16F ECU and I am interested in linking it to a laptop. I couldn't determine yet whether it is ISO/OBD compliant so DIY projects 'out there' might not be suitable. One clue is the three pin connector near the ECU rather than the current standard "J whatever" plug under the dash.

The stuff 'out there' that I have been considering includes:

1. Any circuit based on the ELM323 chip (ISO OBD to RS232 converter) used with the free Scantool software (Opendiag project).

2. The VAG-COM setup which uses a fairly simple hardware design from Jeff Noxon and VAG-COM software from Ross Tech (free older version for simple hardware with opto-isolators). Designed primarily for Volkswagon/Audi but probably OK for anything that is OBD2 compliant (may suit Mk2 Punto).

3. Vehicle Explorer software for OBD2. Don't know what hardware this is designed to work with. Think it is for a proprietary unit but you will have gathered that I don't want to spend much.

The functionality of software varies from basic interpretation of hex codes spat out by ECU on demand to full blown user-chooser gauges and meters for dynamic imformation, accompanied by data-logging. Not surprisingly, the best stuff isn't free!

Anyway, back to my original point, is anyone still working on this project?

Meanwhile I'll start to digest the mass of information in the 16F technical file that arseofbox has kindly translated (I surmise that was no mean feat, so thank you!).

Cheers,

Red.
 
Yes the thread has appeared to have died a death.

The ECU is not ALDL\OBD\OBD2 etc. compliant, and can only be accessed using the protocol it is setup for - that being one specifically developed by Magneti Marelli and all data for it is proprietry to them.

The full interfacing protocol is in that document. The FCCUK (Coupé Club) did something similar to what Im proposing (writing software specifically for ECU interrogation)...as the K/L Line software and hardware is very costly and hard to find!

My work on it has slowed to a crawl due to my lack of programming experience (uC, console C and some VB/VB Script).

The interface circuit needs optoisolation between car and computer as a basic prerequisite, and must act purely as a TTL to RS232 level converter. ECU expects TTL levels and the computer gives out RS232...
 
Can anybody tell me the starting address on the eprom chip of an Spi Sei, of the fuel and ignition maps? I'd be grateful...
 
I am attempting to build an ECU fault code reader of the Magneti Marelli 16F.ER in my GF '97 cinquecento sporting. I have read the (italian) document describing the communication protocol and built and programmed a microcontroller based interface to initiate communication, switch from 1200 baud to 7812.5 baud and read the codes from RAM and EEPROM.

The reader side of things is ready to go, but I am having difficulties getting details on the electrical specification of the diagnostic interface.

I know pin 1 is the L line, 2 is GND and 3 is the K line. I have read the voltage across K and GND as around 10.9 volts when the ignition is switched on, but whenever I try to connect it to any kind of circuit, i.e. transistor / led arrangement the voltage drops to almost nothing. At least too low to saturate (turn on) the transistor.

Is the K line an open collector / open drain output, i.e. does it need to have pull up resistors attached?

Some diagnostic protocols work at battery voltage (12V) though someone on this forum said that the ECU expects/ produces TTL (5V) signals.

If anyone has any details on the electrical details of this interface I would like to hear from you.

If you have any details or schematics of a working DIY fiat/lancia interface that would be brilliant.

I have the most complex part finished (the reader) already, I just want to know how to connect it to the ECU (in a physical sense).

I am willing to share any information and my designs / code with anyone else out there who is trying to do something similar.
 
Back
Top