I’m attempting to use Megasquirt RPM-triggered sensor heating. The heater does stay shut off for about a minute after I power on without RPM. However, then it heats up as normal without getting RPM instead of waiting the full 10 minutes.
I’ve tried setting it to slow heat mode 2 again with no change in behavior.
I just did the same thing with a stopwatch in mode 3, and it also heats up after about a minute (instead of 10 min)
I think I found the bug in my code. Will post new firmware tomorrow.
new firmware is up, https://cdn.shopify.com/s/files/1/0189/1312/files/Spartan3_Firmware_1_06.zip?v=1687152751
I’ll give that a shot today.
Also, I was looking through some datalogs, and seeing some odd behavior. I switched from a techedge unit to the spartan. On the techedge, when closed loop made the pulsewidth larger, I could see it on the wideband output. Now, there are some situations where I can’t. Closed loop will keep increasing correction, pulse-width is getting larger, but no response on the wideband. Then suddenly the wideband will show richer all at once.
Also sometimes coming off of overrun fuel cut, the wideband will show an “intermediate” lambda briefly before dropping to the AFR that makes sense for how the engine is running.
I’m assuming these oddities are expected based on sensor temperature, etc… but would it be possible to actually tell the MS that the sensor reading can be trusted vs. when it can’t?
Also I forgot to mention, MS3’s next alpha firmware will have a built-in option for the Spartan 3 wideband.
For the closed loop issue, is that during idle and light engine load?
do you have a datalog you can share with me?
The closed loop issue doesn’t seem to be tied to light load specifically. Today I was seeing it at about 56% load (but 97.7 kPa … it’s an ITB setup using MS3’s ITB load mode). I have attached a screenshot with the cursor over the area where I see the issue. Pulse-width goes from 6.4ms to 6.9 ms or so with AFR just being a flat line. It happened after being in overrun fuel cut for a while.
can you change the performance mode to 1 by sending “SETPERF1” via USB-serial and see if the problem persists?
I did that, and now I don’t see any issues aside from the AFR trace being a bit noisy.
Set it back to Performance mode 0 then, mode 1 runs the sensor right at the sensor datasheet limits.
I do not know where the issue is or if there is one. The AFR moves at or about the same time the AFR target moves so the ECU is getting a change in AFR in the correct direction and at about the right time the ECU expects.
I don’t think that is the answer. The PW changing should result in the AFR changing, and it does in performance mode 1 where it doesn’t in performance mode 0. I just left it in performance mode 1 and decreased the ms3’s lag factor a bit to smooth it out.
It really seemed to me like the sensor got too cold and stopped working or similar in mode 0 just after overrun.
I saw odd behavior in initial start too where the controller is sending the ms3 weird jittery lambda numbers before the led goes solid to indicate the sensor is warmed up.
It would be really cool if the sensor going out of operating temps told the ms3 not to “trust” the lambda numbers until they went back to normal. I would be happy to add support for using that to ms3. It would make things like after-start delay and after-transient delay unneeded.
Ken
Sorry I misread your post, I thought you wrote performance mode 1 had no effect.
The sensor temperature is sent to MS3 Over CAN. The CAN protocol is in section 9 of the user manual, https://cdn.shopify.com/s/files/1/0189/1312/files/Spartan_3_User_Manual_a944c227-32dd-43d0-9dce-626188e52190.pdf?v=1674287703
There is also a Status Byte that gets sent to MS3. The status Byte is 8 bits and I want to use the first two bits for the sensor temperature status bits, 00=waiting for heating trigger,01=heating up,10=normal operating state,11=error state. So MS should wait until the first two bits read 10 and then the signal is trustworthy.
Did you try firmware 1.06? I retuned the PID controller for the sensor heater, if the sensor got out of operating temps in performance mode 0 then it might solve that. Also in 1.06 the first two bits of the Status byte should be working as in the above paragraph, I am still working on what to put into the other 6 bits.
There is a bug in firmware 1.06 that makes Slowheat stuck at 3, firmware 1.07 has been released that fixes it, https://cdn.shopify.com/s/files/1/0189/1312/files/Spartan_3_Firmware_1_07.zip?v=1687493470
Do those status bytes need to be setup in tunerstudio “CAN Receiving” “Offset” set to 3?
Will Tunerstudio know what to do with that info?
Does tunerstudio know what to do with offset 2, sensor temp?
I have not figured out how to set it up yet in Tuner Studio but I will when I find more time. Tuner studio will be able to log and display the temperature and the Status Byte value, But it might not be able to decode the status byte to pick out the bits of information.
We’ll make the code use the status byte and log the parts we are using decoded. We just need the format.
I changed my mind on the Status bits, still working on it. I am adding an Extended CAN Format that includes pump current and Response time information.
I should have a new firmware in about 2 weeks with the details ironed out.
