[feature request] selectable sensor for fan control

[jsmcortina]

Similrly, the latest beta code recently made deadtime usage "better" for 4 cylinder users but massively "worse" for 12 cylinder dual fuel users.

Please start a new topic and explain why you think this.

James

[racingmini_mtl]

It also is a shame that the MS3 allows only 16 CAN generic inputs because all these electrical paramaters can be sent via CAN to the ECU (my 16 channels are used up for 4 Wideband and 12 EGT inputs)
I did ask for an increase of the number of generic CAN input in feature request but as far as I know there was no interest either to improve that .

Not quite enough, but the current pre-1.6 firmware allows you to receive 8 EGTs from a CANEGT by listening to broadcast data and consumes zero CANADC channels.

James

And if you go with an 8x8 Input Expander from EFI Source (which is a CAN-EGT with 8 EGTs plus 8 analog inputs) you can do the same for EGTs and for 8 wideband controllers which won't use any CANADC channels. This assumes you have wideband O2 controllers with an analog output (0-5V signal connected to an ADC input).

Jean

[Jaguar V12 guy]

I slowly run into the problem hiding add on boxes.
the E-Type is not very spacious under the panel.
I have already:
2 igniters for the coil blocks
2 large coil blocks
2 Haltech controller for 4 wideband sensors (via CAN)
2 EcuMaster EGT to CAN controller to get 12 EGT probes
1 EcuMaster PMU 16 AS Power Management Unit
and of course the ECU itself

I had to discard the car stereo for some components but I can’t keep adding boxes just because I wanted to send the current consumption data to the ECU to be displayed.
The PMU as well as the Wideband and EGT controller are able to send useful data and interesting code and are of great help for troubleshooting but as I said all 16 CAN receiving variables are already used up.

Btw. in TS are are a lot of selectable sensors all over and one more sensor selector for CLT is not adding confusion.
there are a ton of things that are for advanced users and it took me a while to get all CAN data transmitted correctly but a sensor selector was not confusing.

in all honesty, when I started this request I thought it would be easy for the experts to add that and I did not want to start complicated justification why some cooling systems require more flexibility than others.
thanks Gentleman

[edgedj]

the E-Type is not very spacious under the panel.

heh - yeah they do look a bit snug in the cockpit, still you have at least 3 feet of engine bay spare surely ;-) Don't forget you can always drive the fan from a generic pwm out, this is what I do on my Hillman Imp (an even smaller British car) and it's just about spot on:

generic pwm

Screenshot 2024-02-06 at 22.52.16.png (392.37 KiB) Viewed 452 times

Note how the trigger range is between 64c and 76c (sensor in the rad base). One would imagine (hah) the numbers in this chart would explain the difference between using the rad base and the coolant sensor in the head. Here's a datalog from this evening, see how there's not really enough time in the variation of the coolant temp to trigger the fan before the radiator would be allowing over hot coolant into the block. My engine is very sensitive to overheating and the risk on this all aluminium engine from the 60s is that if the coolant hits about 95c the steel bolts pinch the head gasket as the aluminium head and block expand resulting in a head gasket failure. I still need to tweak the kick-in fan levels to smooth some of these peaks out but that's just perfecting things

fan speed vs rad base sensor

Screenshot 2024-02-06 at 23.02.23.png (207.42 KiB) Viewed 452 times

[Jaguar V12 guy]

Thanks for your interesting response.
The engine bay is big but it gets hot in there so I want a minimum on electronic stuff there. The EGT-CAN boxes need to be there anyway but everything else is inside.

I thought that some things can be improved and looking back the thread I can tell that I am not the only one needing a selectable sensor but the people who could help us to solve these shortcomings like to argue but are obviously not interested.

I will go a different route and let the PMU (Power Management Unit) from ECUmaster do what the Megasquirt can only do with unnecessary work-arounds.
The PMU can read a temp sensors, run 1 or both fans with Softstart and/or PWM and also monitor the A/C and all this with PID functionality.

I would have preferred if it can be handled from TS to keep things where they belong (Fan Control onto the Fan Control menu) so anybody after me will understand the setup and not have functions across multiple components.

I have a similar problem with my Flex sensor that sits close to the tank and would send fuel tank temperature but for Hot start situation I want to use Fuel Rail Temp which is available at generic sensor 5 but if I activate Flex Temp I cannot use Sensor 5 and vica versa

Greetings

[ShirtUser]

I've thought about this a lot over the last several weeks, but from a bigger perspective.

What I think is really missing is a ticketing system through which feature requests and bug reports can be made. Which would consolidate reports, provide definitive response and set everyone's expectations.


The benefits I list below are obvious for those who have used these kinds of tracking systems, but just in case...

*It would provide the end users a uniform way to submit requests/bugs

*The developers a uniform way to respond to them

*Let the end users easily know what to expect (e.g. a feature/bug is categorized as user error, acknowledged but not going to be worked on, low priority and might not get done, medium priority and will make it into the next release, or high priority and a patch is coming)

*It would let end users vote so that developers can get a definitive view of what's important to people


But, it would only work if the developers would actually use it. And of course there is a cost in terms of time and money to implement it. I'm willing to contribute both or either of those resources.

[64bit]

I've thought about this a lot over the last several weeks, but from a bigger perspective.

What I think is really missing is a ticketing system through which feature requests and bug reports can be made. Which would consolidate reports, provide definitive response and set everyone's expectations.


The benefits I list below are obvious for those who have used these kinds of tracking systems, but just in case...

*It would provide the end users a uniform way to submit requests/bugs

*The developers a uniform way to respond to them

*Let the end users easily know what to expect (e.g. a feature/bug is categorized as user error, acknowledged but not going to be worked on, low priority and might not get done, medium priority and will make it into the next release, or high priority and a patch is coming)

*It would let end users vote so that developers can get a definitive view of what's important to people


But, it would only work if the developers would actually use it. And of course there is a cost in terms of time and money to implement it. I'm willing to contribute both or either of those resources.

or, you can stop being ignorant to the suggestions you have been given. A method of control already exists here, you just werent listening.

[ShirtUser]

or, you can stop being ignorant to the suggestions you have been given. A method of control already exists here, you just werent listening.

Lol. I can see you didn't read my post at all. Because it had absolutely nothing to do with a specific feature request.

How about you stop brow beating everyone who you don't like the opinions of? That's a feature request I could really get behind. Or, is it a bug fix? Lol

[ShirtUser]

Taking this thread back off of my notifiy list...

[edgedj]

What I think is really missing is a ticketing system through which feature requests and bug reports can be made. Which would consolidate reports, provide definitive response and set everyone's expectations.

Great idea. I think github can do all the things you suggest