Coolant and Inlet Air Temps Transfer Required Accuracy??

[shameem]

The error msg seems to imply that the glade-sharp dll does not exist and/or is not registered.....
Installing GTK# (http://forge.novell.com/modules/xfconte ... 32-0.0.exe) *might* help - if that doesnt help you may have to run it with mono.....

[Fred]

FreeTherm 0.3 is released, much has been done including generating our first C file for inclusion in FreeEMS which I checked into SVN only minutes ago :-)

Shameem did some work on it last night, and I did a lot to it today to bring it up to useful and functional spec.

Changes :
Shameem :
Added slots/signals
Added math for generating SH coefficients
Added file writing code
Added deprecated file dialog
Added some state handling code
Deleted my Makefile
Deleted my safety code
Deleted my about dialog or at least stopped it working :-)
Added number handling code (broken for floats)

Fred :
Fixed math
Fixed file writing code
Changed dialog to up to date version
Renamed many variables
Re added my Makefile and changed it to suit new filenames
Re added my dialog code
Re added my safety code
Added slight structure to the code
Changed number handling code (doesn't reject random chars? (it should))

TODO :
Genericise everything such that all the controls work as anticipated.
Figure out howto/ifitcan work on windows

Right now it's useful to me though, which is the key thing :-)

Download :
Version 0.3 : https://sourceforge.net/project/showfil ... _id=608092

Legacy :
Version 0.2 : https://sourceforge.net/project/showfil ... _id=608087

I need to send you an email Shameem and discuss a few things. Thanks for your help :-)

Fred.

[AbeFM]

Yeah - but I don't have a sense for how much timing is pulled when. Which is why I said I need a better model. It's the best place to start since I don't have any realistic numbers.

[shameem]

Shameem did some work on it last night, and I did a lot to it today to bring it up to useful and functional spec.

Changes :
Shameem :
Added slots/signals
Added math for generating SH coefficients
Added file writing code
Added deprecated file dialog
Added some state handling code
Deleted my Makefile
Deleted my safety code
Deleted my about dialog or at least stopped it working
Added number handling code (broken for floats)

Fred :
Fixed math
Fixed file writing code
Changed dialog to up to date version
Renamed many variables
Re added my Makefile and changed it to suit new filenames
Re added my dialog code
Re added my safety code
Added slight structure to the code
Changed number handling code (doesn't reject random chars? (it should))

Oh man - you make me feel like i am unfit to code - even though there are reasons for every little thing i did in that code....

[Fred]

Oh man - you make me feel like i am unfit to code - even though there are reasons for every little thing i did in that code.... :( 8-)

I'm sorry, I didn't mean it to come across like that. What you did was definitely helpful and good overall. Just a few things that were slightly annoying, the rest was me figuring out GTK and C# etc.

The only parts of the math that was wrong was the ADC > resistance bit and the use of Ints instead of Doubles. I had to sit down with paper and figure that out by rearranging the equations lol. It's been a while since I had to do that. I'll be doing it again soon I suspect.

Overall it's good. With our powers combined, tonight we got this and this :





Which is excellent! It won't be long and we'll have some real calculated pulse widths! :-)

I'll send you the latest tweaked cs file tonight before I retire.

Thanks again,

Fred.

[MotoFab]

Do you fellows know if the thermistor sensor you're using has any self-heating at the current you're driving it at? Self-heating becomes part of the thermistor resistance change, which becomes part of the voltage across the sensor. Driving the thermistor with a good amount of current makes the signal lead very resistant to noise. Sort of like a 4-20mA data link.

Thermistors have a response delay too. That may not be something to factor in the case of the liquid temp sensors because liquid has enough mass, and liquid coolant temps do not change ultra fast.

Off topic, but while I'm thinking about it: MAT changes very quickly on a turbo motor. Faster than a thermistor can track. The uC can use IAT and 'boost pressure' to determine MAT. That, in the related manner which the uC determines airflow mass from IAT and MAP. If there's enough processor time to do that, it can be added at some future point.


Segue from one OT to another OT: Processor workload. The sensor output is read in ADC counts. Those ADC counts can be left as 'counts' and do not need to be converted to voltage, or temperature, within the uC. Instead the uC 'thermistor table' can programmed with the slope between ADC counts.

The PC can display temperature to the user when programming the sensor table, and when viewing sensor reading through a data link. Even though the PC is receiving only ADC counts from the uC.

The data link to the PC can transmit and receive in plain binary, and the PC can do the 'both halves' of the ascii conversions.

I have no idea if the EMS, or the data link, is doing any or all of this. I'm just thinking out loud, as it were, about processor workload. And including some successful common practices.

- Jim

Edit

[Fred]

At 2.2 mA max current when the sensor is close to zero ohms and therefore close to zero power dissipation I doubt any heating is significant. That GM document Shameem posted didn't contain any heating data either.

The MAP + IAT idea is a good one :-) There was some discussion similar to that in another thread.

I don't understand how having a table of slopes will assist us. We'll still have a table and we'll have to do more calculations with it AND we won't be able to use a real physics model of the situation because we won't know what temperature we are at at all. Can you explain how it would work in detail because currently I can't see it :-/

The ascii stuff is only being done short term so I can see values while I write code. Once the serial stuff is finalized that will be implemented and then it will be back to binary again. We are doing the conversions such that the uc knows the temperature. If we didn't want to know, we could just do something that works and is tunable but has no reflection on reality at all and call it MS1 ;-) (to be fair, only some of the values were used raw on ms1, and none on ms2 that i know of) Basically, if the uc DOESN'T need to know the actual value, that is exactly what we will be doing (sending it raw).

Thanks for your input :-)

Fred.

[shameem]

Some interesting links -
http://en.wikipedia.org/wiki/Thermistor ... ng_effects

http://www.latticesemi.com/lit/docs/app ... an6032.pdf
http://focus.ti.com/lit/an/slyt156/slyt156.pdf
http://www.maxim-ic.com/appnotes.cfm/an_pk/1753
http://focus.ti.com/lit/an/sloa052/sloa052.pdf

[MotoFab]

At 2.2 mA max current when the sensor is close to zero ohms and therefore close to zero power dissipation I doubt any heating is significant.

I was thinking your design was using a constant current source to drive the thermistor.

- Jim

[MotoFab]

I don't understand how having a table of slopes will assist us.

Do you know how to do a linear interpolation between two points on a curve?