Coolant and Inlet Air Temps Transfer Required Accuracy??

A thermistor curve calculator and simple code generator program used to develop FreeEMS and generate compile time curves for your custom sensors. Written by Fred and Shameem.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Coolant and Inlet Air Temps Transfer Required Accuracy??

Post by Fred »

Good work, here is the rather plain GUI :

Image

Image

Image

Image

Image

Image

Image

I'd like it to at least display an non working gui before I throw it your way.

Some time today hopefully. You could start by porting that to C# and mono (shouldn't be hard at all).

Thanks,

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Coolant and Inlet Air Temps Transfer Required Accuracy??

Post by Fred »

Here is a non-functional release with exe that just comes up and looks like an app. It does nothing. I've sent it to shameem to work on the back end, and Rob who may or may not tidy up the interface somewhat. Feel free to work on it, but do collaborate with myself and shameem and others by posting in this thread to indicate your intentions.

https://sourceforge.net/project/showfil ... _id=607613

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
AbeFM
Post Whore!
Posts: 629
Joined: Sat Feb 16, 2008 12:11 am
Location: Sunny San Diego
Contact:

Re: Coolant and Inlet Air Temps Transfer Required Accuracy??

Post by AbeFM »

Nice! I like the interface, didn't go through it detail by detail, but it seems the pieces are all there, very impressed!

Now I just have to talk you out of using it. :-P

Fred wrote:...the plan is to sample all ADCs synchronously and to do the averaging on the final variable. If we sample synchronously, but use the sample and average asynchronously then we will be losing samples. I don't know if that matters or not, and would only happen at umpteen million rpm, but it seems ugly. Then again doing mundane things like that in the ISR seems ugly too. We will see.
Yes, it does seem ugly! You want to keep that ISR as streamlines as possible! Certainly the idea of noise rejection by reading everything at one time is actually a good one. What I don't see is how missing a sample will bother you. Live with it, it's better to once in a while grab the average of Coolant_0, Coolant_2, Coolant_3, and Coolant_4 than it is to have the ISR's be too long.


It is not possible to be faster than instantly addressing the memory directly as in

temp = temps[adc];

That says "take the value of length (data type (16)) from address (*temps + adc) and store it in the address (*temp)"

You CAN'T beat that, even if you want to :-)
Still, that's reading an ADC (or is that value stored), then going to look it up? As opposed to just having a memory location (register/buffer?) called "current_temp" which is your defacto standard official temp. You update this as you get a chance. Yes, it might be 1/4 engine cycle out of date that way, but you don't care - and it'll be a rolling average anyway.



Well, it may be somewhat idealist of me to even try to sample the way I am going to, but I'd like to try to make it work. I can use two counters to see how many samples are lost at various rpms with the transfer and averaging done asynchronously. At the moment it will be zero, but I can insert a "sleep 20 ms" in the main loop to ensure it's realistic.
Fred.
Not sure, have to think about it more. LATE, must go. :-)
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Coolant and Inlet Air Temps Transfer Required Accuracy??

Post by Fred »

Did you really think it looks good? I think it's hideous. Yes, everything is there, but it needs a back end. It's not critical, we can generate the file pretty easily without a flash gui tool, but a good collection of tools is a good thing to have :-)
8InchesFlacid wrote:Certainly the idea of noise rejection by reading everything at one time is actually a good one. What I don't see is how missing a sample will bother you. Live with it, it's better to once in a while grab the average of Coolant_0, Coolant_2, Coolant_3, and Coolant_4 than it is to have the ISR's be too long.
I agree, I think losing a few shouldn't matter too much really.
Still, that's reading an ADC (or is that value stored), then going to look it up? As opposed to just having a memory location (register/buffer?) called "current_temp" which is your defacto standard official temp. You update this as you get a chance. Yes, it might be 1/4 engine cycle out of date that way, but you don't care - and it'll be a rolling average anyway.
Here's the thing. We are aiming to do the calculations as close as possible to the event right, and with the most up to date data. Now, for temp, maybe it doesn't matter a lot, but what about MAP? you MUST sample and average and process this for each calculation or more often. I'd like to be consistent with all the vars and have them all processed similarly. There is no point doing the calculation instantly right before the fuel pulse if all the vars are out of date. I know temp doesn't count, but IAT does, and that moves very fast. I've seen my coolant move very fast too due to excess radiator and rush of cold fluid through the engine etc. I'm still thinking about it, but at this stage the "lose samples" way seems best.

We don't have the HP to oversample to hell either. That would yield the best result for sure, but would waste a lot of CPU and time.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
AbeFM
Post Whore!
Posts: 629
Joined: Sat Feb 16, 2008 12:11 am
Location: Sunny San Diego
Contact:

Re: Coolant and Inlet Air Temps Transfer Required Accuracy??

Post by AbeFM »

Fred wrote:Did you really think it looks good? I think it's hideous. Yes, everything is there, but it needs a back end. It's not critical, we can generate the file pretty easily without a flash gui tool, but a good collection of tools is a good thing to have :-)
I'm easily impressed by GUI's, especially those with "too much" instead of "too little"....

Fred wrote: Now, for temp, maybe it doesn't matter a lot, but what about MAP? you MUST sample and average and process this for each calculation or more often. I'd like to be consistent with all the vars and have them all processed similarly. There is no point doing the calculation instantly right before the fuel pulse if all the vars are out of date. I know temp doesn't count, but IAT does, and that moves very fast. I've seen my coolant move very fast too due to excess radiator and rush of cold fluid through the engine etc. I'm still thinking about it, but at this stage the "lose samples" way seems best.
I agree, the losing samples is the best compramise. You're really very close to ontime here. Remember, an engine cycle out of date is data 6 or 7 ms out of date. To be 1 degree off, you're talking temps changing on the order of 175 degrees PER SECOND. That's insane. 10 degrees/minute? Sure, I could see that. 100 degrees per minute? Maybe. But there's 3 or 4 orders of magnitude here that really do seperate the values. If you're going to say all variables were created equal, I demand you check my fuel tank levels in every ISR. I want a warning when my washer fluid is low or I'm due for an oil change and I'm not waiting 175 microseconds for it. :-P Ok, just giving you a hard time, but the truth is, there's a penalty here - if we lose timing accuracy due to mucking around with coolant temps which I'm sure could be sampled once a second (air temps too), then we've hurt engine performance for the sake of looking good while doing it.

In the airflow, I see the same thing. Your turbo and your intercooler are going to act like big old capacitors. They will not let air temps fluctuate significantly in that period of time - averaging is better since the error is likely to be bigger than the fluctuations in the air. :-) Show me convincing logs where air temps moved more than 100 degrees per second, and it totaled more than 5 degrees of change, and we'll talk.

For coolant, it's even more of an issue - the numbers are supposed to be representative of the temps inside the combustion chamber, or at least of the walls. The coolant will lag the temp of the head by at least a second or two. So being up to the, literally, millisecond on that is not only wasting time, it's inaccurate.

I believe you should continue to focus on getting the values accurate, and then just figure that data which is, in all likeliness, less than 1ms old is going to be FINE.

One more time, then I'll try to drop it, when you get a reasonable engine model, do an error propagation, and tell me how much your delivered fuel will be off with data that's 10ms old. Take the highest believable dT/dt you've seen, find out what the change in delivered fuel would be for 10ms at that rate, and show me it makes a 1% difference in injector pulsewidth. If not, you're sacrificing cpu cycles that could be used for something else, and using space on it as well. I know it seems like a PITA to do these propagations, but they give you answers relatively quickly, and keep people from me like soapboxing. :-)
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Coolant and Inlet Air Temps Transfer Required Accuracy??

Post by Fred »

I'll respond to Abe's post a little later.

Image

Image

It now actually does a little bit. And there is enough in it to make Shameem's job much easier :-)

It's fun learning a new language and setup and making it all work. The code is dead simple, but some of the config around it is unobvious and docs are a bit sparse.

Links I used :

API : http://www.go-mono.com/docs/index.aspx? ... slib-gnome
Beginners guide : http://www.mono-project.com/GtkSharpBeginnersGuide
On deb sid guide : http://www.micha.name/Programming/CSharp/CSharp1.html
GTK HOWTO : http://www.adsllc.com/Mono/GUI_Howto/#helloworld
A few pages from this book : http://books.google.com/books?id=fJ9sGW ... #PPA128,M1

Now it's fairly stable and useless :-)

Changes :
Fixed the Makefile to use version 2.0 libs
Fixed Makefile to include graphics and glade file in the exe.
Figured out how to load AboutDialog window and graphic.
Added try catch blocks
Added event handling for some menu items :
Quit works.
Closing the window quits.
Save outputs the low temp pair in HR format.
About dialog comes up with it's graphic when about is chosen and the buttons within function correctly.
Other things?

I'll release it after I've had lunch :-)

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Coolant and Inlet Air Temps Transfer Required Accuracy??

Post by Fred »

SF.net is down for upgrades, so I've emailed it to Shameem. I'll upload it in a few hours when it comes back up.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Coolant and Inlet Air Temps Transfer Required Accuracy??

Post by Fred »

8InchesFlacid wrote:You're really very close to ontime here. Remember, an engine cycle out of date is data 6 or 7 ms out of date. To be 1 degree off, you're talking temps changing on the order of 175 degrees PER SECOND. That's insane. 10 degrees/minute? Sure, I could see that. 100 degrees per minute? Maybe. But there's 3 or 4 orders of magnitude here that really do seperate the values.
I'd say my values are in between those ones. I can provide datalogs showing how fast the water temp moved, but not IAT as my IAT was rock solid due to my HUGE smooth flowing intercooler and HUGE efficient cool running turbo :-)
but the truth is, there's a penalty here - if we lose timing accuracy due to mucking around with coolant temps which I'm sure could be sampled once a second (air temps too), then we've hurt engine performance for the sake of looking good while doing it.
Absolutely. What you don't know is that all ADC's are already being sampled in ISR time and it takes VERY little time to do that. I was using them raw before now, so that was fine. I hadn't considered the transfer to real values carefully. Now that I have, I'd say that I should continue to sample as I am, but do the transfers and calcs in main loop time. I should also make them more generic and access them with offsets and pointers such that you can configure which input is which externally easily :-)
In the airflow, I see the same thing. Your turbo and your intercooler are going to act like big old capacitors. They will not let air temps fluctuate significantly in that period of time - averaging is better since the error is likely to be bigger than the fluctuations in the air. :-) Show me convincing logs where air temps moved more than 100 degrees per second, and it totaled more than 5 degrees of change, and we'll talk.
My engine is the wrong one to get those from. Try an oem car with small IC and small turbo and large boost. Trailing throttle at 6k rpm coming into a corner, stamping the gas on the exit which creates LOTS of heat virtually instantly. Consider cars that aren't setup quite so well as mine and yours(?) :-) (distributor discussion is ringing bells lol)
For coolant, it's even more of an issue - the numbers are supposed to be representative of the temps inside the combustion chamber, or at least of the walls. The coolant will lag the temp of the head by at least a second or two. So being up to the, literally, millisecond on that is not only wasting time, it's inaccurate.
It might be inaccurate, but its least inaccurate the more up to date it is. You are just centring the bell curve of error as close as possible to the correct number.
I believe you should continue to focus on getting the values accurate, and then just figure that data which is, in all likeliness, less than 1ms old is going to be FINE.
I don't have a problem with the age of it on that scale so much. I do have a problem with where they are sampled though. Doing them synchronously = in ISR time. But that's OK so long as that's all we do as that is very very quick indeed.
One more time, then I'll try to drop it, when you get a reasonable engine model, do an error propagation, and tell me how much your delivered fuel will be off with data that's 10ms old. Take the highest believable dT/dt you've seen, find out what the change in delivered fuel would be for 10ms at that rate, and show me it makes a 1% difference in injector pulsewidth. If not, you're sacrificing cpu cycles that could be used for something else, and using space on it as well. I know it seems like a PITA to do these propagations, but they give you answers relatively quickly, and keep people from me like soapboxing. :-)
Let's just give up and use MS :-p Seriously, it's not about if, it's about how :-) I think sampling them in the ISR is fine and almost instant. I think losing some samples makes no difference at higher revs anyway. I think we can achieve synchronous sampling at high speed with transfers in the same piece of code that does the rest of the calculations. Therefore we have no problem.

Boy, hasn't this thread gone Off Topic! :-) For the best. Now we have code to generate thermistor tables, a gui to make it easy, and a plan with regards doing the sampling and lookups. Sweet.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
MotoFab
1N4001 - Signed up
Posts: 307
Joined: Thu May 29, 2008 1:23 am
Location: Long Beach CA

Re: Coolant and Inlet Air Temps Transfer Required Accuracy??

Post by MotoFab »

Fred wrote:Here's the thing. We are aiming to do the calculations as close as possible to the event right, and with the most up to date data. Now, for temp, maybe it doesn't matter a lot, but what about MAP? you MUST sample and average and process this for each calculation or more often.
Yes, what about MAP. The plan is to sample and average on interrupts. I do not know, does that mean crank tooth interrupt, or scheduled interrupt?

How is port wall fuel, and evaporation, controlled and accounted for using average MAP values?

- Jim
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Coolant and Inlet Air Temps Transfer Required Accuracy??

Post by Fred »

MotoFab wrote:Yes, what about MAP. The plan is to sample and average on interrupts. I do not know, does that mean crank tooth interrupt, or scheduled interrupt?
The plan changed to sample only on interrupt and tolerate the loss of samples at high RPM where the calcs won't be getting done often enough. Currently the sampling is done on the crank teeth interrupts when fuel is scheduled, but it could be done in the fuel isr or the ign isr or on different crank teeth, or on the RTC/RTI clock ISR with some calcs as to when to do it and when to not do it (thats the least good idea).
How is port wall fuel, and evaporation, controlled and accounted for using average MAP values?
Of course, wall wetting stuff has not been implemented yet. That is done on a time basis anyway, so provided it is periodic and fairly often it can be done in the main loop or RTC/RTI sections. It doesn't need to be done per cycle IMO. It would be better if EVERYTHING was done once per injection, but I don't think our CPU is up to that really. It might be though :-) I'm fairly confident that having VERY up to date calculations and measurements will mean that "accel enrich" ceases to matter as much as it once did anyway. A lot can change in an engine over two revolutions, and in days gone by, MS did its fuel calcs about that often. Far from ideal. MS2E is a big step in the right direction in that respect from what Ken has said, but still not quite there yet. MS3 should be pretty cool if they can stabilise the highly optimised code enough. Though it will be pricey! Hence us :-) Think of it as a "cheap and open ms3".

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
Post Reply