Good work, here is the rather plain GUI :
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.
Coolant and Inlet Air Temps Transfer Required Accuracy??
Re: Coolant and Inlet Air Temps Transfer Required Accuracy??
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!
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!
Re: Coolant and Inlet Air Temps Transfer Required Accuracy??
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.
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!
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!
Re: Coolant and Inlet Air Temps Transfer Required Accuracy??
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.
Now I just have to talk you out of using it.
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.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.
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.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
Not sure, have to think about it more. LATE, must go.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.
Re: Coolant and Inlet Air Temps Transfer Required Accuracy??
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 :-)
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.
I agree, I think losing a few shouldn't matter too much really.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.
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.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.
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!
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!
Re: Coolant and Inlet Air Temps Transfer Required Accuracy??
I'm easily impressed by GUI's, especially those with "too much" instead of "too little"....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 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. 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.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.
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.
Re: Coolant and Inlet Air Temps Transfer Required Accuracy??
I'll respond to Abe's post a little later.
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.
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!
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!
Re: Coolant and Inlet Air Temps Transfer Required Accuracy??
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.
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!
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!
Re: Coolant and Inlet Air Temps Transfer Required Accuracy??
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 :-)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.
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 :-)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.
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)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.
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.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 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.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.
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.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. :-)
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!
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!
Re: Coolant and Inlet Air Temps Transfer Required Accuracy??
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?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.
How is port wall fuel, and evaporation, controlled and accounted for using average MAP values?
- Jim
Re: Coolant and Inlet Air Temps Transfer Required Accuracy??
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).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?
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".How is port wall fuel, and evaporation, controlled and accounted for using average MAP values?
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!
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!