Hi all,
while measuring RMS Voltages with our Picoscope 4824s, we have noticed a drop in the voltage in the minutes after startup. We now believe we have chased this behaviour down to the temperature behaviour of the ADC-Chip.
The first image shows the general behaviour at startup (y-axis is RMS Voltage according to the Picoscope, custom Software):

The source here is a (warmed up) Fluke 5520A calibrator generating 1 V at 50 Hz, cross-checked with a 6.5-digit-multimeter. It takes 5-10 Minutes for the voltage to settle to a constant value.
We also gently heated up parts of the circuitry with a hair dryer. The following image shows the same startup process while pointing the hair dryer at various parts of our and the picoscopes PCBs. The big drops in voltage at the 400-s- and the 550-s-mark occur when the ADC-Chip is heated up very gently.

We now assume that what we're seeing at startup is the internal reference of the ADC heating up, which increases its output voltage, which in turn decreases the measured voltage.
Is this correct or at least plausible? Has anyone ever made the same observations? It's probably impossible to do anything about this, right? The only things that came to our mind were active heating and on-chip-temperature measurement with software compensation, both of which sound like "Now you have two problems":)
I realize we are operating at the accuracy limits of the Picoscope here, and also that the operating conditions for the Picoscope are only 20°C to 30°C. The operating conditions of the HMCAD 1102 are given as -40°C to 85°C in the datasheet, although no temperature coefficients or accuracy dependencys are mentioned.
I am thankful for any comment.

Another thing struck us in the HMCAD1102 datasheets: It is capable of 14bits, at 65 Msps. Given the chance, we would take an 8 channel, 2Msps, 14bit scope in a heartbeat. Is there a chance of a driver update or a new version that enables this?

Is there a specific reason why you are looking at the start-up behaviour?

Starting conditions can easily take DAQ equipment outside of the range of operation stated in the specifications for that equipment. That is the nature of equipment that relies upon certain conditions in order for precision components to be valid for use (changing conditions during the startup process can affect the output of a voltage reference). Having said that a very long settling time, could be the indication of a fault condition.

It is good practice in Test and Measurement to give equipment some time to settle to a steady state after turning it on. In your tests the PicScope appears to take up to about 5 minutes to stabilize. We generally recommend leaving our products for a while (10 to 20 minutes) after switch-on before using them, for maximum accuracy (although there are exceptions).

Regarding your 14-bit reference, If you look at the data sheet there is a specification for the Effective Number Of Bits (ENOB) which is given as 11.3. So, with the resolution increased to 14-bits, there would be no improvement in the smallest voltage level that could be resolved in an actual application by the PicoScope.

Just to add as well - if you look at the datasheet you can choose between a 12 or 14 bit output data width but its not a 14 bit ADC. Oddly its 13 bits so you can choose to either drop the least significant bit which is mostly noise or have the 13th bit at the expense of slowing the product down.

If you do not need the 80MS/s per channel then try using resolution enhance mode in PicoScope - this should give you a better end result than enabling the 13th bit which unfortunately is not possible in the hardware.

If you need less than 8 channels then consider also the PicoScope 5000 series (4 channels of 14 bits at 125MS/s) or the PicoScope 4262 with 2 channels of 16 bit resolution.

Thanks for the answers!
We noticed the settling behaviour at startup but we are actually more concerned about the general temperature dependency, as we might conduct measurement outside at lower temperatures. I guess we have to account for that, I just wanted to make sure we don't miss any other important aspects.
Thanks also about the answers concerning the bit resolution of the ADC.
About the resolution enhancement - we use our custom software using the drivers under Linux, so we can't use that. I think I read somewhere that the hardware downsampling offered in the driver is different from resolution enhancement, because that uses a rolling average and the downsampling uses block averaging - is that correct?
We tried to use downsampling, but the CPU load increased sharply. The API docs state that downsampling is performed on the scope, so are we missing anything or are there any obvious pitfalls we stepped into?
Thanks and greetings!

Regarding the general temperature dependency, outside of the specified environmental range, you could get the PicoScope calibrated for the additional environmental range (as long as you don't exceed the operating range limits).

You are correct regarding the type of averaging used. For downsampling ratio_mode_average calculates the average as the sum of all the samples in each block, divided by the size of the block, so it is block averaging, while Enhanced Resolution Mode implements a type of moving average filter on the data. So, downsampling is not a good way of cleaning up the signal. Better methods would be:

Implementing a moving average filter in your application. It is a fairly simple implementation in code and there are numerous examples on the Internet.
If you have a repetitive waveform, segmenting the sample buffer to collect multiple waveforms and then averaging the samples across the waveforms.

If you are retrieving samples in Block mode the downsampling is done in the software if the downsample ratio is 9 or less. If the ratio is 10 or greater the downsampling is done in the hardware. So, if you are software downsampling you will be retrieving all the sample data, which will increase the CPU overhead. If you are using streaming mode then the downsampled data is sent along with the streamed data which can also increase cpu overhead.