Wildguzzi.com
General Category => General Discussion => Topic started by: Meinolf on December 14, 2017, 10:54:29 AM
-
Hi,
some might remember that I built a test board to create an virtual engine with a 15M and 15RC ECU http://wildguzzi.com/forum/index.php?topic=67653.0;nowap. Some months ago a Aprilia Mana came into my possession, which uses the 5AM ECU. And shortly afterwards a Guzzi Norge, also using the 5AM. So I decided to built a 2nd ECU simulator for the 5AM and make it versatile enough to run both Aprilia and Mana BINs plus the assorted accessories like dashboard and TCU.
The first step was to arrange the wire loom incl. handle bar switches and ignition switch from a Mana and the 5AM ECU on a board.
(http://thumb.ibb.co/mJBVc6/5_AM_Sim_V0_01.jpg) (http://ibb.co/mJBVc6)
An operator panel was manufactured, containing potis to simulate TPS, engine and intake air temperature, ambient air temperature, air pressure and fuel level. Switches for neutral, side stand, brake, fall sensor, clutch and oil pressure as well as assorted LEDs were added.
(http://thumb.ibb.co/fPCiVR/Altes_Panel.jpg) (http://ibb.co/fPCiVR)
A 1200 Sport dashboard, supposedly defect, came my way and found its place.
(http://thumb.ibb.co/gp3OVR/5_AM_Sim_V0_02a.jpg) (http://ibb.co/gp3OVR)
Then a Stelvio display plus paired key found its way into the laboratory. After some trials a signal generator connected to the wiring loom provided the speed signal. As the pin out of the Aprilia loom to the dashboard and the ECU are different, even the different Guzzi models have slightly other pin outs, a bread board and 40 cables are used to patch as needed.
(http://thumb.ibb.co/ezGMH6/Stelvio_Display.jpg) (http://ibb.co/ezGMH6)
The first attempt to simulate the narrow band probe signal worked, but not reliabely. The ECU expects a signal between 0.3-1.1V at a frequency of 1-3Hz. A steady signal provokes an error.
(http://thumb.ibb.co/kYGhPm/Sprungsonde.jpg) (http://ibb.co/kYGhPm)
So the signal generator was used to provide the required signal. Eventually a Arduino will be used to provide a PWM signal.
(http://thumb.ibb.co/mGjNqR/Signalgenerator_L_Sonde.jpg) (http://ibb.co/mGjNqR)
The operator panel was redesigned and 2 staggered potis each for engine and intake air temperature now provide sufficiently high enough resolution to adjust the temperatures.
(http://thumb.ibb.co/kFPSPm/Panel.jpg) (http://ibb.co/kFPSPm)
More or less finished, but it's certainly work in progress. In addition to the software suite (GuzziDiag, BinWriter/Reader, EEPROMWriter/Reader) from Beard a 4ch DSO will help to track signals.
(http://thumb.ibb.co/bWGrjm/small.jpg) (http://ibb.co/bWGrjm)
The virtual engines now runs with all Guzzi BINs, first findings as to the EEPROM content are already being processed. Operation of the dashboard via the handle bar switches from the Aprilia also work.
Unfortunately the Aprilia BIN doesn't yet allow running the virtual engine. This might be due to the TCU (Transmission control unit) not being present, the missing Aprilia dashboard plus paired key or other cut outs (the Mana is an automatic, no gears or clutch) which I haven't found yet.
While already merrily measuring away some further steps are planned.
The barometric sensor is inside the dashboard and the data is send to the ECU on the CAN bus. So, three pins of the sensor will be de-soldered and the points on the PCB will be connected with cables to the poti.
The dashboard also contains a (smaller) ECU and 24C16 EEPROM. While I have no idea how to connect to the dashboard ECU (there never were any updates published by Guzzi AFAIK), the EEPROM is more accessible. Cables will be soldered to the 24C16 and reading and writing is planned to be done using the Arduiono as well. Contents of the 24C16 include mileage, ID of the paired keys and other interesting stuff.
Beard and PaulDaytona are very supportive, Beard and I had a pyjama party in front of the testboard some weeks ago during a rainy weekend.
If any of you should know of a used (only electric needs to work, the mechanical condition doesn't matter) TCU and a dashboard (condition same as TCU) plus paired key from a Mana, preferably in Europe and at a cost suited to the hobby budget available, please contact me.
Cheers
Meinolf
-
Very impressive :bow:
Now can you dumb it down a bit for us regular folks :laugh:
Dusty
-
Awesome work ! I know next to nothing about electronics but find this fascinating. What is your original intent behind developing such a devise? Thanks for sharing your creation. :thumb:
-
Very impressive :bow:
Now can you dumb it down a bit for us regular folks :laugh:
Dusty
Uhh, Dusty.. I think he already has.. :grin: :boozing:
-
Hi,
indeed, this was supposed to be the executive summary of the project. So dumbing it down might be difficult.
The basic idea, same as previously with the 15M/RC project,
(http://thumb.ibb.co/gg5HPm/ECU_Simulator_MK_VII.jpg) (http://ibb.co/gg5HPm)
is to reverse engineer the program code in the ECU, find the relevant maps and scalars and then use it to optimize the BIN. More or less a blue-printing approach.
Alas, my skills and knowledge in regards to electronics or software are at -10.000 feet, my education is civil engineering and work as marketeer/sales/mgt. in the IT biz. So this was and is a dumb persons approach, relying mostly on tenaciousness and the liberal support from Beard, Paul and others.
The testbed approach worked quite well, at least initially, with the 15M/RC. However, due to the large number of unknowns I eventually had to dive into the dissassembled code of the ECU program and use both the testbed and the code explorations. The 15M/RC use a 68HC11 CPU, the assembly language is well documented and I could understand some of it. Like, 0.1% or so.
The 5AM uses a different CPU (and interfaces with the 2nd ECU in the dashboard), and more important, the code was written in a high-level programming language and compiled with highly optimizing compilers. Which, in laymens terms, means that the challenge to reverse engineer the code get much more difficult. I do have the dissassembled code of the Mana and Guzzi BINs, but it's not the same assembly language used in the 15M/RC. So, a new language and unknown grammar. Difficult - for me. If there are skilled programmers around willing to invest some time in this project, stand up and be counted.
The eventual result of the work with the 15M/RC was that I could correct some bugs in the code and create BINs, having maps and scalars suited to my V11 and Jackal, which provide more power/torque, run more smoothly and consume less fuel. I distributed these BINs liberally, some are being used in the US as well. My V11 and Jackal are permanently equipped with data loggers from Innovate and Zeitronix. AFR for both cylinders, TPS, rpm, engine temp/air temp, voltage and MAP are logged during each drive, the resulting data is analyzed and used in further optimization of the BINs.
Cheers
Meinolf
-
this looks like great stuff, keep on keepin on!
:thumb: :thumb:
Meinholf's BIN's ran great in my Calvin and his generous help gratefully appreciated.
That said, I've since de-up-graded to carbs, but those virtual operating panels are truly amazing endeavours.
-
I've been keeping my eyes open for a wrecked Mana to get a TCU from but so far no joy. One of the problems is they are pretty rare.
-
Will you requires a simulated rider for a simulated ride?
QUOTE: " My V11 and Jackal are permanently equipped with data loggers "
Very, very cool.
-
Have you tried de-compiling with Avast RetDec? Platform independent an de-compiles to C or Python source. It has just been made into an open source project. I'm not sure of what type of processor you are using, so I can't be sure of whether it is supported.
https://retdec.com/decompilation/ (https://retdec.com/decompilation/)
I wish I could help you out, but I'm no expert in this. I can certain write C code though so give me a shout if you need help. The last time I needed to de-compile was about 15 years ago, and that was sucked out as assembly code which I was fairly good at back then. Keep us informed and I'll chip in where I can.
Dave
-
Hi Dave,
thanks for the link and the offer to help with the Firmware. The 15M/RC uses 68HC11 and the 5AM a ST10F269. Neither are supported by Avast.
Anyway, the dissassembled code is available. The task is to understand the assembly code, as it does not contain any comments as one would find in the original source code.
If you are willing to take a look, I'll be happy to send you the code.
Cheers
Meinolf
-
Hi,
in the meantime an Arduino board was added to the setup. It's currently used for two purposes. The first is to provide an adjustable speed signal to the ECU and thereby the dashboard, as well as providing 2 signals simulating the input from the Lambda probes. Beard invested plenty of time and brain smarts in writing and debugging the Arduino sketch. That guy really is a genius, it's unbelievable how freely he supports. Support him!
(http://thumb.ibb.co/mmXG5R/Arduino.jpg) (http://ibb.co/mmXG5R)
The second is to access the EEPROM on the dashboard. Cables were soldered to the SDA/SCA pins of the EEPROM, the RST pins from the ECU and the Vout of the barometric pressure sensors, so that the barometric pressure can also be changed via a poti on the operator panel.
(http://thumb.ibb.co/irB15R/1200_Dashboard_Kabel.jpg) (http://ibb.co/irB15R)
(http://thumb.ibb.co/f5MR5R/1200_Dashboard.jpg) (http://ibb.co/f5MR5R)
Cheers
Meinolf
-
Top Work Meinolf :bow: :bow:
Can you explain why you decided on this route rather than going via a Microsquirt (or similar) after market ECU?
-
Remember back when...feeler gauge, timing lights, maybe a dwell meter if ya had one?
Back When.......Thanks Tim
(http://thumb.ibb.co/fj6Mpm/t.jpg) (http://ibb.co/fj6Mpm)
https://www.youtube.com/watch?v=9PgfQpJFYp8
-
Hi,
Can you explain why you decided on this route rather than going via a Microsquirt (or similar) after market ECU?
because almost everybody is using the OEM ECUs and the knowledge gained can be shared and used. I did look into MyECU, but the 15M was already there.
Cheers
Meinolf
-
Hi,
because almost everybody is using the OEM ECUs and the knowledge gained can be shared and used. I did look into MyECU, but the 15M was already there.
Cheers
Meinolf
Aha - that makes sense!
I've been thinking about the Microsquirt as my B11 suffers from the "poorly dash syndrome" and given that the immobiliser is in the dash it seemed like a way to escape the problem should the dash die completely
Still, maybe your Herculean efforts will find where the immobiliser code hides in the ECU and give us the means to duck around it rather than go the aftermarket ECU route
Keep up the good work
Tris
-
Hi,
the dash EEPROM is accessible. Reading and writing works, now beginning to decipher the content.
User code change works, but plenty of Bytes left.
(http://thumb.ibb.co/gKr6pm/Dashboard_EEPROM_ausgelesen.jpg) (http://ibb.co/gKr6pm)
(http://thumb.ibb.co/fsVVZm/CH341_Dashboard.jpg) (http://ibb.co/fsVVZm)
Cheers
Meinolf
-
A worthy endeavor, Meinholf. As a 15M user, I appreciate your efforts...
-
Hi,
A worthy endeavor, Meinholf. As a 15M user, I appreciate your efforts...
worthy or not, thanks for the kind words. Actually, I am already planning to apply the learnings gained during the construction of the 5AM ECU simulator and upgrade the 15M/15RC simulator.
Cheers
Meinolf
-
Hi,
after getting acquainted with the dashboard and the operation Beard and I pooled our insights. So here's the current status. The green'ed cells are the ones where I believe that they are completely known. Beard is already preparing a XDF.
(http://thumb.ibb.co/ncDLjm/1200_Dashboard_EEPROM_Werte.jpg) (http://ibb.co/ncDLjm)
The 1200 dashboard is currently being operated as stand-alone unit, e.g. not connected to the wire loom and ECU. Once connected to the ECU I need a paired key, which I don't have, to start and run the virtual engine.
So, I either need a dashboard (in a state where soldering cables to the EEPROM doesn't matter) with a paired key or insights in how to extract the transponder value from a key. Once this is available I can apply a speed signal and identify total mileage, trip mileages, lap times, maybe speedo correction factor, etc.
Anybody here with a workable approach on how to extract the key transponder value?
Cheers
Meinolf
-
I may be able to help with a dashboard with key. Does it matter what model?
-
Hi Pete,
thanks for the offer. No, I guess any dashboard (Stelvio, Norge, Griso, Breva, 1200 Sport) will serve the purpose.
You do understand that, if it's not already taken apart, I would have do so and to solder cables to the PCB?
Cheers
Meinolf
-
Hi,
more entries identified.
(http://thumb.ibb.co/dxpi4m/1200_Dashboard_EEPROM_Werte_II.jpg) (http://ibb.co/dxpi4m)
Those identified cover most of the settings selectable via the dashboard. But plenty of Bytes are written in the higher address range and not reflected in any dashboard setting. So, the quest continues.
Time, time format (12/24) and Display brightness are not written to the EEPROM. The assumption is that the respective values are kept by the RTC (inside CPU?) and LCD controller.
Cheers
Meinolf
-
Yup, but sometimes learning stuff costs.
All the electronics, even mapping with known ECU's is NOT my area of expertise so I have to rely on the help with this from the likes of Bernt, yourself, Paul and Mark. I'm more than happy to contribute in any way I can. If it requires the sacrificing of a dashboard? Meh? That's what it costs!
Tomorrow I'll see what we have hanging about. I know I have a complete lock set and dash with two keys of a Griso but I'm also pretty sure I have a Stelvio dash with a single matching key. I'll have to have a dig through the mountain of munt but over the Christmas period Michael and I will be re-locating a lot of our 'Stock' to locations away from the workshop in a pathetic attempt on my part to get more organised! :D
Pete
-
Hi Pete,
that's a splendid attitude :thumb: :bow:
A dashboard with a single key will be enough to connect it to the loom and ECU and start the virtual engine.
I'll at least cover the shipping costs. Which, btw, are very reasonable. One of my daughters currently is is Australia and needed a new digicam. DHL cost was 3,90€.
Cheers
Meinolf
-
Hi Dave,
thanks for the link and the offer to help with the Firmware. The 15M/RC uses 68HC11 and the 5AM a ST10F269. Neither are supported by Avast.
Anyway, the dissassembled code is available. The task is to understand the assembly code, as it does not contain any comments as one would find in the original source code.
If you are willing to take a look, I'll be happy to send you the code.
Cheers
Meinolf
Hi Meinolf,
no worries, send it to me and I'll have a look. I can't promise much though, life is pretty busy at the moment, and its been a long time since I did this so I'm pretty rusty. Have you done any work on it already? If so, send that too, the more info the better. Thinking about it, we do have a steady stream of undergraduate/newly graduated engineers going though our place all the time. Maybe I could get one or two of those on the case.
Thanks
Dave
-
Hi Pete,
STOP - don't send anything yet. Beard came up with a nice approach, which might work with what I already have at my disposal.
Delete the transponder keys in the EEPROM and the pair 2 keys. I have one working key paired with the Stelvio display and the keys from my Norge. I'll connect the dash to the loom/ECU and try this first.
Cheers
Meinolf
-
Hi Dave,
no worries, send it to me and I'll have a look
great, together we are strong :-)
I got your PM, files will be send later today.
Cheers
Meinolf
-
Hi Pete,
after more tests yesterday evening with the dashboard connected to the loom and ECU it finally died (I received it as defective in the first place). I could confirm the addresses for the mileage, 4 identical words beginning at $10 and $20 and the first run indicates that no checksum is written to $05/$25. So here's the current view:
(http://thumb.ibb.co/krcKUm/Dashboard_EEPROM_after_connect_to_ECU.jpg) (http://ibb.co/krcKUm)
It also seems that the spurious data appearing in the higher address space only appears when the dashboard is not communicating with the ECU. Once connected it was FF everywhere, the only exception being a single word.
Pete, your offer to sponsor a dashboard is relevant again. As written above no key is needed.
Cheers
Meinolf
-
Hi,
Will you requires a simulated rider for a simulated ride?
(http://thumb.ibb.co/cfDYCG/Virtual_rider.jpg) (http://ibb.co/cfDYCG)
so sorry, after reviewing the applications I selected a suitable driver, suggested and sponsored by one of my daughters.
Cheers
Meinolf
-
Hi,
the EEPROM is now mostly understood and documented. We could also determine the checksum calculation algorithm, it covers the contents of the block from $10-$18.
(http://thumb.ibb.co/ijcJCG/Stelvio_EEPROM_values.jpg) (http://ibb.co/ijcJCG)
The operator panel was upgraded again to cope with the changed requirements. The Lambda signal amplitude, a 5V PWM signal generated by the Arduino, can now be adjusted with a poti to influence the Lambda 1/2 voltage and Lambda 1/2 integrator values. The cables connecting the EEPROM programmer to the Dashboard EEPROM can now be quickly disconnected to avoid signal interference in the communication stream between CPU and EEPROM. And Up/Down/Set buttons were added as well for more convenient usage.
(http://thumb.ibb.co/ex2zmb/Panel_III_beschriftet.jpg) (http://ibb.co/ex2zmb)
Some research was done about the pinouts of the dashboards. All service manuals and wiring diagrams were reviewed and a table was created listing each pinout by model and dashboard. That simplifies connecting the dashboard(s) to the Aprilia cable loom and helps avoiding misconnections potentially endangering the electronics.
An attempt was made to collect the different dashboard firmware versions. The current status is:
Small dashboards (Griso/Stelvio/..)
MGST0003 und
MGST0004
APMG 0022 (Griso12008V)
Big dashboards (Norge/1200Sport/...)
APSN0002 (Norge 2V, Breva1100)
APSB0010 (Breva1100)
APSB0014 (Breva1100)
APSB0015 (Breva1100)
APSB00016 (1200Sport/Breva1200)
If you can add more here, it'd be appreciated. Bellagio, Norge1200GT and Griso1100 are still missing.
Cheers
Meinolf
-
Hi,
the quest continues.
A solid footing helps determining cause and effect, so a stepper motor was added to the board. Which resolves the idle system error message.
(http://thumb.ibb.co/hnne6b/Steppermotor.jpg) (http://ibb.co/hnne6b)
The last tests were made with a Stelvio 1200 8V BIN, which resulted in finding another bit change in 0x15 when the ATC setting is changed.
Cheers
Meinolf
-
Hi,
somehow I do tend to get sidetracked. So sad....
Anyway, a signal analyzer (8ch, 24MHz, Saleae clone HW - Sigrok SW) was added to the measuring equipment and a first look at what is happening on the CAN bus, which is the means of communication between the ECU, the dashboard and the ABS subsystem, was taken.
(http://thumb.ibb.co/bQXZcR/CAN_Bus.jpg) (http://ibb.co/bQXZcR)
Having no previous knowledge about the CAN bus I'm still very much in the early look and see phase. Identifying IDs, understanding the data inside the packets send back and forth and finding a use for it is the target. Logging data on the CAN bus results in enormous amounts of data, currently I'm looking for a tool to analyze the collected data, It can be done with Excel or the like, but handling data exceeding 1mio data sets slows down things a lot.
Cheers
Meinolf
-
Nice.. since a friend told me about can bus problems with his Beemer several years ago, (he was a BMW mechanic) I decided I didn't want a bike with one. :smiley: Maybe you'll eventually change my mind.
-
I am certainly happy that I don't understand a word of all this. And not afraid to admit it.
It all sounds like poo baah to me.
-
You guys with this ability and mental capacity to produce these projects are totally amazing. I am struggling to just understand the deference between open and closed systems. I am making some progress with the guidance of some guys here on the forum. However I don’t think us older guys who started late in life will ever get up to top levels of this fast advertising technology. By the time we make some progress everything we learned the past year is already old technology. Thanks for this post I’ll try and figure it out somewhat:(
-
Hi,
it's much less amazing than it might seem at first glance. I'm 58, my education is mechanical engineer, my business experience mktg/sales/mgt. No previous electronic or programming experience at all. I'm just lucky to have the time and inclination to "deep"-dive into this stuff and enjoy the learning experience, it keeps the brain busy. And, very important, Beard is always willing to help me out when I ask the most stupid questions.
When I post you only see the tip of the iceberg. So much time being sidetracked or plain ignorance is spent between the posts. To paraphrase and adapt an old saying, for me it's "99.999% transpiration, 0.001% inspiration". If not even less.
So, you are never to old to learn new stuff. And keeping an old Beatles song "Long and winding road" in mind helps :laugh:
Cheers
Meinolf
-
Great post, Meinolf.. :thumb:
-
Hi,
Nice.. since a friend told me about can bus problems with his Beemer several years ago, (he was a BMW mechanic) I decided I didn't want a bike with one. :smiley: Maybe you'll eventually change my mind.
allow me to put this into perspective. The CANBus in itself is interesting, great stuff to get acquainted with, but of no big use, as far as I can make out, in optimizing the BIN. But, understanding what's happening should help in identifying scalars in the BIN. Those are most difficult to pin down, as a single byte in the huge hexdump is less likely to be found than a table.
And a special thanks to John, a British Triking fan, who read this thread and kindly shared his findings about the IDs and data on CANBus.
Cheers
Meinolf
-
Meinolf,
Again, a gracious thank-you for you persistent aggression into the reverse-engineering of our ECU "brains"!
I have a 5AM ECU that I'm planning to use on my ST4s Ducati... And I "think" that the 59M ECU that was OEM on this model had CAN bus merely for the anti-theft (IMMO) module "hand-shake". So given that I am willing to delete the IMMO function with the newer 5AM ECU, I am hoping that much of the CAN bus logic can be ignored also for the 2003 ST4s that I am getting ready again for this 2018 riding season.
A bit of history: My ST$s was giving me intermittent issues with the IMMO light, and most recently running issues -- after I stirred the hornet's nest by wiggling the harness beneath the gauges... Anyway, I did find a lousy fuse connection for the "display" (a 3A fuse that also seemed to interfere with the IMMO LED).
In the long run, I'm hoping that the 5AM will make my Ducati 2003 ST4s run like, or better, than it use to.
FWIW, the 5AM that I bought, came from a HM1100s, and it was able to immediately start my engine (which the 59M was seemed no longer capable of -- and I checked many things B4 doing the swap...).
So I was wondering if the CAN bus could be disabled in the 5AM, since I really have no need for it?
-
Hi,
So I was wondering if the CAN bus could be disabled in the 5AM, since I really have no need for it?
hm, an interesting question. The CANBus HW is in the ECU and controlled by the program code. Which is probably different between Guzzis and Ducatis. As I don't plan to explore the Ducati BINs your existing thread http://www.ducati.ms/forums/241-tech-forum/687521-2003-st4s-planning-install-5am-ecu.html in the Ducati forum is more likely to provide an answer.
Btw, just copying a table or two from one BIN to another is a rather naive approach. The 5AM code is full of yet unknown scalars and tables and. Exchanging a single or a couple of tables is very unlikely to produce reliable results.
Cheers
Meinolf
-
Hi,
it's been some days since the last post. The last couple of days were mostly spent on installing the recently arrived CANBus shield and trying to get Arduino sketches running. I did mention that programming is not my forte, didn't I?
But once again Beard came to the rescue and quickly programmed a sketch and library which now sent the CANBus frames to the serial monitor.
The CAN H/CAN L data lines are connected to the still unpopulated TCU connector of the Aprilia wiring loom. The CANBus runs at 125kBit/s, and only five identifiers have been found so far. The data in the CANBus frames contains includes speed, rpm, air pressure and more.
(http://thumb.ibb.co/gBnWib/canbus_small.jpg) (http://ibb.co/gBnWib)
The electronic equipment in use has increased a lot. From left to right, an EEPROM programmer, the Arduino Uno and the plugged-in CANBus shield, the OBD2 adapter and the signal analyzer.
(http://thumb.ibb.co/hhj0bw/Measure_device_small.jpg) (http://ibb.co/hhj0bw)
A lot of display real estate is needed to have all the required programs visible at the same time.
(http://thumb.ibb.co/bZsmGw/Display_all_small.jpg) (http://ibb.co/bZsmGw)
It now pays off that the former living room was re-purposed as inside workshop when the youngest daughter moved out some time ago.
(http://thumb.ibb.co/bTgP3b/Living_workshop_small.jpg) (http://ibb.co/bTgP3b)
Recently fabricated was a holder to attach 4 plugs to the ignition coils. Which took care of the ignition related ECU errors, but sends a lot of high voltage spikes into the loom, even disturbing the USB interfaces of the PC. Plus, with the plugs and stepper motor attached the power supply runs at ~2.6Amps. Which is probably more power that the PCs requires.
(http://thumb.ibb.co/f8HWib/plugs_small.jpg) (http://ibb.co/f8HWib)
Also fabricated was the infamous resistor module used in the Aprilia Mana. A couple of resistors and a diode, connected to side stand, ECU, starter button and front brake switch. It's not needed when a Guzzi BIN is loaded, but the virtual engine won't start when an Aprilia BIN is active.
(http://thumb.ibb.co/eYZBib/resistor_module_small.jpg) (http://ibb.co/eYZBib)
The standard programs used include Arduino and the serial monitor as well as Sigrok, the frontend used to analyze and display the signals measured with the signal analyzer
(http://thumb.ibb.co/gJJXpG/Display_1_small.jpg) (http://ibb.co/gJJXpG)
The 2nd monitor shows the Guzzidiag suite and the EEPROM programming software.
(http://thumb.ibb.co/kc5Oww/Display_2_small.jpg) (http://ibb.co/kc5Oww)
upload photo (http://de.imgbb.com/)
And last but not least, Tunerpro and a Hexeditor on the 3rd display.
(http://thumb.ibb.co/e3JXpG/Display_3_small.jpg) (http://ibb.co/e3JXpG)
Cheers
Meinolf
-
You've been busy.. :thumb:
-
Great job Meinolf! I've got a room suitable for that purpose too, but I'm find hard to get the wife to agree to the conversion :sad:
I hope you've put heavy duty castors on that desk, when you're finished, its going to be the fastest desk in the Euro zone! :bow:
-
Hi,
I'll be posting more details on the CANBus now. Both to keep John T., who kindly sent his findings on the CANBus, and the guys from www.ducati.ms (http://www.ducati.ms/forums/241-tech-forum/627217-ducati-998-999-iaw59m-canbus-3.html) in the loop.
Again Beard came to the rescue and provided the sketch to get analyzable data from the CANBus shield. So, here's the first take. The BIN used is from a Stelvio (2229STA42Z).
(http://thumb.ibb.co/iYh61w/Canbus_0x100.jpg) (http://ibb.co/iYh61w)
Cheers
Meinolf
-
Good start.
-
Hi,
it's not uncommon for programmers to leave their signatures or witty comments in the code, which is only shown when certain key-combinations are pressed.
In this instance it seems that one of the programmers working on the BIN of the 2-Lambda models hid the following message in 2 Canbus packets.
"Streetfighter"
(http://thumb.ibb.co/k63Htb/Streetfigher1.jpg) (http://ibb.co/k63Htb)
(http://thumb.ibb.co/d9cz6w/Streetfigher2.jpg) (http://ibb.co/d9cz6w)
And maybe there's another message hidden within the message. The last Byte in the 2nd line is $18, which, in the ASCII-code, is defined as CAN(celed). So somebody is sending the message that Guzzi canceled Streetfighters every few ms over the CANBus.
Cheers
Meinolf
-
Hi,
the last weeks were spent in assigning every byte which assumedly is data, not program code, to parameters in an XDF.
An iterative process was used, first trying to identify tables and their format (signed/unsigned, 8/16Bit, array structure like 2x8 or 32x20). The next step was to fill in the holes and assign scalars or flags to those adresses where no structure indicating a table was visible. Again, every single value was evaluated if signed/unsigned or 8/16bit provided a plausible interpretation.
The result is a XDF with more than 400 parameters, well knowing that firstly many of the interpretations are likely to be wrong or incomplete and secondly knowing that not every table, scalar or flag found will be used by the program code in Guzzi BINs.
Concurrently the results of the analysis were tested on the ECU simulator and the idle fuel map was found at 0x4D7B0. The assumed array is 16x8.
(http://thumb.ibb.co/bQjzkx/Idle_Fuel_Table.jpg) (http://ibb.co/bQjzkx)
The range it's active in is TPS closed, rpm > 200 (I haven't tested below 200rpm), rpm < 2600 when engine speed is decreasing and rpm <2650 when engine speed is increasing. While the tests show that one axis if the table is rpm, the meaning of the 2nd axis couldn't be determined yet. Neither engine or air temperature nor vehicle speed have any influence nor clutch, brake, neutral or sidestand.
Further investigations will show if in fact 16x8 is the correct size, the values in that array indicate so, or if it's different. A likely candidate for the rpm-axis is the 8x1 table at 0x4D7A0.
Another tidbit found was that the warm-up function, which was assumed to be active only after starting the engine, also kicks in when the revs decrease rapidly. As the standard setting of the warm-up function is a duration of 2000 engine revolutions after start this hindered the measurement of the idle fuel injection time influence a lot.
Cheers
Meinolf
-
Excellent work, Meinolf.
:thumb:
-
Hi,
while going thru the entire BIN strange findings pop up. Such as the "STREETFIGHTER" string found previously.
A new candidate for strangeness was a string at 0x1820A, "5AM PTPD 1234". I found this string in all 5AM BINs regardless of motorcycle make they were used in.
A bit of research pointed towards https://en.wikipedia.org/wiki/PTPd. PTPd is an Open Source implementation of a Precision Time Protocol from the UNIX world. As it turns out the Open Source license agreements dictate that programs which make use of them mention this.
Now why would this string be in the program code of an ECU?
Some more research and this was found http://www.ieee802.org/1/files/public/docs2013/new-tsn-diarra-in-vehicle-global-synchronization-0716-v01.pdf
A secure way of providing time synchronization is needed for real time data exchange in automotive applications. It's seems likely that the 5AM program code was built with this application in mind.
Cheers
Meinolf
-
Just wondering? Did that dashboard arrive and is it useful?
Pete
-
Hi Pete,
yes, the dashboard arrived. It unfortunately died only a few minutes after powering it up.
Thanks again for your support
Meinolf
-
Shit! I'll keep my eyes out for another. I might have a Stelvio dash around but I think it's part of a full lock kit as well so it's worth something.
I might go down to Sydney and nag, in person, about that TCU and dash that AFAIK are still sitting there.
Pete
-
Hi,
it's much less amazing than it might seem at first glance. I'm 58, my education is mechanical engineer, my business experience mktg/sales/mgt. No previous electronic or programming experience at all. I'm just lucky to have the time and inclination to "deep"-dive into this stuff and enjoy the learning experience, it keeps the brain busy. And, very important, Beard is always willing to help me out when I ask the most stupid questions.
When I post you only see the tip of the iceberg. So much time being sidetracked or plain ignorance is spent between the posts. To paraphrase and adapt an old saying, for me it's "99.999% transpiration, 0.001% inspiration". If not even less.
So, you are never to old to learn new stuff. And keeping an old Beatles song "Long and winding road" in mind helps :laugh:
Cheers
Meinolf
So far above my head, it's embarrassing... :embarrassed:
-
I'm still stepping my way through it, but the table at at 0x482b4 looks suspiciously like the legend for a MAP correction table.
-
Hi Mark,
I'm still stepping my way through it, but the table at at 0x482b4 looks suspiciously like the legend for a MAP correction table.
I don't think so.
The value range doesn't make sense for a non-charged engine. I've logged MAP over the entire driving range on the V11 and Jackal (for the purpose of creating target lambda tables). And the 5AM equipped Guzzi don't have a MAP sensor, only the baro sensor in the dashboard.
This might be an unused table.
Cheers
Meinolf
-
Hi Mark,
I don't think so.
The value range doesn't make sense for a non-charged engine. I've logged MAP over the entire driving range on the V11 and Jackal (for the purpose of creating target lambda tables). And the 5AM equipped Guzzi don't have a MAP sensor, only the baro sensor in the dashboard.
This might be an unused table.
I'm afraid I disagree. I believe it is legend for a MAP sensor correction. I know it's not used, but the developers must have considered it at some point. It turns out the values are exactly the same as the MIU G3 intake correction legend. Yes, 2000 mBar is a bit outrageous, but values of around 1000 aren't. I don't recall what the 35mm (?) throttle body of a V7 produces, but the 50mm 1400 California is in the 650 mBar region.
-
Hi Mark,
even if it's not used in the 5AM, it's valuable information nevertheless. Do you know which to which table (value range and array size) it belongs in the MIU G3? And what the other legend is? If I can find a corresponding table in the 5AM it can be taken of the watch list.
The MAP values I have measured (Jackal) go down to ~40% of ambient pressure. The upper table are centiBar values, the lower table is the normalized view of the upper. Zeros at the breakpoints w/o data.
(http://thumb.ibb.co/kn8LtH/MAP_Jackal.jpg) (http://ibb.co/kn8LtH)
images upload (http://de.imgbb.com/)
Cheers
Meinolf
-
Intake pressure correction.
Intake air temperature (deg C) vs manifold absolute pressure (millibar)
Air temp is 16 values: 20 - 110 (Conversion X - 40).
(https://i62.servimg.com/u/f62/18/91/78/64/f0c29010.jpg)
-
I think there are a number of tabels/legends not used at all. The marelli guys take a stock set of table/maps and start using what is handy. Since a lot of sensors they use have the same characteristics on car of MC.
-
Hi,
some weeks have passed since the last post. Beetle's information, and the tremendous work John Th. from the UK is doing on analyzing the code, provided plenty of information to update the XDFs for the one- and two Lambda Guzzi. While many of the arrays, scalars and flags identified are still unknown in regards to what they actually are for, or as Paul remarked, if they are really used by the program, the XDFs now contain hundreds of plausible parameters.
The idea for the ECU simulator was born when an Aprilia Mana was added to the motor pool, the cable loom and the ECU are used Aprilia parts. However, the virtual engine wouldn't start with an Mana BIN. The assumption was that the missing dashboard and maybe the missing TCU were cutoffs.
Some weeks ago a Aprilia fan from Poland, Robert, approached me and offered to assist in getting a Mana dashboard. Which arrived today. I knew that the mechanical condition wasn't mint, but as long as the electronics work all would be well.
(http://thumb.ibb.co/epDOUc/Dashboard_nach_Ankunft_small.jpg) (http://ibb.co/epDOUc)
The complete dissassembly is much easier than that of the Guzzi dashboard. The PCB was removed and power applied. And, it worked. The stepper motor stepped and the LEDs lit up.
(http://thumb.ibb.co/nGrXNx/Dashboard_zerlegt_small.jpg) (http://ibb.co/nGrXNx)
pic upload (http://de.imgbb.com/)
The EEPROM was quickly identified and cables soldered to the SDA/SCL pins. Then a connection to the programmer and the EEPROM content could be read. Great. The next step was to program the EEPROM with a Usercode and the transponder keys fitting to the ignition key used. Alas, programming didn't work, the software gave an error message. So, a quick study of the EEPROM datasheet and some thinking led to the assumption, that maybe the Aprilia dashboard made use of the Write Protect pin. Another cable was added and connected to ground. And now the EEPROM could be programmed as well.
(http://thumb.ibb.co/cXDU2x/Dashboard_nackt_mit_Kabeln_small.jpg) (http://ibb.co/cXDU2x)
Another quick check was made to verify if the algorithm (found for the Guzzi dashboards) for calculating the check sum protecting the mileage and other values in the EEPROM also worked with the Aprilia firmware. And yes, it's the same algorithm.
The next step will be to connect the dashboard to the ECU simulator and check if the virtual engine can now be started. Then the XDF describing the addresses and contents of the data can be validated. And take a look at what's happening on the CANBus as well.
And a special thanks to Robert and his support in getting the dashboard. Chapeau!!!
Cheers
Meinolf
-
Hi,
it's not uncommon for programmers to leave their signatures or witty comments in the code, which is only shown when certain key-combinations are pressed.
In this instance it seems that one of the programmers working on the BIN of the 2-Lambda models hid the following message in 2 Canbus packets. "Streetfighter"
I normally look at the hexdumps in 16bit LoHi-notation, so ASCII characters are not usually visible. Just for the hell of it I scrolled through the Aprilia code in 8bit notation.
And found this message string: SONO UNA Ducati. Which translates to "I am a Ducati".
Some of the programmers are real jokers....
(http://thumb.ibb.co/k91dVH/Ich_bin_eine_Ducati.jpg) (http://ibb.co/k91dVH)
The string "STREETFIGHTER" is displayed on the Guzzi dash after power on, I can't remember seeing anything similar on the Mana. I'm curious to see if the string is send over the Aprilia CANBus as well.
Cheers
Meinolf
-
:grin: :grin:
-
Hi,
it's snowing again and well below 0°C. A good opportunity to follow up some thoughts. Firstly the infamous Fuel Phase table (I'd give my left arm to learn who selected this name based on which thinking) and secondly the Ignition Dwell table. And as a plus the battery voltage legend. But first things first.
The Fuel Phase table is one of the bigger arrays in the 5AM, using 20x32 cells and having TPS and rpm as legend. The original table looks like this
(http://thumb.ibb.co/fJk3nx/Fuel_Phase_original.jpg) (http://ibb.co/fJk3nx)
Now the question was, which function could this be describing. Rather large and sudden value changes and no obvious relation between value changes and legend values. It looked strange.
For the longest time I tried to figure out a way to trigger the scope to a fixed reference. The obvious choice was the 2 teeth hole in the engine speed signal, but I haven't found out how I could get my scope, a Rigol DS1054Z, to trigger to the lag. Then the idea was born to do this in a roundabout way. Set ignition values and all relevant trim tables (temperatures, baro, idle mode, ...) to 0, then the pulse would be fixed in a relationship to TDC, regardless of changes to rpm or TPS.
(http://thumb.ibb.co/bDsSEc/Fuel_Phase_DSO.jpg) (http://ibb.co/bDsSEc)
Then the Fuel Phase table was filled with staggered values suitable for identifying steps and uploaded to the ECU.
(http://thumb.ibb.co/g4PA0H/Fuel_Phase_Test.jpg) (http://ibb.co/g4PA0H)
Then all relevant TPS settings were selected and the time delta between the respective flanks of the injection and ignition pulse were measured. And lo and behold, a structure became visible. Low values moved injection pulse end towards TDC, large values moved the pulse end to earlier timing.
So the working hypothesis now is that Fuel Value (Duration of injection pulse) + Fuel Phase Value (timing for end of injection pulse) determine the injection event in regards to duration and timing.
More to follow
Cheers
Meinolf
-
Hi,
it's been a cold day with lots of new snow. I'm glad I used the better weather during the last couple of days to service my motorcycle pool and especially the Norge and Futura, which are new, and tailor-suit them to my requirements. The next days will be to cold enjoy staying in the workshop.
But, it must be an ill wind which brings no good. Time invested in the ongoing quest paid off. The Fuel Phase table is mostly revealed, some details need to be validated, that's for the coming days.
One of the results of todays work was the identication of the ignition dwell table. That's the one which governs the time the ignition coils are charged dependent on the battery voltage. The formula used is X/500 = charging time in ms.
(http://thumb.ibb.co/btmzuc/Ignition_Dwell_and_Battery_legend.jpg) (http://ibb.co/btmzuc)
And just as important, this validated the assumed battery legend table at 0x4D056. The formula used is X/10 = voltage. There at least two other 16x1 tables which are likely to use it. Which helps a lot in trying to identify what their function is.
From some of the previous replies I gather that this seems like mysterious stuff to many. Not so. Disassemby and programming are not my core competencies. So the tedious route is the one I'm using. 2 identified tables out of about one hundred unknown, plus another factor used in a formula found helps a lot in narrowing down the search for the remaining ones.
We've made a lot of progress since John Th. from England has joined this endeavour. He's digging into the disassembled code in a very British way. Soft-spoken but very!!! knowledgeable.
Cheers
Meinolf
-
That is VERY interesting and might explain some of the slightly weird things I've noticed about the running of bikes with marginal batteries. Thanks.
Pete
-
Hi Pete,
which were these "slightly weird things" you've noticed?
Cheers
Meinolf
-
Hi,
I firmly believe in some fundamental truths.
Firstly, sleep on it for a night
Secondly, apply Occam's razor
Thirdly, with sharing you make friends
...
... Numerology may actually make sense
Applying all of them at the same time is a powerful tool.
So in this case. While I was researching using the ECU simulator with my hands-on approach, John Th. is busy deep-diving into the disassembled code.Some days ago he mentioned that the code is using a counter running from 0-7199 over two crankshaft revolutions. Which, as it happens, turns out to coincide with the angle of one camshaft revolution if divided by 10.
7200/10 = 2x360°
Now, throwing the number of teeth, both those actually present (46) and the ones missing (2), into the ring leads to another number.
720° / (46 + 2) = 15° crankshaft/tooth
And he mentioned that the formula applied to the Fuel Phase table is likely X/10 = ° Crankshaft BTDC.
Mixing the tidbits from different sources, sleeping it over and slowly shaving with Occam's razor in the morning after leads to some conclusions.
The Fuel Phase table contains values for the end of injection pulse, and quite likely for ignition pulse as well, in ° crankshaft. A likely algorithm for the calculation of the beginning of the respective pulses is
(Valueinj/ign * trim values) + Fuel Phase values = Start of pulses in ° BTDC
The trim values would take care of the voltage dependencies of the inductive nature of the ignition coils and injectors. And quite likely there's a table or scalar for the deadtime of the injectors as well.
The numbers 7200/720 and 15/150 also provide hints which values or value ranges to search for in the quite large number of scalars, both known and assumed ones.
Chasing scalars has proven to be quite successless. A considerable number of switching values have been determined. Such as revolutions since start as duration of the warm-up function, fan On/Off temperature, closed loop area in regards to engine temperature, TPS and rpm or rpm's at which the idle fuel goes active/inactive.
But, not many of the discrete absolute values could be connected to a scalar yet. Quite the opposite, at least for idle fuel the switching point is the notional index of the y-axis. When increasing rpm the idle fuel function stops after exceeding the last 1/16ths of the legend and kicks in when decreasing below the 2nd from top 1/16ths.
It's likely that other switching points are also linked to notional indices and not to discrete values.
Cheers
Meinolf
-
Hi Pete,
which were these "slightly weird things" you've noticed?
Cheers
Meinolf
I'll email you in the next few days. Busy as a very busy thing right now but battery voltage seems to affect certain things.
-
Hi,
it's not that the work on the 5AM simulator has stopped, but since May we have terrific weather here in Germany. So plenty of driving, hiking (including a week in Cyprus), working in the garden and servicing my motorcycle fleet took up a lot of time.
So, what happened in the meantime. The code analysis of the 2V BIN continued, the results were compared to the 8V BIN and also the Aprilia Mana BIN. The XDFs for all three are now covering almost the entire code and data area, consisting of hundreds of tables, scalars and flags. I believe that most of the essential ones are understood and validated, but there are plenty of unknowns left. Copies were sent to Peter Roper, Beetle, Beard and PaulDaytona. And a Mana driver from Portugal, Luis, already used the XDF to disable Lambda and thus fix issue which have troubled him.
I also began logging data on my Norge 12002V. Initially with the Innovate LM-2 and two lambda sensors, but one channel died during the tests. I have been using the LM-2 for several years, this is the most troublesome and unreliable tool I've ever come across and Innovate's technical service is horrible. Plus, it eats WBOs. The only good part of the package is the software for analyzing the logged data. The LM-2 is now moved to the 5AM simulator, I'll explore if it's OBD communication can be hooked up to the 5AM to monitor the status messages sent over the K-line.
So the two ZT-2 were moved from the V11 to the Norge. Now the ZT-2 are very robust and reliable devices, but they suffer from a number of shortcomings in comparison to the LM-2.
First, TPS is logged as %-value. That's acceptable if the number of breakpoints is not more 16 and the delta between the breakpoints is big enough to be expressed as a percentage integer value. It worked on the 15M, even though I had to change the TPS breakpoints to accommodate the resolution. It's not good enough for the 5AM, which uses 20 TPS breakpoints, of which the first ones are very close. 4.59°, 4.7°, 5.2°. Now with a resolution of (85°-4.59°)/100=0.801° those breakpoints can't be discerned, all are in the range 0-1° and that's the most difficult area to log and analyze. And even and larger TPS values it's critical because the bi-linear extrapolation of the code interferes with associating values to a specific breakpoint.
Second, ZDL, the Zeitronix software. It displays the log, but is unusable for analyzing the logged data. And that's a real problem, as the ZT-2 logs at ~60Hz. Which amounts to >200k datasets (each containing lambda left/right, TPS, rpm, engine temp, EGT and MAP values) in one hour of driving. In the past a rather tedious route was taken to analyze the data. The log was loaded into ZDL and exported as CSV. Beard wrote a program to convert the CSV to DIF, which could be then imported into Logworks, the Innovate software, for visual inspection and analysis.
However, the main work was done with the Excel worksheet created and maintained by Punch, originally intended analyzing Innovate logs. A really great piece of Excel coding, but feeding the amount of datasets created by ZT-2 into the worksheet eventually brought it to its knees, a re-calculation took up to 15min.
So, quickly more than 10h of road logs were logged, but no reliable method of analyzing the data was available. I mentioned this in the German Guzzi forum, where most of the discussion happens, and, not surprisingly, Beard again came to the rescue. He proposed to write a data base program which used SQL to import and analyze the data. Initially we used CSV exports from ZDL, but quickly decided to try and use the native log files without the error prone and time-wasting export procedure. Zeitronix kindly supplied the specs of the serial communication and the data structure in the log file and the work began in earnest.
The result is a very usable piece of software to analyze lambda values, rpm and TPS. TPS and rpm values are user-definable, %-ranges for TPS and rpm also. A minimum number of datasets used for filtering can be selected and also data is displayed as AFR or Lambda. Zeitronix logs can be loaded individually and can also be appended. So the >10h logs resulted in a single database of more than 2.1mio datasets. Which gives more than enough datasets at each breakpoint to arrive at meaningful data, even taking into account the effects of acceleration/deceleration and so on.
And, it's blindingly fast. Re-calc of the 2.1mio datasets takes ~4s.
(https://thumb.ibb.co/mhWa2T/meinolfs_Lambdadatabase.jpg) (https://ibb.co/mhWa2T)
This morning the analysis was brought into a new BIN. And, after one hour of logging with this BIN and looking at the resulting data the conclusion is that never before could I apply logged data so quickly, effortlessly and accurately. The after-analysis showed that the delta of the left/right cylinder lambda values are almost all <= 0.01 and in line with the set lambda target values.
Last Saturday Beard came over, he asked me to straighten the rotor from his washing machine on my lathe, and while we were turning and chatting an idea came up to circumvent the TPS %-issue of the ZT-2.
The ZT-2 has several input ports - WBO, TPS, rpm, User1/2 for 0-5V, EGT and MAP sensors. When logging 2 cylinders two ZT-2 are slaved, the 2nd lambda signal is feed into one of the 1st ZT-2 voltage input ports. The 2nd voltage port is free for other purposes, I've used it to log engine temp, air temp, oil temp or voltage.
Now the idea is to feed the voltage of the TPS into the 2nd voltage port. It logs the 5V with a resolution of 5V/256=0.0195V, or in other words, the TPS range of (85°-4.59°)/256=0.314°, an improvement of 255% compared to the %-resolution. Thus a very accurate mapping of TPS breakpoints is possible. The largest error (deviation 4.3%) would be at 2nd TPS breakpoint of 4.7°, all other deviations are in the 0.1% range. That's good enough.
So, the quest continues. And, again, kudos to Beard for his splendid support and un-ending patience with my ignorance.
Cheers
Meinolf
-
Good job. I too, found the LM-2 to be a piece of junk. Luckily, I got my money back! I've stuck with Innovate, however. I use LC-2's, SSI-4 and PL-1 for data logging.
-
Hi Mark,
we are continuing the work on the program. Beard wants to implement reading native Innovate logs as well. I've approached Innovate and asked for specs of the log format, but their support is spurious. Do you (or anybody else) have the specs?
Cheers
Meinolf
-
Only this:
https://www.firetooth.net/confluence/display/public/Innovate+Motorsports+D32+file+format
-
Hi Mark,
thanks.
https://www.firetooth.net/confluence/display/public/Innovate+Motorsports+D32+file+format
following the link and doing some further searching this also was found:
https://www.innovatemotorsports.com/support/manual/OT-2%20SDK.pdf
https://www.innovatemotorsports.com/support/downloads/Seriallog.pdf
and this seems to be the current version: https://www.innovatemotorsports.com/support/downloads/Seriallog-2.pdf
That should help us in deciphering the logged data.
Cheers
Meinolf
-
Hi Mark,
Good job. I too, found the LM-2 to be a piece of junk. Luckily, I got my money back! I've stuck with Innovate, however. I use LC-2's, SSI-4 and PL-1 for data logging.
I'm not familiar with the LC-2, SSI and PL-1. But, if they also create D32 log files, another tool written by Beard yesterday might of use to you. It extracts data directly from the unedited D32 file and converts it to a CSV format.
When deciphering the D32 file Beard found a discrepancy in the data created by the 4th analog channel. The conversion of the logged hex data into CSV produced different values than expected. He quickly found the solution though (he always does), every 2nd value is the average of the preceding and following value and not a logged value. Not according to the specs, I've sent an inquiry to Innovate.
AFR1 AFR2 RPM A1 A2 A3 A4 RPM2
13.33 14.04 1140 0.52 2.74 1.48 3.07 0
13.29 14.04 1140 0.52 2.74 1.47 2.83 0
13.24 14.02 1140 0.52 2.74 1.48 2.59 0
3,07 - 2,59 = 0,48
0,48 / 2 = 0,24
3,07 - 0,24 = 2,83
Cheers
Meinolf
-
Must be peculiar to the LM-2. I don't have that issue with the SSI-4. It does log a minimum value, however.
Session: Session 14
time Lambda RPM TPS Temp SSI4_4
(sec) (Lambda) (RPM) (Deg) (Temp) (Volt)
0 0.958 1293 4.8 95.1 0.01
0.08192 0.956 1293 4.8 95.6 0.01
0.16384 0.954 1284 4.8 96.1 0.01
0.24576 0.947 1258 4.8 95.6 0.01
0.32768 0.94 1232 4.8 95.1 0.01
0.4096 0.935 1232 4.8 94.9 0.01
0.49152 0.939 1232 4.8 94.5 0.01
0.57344 0.951 1249 4.8 94.7 0.01
0.65536 0.955 1267 4.8 94.9 0.01
I tried Bernd's converter, but it cocantenated all the log sessions into one big CSV file. Not useful for me. If I need to produce a CSV or DIF file, I just export them from Logworks.
-
Has anyone taken another approach to try to find the programmer(s) from Guzzi who wrote the code and see if they could help. If still at Guzzi they may not be able to help but if retired or moved somewhere else they might.
-
Hi Dave,
I have not tried nor would I expect an answer. The source code would certainly be considered to be IP of Marelli and not be disclosed. And past inquiries about trivial specs for Marelli injectors were answered neither by Marelli HQ or the motor sport group in the UK.
More so because it seems that Marelli is using a library for the code used in their ECUs, beginning with the 15M/RC, the 59M and the 5AM. Some weeks ago I was asked to look at a 59M XDF, some more details here: https://www.ducati.ms/forums/241-tech-forum/715211-59m-ecu-xdf-st4s-800-1000ss-still-interest.html
In fact I have wondered during dark moments if and when a Marelli lawyer would contact me. I'm not sure if the reverse engineering and disclosure of the findings is proper.
Cheers
Meinolf
-
Reverse engineering for profit might raise some eyebrows but as a hobby, probably not. Especially if it’s for the older bikes.
You’re not creating a competitive advantage for any other manufacturer nor are you doing anything a competitor hasn’t done with a lot more resources, not that they may even bother.
Carry on!
-
In fact I have wondered during dark moments if and when a Marelli lawyer would contact me. I'm not sure if the reverse engineering and disclosure of the findings is proper.
People have been doing it since the late 80s without issue. A guy employed by Duane Mitchell (FIM) in Australia may have been the first to decode the WM firmware of that time. Others have followed ever since then, more or less keeping up with Marelli.
BTW, Australia has always been a hotbed of aftermarket car and bike ECU activity, not least because the products could be sold into the US and Europe without fear of being chased down and fined by local government - which is a bigger issue, particularly in places like California.
Regardless, do carry on :laugh:
-
Hi,
ok, so no immediate danger of getting thrown into jail. Which is good, as I did dabble around a bit with a DUC BIN and a XDF for a iaw59M:
https://www.ducati.ms/forums/241-tech-forum/715211-59m-ecu-xdf-st4s-800-1000ss-still-interest.html
More for the fun of it than anything else, as I don't have a bike using a 59M.
And here are the links to the One and Two Lambda XDFs for Guzzi CARCs
One Lambda: https://drive.google.com/open?id=1r_r4iD9WROsOLqgHpiHfEthMkyeACaVU
Two Lambda: https://drive.google.com/open?id=1a_stCXFRzbcmTZGxlUSaSqStGSj4Dnjq
Cheers
Meinolf
-
Hi,
it's time for an update, I guess. The last couple of months less time than usual was spent on the 5AM exploration and building of the ultimate BIN for 2V CARCs, as dry storage room was urgently required for the motorcycles. The beautiful sunny weather will eventually end. So trees were felled, roots whittled down and plaster laid.
(https://thumb.ibb.co/byGw9p/Seitenstreifen5.jpg) (https://ibb.co/byGw9p)
(https://thumb.ibb.co/iSZoN9/Seitenstreifen2.jpg) (https://ibb.co/iSZoN9)
(https://thumb.ibb.co/kVRXFU/Seitenstreifen15.jpg) (https://ibb.co/kVRXFU)
(https://thumb.ibb.co/ny0jvU/Seitenstreifen21.jpg) (https://ibb.co/ny0jvU)
(https://thumb.ibb.co/bYgDpp/Seitenstreifen22.jpg) (https://ibb.co/bYgDpp)
(https://thumb.ibb.co/fnqpUp/Seitenstreifen24.jpg) (https://ibb.co/fnqpUp)
The foundations for the carport are ready, building the carport is the next step.
But nevertheless, for recreational purposes the 5AM exploration and constant improvement of the BIN continued...
Cheers
Meinolf
-
Hi,
the database program, programmed by Beard, for analyzing the huge amounts of datapoints collected by the ZT-2, really proved to be a major improvement. The latest enhancement was adding the ability to use voltage input from the TPS via one of the two analog channels instead of continuing to use the standard %-measurement of the TPS, which suppresses individual breakpoints in the low load area.
The result was a BIN in which the AFR values of the two cylinders not only were identical (or close to identical), but also were in line with the target AFR values choosen over the TPS/rpm breakpoints. In German I'd probably use the wording - it runs as smoothly as a sewing machine.
But, a number of circumstances still make visual analysis necessary. The closely spaced breakpoints and the bilinear interpolation used by the code for in-between datapoints make the identification of individual occurences difficult, the are simply hidden in the mass of averaged datapoints.
(https://thumb.ibb.co/kna69p/ZDL_Lambdadatabase.jpg) (https://ibb.co/kna69p)
So, an occasional reset is needed. While it is normal that the fuel maps look like a hilly landscape, neighboring datapoints which differ to much are simply not plausible. Manual identification and changing them to fit into the respective contextual data is occasionally needed.
(https://thumb.ibb.co/eXtjUp/Delta.jpg) (https://ibb.co/eXtjUp)
(https://thumb.ibb.co/dExpvU/Main.jpg) (https://ibb.co/dExpvU)
The resulting BIN was logged and performed well, the normal optimization process can continue based on a more stable basis.
Alas, one area was still not satisfactory. This is the low load area in the range of 4.6-6� TPS and rpms up to 3000min-1. The reason was known, the idle fuel map replaces the main fuel map in that area, if and when the ECU considers the TPS to be fully closed. However, that is a range, not a single switching over point.
The idle fuel table and its function was already investigated at length on the ECU simulator, but it's function never understood. The x-axis uses a table with rpm values, the y-axis uses steps in the range of 55-200. A recent observation by Gelos, a Guzzi expert from Poland, led to a better understanding. The y-axis uses the steps employed by the stepper motor. In retrospect this seems very obvious. But that's usually the case with hindsight.
So the idle function uses the idle fuel table to move the stepper motor to steer the idle rpm. But under which circumstances and when?
The above led to the decision to re-start a detailed code analysis with IDAPro, very much based on the astonishing code analysis John Th. from the UK has started...
Cheers
Meinolf
-
Hi,
for some time the assumption was that the entire fueling calculation was done by a subroutine at 0x2C8B4. But, my coding skills being non-existent, understanding escaped.
(https://thumb.ibb.co/j9sm9p/Fuel_Graph_1.jpg) (https://ibb.co/j9sm9p)
(https://thumb.ibb.co/h8iF29/Fuel_Graph_2.jpg) (https://ibb.co/h8iF29)
(https://thumb.ibb.co/hEucFU/Fuel_Graph_3.jpg) (https://ibb.co/hEucFU)
(https://thumb.ibb.co/nhQjvU/Fuel_Graph_4.jpg) (https://ibb.co/nhQjvU)
Luckily John brought light into the dark. And now the function is much better understood.
The first step is to decide if main or idle fuel is used. Either one is then used during the rest of the calculation, the delta fuel values a used in both cases.
Then, depending on whether closed loop is active or not, either the learned Long Term and Short Term fuel corrections are applied, or this is skipped and the air temp/pressure and engine temp corrections are calculated.
Then some, not yet fully understood, scaling operations.
Next the warm-up table corrections are used, if the conditions for the warm-up function are met.
Yet another scaling calculation, if closed loop is active, or application of the CO trim (up to a not yet found rpm) if closed loop is disabled. Finally a check versus the max. value for injection and a cutoff if needed.
The result is the fuel injection value for left and right cylinder.
Yet to be researched is how clutch, gear and maybe even brake are included in above...
Cheers
Meinolf
-
Fascinating! Thanks, both for your continued effort on this, and for keeping us updated.
Cheers,
Shaun
-
Hi Shaun,
thanks for your kind words.
This is really a community effort, the main contributors being John and Beard. I'm just the one trying to combine the individual efforts of the ones who know what they are doing and learn something in the process. And the strong urge to share the findings of the countless hours spent on measuring and analyzing to make it worthwhile.
If there's anybody else with some knowledge in reverse engineering assembled code, stand up and be counted :-) Still lot's to learn and explore...
Cheers
Meinolf
-
Hi,
a starting problem on the Norge during a trip to Vienna with temperatures close to 0°C was the reason to look at the use of the parameters used by the code to evaluate battery voltage, even though the starting issue was, it turned out, caused by the battery.
Many, if not all subroutines and parameters used for processing the voltage, were found. One parameter, BatteryVoltageCalc at 0x4C64A, seemed to be the scaling factor applied to the raw ADC values.
(https://thumb.ibb.co/hAy6pK/Battery_Calc_Value.jpg) (https://ibb.co/hAy6pK)
So different values were loaded on to the ECU simulator and actual battery voltage, voltage as reported by OBD and on the CANBus and the voltage shown in the dash were noted and evaluated. Quite easy, it turns out, a value of one corresponds to 0.057V. The voltage shown in the dash is not taken from OBD or CANBus, the dashboard uses an independent source. A pity, as the discrepancy between actual voltage and dash voltage can't be set right.
However, as the ignition coils and injectors are acting on voltage related trim tables, and the automatic start on some models also monitors voltage, correcting a discrepancy is an easy blueprinting improvement.
Cheers
Meinolf
-
Hi,
However, as the ignition coils and injectors are acting on voltage related trim tables, and the automatic start on some models also monitors voltage, correcting a discrepancy is an easy blueprinting improvement.
it turned out that the easy bluepring improvement wasn't that easy. A change of the BatteryVoltageCalc factor from 238 to 243 brought the voltage as seen by the ECU in line with the actual voltage, but the bike ran fat - Lambda increased significantly. The assumption was that a voltage trim function for the injectors was the reason.
A few weeks later the assumed trim function was found. The BIN has two trim tables, which govern the pulse length of the injectors depending on the voltage. A Byte value determines which of the two tables is used, that value is fixed in the code, so in fact only one of the two tables is used. And a base value at x04C000 which correlates to the the flow rate of the injector is also present.
(https://thumb.ibb.co/hFAQhq/2230-Injector1.jpg) (https://ibb.co/hFAQhq)
The trim table at 0x4C002 (the 2nd one at 0x4C26 isn't used) then determines the pulse width applied to the injector dependent on the voltage.
(https://thumb.ibb.co/juLQhq/2230-Injector-Trimtable.jpg) (https://ibb.co/juLQhq)
Cheers
Meinolf
-
Hi,
Have you allready find a way where/how to change the idle map.
"Alas, one area was still not satisfactory. This is the low load area in the range of 4.6-6� TPS and rpms up to 3000min-1. The reason was known, the idle fuel map replaces the main fuel map in that area, if and when the ECU considers the TPS to be fully closed. However, that is a range, not a single switching over point."
I have a bike that is running very lean when it is using the idle map, but runs well when it uses the main map. So I would like to tweak the idle map if that is possible.
Ciao
Omo
-
Hi Omo,
Have you allready find a way where/how to change the idle map.
as visible in the flow chart above the idle fuel table is located at 0x4D7B0. X-axis are the stepper motor steps, y-axis the Idle Fuel rpm-values.
(https://thumb.ibb.co/dppDNq/One-Lambda-Idle-Fuel.jpg) (https://ibb.co/dppDNq)
I have a bike that is running very lean when it is using the idle map, but runs well when it uses the main map. So I would like to tweak the idle map if that is possible.
Sure, it's possible, but very difficult. I haven't found a way of matching the stepper values to logged AFR data. There's a flag which disables the idle fuel function, but it's used all over the code, so I've refrained from changing it so far.
How do you know that your bike is running lean when using the idle fuel values and well when using the main fuel values?
Cheers
Meinolf
-
Hi Meinolf,
I am assuming that the idle fuel table is in use when PADS shows message idle on its screen, and thats when the lambda correction values are also very high.
When I give it some revs the PADS shows off idle and the lambda correction values come back to normal +/- 5%.
Also if I tweak the main fuel table on the idle range it has no effect on the lambda correction.
This is a twin lambda Stelvio I am playing with.
Ciao Omo
-
Hi Omo,
you should have mentioned earlier that you are referring to a two lambda model. The code is quite different from the one lambda models and the offsets also. My focus is still on the one lambda BIN and I haven't spent much time yet on the two lambda BIN.
But, here's a look at the current status of the two lambda BIN. The offset of the idle fuel is 0x4D78C, y- and x-axis are the same, idle rpm and stepper motor values.
(https://thumb.ibb.co/ds32hq/Two-Lambda-Fuel1.jpg) (https://ibb.co/ds32hq)
Cheers
Meinolf
-
Hi Omo,
I am assuming that the idle fuel table is in use when PADS shows message idle on its screen, and thats when the lambda correction values are also very high.
When I give it some revs the PADS shows off idle and the lambda correction values come back to normal +/- 5%.
I'm not familiar with PADS, I work with GuzziDiag only, so the idle status as shown in PADS might be different from the one shown in GuzziDiag. But, let's assume PADS also uses the OBD function, then the reported status should be the same.
I assume you have checked other potential causes such as defective stepper motor or air leakage (bypass screws?) and have reset TPS and learned values?
Cheers
Meinolf
-
Hi Meinolf,
Yes I have checked the stepper motor and done the normal tune-ups, TPS/learned values resets etc.
It is odd that the problem is in both cylinders. Both lambda corrections (left/right) are high when idling. Thats why I am thinking there cant be something mechanically broken/air leaks etc... on both cylinders.
I just thought that tweaking the idle fuel table would give me some answers. But if it cant be done then I just have to keep on trying to figure out what is wrong with this bike.
Ciao
Omo
-
Hi Omo,
my mistake, of course you can change the values in the idle fuel table, I've done so.
What I was trying to say is that the matching logged AFR data against the rpm/stepper position values to change values based on measurements is difficult, I haven't found a fact-based approach yet.
The problem is that logging stepper values in sync with TPS and rpm is not possible with the logging equipment I use. Stepper values are sent with a low frequency (12Hz in total, shared by all values requested) as OBD packets, while the data logger (ZT-2) samples at 60Hz and is directly connected to TPS and rpm signal, so sync'ing the data stream is not possible.
So, change away, but it's a hit and miss procedure.
Cheers
Meinolf
-
Hi Omo,
It is odd that the problem is in both cylinders. Both lambda corrections (left/right) are high when idling. Thats why I am thinking there cant be something mechanically broken/air leaks etc... on both cylinders.
if it concerns both cylinders one possible avenue to explore could be the lambda sensors. Either check the sensors or disable closed loop to eliminate one or both of them as possible cause.
It seems unlikely that the idle values should suddenly (that's my assumption) should be wrong, the influence must be elsewhere. Hence changing the idle fuel values would be working on the symptom, not the root cause.
Cheers
Meinolf
-
Hi,
the exploration of the code is proceeding steadily, but the low hanging fruits are picked and learning curve gets flatter.
Last year I noticed several times that idle rpm when stopping with gear engaged and clutch pulled was several hundreds revs higher than expected. In the meantime we found the RAM variables representing the status of clutch and neutral, so this was revisited.
Actuating the clutch causes a change between the two idle ignition tables. Increasing the timing leads to, within certain limits, increased engine power and thus to higher rpm if everything else is unchanged. But, in the 2230 BIN for the Norge 1200 2V both tables contain the same values, so this was not the cause of the increased idle rpm.
(https://i.ibb.co/M77pLcd/2230-idle-ignition.jpg) (https://ibb.co/M77pLcd)
However, this serves as a good example for the flexibility of the program code. While this function seems unnecessary on a bike with a dry clutch, it makes sense with a wet clutch. The friction between the clutch plates due to the oil viscosity will act like a brake and lead to a drop of the idle rpm.
The 2230 uses only one main ignition table , the values for the right cylinder are calculated separately as a delta value, if the TPS in the "not closed" state. We also found the steering and learning function responsible for determining the change from closed to open and from open to WOT.
Cheers
Meinolf
-
Hi,
the idle ignition function of the 3222 BIN is basically the same. However, a few twists were added.
Not only does the clutch switch act as branch condition for switching between the two idle functions, but the neutral switch is added. Which, following the thoughts about the increased friction between the clutch plates, makes a lot of sense. In neutral with the gears not engaged the friction would not be a factor.
(https://i.ibb.co/jLMBq6F/3222-idle-ignition.jpg) (https://ibb.co/jLMBq6F)
Cheers
Meinolf
-
Hi,
seeing that the identical values used in both idle ignition tables would not lead to changes in idle rpm, another direction was explored. Which is concerning the changes caused by engine temperature.
The 2230 has two idle ignition tables which trim ignition in line with engine temperature and are also selected by the clutch switch. Which makes sense, as the oil viscosity and thereby the braking effect will decrease with increased oil temperature. If the clutch is a wet type. Which it isn't, so again identical trim values in both tables.
(https://i.ibb.co/RNRxdyc/2230-idle-ignition-engtemp.jpg) (https://ibb.co/RNRxdyc)
And the question could be asked if this control mechanism is needed in an engine with idle stepper control in the first place.
Cheers
Meinolf
-
Hi,
above might explain why one of the two idle ignition temperature trim tables was dropped from the 3222 BIN.
(https://i.ibb.co/wJ7TT2C/3220-idle-ignition-engtemp.jpg) (https://ibb.co/wJ7TT2C)
Cheers
Meinolf
-
Hi,
while, driven by curiousity, a Ducati 5AM BIN was analyzed in between, the main focus is on the Guzzi 2230, then the Guzzi 3222 and finally the Aprilia Mana BIN. And thus it was interesting to find a parameter setting a number of possible gear box configurations.
The parameter at 0x4CF60 (2230, a different offset in the 3222) contains values from 1-6 and 20 and 21. The values from 1-6 represent the number of gears, though a transmission with two or three gears probably is no longer state of the art. The value 20 is used if the bike is using a CVT automatic transmission, as is the case with the Mana. The function of value 21 is unclear, but it is queried as branching condition value in the code. Possibly for a different automatic transmission or a double clutch system.
(https://i.ibb.co/rZWykGd/2230-trans-type.jpg) (https://ibb.co/rZWykGd)
Cheers
Meinolf
-
Meinolf,
in the griso map, what addresses are the different idle ignition tables? The 2230G803 map I use does have the idle rise with pulled clutch and not in neutral, Switching to neutral gest idel normal again.
-
Hi Paul,
the offsets are for the idle ignition maps are legible in the picture above, 48D9E and 48DFE.
Cheers
Meinolf
-
Yes they are different, now waiting until its a bit hotter to test. I had it most when hot. I see the normal ignition/temp table doesn't do anything over 7 degree. And making both ignition tables the same didn't change your behaviour. The neutral switch makes the difference, switching to neutral makes idle good again.
-
Hi Paul,
yes, moving to neutral leads to a normal idle.
Finding the code section which uses the neutral flag and leads to functions which would influence idle speed is a challenge, though. One of the most convoluted subs uses the neutral flag about a dozen times. Working thru it and backtracking the numerous other variables called takes days and weeks, and that's only one of hundreds of subs and thousands of possible combinations including timing conditions.
(https://i.ibb.co/6tFKpfW/2230-neutral-flag.jpg) (https://ibb.co/6tFKpfW)
Cheers
Meinolf
-
Hi,
some more tidbits, this time with the focus on the fuel acceleration function. Which takes cares of adding or subtracting fuel if the throttle if moved rapidly.
The underlying model is called X-Tau and takes into account
X, the amount of fuel clinging to the port walls, etc.,
and
Tau, the time it takes for the film to dissipate.
More details can be found here: http://www.megamanual.com/ms2/xtau.htm
The calculation is handled by two subprograms, in which an enormous amount of scaling takes place. The first one covers the scaling of TPS and rpm.
(https://i.ibb.co/wryBzxT/2230-accel-calc-rpm-tps-1.jpg) (https://ibb.co/wryBzxT)
(https://i.ibb.co/2ShzZ6Q/2230-accel-calc-rpm-tps-2.jpg) (https://ibb.co/2ShzZ6Q)
The 2nd sub handles the scaling of engine and air temperature. The cut-off rpm for acceleration/deceleration fuel change is 7000rpm.
(https://i.ibb.co/RH29jXm/2230-accel-calc-temp-1.jpg) (https://ibb.co/RH29jXm)
Next comes the code which handles TPS change speed and amount, based on comparisons between current and historical values.
(https://i.ibb.co/R61X0yN/2230-accel-calc-temp-tps-2.jpg) (https://ibb.co/R61X0yN)
Now the calculation of fuel_time values for the boundary -0,5°TPS > TPS change > 0,5°TPS. The -0.5/0.5° are the thresholds below which no fuel re-calc takes place.
(https://i.ibb.co/C9zW04j/2230-accel-calc-temp-tps-3.jpg) (https://ibb.co/C9zW04j)
The a final scaling and the result are fuel_accel_left- and fuel_accel_right values, which then are added to the fuel time values calculated in the previous code sections.
(https://i.ibb.co/C9Pt4cS/2230-accel-calc-temp-tps-4.jpg) (https://ibb.co/C9Pt4cS)
Cheers
Meinolf
-
While I don't pretend to understand this logic I can see some similarity to a crude Programmable Logic Controller.
I would be interested in seeing the section that deals with the low Voltage interlock i.e. the part that prevents the Start Relay from picking up.
What i the set point below which it will no longer pick up?
Could you perhaps explain this part of the logic as used on a Norge
Is it similar on the 2 Valve Griso?
Is it possible to make changes to the logic or is it cast in stone?
What is the software called that compiles this code?
-
Hi Roy,
as chance goes I've started to work on the code again. It's too cold and wet for driving for the time being.
I'll look for the respective code and post it. The software used to translate the high level language used for programming into a binary file is a compiler. The version depends on which CPU the binary is intended for. In the case of 5AM a Freescale CPU is used, the ST10-269.
Guzzi has 2 BIN streams for the CARC models. 2230 is used in all one lambda models, be it Griso, Norge, Breva,...
3220 is used in all two lambda models. The respective BIN streams differ only slightly, for example the value for speedo correction across the model range. The actual code in each stream is mostly identical. Not so when comparing the streams, the code is quite different.
Cheers
Meinolf
-
Hi Roy,
Is it possible to make changes to the logic or is it cast in stone?
fundamentally the actual code can be changed, but that's a hot iron. Beard and I tried this with the code of a 15M, but even a minor change screwed the timing up. At least the 15M needs all the processing power it has to function in real time operation, a single changed assembler instruction needing one or two more cycles meant mayhem.
Changing the parameters is safer, but still the consequences of a changed parameter are very difficult to predict or analyze.
Cheers
Meinolf
-
Hi Roy,
I would be interested in seeing the section that deals with the low Voltage interlock i.e. the part that prevents the Start Relay from picking up.
while the code dealing with the start relay is still unresearched, the following code snippet is checking the voltage while starter active/not active. And might be the one preventing the starter relay from engaging if the voltage is below 9V when pressing the starter button.
(https://i.ibb.co/0Z5340f/Low-voltage.jpg) (https://ibb.co/0Z5340f)
Cheers
Meinolf
-
The programming reminds me of "flow chart" I find it very interesting even though I don't understand it.
Decision blocks where the the input takes one of two paths out depending on the script (one input two outputs)
Action blocks that modify a signal or calculate (one input one output)
The blocks operate in sequence down the string then loop back to the top
I imagine there must be some strings that execute very fast whereas others like the Voltage one or discrete inputs could be quite slow to leave more time for the fast ones.
At least that's what we had to do with small Programmable Logic Controllers.
Perhaps when you make a change you need to re-order the blocks so that they operate in sequence properly otherwise it might be trying to execute
on one scan and have to wait for the next scan before it can carry on to the next instruction.
I'm not very good at putting thoughts into words and I was never very good at script language, ladder logic was more my speed.
I think its best not to have an electronic background if you work on computers otherwise you overthink it.
-
Hi,
I mentioned some time ago that the project team looking at the innards of the 5AM consists of 2. John, a proficient EE, found most of what we know today. And since December we are at it again, the weather is mostly to cold and wet for riding.
John's interest is based on furthering the development of Trikings using the 5AM and CARC engines.
(https://i.ibb.co/dL2XC07/John-Triking.jpg) (https://ibb.co/dL2XC07)
A giant step forward in understanding the details of the program code was the dissassembly of a 5AM. John managed to dig out the PCB, which is buried in sealant stuff.
(https://i.ibb.co/25CwjgQ/John-5-AM-naked.jpg) (https://ibb.co/25CwjgQ)
And actually reverse engineered the connections leading from the ECU pins to the ECU and the 2 ASCIs. I'm no EE and found this to be absolutely breath taking, the amount of knowledge and dedication is astounding.
(https://i.ibb.co/tM0VX1Y/John-5-AM-ASIC-2.jpg) (https://ibb.co/tM0VX1Y)
(https://i.ibb.co/sQNxXSR/John-5-AM-ASIC-1.jpg) (https://ibb.co/sQNxXSR)
He even drew up schematics of some of the circuits.
(https://i.ibb.co/YQP13fV/John-5-AM-schematics.jpg) (https://ibb.co/YQP13fV)
Cheers
Meinolf
-
Hi,
the last months were spent mostly working through the system programs (located below 0x4000h). These have the charme of being used almost unchanged across the all BINs and manufacturers, thus facilitating a smoother entry when looking at a new BIN.
And due to John's persistent and very analytic approach more and more of these low-level routines are understood. Only recently did it become clear that a sub I assumed to count down a time value really counted engine revs. Which neccessitated a re-work of all involved values and functions and conclusions based thereupon.
For relaxation I regularly re-visit already analyzed parts of the code and include the new findings. Last week the 11 engine run modes were the target, they are becoming much clearer now. The respective code has cross connections to other parts, for example the ignition timing calculation. There is one sub in the convoluted calc which wasn't understood so far.
After working through many factors such as temperature caused corrections, accel/decel influence, which engine run mode is currently active, there comes one sub in the convoluted calc which wasn't understood so far.
(https://i.ibb.co/LZN2tSM/2230-ignition-1.jpg) (https://ibb.co/LZN2tSM)
It's the branch at loc_1BC62. This uses the current ignition timing value and and then proceeds thru another branching dependent on CAN50_flag1_D8EA. This ones get's its value of a CAN50 packet, the meaning of which wasn't known.
As I don't have the disassembled and reverse engineered BIN of the dashboard, scenario playing was required. Almost all pins on the ECU, the dashboard and the ABS module are understood, but one remained so far. That's the line between dashboard pin29 and ABS modul pin12.
(https://i.ibb.co/25z8j2m/2230-ABS-Dash.jpg) (https://ibb.co/25z8j2m)
So, the idea was to go thru the code with the assumption that this line would contain the information about ABS being active or not and how the ignition timing would be influenced.
(https://i.ibb.co/z7JbkgF/2230-ABS-ignition-offset.jpg) (https://ibb.co/z7JbkgF)
First the branching to the left was looked at, ABS assumed to be active. The table at 494F6 contains ignition values, all being negative (-30=-1°). This table is indexed by table 494D6, which is indexed by data coming from the CAN50 package. The next step is towards loc_1BF52, where the negative ignition value is added, or rather subtracted, from the current ignition value. The result is a retardation of 1°.
Next the branching to the right, ABS not active, was followed. The threshold value at 4956 is negated and compared with table 494F6 values. The branching, using "if Table value > 49516", is always true with the values in the BIN, as -10 is bigger than -30. Consequently the branching jumps again to the right and eventually lands up with a 0 value being added to the current ignition value. So, no ignition change if ABS is not active.
If above criteria wouldn't be met, the left branch would be followed. Adding -30 (threshold value) to -10 (table value) and the resulting 4° would be subtracted from the current ignition timing.
Cheers
Meinolf
-
Hi,
further consultation with John brought to light that the CAN50_flag1_D8EA doesn't originate from the dashboard, but another device not fitted to CARCs bikes.
So, the scenario playing was only useful in confirming that the routine is not used in CARCs.
Cheers
Meinolf
-
The Stelvio has traction control could this be ignition retard mentioned above.
-
Hi,
The Stelvio has traction control could this be ignition retard mentioned above.
unfortunately it's not. The Stelvio (BIN 3222) has a routine with the similar structure and the same function. Disregard any ABS mentioned in the picture, I haven't updated the comments and names yet.
(https://i.ibb.co/DWjsSkp/3222-ABS-ignition-offset.jpg) (https://ibb.co/DWjsSkp)
However, the entry point to this routine is a branch condition at loc_1E90E, which checks the value at 4BC10, and this value being 0, bypasses the ignition retard function.
(https://i.ibb.co/GCxkK28/3222-ignition-1.jpg) (https://ibb.co/GCxkK28)
However, after further deliberation and cross-check with the BIN from an Aprilia Mana it turns out that the CANBus device probably is the TCU and the ignition retardation occurs when using the manual gear change buttons (The Mana has automatic gear box). The ignition retard of 30° fits to the purpose.
While the traction control flag has been found, I haven't followed this thru and looked for the routines involved in the traction control.
Cheers
Meinolf
-
Hi,
some more tidbits which you might find interesting.
Several of the ECU pins are active, even though the ECU plug doesn't have live plugs and cables connecting them to the wire loom. There's also live code supporting the respective PINs. All below are ECU plug B/V (blue).
PIN 9, output. Supplies a engine rev signal. 2 pulses every 720° crankshaft. This can be used to connect a rev counter. Either a digital one for counting engine revolutions or a regular one to show engine revs.
PIN 13, output. Other makes use this output for a relais to activate a fan. Not really neccessary with CARCs, but can be used by gadget-lovers to drive an engine temperature activated aLED, for example, to indicate engine temperatur status. The engine temp upper and lower thresholds are user configurable.
PIN 23, input. Other makes use this as input for brake switches or the signal from an analogue fuel level sensor. The incoming signal is reflected in a CANBus paket, this could be used for data-logging via CANBus or OBD to capture an additional input.
For those who are interested, here are links to revised wiring diagrams.
Norge 1200 2V: https://drive.google.com/open?id=1j4pE71vCgqv6HCUBSJLBMeulRcd3vnT9
Norge 1200 8V: https://drive.google.com/open?id=18aA3VwTYLwZXGsqg9Jc1rah6FfCN2mEe
Cheers
Meinolf
-
This is an outstanding thread!
I will read the complete thread with great interest, thanks to those who took the time to post
-
This is the 2nd time, I've read this complete thread, but it's the first time I've read it owning ECU bikes and having dabbled a little bit with guzzidiag and fuel maps etc.
I still don't understand most of it, lol, but I now have a much greater appreciation for just how valuable this work is to us guzzi owners. :thumb:
Meinolf, I realize that there have been many contributors and collaborators to get to this point, but time, energy, focus and head space are all finite resources, thank you very much for being so generous in your efforts to help us modern guzzi owners. :bow:
Much gratitude and respect
Kelly