Wildguzzi.com
General Category => General Discussion => Topic started by: Meinolf on June 06, 2021, 12:28:08 AM
-
Hi,
recently some question about the MIU G3 as used in the V7 III were asked in the German Guzzi forum. So, another deep dive into a BIN was taken, disassembling and reverse engineering the code as done previously for the 5AM BINs.
The result is this V7III XDF https://drive.google.com/file/d/1tt02RMq80C2hMfRFN2WDMZ8aAlMgoAup/view?usp=sharing
<Edit> Responding to questions further down the thread a XDF for the V9 was written. The addresses are based on the CM275401 / 46040VC29 BIN with HW311.
The result is this V9 XDF https://drive.google.com/file/d/1jKjloifm4S9aAEIvOKR2E6ZfgYg7u4Id/view?usp=sharing
The code of the V7III and V9 is very similar. Without having done a deep analysis of either BIN the differences are mainly sligthly shifted addresses.
Cheers
Meinolf
-
:thumb:
-
Awesome work.. :thumb:
-
Is there a newer one for the V9? Seems like there is more data there that hasn’t been figured out yet.
-
Hi,
Is there a newer one for the V9? Seems like there is more data there that hasn’t been figured out yet.
which BIN are you refering to? The exact name or numbering, please.
Cheers
Meinolf
-
I’m referring to the current xdf for the V9: MIUG3_V9_464DVCAO_V 1.09 and the stock bin. Using GuzziDiag returns several values as unknown. So I’m wondering if there is more to be discovered that may be of use to us. I’m just trying to understand it all relating to my own bike and maybe contribute to the group knowledge base. It seems asking fueling related questions on another forum is taboo. Using Tunerpro and your newer xdf for the V7III and comparing to the V9 xdf and my bin, it looks like the V9 is less developed at this time. I’d also be curious to know if MG has issued newer V9 bins than my 2017 version and what improvements it addressed. Being that the V9 and V7III use the same ECU and are similar engines I wonder what can be extrapolated from one map to the other.
-
Hi,
And the stock BIN number is? I'll take a look and will update the xdf.
Cheers
Meinolf
-
Hi,
And the stock BIN number is? I'll take a look and will update the xdf.
Cheers
Meinolf
Where is that found?
Here is what GuzziDiag reports:
GuzziDiag V0.50 2020.12.09 13:40
V9 Roamer IAW MIUG3
CM275401
38M3G3HW311
464DVCAO
F01
130950203
2020.04.28
Tunerpro says the software date is June 7, 2017.
I can send you the original bin if that helps. When I saved it originally I just named it “stock V9.bin” as I didn’t know it’s original name.
-
Something I was thinking about (I’ve been told I think too much) is that on USA models the CO adjustment is blocked. I wonder if there is a data byte in the .bin that would toggle it on thus giving us another avenue of adjustment. I’d like to compare a European version to a US version. Anyone have a Euro V7III or V9 factory .bin they would send me?
-
Something I was thinking about (I’ve been told I think too much) is that on USA models the CO adjustment is blocked. I wonder if there is a data byte in the .bin that would toggle it on thus giving us another avenue of adjustment. I’d like to compare a European version to a US version. Anyone have a Euro V7III or V9 factory .bin they would send me?
Here is a bin of a V7III Euro Factory : https://1drv.ms/u/s!AuqxioVGI9b-hvg3tVpX8dBwkfS47A?e=Taipnq
(https://lh3.googleusercontent.com/pw/ACtC-3euqsLolE4bKmW0RJpuvVrs1mDCmenKTPL6iDluxNJotyvkEIbI7a-7TQEmoMM4cQ2QxVcGAtceVgohV0aHuA5y15hpaad2UvrLDBWvDXTvIpSZyi0gchIx5DZvjLrPJzw6tkO4VnZFQWe_X_7hRw138Q=w383-h308-no?authuser=0)
-
Here is a bin of a V7III Euro Factory : https://1drv.ms/u/s!AuqxioVGI9b-hvg3tVpX8dBwkfS47A?e=Taipnq
(https://lh3.googleusercontent.com/pw/ACtC-3euqsLolE4bKmW0RJpuvVrs1mDCmenKTPL6iDluxNJotyvkEIbI7a-7TQEmoMM4cQ2QxVcGAtceVgohV0aHuA5y15hpaad2UvrLDBWvDXTvIpSZyi0gchIx5DZvjLrPJzw6tkO4VnZFQWe_X_7hRw138Q=w383-h308-no?authuser=0)
Thanks, Chrisfer. It appears identical to the V7III bin I have. Now I’m not sure the bin I have is a USA version as I expected to see differences. I downloaded it from somewhere last year for research purposes and can’t remember the source. I do know the V9 version I have is a USA version as it’s from my bike so I still need to find a Euro version .bin of it.
-
Thanks, Chrisfer. It appears identical to the V7III bin I have. Now I’m not sure the bin I have is a USA version as I expected to see differences. I downloaded it from somewhere last year for research purposes and can’t remember the source. I do know the V9 version I have is a USA version as it’s from my bike so I still need to find a Euro version .bin of it.
Here is a V9 Euro : https://1drv.ms/u/s!AuqxioVGI9b-iZBaQRJSqFXUoRhnMQ?e=lIuOga
-
Hi,
V9 Roamer IAW MIUG3
CM275401
38M3G3HW311
464DVCAO
F01
130950203
2020.04.28
I've written a XDF for another version (see first post in this thread), the differences are slight and I will provide an updated XDF for this version later.
Cheers
Meinolf
-
Hi,
Something I was thinking about (I’ve been told I think too much) is that on USA models the CO adjustment is blocked. I wonder if there is a data byte in the .bin that would toggle it on thus giving us another avenue of adjustment. I’d like to compare a European version to a US version. Anyone have a Euro V7III or V9 factory .bin they would send me?
by now I've looked into several Guzzi, BMW (MBC1 ECU) and Aprilia BINs for the MIUG3. I haven't found any CO trim function in the code of any of the BINs. But, I haven't really researched if there are different BINs for different regions. If there were, the typical approach would be to skip/enable CO trim functions by setting flags and not by changing the program code proper.
This is part of the fuel calc routine. The CO trim code would be right after the warm-up section. But it isn't...
(https://i.ibb.co/YTK57qS/V9-no-CO-trim.jpg) (https://ibb.co/YTK57qS)
Cheers
Meinolf
-
Here is a V9 Euro : https://1drv.ms/u/s!AuqxioVGI9b-iZBaQRJSqFXUoRhnMQ?e=lIuOga
Thanks, Chrisfer.
Comparing mine and yours the conclusion is there are no regional differences in .bins, at least Euro and American. They are identical. I had expected differences. Interesting.
-
Hi,
I've written a XDF for another version (see first post in this thread), the differences are slight and I will provide an updated XDF for this version later.
Cheers
Meinolf
Thanks, Meinolf.
-
The MIU G3 does not have a CO trim adjustment option.
-
The MIU G3 does not have a CO trim adjustment option.
Thank you. Apparently I’ve been misinformed.
-
Hi,
some more time spent analyzing the code provided more insights. Let's take a closer look at the fuel calculation.
The routine calculating the fuel values is called in several other subprograms.
(https://i.ibb.co/N3rz75R/V7-fuel-1.png) (https://ibb.co/N3rz75R)
Let's look at the fuel calculation while in idle mode first. Right at the top there's a user-changeable flag to skip idle fuel calculation. The default is to do the calc. The next branch is TPS state. If closed then we proceed to IdleFuel_Table_C7D7 7A. Which is indexed by a RPM-legend derived from the current rpm and a Idle valve steps index.
(https://i.ibb.co/88L0YS5/V7-fuel-3.png) (https://ibb.co/88L0YS5)
After consulting the main idle fuel table (for the left cylinder) a branch leads to the delta idle fuel table for the right cylinder. In case the right cylinder is currently active the main and delta fuel table values are added. Or subtracted if the delta value is negative.
This concludes the idle fuel calc.
(https://i.ibb.co/qg2bp2W/V7-fuel-2.png) (https://ibb.co/qg2bp2W)
Cheers
Meinolf
-
Hi,
going back to the start, let's look at what happens if idle mode is enabled and the TPS is not closed. Which includes any TPS state above the threshold of being closed. Which is a learned value. Anyway, the branch leads to a user-changeable flag to disable delta (right cylinder) fuel calculation. The default is to calculate both left and right cylinder values.
(https://i.ibb.co/PtsScSD/V7-fuel-5.png) (https://ibb.co/PtsScSD)
The next branch depends on the current cylinder being looked at. The program proceeds to the MainFuel_LeftCyl_Ta ble, another branch depending on the current engine temp being above or below 60°C is not used. If it were used, the left and right fuel table would be used as the sole source for fuel values depending on the engine temperature.
(https://i.ibb.co/mt2PBNh/V7-fuel-4.png) (https://ibb.co/mt2PBNh)
At this point either the fuel value for idle or non-idle mode have been retrieved from the respective tables. No the water gets muddy. Several flags, both user-changeable and calculated in the code, determine if values from Fuel_Table_C7DFBA are added. The rev_below_limit_fla g_9103, flag_9104 and flag_910C have escaped my understanding until now, so it's unclear if and when the adder is used.
(https://i.ibb.co/JvfBTRj/V7-fuel-6.png) (https://ibb.co/JvfBTRj)
Then the going get's easier again. Next the lambda flags and Skip_STFT_scaling_f lag_C7C7FD are taken under consideration. If either is clear (default is set), the entire closed loop scaling process is circumvented. Then a scaling process is set up, using the last current fuel values. And now the closed loop begins massaging the fuel calc. Here the short term fuel trim (STFT), which is calculated in a separate routine, is applied as a scaled factor to the fuel values.
(https://i.ibb.co/6mRQb6y/V7-fuel-7.png) (https://ibb.co/6mRQb6y)
At this point the air temperature and air pressure influences are looked at. Both change the air mass per volume, so they influence the AFR. Rather straightforward, factors are calculated and applied to the fuel values.
(https://i.ibb.co/BffFXXS/V7-fuel-8.png) (https://ibb.co/BffFXXS)
Then the warm up mode is considered. Which has several possible states:
values used
0: engine stopped
1: pre-crank (if engine run mode 1 or 2)
2: warm-up (if engine run mode 2)
4: warm-up, if curr rpm > 750 or rpm < 750 and delay revs passed
8: warm-up passed, normal run (if engine run mode 6, 7 or 9)
Basically the revs since engine start are counted down and act as index for a table in which factors applied to the fuel values a stored. Lastly the resulting values are compared a max. value of 62500.
(https://i.ibb.co/DpfwNLR/V7-fuel-9.png) (https://ibb.co/DpfwNLR)
And last but not least several more branching decisions are due, depending on the engine run modes, of which there are 11.
0: engine stopped
1: start requested / pre-crank, already turning
if power_state = 4
2: during warmup / if throttle closed
or throttle closed and curr rpm > target_idle_rpm + RPM_Word + RPM_Word
or mode_2_6_chg_flag = 1
or mode_2_6_chg_flag = 0 and TPS closed
or mode_2_6_chg_flag = 0 and curr rpm < target_idle_speed + RPM_Word
3: during warmup / if TPS in between and no accel/decel and curr rpm >= target_idle + RPM_Word (non-idle fuel mode)
4: during warmup / if accelerating
5: during warmup / throttle closed and curr rpm <= target_idle + RPM_Word (idle fuel mode)
6: after warmup / throttle open (main tables)
or throttle closed and curr rpm < target idle + RPM_Word (idle fuel mode)
or throttle closed and curr rpm > target_idle + RPM_Word + RPM_Word
or mode_2_6_chg_flag = 1 (still unclear when set)
or if rev passed > rev_Table_
7: after warmup / if throttle open and curr rpm < target_idle + RPM_Word (idle fuel mode)
8: after warmup / throttle in between and accel (main fuel tables, non-idle fuel mode)
9: after warmup / throttle closed and curr rpm < target idle + RPM_Word
if throttle WOT
or throttle in between and accel/decel and curr rpm > target_idle + RPM_Word
10: after warmup / engine turning
if mode_10_11_chg_word = 1 or 2
11: engine stopped, start for run mode selection?
if mode_10_11_chg_word = 2
or power_state <> 4
or if rev passed < rev_Table
Simply put, modes 10 and 11 are engine braking modes. The respective routines calculate different fuel values. And finally, voila, the fuel values for both cylinders are there.
(https://i.ibb.co/brB7P6J/V7-fuel-10.png) (https://ibb.co/brB7P6J)
And are used in another sub, which inputs the changes from acceleration/deceleration modes and leads to the calculation of the injector pulse width.
(https://i.ibb.co/R6LfVpZ/V7-fuel-11.png) (https://ibb.co/R6LfVpZ)
Cheers
Meinolf
-
So, in no more than a three or four sentences, what does this all mean?
-
Thanks, Meinolf. This is fascinating. I appreciate all your research.
A couple of questions if I may: Where do the traction control modes figure into this? If I want to make any small changes to fueling (assuming I have the lambdas turned off) would it be best to make those changes in the right and left cylinder main fuel tables and leave everything else alone or divide the changes up across other tables?
-
Hi,
So, in no more than a three or four sentences, what does this all mean?
lot's of interesting stuff going on inside the ECU....
Sorry, my description of the fuel calc part is already very much simplified.
Cheers
Meinolf
-
Hi,
Where do the traction control modes figure into this?
What do you mean by traction control modes. I have not extensively researched the different models using the MIUG3, but haven't found any mention of traction control modes in the user manual or the wiring diagram. On other models any traction control is activated by discrete switches connected to the dashboard, which then sends this as part of a CANBus message to the ECU. I've identified the CANBus sections and packet IDs in the code, but having no log of the stuff being sent on the CANBus makes it very difficult to understand the content and meaning.
If I want to make any small changes to fueling (assuming I have the lambdas turned off) would it be best to make those changes in the right and left cylinder main fuel tables and leave everything else alone or divide the changes up across other tables?
My experience is that the lowest hanging fruit for improving engine performance (not neccessarily torque/power) is to check and correct, if so required, the synchronization of AFR/Lambda between the cylinders. My experience after logging Lambda, rpm, TPS, etc on a V11, a Jackal and a Norge over more than 40.000km is that the fuel values are not optimized for this. Setting this right will result in 90% of the achievable improvement, anything else really is just cream on top. Nice to have, but not essential.
Changing any of the trim and scaling scalars or tables generally not a good idea. In the past I've found that Marelli uses airtemp/pressure correction values in the respective tables of the 15M/RC and 5AM which are wrong. They differ from the values dictated by the general gas equation pV=mRT, I created a spreadsheet several years ago to calculate the correct values and used this in my BINs.
Turning off the closed loop operation is not really a good idea unless you a willing to deep dive into this topic. The engines are designed to work well at Lambda 1.0 and the resulting fuel and ignition values are closely intertwined. Changing Lambda absolutely requires corresponding changes in ignition values.
On a different note, you are an E.E.? Have you taken a closer look at the MIUG3? Understanding how the I/O pins of the ECU are internally connected to the CPU and ASICs and stuff would be very helpful, in fact it's a prequisite, to make further progress.
Cheers
Meinolf
-
Hi,
What do you mean by traction control modes. I have not extensively researched the different models using the MIUG3, but haven't found any mention of traction control modes in the user manual or the wiring diagram. On other models any traction control is activated by discrete switches connected to the dashboard, which then sends this as part of a CANBus message to the ECU. I've identified the CANBus sections and packet IDs in the code, but having no log of the stuff being sent on the CANBus makes it very difficult to understand the content and meaning.
My experience is that the lowest hanging fruit for improving engine performance (not neccessarily torque/power) is to check and correct, if so required, the synchronization of AFR/Lambda between the cylinders. My experience after logging Lambda, rpm, TPS, etc on a V11, a Jackal and a Norge over more than 40.000km is that the fuel values are not optimized for this. Setting this right will result in 90% of the achievable improvement, anything else really is just cream on top. Nice to have, but not essential.
Changing any of the trim and scaling scalars or tables generally not a good idea. In the past I've found that Marelli uses airtemp/pressure correction values in the respective tables of the 15M/RC and 5AM which are wrong. They differ from the values dictated by the general gas equation pV=mRT, I created a spreadsheet several years ago to calculate the correct values and used this in my BINs.
Turning off the closed loop operation is not really a good idea unless you a willing to deep dive into this topic. The engines are designed to work well at Lambda 1.0 and the resulting fuel and ignition values are closely intertwined. Changing Lambda absolutely requires corresponding changes in ignition values.
On a different note, you are an E.E.? Have you taken a closer look at the MIUG3? Understanding how the I/O pins of the ECU are internally connected to the CPU and ASICs and stuff would be very helpful, in fact it's a prequisite, to make further progress.
Cheers
Meinolf
My V9 has the MGTC system(Moto Guzzi Controllo Trazione). It reduces acceleration if it detects wheel slippage - for instance - if you accelerate in the rain and lose traction it reduces your acceleration to compensate. My thought is either the CPU has to back off the fueling or spark timing to compensate or the ABS is applying slight braking. If you see nothing in the programming then perhaps the latter applies.
I have not found any literature beyond the brief MIUG3 tutorial linked here in other threads. Searching the internet yields little beyond linking Magnetti-Marelli’s home page. I have hesitated to actually open mine up to ID the chips and do any circuit tracing. Maybe I should start there.
My impetus for delving into this in the beginning was after trying a popular map to get rid of the herky-jerky nature of the V9 at slow steady speeds. The map did cure that wonderfully but also introduced more vibration and an unsteady (kind of lumpy) idle. When opening the throttle it immediately accelerates without bogging down (that’s good) so my impression is it may be a tad rich rather than too lean at idle. On examining the map I see the O2 sensors are turned off which makes sense because they would negate any changes to the fueling. However no corresponding changes in ignition timing were made. What has piqued my curiosity most is the fact that this map was made last year when the current XDF has the right and left cylinders incorrectly labeled as warm and cold. That misconception may have influenced some of the changes I see in the map as far as unbalanced right and left fueling that may be the source of the vibration. Another related issue is in the change to reduce overrun popping. On one cylinder at minimum throttle the fueling is reduced to zero at minimum throttle and the other it is only slightly reduced. My OCD says fueling in both cylinders need to be equal at that stage. Another change that caught my attention is the Pressure-Air Temp Correction table. The values are nearly negated over what Marelli thinks they should be so it looks like almost no temperature/air pressure compensation. I seem to be running rich at higher elevations.
-
Turning off the closed loop operation is not really a good idea unless you a willing to deep dive into this topic. The engines are designed to work well at Lambda 1.0 and the resulting fuel and ignition values are closely intertwined. Changing Lambda absolutely requires corresponding changes in ignition values.
Cheers
Meinolf
Since part of the time at RPMs below 4k it is operating open loop ie not at a steady cruise, wouldn't it be a safe assumption that the open loop base map is reasonably safe if the O2 sensors were turned off. There have been a few mentions in other threads where just turning them off resulted in smoother operation or elimination of snatchiness. Assuming, of course, a basically stock bike with stock exhaust not needing a substantially richer mapping change.
-
Fascinating stuff. Thanks for sharing all your hard work.
Here’s a dumb question. I have a 2013 V7 Stone. I foolishly left my mufflers out in the rain for a month while working on my clutch. When I put everything back together, I now have a constant check engine light, which has persisted for 35,000 miles now. I’m convinced it is due to failed/rusty lambda sensors, but haven’t confirmed it.
Here’s the deal though. The bike runs just fine. I get the exact same gas mileage. It starts fine cold or hot. The only difference is that about 10 seconds after a cold start, it obviously gets too lean and won’t idle well unless I rev it to 1500 rpm or more and let it warm up a minute or so. When warmed up it idles fine.
Is this the behavior you would expect give this stock fuel mapping and a presumed failure of the lambda sensors?
I probably need to get a Bettle map but just haven’t gotten around to it.
If this is somehow horrible for my engine please let me know.
-
Hi,
My V9 has the MGTC system(Moto Guzzi Controllo Trazione). It reduces acceleration if it detects wheel slippage - for instance - if you accelerate in the rain and lose traction it reduces your acceleration to compensate. My thought is either the CPU has to back off the fueling or spark timing to compensate or the ABS is applying slight braking. If you see nothing in the programming then perhaps the latter applies.
Thanks, following this up I did find some basic explanation MGCT. I'll keep my eyes open when browsing the code. As MGCT seems to be using the speed wheel sensors and the delta between the speeds as slip indication it's very likely that this is send to the ECU over the CANBus. BUt, without having log data of what is sent on the CANBus it will be challenging to find the details.
The speed wheel sensors are connected to the ABS modul, not the ECU. I can't imagine that ABS is used for this purpose, ignition retardation is more likely.
On examining the map I see the O2 sensors are turned off which makes sense because they would negate any changes to the fueling
My experience is that the fuel tables are on the rich side, which serves as a precaution in case the O2 sensors fail. Rather a to rich than a to lean mixture. The closed loop operation is only active in a small range. TPS below ~25°, rpm < 4000, temperature thresholds are met, no acceleration/deceleration.
...when the current XDF has the right and left cylinders incorrectly labeled as warm and cold
There's a user changeable flag which can dedicate the two main fuel to act as cold/warm main fuel tables. As, however, a multi-cylinder engine always requires different fuel values for each cylinder this arrangement would only make sense on a single cylinder engine. As it turns out the code base used in the MIUG3 is very similar to the MBC1 ECU used in a number of BMWs. Some of which, I believe, are single cylinder engines.
However no corresponding changes in ignition timing were made.
Searching for "afr flame propagation" will lead towards many sources explaining the effect the mixture has on which ignition retardation is required. On a typical street engine the highest combustion chamber should occur ~12-15° after TDC. Leaning, or enrichening, the mixture delays the initial flame propagation by up to ~+/-20°, which could either lead to a to high pressure while the pistons are still on their way up to TDC or wasted power/fuel if the max. pressure occurs when the piston is already traveling downwards.
...I have hesitated to actually open mine up to ID the chips and do any circuit tracing. Maybe I should start there.
If you have the time and experience to trace the circuits then understanding more of the details would be easier. Certainly the mastermind behind the analysis of the 5AM, John, which is an experienced E.E. from the UK, drew numerous conclusions from dissecting, identifying the active and passive components and circuit tracing.
I wouldn't use a working ECU, though. Maybe someone can sponsor this with a defective ECU.
Cheers
Meinolf
-
Fascinating stuff. Thanks for sharing all your hard work.
Here’s a dumb question. I have a 2013 V7 Stone. I foolishly left my mufflers out in the rain for a month while working on my clutch. When I put everything back together, I now have a constant check engine light, which has persisted for 35,000 miles now. I’m convinced it is due to failed/rusty lambda sensors, but haven’t confirmed it.
Here’s the deal though. The bike runs just fine. I get the exact same gas mileage. It starts fine cold or hot. The only difference is that about 10 seconds after a cold start, it obviously gets too lean and won’t idle well unless I rev it to 1500 rpm or more and let it warm up a minute or so. When warmed up it idles fine.
Is this the behavior you would expect give this stock fuel mapping and a presumed failure of the lambda sensors?
I probably need to get a Bettle map but just haven’t gotten around to it.
If this is somehow horrible for my engine please let me know.
You should check the DTC's (error codes). Keep in mind that the ECU doesn't go into closed loop mode (lambda fuel trims active) until the engine & intake temperatures meet a predetermined value (typically 55 degrees C for the engine).
Since part of the time at RPMs below 4k it is operating open loop ie not at a steady cruise, wouldn't it be a safe assumption that the open loop base map is reasonably safe if the O2 sensors were turned off. There have been a few mentions in other threads where just turning them off resulted in smoother operation or elimination of snatchiness. Assuming, of course, a basically stock bike with stock exhaust not needing a substantially richer mapping change. I want to try it on mine.
In open loop mode, the base map is usually slightly rich (for the stock exhaust). Deactivating lambda (and resetting the fuel trims) with a stock bike will typically result in a slightly rich running bike. It certainly won't cause any harm, but fuel consumption will be noticeably higher. Acceleration may seem more tardy.
-
Quote from: Meinolf on June 06, 2021, 12:28:08 AM (https://wildguzzi.com/forum/index.php?topic=110952.msg1760167#msg1760167)Hi,
recently some question about the MIU G3 as used in the V7 III were asked in the German Guzzi forum. So, another deep dive into a BIN was taken, disassembling and reverse engineering the code as done previously for the 5AM BINs.
The result is this V7III XDF
https://drive.google.com/file/d/1tt02RMq80C2hMfRFN2WDMZ8aAlMgoAup/view?usp=sharing (https://drive.google.com/file/d/1tt02RMq80C2hMfRFN2WDMZ8aAlMgoAup/view?usp=sharing)
<Edit> Responding to questions further down the thread a XDF for the V9 was written. The addresses are based on the CM275401 / 46040VC29 BIN with HW311.
The result is this V9 XDF https://drive.google.com/file/d/1jKjloifm4S9aAEIvOKR2E6ZfgYg7u4Id/view?usp=sharing (https://drive.google.com/file/d/1jKjloifm4S9aAEIvOKR2E6ZfgYg7u4Id/view?usp=sharing)
The code of the V7III and V9 is very similar. Without having done a deep analysis of either BIN the differences are mainly sligthly shifted addresses.
Cheers
Meinolf
My V9’s bin requires the 464D version xdf which shifts a few addresses. I’ve changed them in your xdf so I can read mine. The only slot I couldn’t verify is 76F95 ISO Code as I didn’t know what I should see there. It’s at https://www.dropbox.com/sh/ad6lmx6pikb51bw/AAAeoe2wwYtlAkKANCeM557ja?dl=0 (https://www.dropbox.com/sh/ad6lmx6pikb51bw/AAAeoe2wwYtlAkKANCeM557ja?dl=0) if anyone wants to try it.
-
Hi,
There's a user changeable flag which can dedicate the two main fuel to act as cold/warm main fuel tables. As, however, a multi-cylinder engine always requires different fuel values for each cylinder this arrangement would only make sense on a single cylinder engine. As it turns out the code base used in the MIUG3 is very similar to the MBC1 ECU used in a number of BMWs. Some of which, I believe, are single cylinder engines.
Cheers
Meinolf
It’s interesting that the MIUG3 can be configured different ways. Can you clarify if, as used on our V7/9’s, the warm and cold tables are in fact configured as left and right? Thanks.
-
Hi,
It’s interesting that the MIUG3 can be configured different ways. Can you clarify if, as used on our V7/9’s, the warm and cold tables are in fact configured as left and right? Thanks.
maybe this wasn't so obvious in the screenshots in a previous post. The main fuel tables are used for left and right cylinder, not for cold/warm use.
The first branch is set by Use_left_main_fuel_ flag_C7CD58, which is 1, hence the program flows directly to the MainFuel_LeftCyl_Ta ble_C7CD5A if the left cylinder is the currently active one (from a program point of view, the code supports up to 6 cylinders and a max. rpm of 20.000).
If this flag would be changed to 0, the flow would proceed to the next branch, Engtemp_above_thres hold_flag_8AFD. This would lead to using the MainFuel_RightCyl_T able_C7D25A values for both cylinders as long the engine temperaure is >60°C. Or to using the MainFuel_LeftCyl_Ta ble_C7CD5A values for the left cylinder if engine temperature is <=60°.
(https://i.ibb.co/HrM39K1/V7-fuel-7-main-tables.png) (https://ibb.co/HrM39K1)
HOWEVER..... Changing the flag at C7CD58 from 1 to 0 would necessitate a MAJOR rework of the entire code, as so many flags and scaling operations would be concerned. So, try this only if you lost one of your cylinders.
But, joke aside, I can't imagine any reason why one would use the warm/cold scenario on a multi-cylinder engine. And even a single engine wouldn't require it as all relevant ambient factors like air/engtemperature, baro pressure and the like are taken care of by the numerous scaling and triming ops.
Cheers
Meinolf
PS I guess I fell into the trap of assuming that everybody understands the logic of program flow and the colors used for the connecting lines between the boxes. Three colors are used. Blue if there's no conditional branch involved. Green if a conditional branch is answered positively, for example is 1=1, the program flow then would be using the green line. Or the opposite, then the red line is used.
-
Thanks, Meinolf. It’s becoming clearer.
Back when I was involved in machine level and assembly language code we only had green screens and dot matrix printers. Lol.
-
Hi,
I know what you mean. My first and only formal contact with programming, a language called APL, was more than 40 years ago while I was studying mechanical engineering. C64 was the leading edge home computer at that time and I wrote my thesis with Vizawrite on it.
But, you live and learn. Natural curiosity, sufficient time and the generous and patient support of Beard (the Guzzidiag programmer) and John, an EE from the UK, helped in understanding assembler. Well, the understanding is very limited, but being one eyed amongst the blind is ok.
I do wonder where all the computer whizz kids are. Certainly not in the Guzzi or Ducati or Aprilia or Morelli community. Except for Beard and John I have yet to meet anybody having a clue about assembler.
Cheers
Meinolf
-
There is one table for Idle at 0x7D77A, how is the right and left distribution adjusted?
-
Changing any of the trim and scaling scalars or tables generally not a good idea. In the past I've found that Marelli uses airtemp/pressure correction values in the respective tables of the 15M/RC and 5AM which are wrong. They differ from the values dictated by the general gas equation pV=mRT, I created a spreadsheet several years ago to calculate the correct values and used this in my BINs.
Cheers
Meinolf
You mention that you had found wrong values in the air temp/pressure correction tables. Just for grins I looked at my V9 table and using the 1976 Standard Atmosphere Calculations I came up with slightly different values. I only checked two axis’, sea level at all temps and the standard reference temp at all altitudes (in millibars). My values are in red.
(https://i.ibb.co/rZTfvMw/A6-E72-A47-678-B-4784-B33-F-35-EE229-B198-C.png) (https://ibb.co/rZTfvMw)
Is this along the lines of what you found or am I way off base? Is it significant enough to change?
Thanks.
-
Hi Chris,
There is one table for Idle at 0x7D77A, how is the right and left distribution adjusted?
the idle fuel calc uses, same as main fuel, two tables. The one at 0x7D77A is for the left cylinder, the values for the right cylinder are calculated using a delta table at /D97A and adding/subtracting these values.
mov r12, r8 ; IdleFuel value left
mov r13, r4 ; IdleFuel delta value right
calls 0C3h, add_unsigned_R12_R1 3_sub_C30014 ; here the 2 values are added, or subtracted in case the delta value is negative
mov r8, r4 ; IdleFuel value right
(https://i.ibb.co/cYqwM2R/V7-idle-fuel.png) (https://ibb.co/cYqwM2R)
Cheers
Meinolf
-
Hi,
Is this along the lines of what you found or am I way off base?
yes, this is along the lines of what I found in BINs from Guzzi, Ducati, Aprilia and Mana. Several years ago I built a spreadsheet to calculate the correct trims. The values here are from a Aprilia Mana because that's the file i found first :-)
(https://i.ibb.co/5Gfj5pq/Air-p-T-table.png) (https://ibb.co/5Gfj5pq)
Is it significant enough to change?
Well, the deviations are not really large enough to justify it. But, why accept wrong trims if a correction is easily done. And if the re-calc is started from the 1.0 value (green colored cells in the screenshot), then the values in the fuel tables can be left as they are.
When first looking into this I wondered if the deviations of the trim table values from the general gas equation were not accidential (I find it hard to believe that the programmers at Marelli don't know the physics) but reflected other influences. The only ones which came to mind were the fuel density, which is also changing corresponding with temperature and the fuel pressure regulator being fed by atmospheric and not by manifold pressure, which in turn influences the total pressure delta and hence the fuel pressure.
However, the trim table deviations are to erratic to achieve this purpose.
Cheers
Meinolf
-
Hi Chris,
the idle fuel calc uses, same as main fuel, two tables. The one at 0x7D77A is for the left cylinder, the values for the right cylinder are calculated using a delta table at /D97A and adding/subtracting these values.
mov r12, r8 ; IdleFuel value left
mov r13, r4 ; IdleFuel delta value right
calls 0C3h, add_unsigned_R12_R1 3_sub_C30014 ; here the 2 values are added, or subtracted in case the delta value is negative
mov r8, r4 ; IdleFuel value right
(https://i.ibb.co/cYqwM2R/V7-idle-fuel.png) (https://ibb.co/cYqwM2R)
Cheers
Meinolf
Thank you very much :thumb:
I have add it to my V7 III XDF : https://1drv.ms/u/s!AuqxioVGI9b-iaU27CSFM4KGwAFKsA?e=ZesCF7
-
Thank you, Meinolf. :bow: :bow:
-
Hi,
... and using the 1976 Standard Atmosphere Calculations I came up with slightly different values.
at 1st glance I wasn't familiar with 1976 Standard Atmosphere Calculations, so I looked it up. This is not the base for the density change calculations, rather it's the shortened general gas equation pV=mRT. Which is being used in the spreadsheet mentioned above.
Here's a link to the spreadsheet, I hope it's self-explanatory. https://drive.google.com/file/d/1DOKKyUSbvLCOmPANT561f0rEtf-UE5HW/view?usp=sharing
Paste the existing values into the upper left cell area, and the corrected values are in the two cell areas below. The bottom one has hex-values for direct C&P into Tunerpro.
Cheers
Meinolf
-
Here is what I get with values from my Roamer and adjusting labels for the differences of temperature and pressure points with the MIUG3. It looks like a lot of areas would run richer using those calculations. I'm curious about your using 990mb @ 20C (green) as a base. Is that a Guzzi thing? I would have expected to see 1013mb (sea level) @ 15C which is the standard for calculations I'm familiar with. I'm still learning, though.
(https://i.ibb.co/FsBJCQ2/roamer.png) (https://ibb.co/FsBJCQ2)
-
Hi,
Here is what I get with values from my Roamer and adjusting labels for the differences of temperature and pressure points with the MIUG3. It looks like a lot of areas would run richer using those calculations. I'm curious about your using 990mb @ 20C (green) as a base. Is that a Guzzi thing?
I selected the base point where the trim factor was 1.00, as calculating the corrected trims from this starting point avoided the neccessity to re-calculate (shift) the fuel values. If the spreadsheet is used the factor 1.00 being in a different cell, the cell formulas have to be adapted. Did you do so?
Is that a Guzzi thing? I would have expected to see 1013mb (sea level) @ 15C which is the standard for calculations I'm familiar with.
The standard conditions vary between applications and over time. During my studies the standard condition used was 295,15K and 1013mBar. At the end of the day it doesn't matter which base point is used. The mass change over temperature and pressure is linear.
If the equation is reduced by using an equivalent term without the constants V and R the formula boils down to m⇔p/T - which in laymens terms means m⇔p/1 if the temperature is constant and m⇔1/T is constant.
https://en.wikipedia.org/wiki/Standard_conditions_for_temperature_and_pressure
Cheers
Meinolf
-
Here is what I get with values from my Roamer and adjusting labels for the differences of temperature and pressure points with the MIUG3. It looks like a lot of areas would run richer using those calculations. I'm curious about your using 990mb @ 20C (green) as a base. Is that a Guzzi thing? I would have expected to see 1013mb (sea level) @ 15C which is the standard for calculations I'm familiar with. I'm still learning, though.
(https://i.ibb.co/FsBJCQ2/roamer.png) (https://ibb.co/FsBJCQ2)
The MIU G3 outdoor temperature sensor, Air Intake Temperature, is on the electronic board and is not ventilated at all.
So for ten minutes, summer and winter, there is a difference of nearly 14 ° C more than the outside temperature ...
(https://lh3.googleusercontent.com/Ti8mecSyNGCk68M0QSEKPEoP924wpnd9_OAVqsbEQY-nG39IDnEfOVTydUwp8SHqS9i_GLYJN1qKoW1dcetQ-J1xkasq4Q-P4ebdn7RnbrB0_jaZnE7kWpyqa9eD1fXRwFX7XHUNnR4rko22SF1EpXu86fButzUITc6kSlsyEOQzmqLHykmnCymNzyAEkrjSG6C1WltGPqGkuyHRB84c9rVbYFyolpEwfEGAvyRSZgRUOEpUnb04q9xQ2ZjhJXkOIlc4eg1m2m4BweNowVBJyvQLonBxwY5DOvBZ7G8cKjqtdjdRlFnRbBdzEoQN2TRmGgdVuX1DduwIhrt2fabO3gj78kUkrgnd-p_tlbGRa65ZYcWXt5lnlu0yCmgb8-9CL4ZFVLvccWFBktAWrBLwtZV7jg4wcKSDi6nuqJOHshn7Hwuh03XIwkPnypkMq0h_rcH6J5UQXiMgSnOcAz2P6J42Or7_OS9RbSz5-jmYS2vWMlRMddsKuyLfmV0vNY8z8AYWrGZMDtDpfNi32Rkec2fC25AeGdOra7nDiyFiosb0BgFkkz8pNeYSSGaKwi06DUk3S1EmzdkVefke-Cpd4gObCiEbT8F9pGF8O7l4Cy8fE7BMF7qWryOjamRHbuv5CcEV2ZKv5tw0HvnttlVOZy5xKQ49zWz0R2TaSgOQDQYxA1jhRKaHHHRXeb9JszRmkwEC94dHg92fKVpbRJDgiuw8=w958-h539-no?authuser=0)
-
Interesting.
-
Thanks, Meinolf. That makes sense. I sort of suspected that might be it but I’ve learned it’s counterproductive to assume something.
Thanks, Chrisfer. I hadn’t considered that engine heat would affect the sensor at the MIUG3. Should have.
-
More MIUG3 curiosities for the sake of discussion. I charted the percentage differences between my V9 right and left fuel maps. I realize that slight differences in manifold length from the "y" as well as small surface differences affecting flow as well as valves and seats, even flow into the cylinder and piston position will affect flow. I would have expected much less variation than the results show. Like maybe one side is very slightly less efficient or has slightly more impedance to air flow. The chart shows highly chaotic differences and at some points more than 25% differences. How can this be? Is it due to turbulence at different throttle openings and RPMs? What else is a factor here?
(https://i.ibb.co/yXn8qyv/cylinder.png) (https://ibb.co/yXn8qyv)
-
What else is a factor here?
The exhaust.
-
Thanks, Chrisfer. I hadn’t considered that engine heat would affect the sensor at the MIUG3. Should have.
Even with the engine off, simply the ignition, the printed circuit heats the probe by ten degrees.
-
More MIUG3 curiosities for the sake of discussion. I charted the percentage differences between my V9 right and left fuel maps. I realize that slight differences in manifold length from the "y" as well as small surface differences affecting flow as well as valves and seats, even flow into the cylinder and piston position will affect flow. I would have expected much less variation than the results show. Like maybe one side is very slightly less efficient or has slightly more impedance to air flow. The chart shows highly chaotic differences and at some points more than 25% differences. How can this be? Is it due to turbulence at different throttle openings and RPMs? What else is a factor here?
(https://i.ibb.co/yXn8qyv/cylinder.png) (https://ibb.co/yXn8qyv)
The first column really usable by opening very slowly is the 5th, 6.88 °.
10% less for the right cylinder for small openings, then it becomes very low.
-
I zeroed the first two columns above 2250rpm to experiment. It gets rid of deceleration popping but increases engine braking a bit. Interesting effect as you feel the engine come back to life just before you completely stop.
-
Hi,
after having some fun with the basic fuelling functions it's time to look at the less trivial stuff. So, let's have a closer look at the ignition.
It all starts off with the trap_50_0 sub and the subprogram group Engine_running_proc esses_sub_C4CAC6.
(https://i.ibb.co/BrBjbDr/V7-ign-1.jpg) (https://ibb.co/BrBjbDr)
Which, amongst other interesting stuff, also calls Ignition_calc_sub_C 4CFD8
(https://i.ibb.co/C8ZFXyF/V7-ign-2.jpg) (https://ibb.co/C8ZFXyF)
Nestled in which the first selection about which main/idle fuel tables will be used are taken in yet another subprogram, ignition_lookup_sub _C4D494.
Let's look at the main fuel tables first. Right at the top a branch conditions selects if idle or main fuel tables are required, which is the TPS state. If it's open, the next conditional branch is Engtemp_above_thres hold_flag_8AFD. The flag is determined elsewhere, but basically it's One if the engine temperature exceeds a threshold value and Zero if not. If the threshold (60°C in this BIN) is exceeded, then the Ign_Adv_Main2_Table _C79014 is used as base for the following calcs. If not, then Ign_Adv_Main1_Table _C78B14 is used.
(Btw, the naming is more or less based on other BINs I_ve looked at and doesn't yet reflect the usage).
(https://i.ibb.co/ZSLw21R/V7-ign-3.jpg) (https://ibb.co/ZSLw21R)
Now for the idle stuff. TPS state again is the starting point. If it's closed, the state of which is determined elsewhere by start parameters and a self-adaption process, then the idle tables are choosen. IgnIdle_Clt_dis_Tab le_C79A14 is the one used if the drivetrain is engaged and IgnIdle_Clt_en_Tabl e_C79A54 if the drivetrain is disengaged.
(https://i.ibb.co/2SsJ64h/V7-ign-4.jpg) (https://ibb.co/2SsJ64h)
So far, so good. A straightforward selection process without any complications.
Cheers
Meinolf
-
Fascinating information! Thanks for sharing.
-
Let's look at the main fuel tables first. Right at the top a branch conditions selects if idle or main fuel tables are required, which is the TPS state. If it's open, the next conditional branch is Engtemp_above_thres hold_flag_8AFD. The flag is determined elsewhere, but basically it's One if the engine temperature exceeds a threshold value and Zero if not. If the threshold (60°C in this BIN) is exceeded, then the Ign_Adv_Main2_Table _C79014 is used as base for the following calcs. If not, then Ign_Adv_Main1_Table _C78B14 is used.
What I see while driving is that the table_C78B14 is the one used.
I did not see when the table_C79014 is used.
And what one can notice is that, surprisingly, this table is identical in all respects to the engine of the V7 III (750cc) and to the engine of the V9 (850cc).
-
Hi Chris,
interesting. This leads to an enhanced understanding of the Engtemp_above_thres hold_flag_8AFD. The actual threshold situtation of the flag, 1 if engine temp > 60°C and 0 if below is certain. However, this is determined at the end of a routine in which the raw values of 2 ADC channels are checked. Not knowing which pins of the ECU connect to which pins of the CPU or ASICs makes it difficult to determine which ADC channel connects to which sensor. Further code analysis may shed some light on this by the process of elimination, but my understanding of assembler and processors is very limited, to put it politely.
(https://i.ibb.co/TP0t3RC/V7-engtemp-above-threshold-flag.jpg) (https://ibb.co/TP0t3RC)
Anyway, in light of your observation the conclusion is obvious. The main fuel table at (C)79014 is a limp-home table used if the engine temperature sensor is defective.
Cheers
Meinolf
-
Anyway, in light of your observation the conclusion is obvious. The main fuel table at (C)79014 is a limp-home table used if the engine temperature sensor is defective.
Cheers
Meinolf
indeed, that seems very possible. :thumb:
Thanks :bow:
-
Hmmm. On my V9 the C78B14 and C79014 tables are identical. So, which ever is chosen - nothing is changed.
-
Hi,
one might think that the previously introduced ignition tables for idle and non-idle operation more or less answer which ignition advance is used at a given rpm/TPS breakpoint. Well, not so. Let's take a closer look at the proceedings when delving into the ignition calc sub-program.
Here we see some initial decisions being taken. Is the current rotary process #7, is the engine turning, is the TPS closed, in between or WOT and a first branch into a subroutine if the engine is accelerating.
(https://i.ibb.co/qr41qFn/V7-ign-5.jpg) (https://ibb.co/qr41qFn)
Then a short break is used to define TPS change speed. The current TPS value minus the TPS value from the previous cycle result in a delta value. This delta value is used to index TPS_deg_speed_Table _C7A270, which houses the TPS speed values. This value is used later to calculate ignition changes when accelerating. The a look at where we are in the warm-up stage. If it'still pre-crank, eg the starter us rotating but the engine is not yet running by itself, the code would lead directly to a calculation of the ignition dwell. But let's assume the engine is running already. A final check of the starter state and off we go to
(https://i.ibb.co/YXrvL6K/V7-ign-6.jpg) (https://ibb.co/YXrvL6K)
consider the engine run modes. Modes 10 and 11 use different routines to calc ignition (and fuel as well) values. We skip these for the time being and arrive at the previously discussed ignition_lookup_sub _C4D494.
(https://i.ibb.co/HYPgDTD/V7-ign-7.jpg) (https://ibb.co/HYPgDTD)
Now the values for the right cylinder are calculated by adding the value from the IgnAdv_Delta_Table_ C79514 to the main table values. The current ignition value is the massaged in the IgnTemp_corr_sub_C4 D504.
(https://i.ibb.co/QnTcNKT/V7-ign-8.jpg) (https://ibb.co/QnTcNKT)
Values from the air temperature and engine temperature trim tables are added. In case of engine temperature there are 2 tables, one for Idle and one for non-idle.
(https://i.ibb.co/RpY4jFT/V7-ign-9.jpg) (https://ibb.co/RpY4jFT)
to be continued...
Cheers
Meinolf
-
There sure is a lot going on in that little TB! Kudos to Meinolf for all his work delving into this.
I found out the MCU chip in use is an Infineon SAK-XC2060M 16 bit processor and a 95320 eeprom. I contacted Infineon to get data sheets and whitepaper applications. They replied that the chip was obsolete and no longer supported and information wasn’t kept. I wonder if the 2021’s are using a redesigned unit.
-
I wonder if the 2021’s are using a redesigned unit.
The MIU G4.
-
I wonder if the 2021’s are using a redesigned unit.
The MIU G4.
That's the same question I was going to ask as I'm looking at a 2021 V7 850 Special purchase very soon.
-
The G4 is talking CAN bus to the outside world for diagnostics and programming. Bye bye K-line
-
Here is an inside view of the MIU G3 and a block diagram of the MCU chip.
Full documentation of the chip is at: https://www.infineon.com/cms/en/product/microcontroller/legacy-microcontroller/legacy-8-bit-16-bit-microcontroller/xc2700-family-powertrain/xc27x5x-series/#!documents (https://www.infineon.com/cms/en/product/microcontroller/legacy-microcontroller/legacy-8-bit-16-bit-microcontroller/xc2700-family-powertrain/xc27x5x-series/#!documents)
I believe that an MIU G3 that gets bricked during programming is a failure of the base program to account for data errors and request a retransmission of the data byte or at least reset to a stable state. If someone wants to jump down the rabbit hole and figure out a way to recover a bricked unit.
(https://i.ibb.co/xqV1P4t/6-F665-FB3-9-E73-4-B67-B8-EC-6-DCC1-DF57866.jpg) (https://ibb.co/xqV1P4t)
(https://i.ibb.co/vwSwdS3/217747-B3-7-A32-491-B-95-F3-F1-E46105-D78-B.png) (https://ibb.co/vwSwdS3)
-
Hi,
thanks for the picture. Can you trace the ECU I/O pins to the CPU, the ignition coil driver, the baro sensor and other chips?
Similar to what John did on the 5AM?
https://drive.google.com/file/d/1LOuP-p3JJdLPeWa-CckuKrN60AExXM6U/view?usp=sharing
Cheers
Meinolf
-
I plan to take a stab at it soon. :cool:
-
Hello Meinolf,
would it be possible for you to find the correct speedo correction factor on the XDF of the MIUI G3 ECU (V7 III), the current one (0x7C996) is not working... :bow:
-
Hi Chris,
the address is definitely correct.
(https://i.ibb.co/frS5pSt/Miu-G3-speedo.jpg) (https://ibb.co/frS5pSt)
However, and here I need to check with somebody more knowledgeable, the code uses a shifting of memory space and I'm not sure if the Tunerpro address representation 7C996h leads to a different address than the real C7C996.
On 2nd thought, which BIN are you using? Is it the CM275405/464AVFAL for which I created the BIN? When you open den speedo correction factor, do you see the value 1535?
Cheers
Meinolf
-
On 2nd thought, which BIN are you using? Is it the CM275405/464AVFAL for which I created the BIN? When you open den speedo correction factor, do you see the value 1535?
I tried the XDF 1.07 (and your) with the original bin of my V7 III (and my last modified), and yes the initial value is 1535.
My V7 III bin : https://1drv.ms/u/s!AuqxioVGI9b-hvg3tVpX8dBwkfS47A?e=CKiabk
-
Hi,
recently I was asked to take a look at the BIN running in a MIUG4 (Vespa GTS 300 HPE). And leveraged the work already done on the MIUG3-code. Quite similar, which eased the work a lot.
Anyway, as a side result the V7III-XDF was also updated. V1.10 is here: https://drive.google.com/file/d/135EETvqe0UagrX_bsSpV4_tX8jnaGFue/view?usp=sharing
The injector scaling value (ms/g fuel) and the injector trim table were added.
Cheers
Meinolf
-
Thank you for the add of injector scaling value and the injector trim table.
I found these threads about the speed correction... : https://www.guzzi-forum.de/Forum/index.php?topic=52213.0
https://www.guzzi-forum.de/Forum/index.php?topic=47810.0
-
Older ecu like 5AM did have a speedo input that was used for a sensor on the wheel, or the speed output of the ABS unit. The V7III has nee sped output from the ABS unit, so they will use CAN bus for it. The value is they as legacy and might be of use in the ecu calculations.
-
Hi Chris,
Is the injector scaling value (ms/g of fuel) only used to display fuel consumption or is it taken into account to adjust injection times?
the latter. Fuel consumption is just a collateral effect, it's a purely informational value passed over the CANbus to the dashboard.
The (rough) procedure is as follows. It starts with an interrupt driven event, which calls a subset of ops including ignition calcs and fuel_value-to-injection-time conversion. Along the way the fuel values (idle fuel/main fuel) are derived from the known tables. Then it branches of into the conversion of the fuel values into a time-based injection pulse width. The result of which is fed into the fuel phase routine, in which the fuel phase tables/scalars define the rotational degree (crankshaft) at which the injectors are closed, eg the current to the injectors begins flowing again to build up the magnetic charge of the coils. (Btw, the same procedure is used for the ignition coils).
The injector scaling value is used to convert fuel values to injection pulse width values based on the specs (flow rate at 3bar/coil saturation over voltage/other coil characteristics) of the injectors.
Cheers
Meinolf
-
Hi Chris,
would it be possible for you to find the correct speedo correction factor on the XDF of the MIUI G3 ECU (V7 III), the current one (0x7C996) is not working... :bow:
For lack of a V7III I can't check myself. While I'm sure that the address is correct and that the respective code segment is actually called and not bypassed by branching conditions, the evidence seems to indicate that it's not used.
As pointed out by Paul the V7III doesn't get the speed sensor pulses from the ABS ECU via a discrete signal, so it's likely part of a CAN package. I've identified the code in the CAN rx ops which puts a roadspeed variable into a CAN package, but this is send to the dashboard without any correction I can identify.
So unless and until we have the chance to examine either the traffic on the CANBus or look at the dashboard or ABS module BINs the speedo correction factor isn't used.
Cheers
Meinolf
-
Hi Chris,
the latter. Fuel consumption is just a collateral effect, it's a purely informational value passed over the CANbus to the dashboard.
The (rough) procedure is as follows. It starts with an interrupt driven event, which calls a subset of ops including ignition calcs and fuel_value-to-injection-time conversion. Along the way the fuel values (idle fuel/main fuel) are derived from the known tables. Then it branches of into the conversion of the fuel values into a time-based injection pulse width. The result of which is fed into the fuel phase routine, in which the fuel phase tables/scalars define the rotational degree (crankshaft) at which the injectors are closed, eg the current to the injectors begins flowing again to build up the magnetic charge of the coils. (Btw, the same procedure is used for the ignition coils).
The injector scaling value is used to convert fuel values to injection pulse width values based on the specs (flow rate at 3bar/coil saturation over voltage/other coil characteristics) of the injectors.
Cheers
Meinolf
Ok this injector scaling value therefore acts always, globally.
Thank you :azn:
-
Hi Meinolf
In reply #63 you were talking about ECU I/O pins to the 5AM CPU and I see from the image that one of the inputs is the clutch switch.
I've just fixed the clutch switch on my V9 so it now shows continuity with the lever pulled as opposed to permanent open circuit.
Does the MIU G3 have an input from the clutch and if so what does it do to the operation of the engine ?
I just wondered whether I'd missed out on anything while the switch was out of action :laugh:
-
Hi,
sure, lot's of exciting stuff happens when the switch worls and you missed it all.
1. Selection between IgnIdle_Clt_dis_Tab le_C79486 or IgnIdle_Clt_en_Tabl e_C794C6
2. maxDelta_IdleIgn_Ta ble_C7A330 bypassed
3. Several safety interlock routines
4. Selection between table_C7E9D8 or table_C7E9B0
5. Selection between table_C7EA28 or table_C7EA00
plus many other clutch state dependent subroutines.
Cheers
Meinolf
-
Cheers Meinolf, and apologies for the slow reply. Too busy doing non bike stuff for domestic management :wink:
The safety interlock effect I expected
But I'm keen to see if a working clutch switch helps with the horrible snatchy throttle my bike has from low positions
I just need to get some miles with the working switch and see where we are
Thanks again
Tris
-
Well, there is no discernable difference in the bike with a working clutch switch compared to a non working clutch switch.
However. the bike went in for servicing today and came back with a new map.
The old map was 4640VC29 and the new one is 464DVCAO
I've not ridden it yet but is there anything in the new map to address the snatchy throttle?