Easytherm is a tool that helps making curves from a few calibration points for an NTC temperature sensor.
To make the process easier:
- EasyTherm/SensorTable
- [calibration data and hexpatch utility] for the most common NTC sensors. 2400_287 and 2700_287 will be the most popular with v3.3. Should be able to get tables within a few Celsius error from real values, without any recompile or any special tool.
How to update calibration - using hexpatch.exe
Earlier a text editor was used, but users sometimes messed up a line or converted line-endings (win32 weirdness) unintentionally.
hexpatch.exe was developed to help updating the vems.hex with the calibration tables
- changes max 32 lines for airXfactor (near the beginning, 0x100 .. 0x2FF address), since airdenfactor and matfactor are separate tables
- changes max 16 lines for cltfactor (also called thermfactor), since it is just 1 table (address 0x300 .. 0x3FF).
(hexpatch binary is also available on linux, or in sourcecode, but linux users rarely have problem with copypasting 32 lines)
RUN
- hexpatch.exe vems.hex < airXfactor_3000_287.hex > vems_1.0.30_airXfactor_3000_287.hex
command will change the airdenfactor _and_ matfactor for 3000,287 parameters. The output is named accordingly (instead of the generic vems.hex) for distinguisment in your storage. You can copy to vems.hex before uploading with upload_firmware.bat (or change the .bat to use the long-descriptively-named file).
- hexpatch.exe vems_1.0.30_airXfactor_3000_287.hex < cltfactor_2252_287.hex > vems_1.0.30_airXfactor_3000_287_clt2252_287.hex
changes coolant temp calibration in the file previosly patched (with the airX 3000_287 airdenfactor and matfactor tables). So coolant (thermfactor) can be changed independently (or left alone, if you like default coolant temp readings).
Example - verified on the bench, works as expected
From the unzipped ntc_airX_cltfactor.zip (see above), using
- airXfactor_3000_287.hex This reads -02C where 1.0.18 (or anything before 1.0.29) read -16C (at 3.92V on the ECM I measured, serialnr=375) => very close to MembersPage/NanassyPeter's MAT calibration.
- verification of these .hex files is similar as of firmware vems.hex: perl bin/prog.pl /svn/firmware/utilities/propertherm/ntc/airXfactor_3000_287.hex Report 2 page error (address 256 and 512) for air, and 1 page error (address 768) for coolant table mismatch. Similarly, if you get 1..3 pages mismatch (address 256, 512, 768), that means same firmware, only air/coolant tables differ. If you keep track of what firmware you upload, and name hexpatched firmwares sufficiently, you never need this.
- cltfactor_2400_287.hex This reads -07C where 1.0.18 (or anything before 1.0.29) read -16C (at 3.92V on the ECM I measured, serialnr=375) => very close to MembersPage/MarcellGal/EngineSwap 's coolant calibration.
- used a vems.hex (actually 1.0.30 not-yet-released version)
- by replacing the sections in a text editor, see result [vems_air3000_287_clt2400_287.hex (zipped)]
- note the descriptive filename! Always keep track of the firmware uploaded to a certain ECM (serialnumber!), because verification will fail if either the temperature tables or anything else in the vems...hex is different and you will not be able to verify firmware integrity, and will not easily tell what you uploaded if you don't keep track.
How to pick tables
Currently 56 example-tables are provided (28 airX + 28 clt), picking the best will closely match to almost any curve normally found in real life.\n
egrep 'adc=26|adc=50|adc=100|adc=150|adc=200|adc=240|Using' ntc_propertherm.out
command or inspection of ntc_propertherm.out file will help you pick the best curve, eg. if you had measurements (eg. reading MAT=-16C when in fact airtemp sensor was at 0C) with the tables in the released firmware.
diff=14 means the new table will display +14F (+8C) higher (at certain hightemp/lowtemp point) than the traditional "factory-released" firmware.
- Don't hesitate to ask for help after documenting (on your MembersPage) your measurements , readings, wishes as precisely as you can (someone with experience will be able to point to a good curve in 10 minutes, unless you have some very weird setup or problem).
You'll need to hexpatch (or cutnpaste) your favorite tables to vems.hex (every time you upgrade)
- that can be applied to vems.hex with hexpatch command,
- or any text-editor (256 bytes of calibration lives in a 16line snippet, easy to change vems.hex manually)
PTC - very special type sensor
- [ PTC tables] With a PTC MAT that exactly matches Miska's [Audi PTC MAT] airXfactor_2252_256.hex applies (admittedly, the 2252 is confusing, it means scale up the reference curve's parameters by *2252/2252=1.0 which means to use the reference values directly; Historical reason, see standard NTC curve to understand). Note that min to max range for a PTC is worse than for an NTC, appr. 1/12 of the ADC range is utilized for -40..+101C. This makes it more sensitive to calibration.
- note that we keep distributing vems.hex with similar calibration data as used since long (eg. in 1.0.23) so behaviour (temp-reading and airdenfactor enrichment) does not change unexpectedly.
The coolant and manifold air temperature sensors are (in 99.9% of cases) NTC type. The ExhaustGasTemp sensor can never be an NTC type. [ATP Inc] has some useful notes about [NTC] and [PTC] sensors.
Easytherm
ONLY for advanced users, because firmware recompile needed !!!
files are located in the files section of the Megasquirt group at http://groups.yahoo.com/ or directly from [msefi.com]
Steps:
- 3 calibration points must be measured. Say, at sensor temperatures
- 95C warmed engine
- 20C cold engine (or a little warmer, say 35C depending on the sensor, as the middle value should be around the inflection point of the thermistor curve)
- and 0C (a cup of icy water before installing the sensor to the final location)
- Check pullup resistor values, v3.2 has 2.7k resistor instead of 2.49k used in megasquirt. If incorrect pullup value is used, there will be a few degrees error in the lower temperature range.
- .inc file can be generated with easytherm, or other means. This is a very simple function, a few lines.
- note: (AFAIK) MSToolsII can also be used to create .inc files
- but: the upload function in MSToolsII is NOT compatible with GenBoard. GenBoard's has it's own firmware generation and upload procedure. The .inc files need a slight automatic formatting (into .c files) with the following commands, so that they will actually be used in the firmware build process:
- perl bin/inc2tbl NAME-OF-THE-MAT-INC-FILE > etc/airdenfactor.c
- perl bin/inc2tbl NAME-OF-THE-CLT-INC-FILE > etc/thermfactor.c
- See GenBoard/FirmWare for firmware compiling and uploading. NOTE THAT THIS IS FRUSTRATING for MOST USERS and NOT RECOMMENDED. Takes appr 1..2 hours for initial setup (after that it's 5 mins), while using hexpatch.exe is no more than 5 minutes.
Very important to review the tables before using
- First check (no matter what tool you use) that the tables are monotonous increasing / decreasing (whichever applies).
- You might want to edit the 0 and 255 line to NOT assume failed sensor. It's often a bad idea (eg. 255 reading does happen with NTC, in very cold near -40C! A guy in sweden almost blew up his engine because of using the default megasquirt table asis, with the 255 adcreading assuming "failed sensor" and 76C).
-40,395 -20,425 0,457 20,490 30,503 40,520 60,555 80,585 100,620
The following 3 picked points:\nÿ3ÿ
generated non-monotonous tables. The fitted parabola was totally trash for what it was ment. Either use propertherm or make the tables manually.
PROPERTHERM Developer TODO - to make some of the above few simple steps automagic:
- note that automatism here might be dangerous. The user should be aware if changing the tables, and he must know what he does/uses (otherwise he might forget when upgrading firmware!!!). Best to check the vems.hex table manually too.
- add makefile entries, so inc2tbl is automagically run if etc/airdenfactor.inc is newer than etc/airdenfactor.c
- likewise for etc/thermfactor.c
- generate etc/airdenfactor.inc from simple text-based etc/airdenfactor.cal textfile of a few calibration points (containing Celsius => whatever)
- update the above steps to match
MembersPage/PhatBob Would it be possible to write a quick explaination of just how I feed Propertherm data?
Propertherm - in more detail
a utility to make calibration tables. Main functions:
- Best curve fitting on user-supplied data (any number of points! Less than 3 points make little sense of course). This is an advanced function, uses simulated annealing. The output is "model parameters", which is aref and ntc resistance when thinking in the NTC model. The best-curve fitting is currently for advanced users. It is documented in the code:
- add_adcread_internal()
- and temp_but_read() for useful functions to specify $measured->{} points
- Printing output "hex-snippets" to .hex files for the given modelparam. Format is originally in vems.hex snippet form, but easy to make it output any desired (eg. .inc) format. At the same time, useful info is plotted on how the new table differs from $orig_mat_byadc, $orig_mat_bytemp that read_inc() read from an .inc file from standard input. See
- print_factor() can be called for any modelparam (check the double for-cycle that actually calls print_factor()).
We that fitting a 2nd order polynom (parabola) to 3 measured points over the whole temp-range (IIRC this is what easytherm does, I read it a long time ago, but I couldn't download to check) gives very poor fitting to the NTC curve.
The proper way is:
- DONE: use proper NTC calibration data (we found appr 20 points at elfa, and another pdf, see /svn/vems/chipdocs/...). Let's call this NTC_res[]
- DONE: interpolate between these points. If we have 20 datapoints in NTC_res[0] to NTC_res[19] array, we can fit 18 2nd order poly (call it NTC_res_poly[1] to NTC_res_poly[18], index 0 is not used ) around index 1..18 : note that this is a short section, not on the whole curve!
- I solved the equation with parabola.oct (http://www.octave.org program). simulated annealing could also be used (more cpu-clocks but this is a one time operation on PC).
- DONE: blend between neighboring parabolas, for example between NTC_res[3] and NTC_res[4] we blend between NTC_res NTC_res_poly[3] and NTC_res_poly[4]. We call the result ntc_res_blend().
- DONE: the model scales the ntc_res_blend() according to parameters. aref is appr 255, which is the open-circuit (Rntc=inf) adc reading (might be > 255, since it is theoretical). Also, not real (10..11 bit) ADC reading, but truncated to 8 bits.
- DONE: model actually uses $model_nominal_res = $model_param->[0]; and $model_nominal_aref = $model_param->[1];
- DONE: we find model_nominal_res and model_nominal_aref that gives best fitting between user-specified datapoints (simulated annealing makes it possible to use any number of points!) and ntc_res_blend()
- we like the values where sum( err * err) is minimal
- DONE: in simulated_annealing(), updated errsquare to use model() of ntc_res_blend() and sum( err * err )
- DONE: print it in vems.hex form, so any factory vems.hex can be easily changed to contain the new tables (0x100 .. 0x1FF, 0x200..0x2FF, 0x300..0x3FF for the 3 tables: airden, matfactor, thermfactor, check makefile for the exact order)
- DONE: railing, and check output for sanity
- TODO: during simulated annealing, add restrictions for the model parameters, so they cannot deviate too much
- DONE: drop the adc=0 and 255 special values according to GenBoard/UnderDevelopment/FirmwareChanges
- TODO: make a CGI-wrapper for best-fit algorithm that prints best modelparam values for user-supplied temp data:
- preferrably feeding temp_but_read() from CGI data (user-supplied)
- and default firmware matfactor.inc (currently read from STDIN, will need to come from a file) for reference.
- TODO: generate ptc and release in same zip as ntc data, just in separate subdir (ptc/)
developers: /svn/firmware/utilities/propertherm/