A couple issues this weekend may be a bug ?

[jeffmarsh750]

1) Can't seem to find the water injection duty in data logging, not sure if it is coming on down track or not. It is active and tests fine under test mode but can't see that channel in data.

2) The nitrous timer starts all over again after launch. Sometimes multiple times. On my turbo bike (1.3.1)I use a NOS solenoid to spray additional fuel in the turbo intake. I use the NOS 1 channel as it also activates timing and fuel that I can adjust down track based on time. This Is also hapening on the NOS bike (1.4.2 pre alpha)with carbs but only once and at the 2nd gear shift. We think we fixed that one my moving tps down to 20% and rpm upper limit 1000 rpm above shift limit. Mine I am now where near the upper limit when it re-activates and I moved the TPS way down too. My Boost after launch was doing this too and I had to activate the VSS and put a low number there to stop it. Any Ideas ?

3) My can EGT's are a bit fuzzy (any smoothing I can add ?) and they also seem to just shut off in the data mid track, Any Ideas ?

Other than that these bikes rocked all weekend !
Thanks Jeff.

[jsmcortina]

I'll take a look soon.

James

[Marek]

Unless I am mistaken, the IOX doesn't have any way of introducing a lag factor prior to sending its ADC values down the CAN, so it'd be nice to have the option of applying a single lag factor setting to all CAN EGT inputs at the main controller end.

Trying to do this through generic sensor inputs would get problematic very quickly if there are a lot of CAN inputs to lag. In my case, it'd use up all of the remaining generic sensor inputs straight away as I'd have 12 of them and have already used 4 generic inputs. This would mean that the remaining 12 (of 24) CAN ADC inputs couldn't be lagged or mapped at all even if I wanted to and it is likely that introducing another per cylinder sensor would quickly gobble up all available expansion in one hit.

A nice way to do this would be to give Jean a bit of code so that IOX ADCs can be mapped and lagged as "IOX generic sensor inputs" before they get to the main controller so it keeps resources free at the MS3 end.

kind regards
Marek

[racingmini_mtl]

Unless I am mistaken, the IOX doesn't have any way of introducing a lag factor prior to sending its ADC values down the CAN, so it'd be nice to have the option of applying a single lag factor setting to all CAN EGT inputs at the main controller end.

There are already lag factors on the IOx and CAN-EGT.

Jean

[Marek]

Sorry, I think I must have missed that - I thought from reading the forums that the lags were supposed to be set to 100 because it was "CAN", but I must have confused this with digital AFR data.

If I understand correctly, the lag factor for CAN AFR in MS's general setings has to be set to 100 rather than the usually lower number because the AFR data comes through digitally from the CAN and the lag on this datastream has a truncation effect rather than a smoothing effect, but the ADC data from the CAN, as you point out, has its own lag settings at the IOX/TinyIOX end of things. My mistake.

kind regards
Marek

[racingmini_mtl]

Sorry, I think I must have missed that - I thought from reading the forums that the lags were supposed to be set to 100 because it was "CAN", but I must have confused this with digital AFR data.

If I understand correctly, the lag factor for CAN AFR in MS's general setings has to be set to 100 rather than the usually lower number because the AFR data comes through digitally from the CAN and the lag on this datastream has a truncation effect rather than a smoothing effect, but the ADC data from the CAN, as you point out, has its own lag settings at the IOX/TinyIOX end of things. My mistake.

kind regards
Marek

Yes the digital AFR data is a special case where you want to set the AFR lag factor to 100 on the MS since the data is never in an analog form so you don't want any filtering. The filtering would degrade the data instead of improve it.

Jean

[jeffmarsh750]

Bump, Any oyher Ideas with the other issues ?

[jsmcortina]

Bump, Any oyher Ideas with the other issues ?

Not yet, sorry.

James

[jeffmarsh750]

James,
Not a problem, I know you're busy. I just need to stay on top of my game now that my competitor is using MS too !

[24c]

I just need to stay on top of my game now that my competitor is using MS too !

...and he'll be visiting these forums too, looking at your questions and answers!

[jsmcortina]

1) Can't seem to find the water injection duty in data logging, not sure if it is coming on down track or not. It is active and tests fine under test mode but can't see that channel in data.

That's an omission. I'll email you an updated "ini" file that includes water_duty. It will also be in the next code releases.

2) The nitrous timer starts all over again after launch. Sometimes multiple times. On my turbo bike (1.3.1)I use a NOS solenoid to spray additional fuel in the turbo intake. I use the NOS 1 channel as it also activates timing and fuel that I can adjust down track based on time. This Is also hapening on the NOS bike (1.4.2 pre alpha)with carbs but only once and at the 2nd gear shift. We think we fixed that one my moving tps down to 20% and rpm upper limit 1000 rpm above shift limit. Mine I am now where near the upper limit when it re-activates and I moved the TPS way down too. My Boost after launch was doing this too and I had to activate the VSS and put a low number there to stop it. Any Ideas ?

Is there any way that the "arm" switch could be bouncing or getting de-activated somehow? I think that I have seen this on my car at times and believed it to be an electrical problem e.g. corroded connections to my nitrous microswitch or corrosion internally.

If you could add "PORTT" to the datalog that might capture what's happening.

It is difficult to know how to handle this in code, you don't really want to ignore the button/switch input going off, but perhaps a little delay to filter out glitches could be created.

3) My can EGT's are a bit fuzzy (any smoothing I can add ?) and they also seem to just shut off in the data mid track, Any Ideas ?

That doesn't look right at all, I'm not sure what's going on though.
Jean - any ideas?

James

[jsmcortina]

For reference here is a datalog from my car. The EGTs are far smoother.

James

[racingmini_mtl]

That's more than a bit fuzzy; that's all over the place. And I don't understand how the value would freeze like that other than a failed CAN bus connection. James' datalog shows what I would expect in terms of "fuzziness" in a normally working setup (I' m surprised by the temperature difference between cylinders but that's a different topic).

What type of EGT probes are you using? I've heard some people having problems with some probes (some cheap and some not so cheap). I do know that the ones from DIYAutotune give good results but they shouldn't be the only ones. You also need to have a good ground on your CAN-EGT.

I should add that when I was doing some bench tests on the CAN-EGT with the DIYA probes, I had to connect the probe sleeves to ground in order not to have similar jumps in EGT readings. If your probe sleeves are not grounded through their mounting location, that might be something to look into.

Jean

[jeffmarsh750]

Thanks James for the Ini. file. On the NOS timer turning off, I have replaced the arming/activation switches, and both bikes have done the same thing. On the NOS bike I think we corrected it (at least in the last 2 runs) by turning the NOS rpm upper limit to 14k and the TPS setting down to 10%. I think I will try a noise filter by adding a capacitor in the TPS signal (unless software can do this) and see if that corrects it.

On the EGT all over the place, the current probes/location/ground were working fine with aftermarked data logger and the Haltech can unit. I have tried the IO expander from turbo355 with the same all over results, just not the locking up problem. Will try some new grounds and probes. I might add that these EGT's are smooth with the engine not running. Maybe spark noise ?

Thanks, Jeff