Thermocouple calibration about t-962-improvements HOT 14 CLOSED

That's an interesting point. It would be nice if such information were available, but I suppose it may not be, given the overall design choices and cost of the device ;).
If they are, then this could be a procedure for finding them and finding their meaning:

• have the original firmware still installed..
• hook up a multimeter for measuring the voltage of the thermocouples
• place the multimeter next to the display
• start recording a video of the display and the multimeter
• start a cycle
• derive the relationship between the voltage and the temperature displayed (ie. use curve fitting to some K-thermocouple formula)

If a calibration number is found from the EEPROM, it could be compared to the constants gained in the previous step.
Alternatively: perhaps someone is able to dump the contents of the original firmware and reverse engineer this particular feature..

from t-962-improvements.

Correct, as far as I can tell the only calibration you have is the gain adjustment in hardware (the blue multi-turn potentiometers). Great that you also confirmed that you got the same data in your eeprom as I did Waldo! I read the same temperature in my code as the original firmware did (when I assumed 20C cold-junction and did not have the offset adjust). The Op-amp used does introduce a small offset error that is individual and the gain probably isn't super exact, but I think that anything more complicated than a standard straight linear approximation of the K-profile is way overkill in this hardware as the ADC resolution with their chosen gain is 1 LSB per 1C.

I'm planning to add adjustable offset and gain adjustment (+/- a few percent) and store them in the "unused" portion of the eeprom. Hopefully the values might even survive a run through the original firmware. I have used the same type of calibration for power supplies in the past and as I'm already in floating-point domain it's relatively fast to do.

from t-962-improvements.

For some reason, it did not occur to me that those pots would be for calibrating the thermocouples. In that case, I would have expected my oven to be more accurate since I did not adjust the pots but I saw temps about 10 C too high.

from t-962-improvements.

Well, the problem is that you need two adjustments per channel (offset + gain), but they only have one (gain). To determine if your gains or offsets are off you can use bake mode and measure two different fairly high temperatures and note actual measured temperature versus the reported left and right temperatures. My gains are pretty much spot on (within a few degrees) but my two offsets needed the adjustments I put in the code.

If you don’t plan to run the original firmware again you can bump the gain on the channels to 3.5x and get a lot higher resolution too!

To calibrate I would recommend running bake at 240C and 140C (let it stabilize for a 5-10 minutes in both cases, and preferably measure the temperature in close proximity to both of the thermocouples). If the actual measured temperatures does not differ by 100C your oven's gains are off. If the absolute values are high or low after gain compensation then the offsets need adjusting. I will add the gain adjustments to the code as well for completeness.

from t-962-improvements.

Thanks. I'll try that.

You probably already know this, but this chip has IAP, so you could use that for storing "setup" settings without using external EEPROM.

from t-962-improvements.

I have seen the IAP parts and was thinking about using it for profiles as well at first, but it seems to be very large blocks that have to be erased (like in a normal NOR flash). Not sure if the normal reprogramming of firmware in FlashMagic issues a chip erase before programming either - that would be a bummer for settings to get nuked everytime a reprogram happens. The external e2 will be ok at least as long as the original firmware isn't run. Hopefully the original firmware just keeps whatever we store at the end of the profiles though!

from t-962-improvements.

Flash Magic can be configured to either erase all flash or to erase only those blocks defined in the .hex file. So to avoid erasing settings each time, you could configure it to erase only "used" blocks and make sure there is no initialization of those blocks in the .hex file.

Also, I noticed that the current build is over 2X the size of one from about 1 week ago. Is this the data for the settings?

from t-962-improvements.

from t-962-improvements.

Wow. I knew redlib was an optimized library but I did not expect it to be 30K larger. Is the linker removing unused parts of newlib?

I noticed that your startup code will decode the processor type, including types that have 32K and 64K flash. I guess those smaller parts would not be possible now that the code size is close to exceeding 64K.

Is there enough extra room in external eeprom for settings? It is somewhat less elegant to embed "global" settings like thermocouple calibration into spare bytes inside the custom profiles, but it may avoid having to deal with IAP.

Another approach to free up eeprom space would be to use a different format for profiles such as 1 byte per point, 50 C to 305 C points or 2 degrees per point. When first running the new firmware, you would read the eeprom and do the conversion to the new format if needed. The downside, of course, is that you would not be able to go back to the factory firmware and still maintain your custom profiles but I personally don't see a need to maintain backward compatibility with the factory eeprom format.

from t-962-improvements.

I would guess not using 'printf' might cause a significant drop in runtime size.

..and I tried removing printf on my hunch and the text size dropped from 64780 bytes to 51612. So that's something to consider. Probably this project doesn't need such a sophisticated printf for its printing needs. Didn't even look at other functions, there could be other opportunities. This change also dropped the text literals, but data dropped only from 2532 bytes to 2492, so it's not that significant.

It doesn't seem like the chip has floating point support, so perhaps if those calculations were changed to fixed point, it would also reduce the size.

from t-962-improvements.

Yeah newlib is pretty bloated. Printf with float support certainly isn't
small (but as you noticed didn't really take much code out when
removed), so there must be a ton of other system stuff that newlib adds
that really isn't necessary. It seems that it is a reentrant version of
newlib that gets loaded as the symbol table is full of functions with _r
suffixes. That will add some more bloat for sure, the redlib one was not
reentrant.

It turns out though that there can be no ovens with 32kB parts as the
original firmware is just over 32kB in size (35840 bytes to be precise),
so the only issue would be if there are any LPC2132/01- or LPC2142-based
controllers out there. We are slightly over 64kB right now. Moving to
fixed-point is one alternative but it is tricky to get the precision
right for PID math.

I have put IAP on hold for the time being as the 2x28 bytes we have in
the eeprom is more than enough for settings right now. Reworking the ee
format to something more efficient is a good move (with built in 1-way
conversion). Now that we are approaching the usability of the original
firmware hopefully very few people will want to revert back!

from t-962-improvements.

Hmm, so I switched to newlib-nano instead with much more promising results (keeping printf floating-point support) and now I'm down to a much more reasonable 41672 bytes of flash utilization (including only 372 bytes of initialized data). Unfortunately the travis-ci builder pulls in a cross compiler that is too old and therefore barfs on newlib-nano. My Ubuntu 12.04 LTS VM gives me arm-none-eabi-gcc version 4.8.4 when running the same installation sequence (and the resulting hex-file works with no issues found so far). The changes sits on the newlib-nano branch for now.

from t-962-improvements.

newlib-nano issues solved, library name changed, all is well again in travis-ci land

from t-962-improvements.

Issue cleanup

from t-962-improvements.