FW ATMEGA328P and High Temperature Sensor

Good afternoon…
I am using the GrovePi + with an analog High Temperature Sensor that has a cold junction reference on the PCB. I am having issues with the RTD probe temperature jumping around as it is being sampled on the order of 4 degrees or so while resting at room temperature. The cold junction measurement is pretty rock solid. I feel that there may be a settling time issue in the firmware of the Atmega328P when doing the A/D sampling for this sensor. I proceeded to go to the Firmware section on GitHub but only see files there that seem to pertain to IR stuff…(In short I was looking through files and saw NO A/D stuff).

Can someone point me to the A/D sections in the firmware along with the pin configuration?

I don’t understand the I/O mapping either as the python file (high_temperature_example.py) want to use pins 15 and 14 but clearly the schematics show pins 23 and 24 for A0 and A1??

Finally (assuming I can get my hands on the firmware AND assuming I want to make a change)…If I make a change to a .cpp file how do I go about creating a new “grovepi_firmware_update.hex” using linux command line tools?

Thanks
Steve

(Not DI, just a user here) The function parameter in named “pin” but is a misnomer - it actually is the “register” or “index” to the start of the information corresponding to the storage of information associated with the port.

It may or may not be settling time. It may also be related to other factors 1) the value of the LSB of conversion, 2) the precision of the sensor as a percent of the value, 3) sensor noise or variation as a percent of the value, and this one is perhaps controversial 4) the stability of the reference voltage to the A/D under varying processor load.

Using an average of several readings will reduce the uncertainty by one over the square root of the number of samples.

I don’t know what the design specs for the A/D are, but I doubt we should expect better than +/-3% accuracy on any one conversion - so for 78degF it might be reasonable to expect +/-2degF readings even if the conversion precision is 8 or 10 bits covering 500 degF giving half degree precision.

Again if that variation is +/-2 deg and we want +/- 0.5 deg accuracy, we could average 16 readings (2 div (1/sqrt(16))) = 2 div 4 = 0.5) and expect the average reading to bounce around +/- 0.5 deg.

BTW, I’m not a mathematician nor statistician, so I could be way off base here. Measuring reality with any certainty is certainly really complicated.