Karter16's Silbergrau E46 M3 Journal

[karter16]

Mine is rock steady in closed loop except for occasionally on hot starts, +/-4rpm or so. Weird.

That's with the MAP sensor enabled and tuned right? The logging I'm currently doing is with MAP sensor adjustment to RF disabled. I was thinking last night about the fact you have rock solid idle rpm and have been trying to get clear in my head how the MAP sensor is influencing that positively. There's so many things at play at once so I haven't quite got it clear in my brain, but I'm presuming that the variation in fuelling from the lambda oscillation is driving a corresponding difference in airflow which the MAP sensor identifies and effectively cancels out. But that's conjecture cause I haven't figured out yet exactly how it's happening.

Anyway - if I re-enable the MAP sensor and get it appropriately tuned I should be able to confirm this.

[Bry5on]

Mine is rock steady in closed loop except for occasionally on hot starts, +/-4rpm or so. Weird.

[karter16]

Very interesting find! PI gains could definitely create a nice oscillator.

Yeah it'll be interesting to see if anything comes of it. I think to a large degree the issue is at idle the plant lag means it takes longer for changes in fuelling to reach the O2 sensor and flip it from lean to rich and vice versa. Which is why, I think, at idle the Lambda integrator period is 3.5 to 4 seconds and the magnitude is much higher than at load, so not sure how much is able to be done about it. Not even sure if it's a problem to be solved so to speak, it's interesting/annoying though seeing N nice and flat during open loop warm up, and it then starting to oscillate when closed loop kicks in.

[Bry5on]

Very interesting find! PI gains could definitely create a nice oscillator.

[karter16]

I've been experimenting with some changes to my tune. In particular some of the differences in the idle controller parameters. There's some fairly subtle differences between the standard M3 and CSL which are almost certainly due to the CSLs different cams and exhaust valves. Given I'm running pretty much standard M3 VANOS/ignition/fuelling in this area it makes sense to me to port these differences across as well. I'm going to do a VE tuning run and then drive on these parameters for a bit and see if I can notice any difference/improvement/degradation. I am seeing a little bit of difference in the VE measurements before and after but very hard to tell whether that's due to these changes or just environmental variability.

The second thing I've been experimenting with is the lambda PI controller gains. These are fairly different between the standard M3 and the CSL. In general both I and P gain is higher in the CSL than standard M3. I've been looking at the logs and am pretty confident that this is what's responsible for the oscillation of N (rpm) at idle between about 860 and 890 rpm. N rises and falls in phase with the same period as the (intentional) oscillation of the lambda controller. As fuelling is varied based on instantaneous lambda it has the effect of driving N high then low.

Initial logging suggests that the end result between the standard M3 and CSL gains is fairly similar (again which makes sense) but will probably play around with this some more to experiment. It also occurs to me that before I go too far further down this path I should probably replace my O2 sensors with new ones.

Anyway interesting stuff.

[karter16]

I've had a few weeks of being very busy with work and family, and now myself, sick.

I've still found some time to work on projects - progressing my tune under heavy closed-loop load, figuring out my persistent lean condition with aircon on (and finding a bug in the Terra full binary in the process), getting more done on the XDF, etc.

This evening I found myself without much energy to do anything, so took the opportunity to do something I've been wanting to for ages. A direct comparison of KF_RF_N_AQ_REL and kf_rf_soll.

Quick reminder:
KF_RF_N_AQ_REL: The AlphaN map for the standard M3.
kf_rf_soll: The larger AlphaN map for the CSL.

The comparison is not entirely straightforward as the two tables differ in size in both dimensions. This means interpolating both axes. Once that is done then you have to account for the fact that the y-axis for KF_RF_N_AQ_REL is AQ_REL, whereas for kf_rf_soll it's aq_rel_rf which is a variably modified version of AQ_REL under 2400rpm.

A bunch of excel later (which I'm sure would have been quicker if my brain was sharper) and I was able to spit the result out.

Here's a comparison of the two maps (y axis in aq_rel_rf). number less than 1 means KF_RF_N_AQ_REL has more fuel in that cell and likewise greater than 1 means kf_rf_soll has more fuel.



It's important to note that the two still aren't entirely directly comparable as the injection tables differ somewhat between the CSL and standard M3. I will do these adjustments next, but I'm more just interested to see the patterns and if there's anything that can be extrapolated into the VE table for cells that are hard to hit in VE tuning. Interesting as well to run this comparison against my current VE table and see the areas of convergence, etc.

[karter16]

Well I'm finding the ability to configure the CAN messages very useful as I dive into understanding the RF calculations in more detail. I'm currently looking to understand the effect that things like TETV (tank ventilation), BA (fuel enrichment), etc. have on the repeatability of the lambda logging, and being able to easily swap around what I'm logging is a massive time saver. It's simply a case of:

1: look up the variable I want to log
2: update the address into the tune file parameter
3: update the Gauge.S config with the parameter name and conversion factor.


I also came across the first thing (DKBA - After-Spray) I want to log that is only available on the Slave CPU (it was only a matter of time), so the CAN logging feature now needs to be expanded to handle that. I confirmed a couple of weeks ago that the DPR (dual-ported RAM) is only about half full, so there's room for sure to use. I plan to prove the concept in a very similar way to what I did for the CAN send. I'll replace an existing function call in the Slave 10ms Task with a new function call which then calls both the original function and my additional function. That function will then copy the relevant memory address to the DPR.

Once I've proven it out I'll probably then look to build out the ability to configure a set number of bytes to be pushed to the DPR so they can in turn be inserted into the CAN messages. The approach would be the same, parameters in the tune file that configure which Slave-only variables to push to the DPR. The parameters would be checked for valid address same as I am doing for the CAN parameters. I imagine 8 bytes (e.g. 1 whole CAN message) would be enough for all practical purposes.

[karter16]

Now that I'm setup for CAN logging I finally got a chance to try out my custom program and tune ROMs that allow for configuration of the additional CAN messages (7D0 and 7D1) in the partial binary (see here for the background: https://nam3forum.com/forums/forum/s...454#post310454).

The good news is that it all worked first time! (to be fair I put a lot of effort into checking and rechecking the code to make sure it was right)

First up I flashed the custom program to the DME and ran it with the standard tune. I've designed this such that if someone uses the custom program with a tune file not designed for it the additional functionality is simply disabled. Likewise if someone uses the custom tune with the standard program it is also gracefully handled.

I then verified that DME functionality was as expected. E.g. normal function and no additional CAN message activity. All was well.

I then added the new parameters to my tune file:



and flashed the tune. Sure enough everything still worked, and the 7D0 CAN message was present on the CANbus.

Here are the values being logged.



I've got some more scenario testing to do. e.g. test the 7D1 message as well, intentionally put bad data into the config parameters and make sure it's handled gracefully etc. but super stoked all is working so far as this is the most complex change I've made to the program so far!

Onwards and upwards - this functionality will be very useful to me as I dive into more refinement of my tune now I have high-frequency CAN logging available!

[karter16]

So it was in fact the display that was at fault!



Stoked to have this sorted and have captured a test log.

The harness extension I'd made up worked perfectly. Simply intercepts at the steering angle sensor. I will be logging everything I need over CAN, so no need to do anything with the K-line. The 12V power to the steering angle sensor is from Terminal 15 so perfect for this use.

[karter16]

He's pretty cool about replacing HW. He sent me a couple boards when we were debugging the FW for the latest HW. They cost nothing to manufacture, so retaining the client is likely worth a lot more than one board.

Also, he's pretty active on the Gauge.S discord, in case you need to reach him quicker.

You were spot on with this advice. He did some quick troubleshooting with me over email to confirm the board is at fault and he's shipping me out a new unit this week :-)

[heinzboehmer]

yeah - not an ideal situation to be dealing with but it is what it is. Will see how I get on when I hear back from Sorek (think he was on vacation until today). I appreciate it's a tough one with this sort of product. As far as he's concerned I equally could have done something wrong to fry the board so will see how it goes.

He's pretty cool about replacing HW. He sent me a couple boards when we were debugging the FW for the latest HW. They cost nothing to manufacture, so retaining the client is likely worth a lot more than one board.

Also, he's pretty active on the Gauge.S discord, in case you need to reach him quicker.

[karter16]

Ah that's annoying. Hopefully it doesn't take too long to resolve!

yeah - not an ideal situation to be dealing with but it is what it is. Will see how I get on when I hear back from Sorek (think he was on vacation until today). I appreciate it's a tough one with this sort of product. As far as he's concerned I equally could have done something wrong to fry the board so will see how it goes.

[heinzboehmer]

Ah that's annoying. Hopefully it doesn't take too long to resolve!

[karter16]

I've had the ribbons for the screens fail on me. The case bends them at too sharp of an angle and causes breaks. Try forcing wifi on (there's some setting you can set to true on the SD card, look at the github wiki) and scanning for networks with your phone. If you see "Logger.S" (I think), then the board is most likely fine.

The screens are this: https://www.amazon.com/HiLetgo-SSD13...dp/B0CFF2QW5V/

Should be easier to find a source for those than to have another board shipped out to you from the UK. Hopefully the screen is your problem!

Edit: The other thing you can do is to try to talk to the uprocessor directly. It's just an ESP32, so any cheap programmer will let you do that. I'm pretty sure that even the prod FW builds print something out over serial when the device boots. More info: https://github.com/handmade0octopus/Gauge.S-sd-updater

I also wrote a hacky validation FW that you can flash onto the board just to see if it is working: https://github.com/heinzboehmer/Gaug...54HP-Validator

Use the sd card updater afterwards to flash back the FW from the main Gauge.S repo.

Thanks for this - I forced WiFi on and powered up but no dice.

Will wait for a reply from Sorek before going down the programmer route I think but that's some good options thanks!


Sent from my iPhone using Tapatalk

[heinzboehmer]

Well the Gauge.S appears to be dead on arrival. No action when connected to 12VDC bench supply. I've reached out to Sorek to find out whether there's any diagnostics I can do to confirm whether the board or display is at fault, but given the screen came in a lovely 3d printed case and the board itself was just chucked loose in the bubblewrap envelope I'm guessing it's probably the board.

Will update when I have more info.

I've had the ribbons for the screens fail on me. The case bends them at too sharp of an angle and causes breaks. Try forcing wifi on (there's some setting you can set to true on the SD card, look at the github wiki) and scanning for networks with your phone. If you see "Logger.S" (I think), then the board is most likely fine.

The screens are this: https://www.amazon.com/HiLetgo-SSD13...dp/B0CFF2QW5V/

Should be easier to find a source for those than to have another board shipped out to you from the UK. Hopefully the screen is your problem!

Edit: The other thing you can do is to try to talk to the uprocessor directly. It's just an ESP32, so any cheap programmer will let you do that. I'm pretty sure that even the prod FW builds print something out over serial when the device boots. More info: https://github.com/handmade0octopus/Gauge.S-sd-updater

I also wrote a hacky validation FW that you can flash onto the board just to see if it is working: https://github.com/heinzboehmer/Gaug...54HP-Validator

Use the sd card updater afterwards to flash back the FW from the main Gauge.S repo.