ADC_INTERNAL_TEMP calculation in Example4 appears to be incorrect

[davexre]

Subject of the issue

The calculation method for ADC_INTERNAL_TEMP described in the code for Example4 appears to be off by a wide margin - at least for the RedBoard Artemis.

Your workbench

• What platform are you using?
  2018 MacBook Pro, Arduino IDE 1.8.12, SparkFun RedBoard Artemis

• What version of the device are you using? Is there a firmware version?
  Apollo3 IC revision code: B0
  Arduino library v 1.0.30

• How is the device wired to your platform?
  USB-C cable

• How is everything being powered?
  via the USB cable

• Are there any additional details that may help us help you?

Steps to reproduce

Connect a RedBoard Artemis and run Example4_analogRead

Expected behaviour

I would expect to see a valid temperature in degrees C - for normal room temperature, somewhere in the neighborhood of 20-22 (+/- 3 per the notes in Example4's code).

Actual behaviour

The code outputs a temperature in the 440 degree C range, instead. Example rows look like:

A3: 16383 VCC/3: 9134 VCC: 3.34V internalTemp: 441.09 vss: 0
A3: 16383 VCC/3: 9130 VCC: 3.34V internalTemp: 440.31 vss: 0
A3: 16383 VCC/3: 9131 VCC: 3.34V internalTemp: 440.84 vss: 0
A3: 16383 VCC/3: 9133 VCC: 3.34V internalTemp: 441.64 vss: 0

I added a bit of code to output the intermediate math steps - the data corresponding to the last row above is:
Internal temp raw: 8221 internal temp voltage: 1.68

So, 8221 is the raw read off the ADC, and that calculates to a voltage of 1.68 in the code (using 3.34v as the reference voltage).

@stephenf7072 and I had a discussion on the SparkFun forum ( https://forum.sparkfun.com/viewtopic.php?f=169&t=52770 ). He conjectured that Example4 should really be using 2.0v for vref (which corresponds to the ADC reference voltage), and then it looks like there's an offset on top of that. Subtracting 247 (for Stephen) or 242 (for me) gets us to a result like looks like our room temperatures. So, a raw reading of 8221 becomes 22C for me, which perfectly lines up with my current room temp. Basically, this code:

float temperature = (analogRead(ADC_INTERNAL_TEMP) * 2.0 / 16384) / 0.0038 - 242)

I've dug into the library code here a bit, but I've not yet pinned down the issue - this might not be something I can find without more intimate knowledge of the hardware spec.

[davexre]

Note - the document https://github.com/sparkfun/SparkFun_Artemis/blob/master/Documents/Apollo3_Blue_MCU_Data_Sheet_v0_10_0.pdf mentions on

On page 2, it describes the temperature sensor like so: "Temperature sensor with +/- 3oC accuracy after calibration" (emphasis mine!)

On page 774, it lists the sensor accuracy and slope - this is where +/- 3 degrees C accuracy, and 3.8 mV/degree C are listed.

I'm not finding a method described in the document to calibrate the sensor.

[nseidle]

Thanks for reporting. Internal temp sensors are notoriously inaccurate but I doubt you're annealing steel near by. I'll try to dig into this today.

[davexre]

Thanks, @nseidle !!

You know, it's funny that you mention annealing steel - the project I'm working on is actually an induction annealer for brass. I have a separate thermistor that will measure temperature at the capacitors on the induction board - I was just curious if I could use the internal temperature as a gauge on overall internal temp within the enclosure. Mostly as a sort "emergency stop cause things are way out of whack", not as a fine tuned temp. Temps within the enclosure shouldn't exceed 90F - I'd be surprised if they get there, even.

If it's not possible, I'm not too worried about it from a practical standpoint - I can easily add another thermistor to the configuration. But, it does make sense that Example4 shows a realistic way to use the sensor - or at least documents what to expect, if a real temperature isn't actually derivable.

[nseidle]

As usual, Ambiq has an example demo'ing how to successfully read the temp sensor. adc_vbatt.c from SDK. They use a hal call that looks like this

        ui32Retval = am_hal_adc_control(g_ADCHandle, AM_HAL_ADC_REQ_TEMP_CELSIUS_GET, fVT);

to take the ADC value and then wash it with calibration values and offset changes. The output of which looks very good:

So now I'm just figuring out how best to plumb this into our core.

[nseidle]

Got it fixed. Adding a new getTemperature() function to make it easy. Branch is here. PR is here.

Please try it out and reopen if you have any concerns. Note, if you pull the branch I recommend changing platform.txt in the following way:

compiler.path={runtime.tools.arm-none-eabi-gcc-8-2018-q4-major.path}/bin
#compiler.path={runtime.tools.arm-none-eabi-gcc-7-2017q4.path}/bin

This will fix the printing of floats due to a compiler issue.

[stephenf7072]

Brilliant, thanks Nate. Not just on the the getTemperature(), which works nicely, but for the change to platform.txt, that was stopping me from being able to try out the new core in it's entirety.

[davexre]

Working on testing, too. First time doing this, so it's taking me a bit to figure out how to set things up to use Nate's code correctly in the IDE.

[davexre]

Confirm that the example now works as expected in my environment, too! And, thanks, Nathan for helping me get my Arduino IDE environment squared away!