Some news...
 
I tried different things for CPU temp.
 
A circular buffer smooths the display. But I won't go further with this as I tested something very different and much more simpler with success !
 
I uninstalled FAN Xpert+, and played with QFan parameters in the BIOS. I now use this : 20% (minimum) for 20°C (minimum), and 100% (maximum) for 75°C (maximum). The curve seems to be perfectly linear ! The formula that computes temperature from PWM fan control signal duty cysle becomes : T = 0.6875 * DutyCyclePercent + 6.25
 
I tested several monitoring softwares for comparison with this formula :
 
SpeedFan and OpenHardwareMonitor gave bad results, as bad as FAN XPert+ : temps are far too low to be correct. 35 to 40°C with minimal cooling and all 6 cores at 100% is simply impossible !
 
OCCT and CPUID HWMonitor gave same plausible readings for cores temps (50 to 54°C at full load, minimum cooling). OCCT often loses 1 or 2 cores temps (sometimes gives continuous 25°C or 85° !). With this new BIOS parameters and new routines, I got values very near to the temp of the hottest core displayed by these tools (OCCT and HWMonitor) : 1 or 2 °C difference. Under BIOS, I get exactly the same temp (AFAIK, only 1 core is in use). (will have to make a small video, but no much time to do this)
 
So, I concluded that the QFan control algorithm retains the hottest core temp, and then calculates the duty cycle according to a linear curve defined with these 4 BIOS parameters : % min, T min, % max, T max. Linear, without discrete steps or thershold values...
 
This is exactly what I was dreaming of !!! And this means that the CPU temp monitoring is now independant from the OS.
 
I also simplified the code : only one PWM sample every second (or whatever needed), without calculation of a mean value, and no more circular buffer (no more "inertia" that costed a lot of CPU clock cycles). My display now fluctuates the same way that OCCT and HWMonitor do : 1-3°C (idle or at load). This is far better than the fluctations I had using a FAN Xpert+ custom fan curve.
 
Therefore, I could maybe get results with the GPUs. But first, a "fan emulator" has to be built to fake the 780ti closed loop control. I have some PICAXE around, AFAIR, they are better than Arduinos as signal generators. But they have to be programmed in BASIC, and I really hate BASIC : lost after 20 lines or so of this ugly non structured langage.

It will take ages to be achieved !
 
Everytime a problem is solved, a new one is coming...
 
Previously, I wrote that I got rather good CPU and GPU readings through the PWM fan control signal. I was wrong. In reality, readings where good because they were inacurate !
 
I am a beginer with Arduino's. I did'nt know exactly how pulse durations are measured. In fact, time is measured by counting (incrementaing counters), and then calculating time knowing the number of machine cycles used by the routines. After some readings, I could greatly optimize frequency and duty cycle measurements. First, I got better readings, and then I could identify the CPU probe comparing the readings with Asus Probe II and HWMonitor.
 
The probe identified "CPU" with BIOS and Asus Probe II is called "TMPIN3" in HWMonitor. This probe is the temp probe used by the BIOS for fan control. TMPIN3 gives readings 9-10°C lower than "package" and core probes. The use of this probe is the reason why CPU temp can be lower than ambient ! I tested with OCCT, running 1, 2, 3...12 threads (1-6 cores). Now I can really get CPU temp at hardware level by the fan header : just have to add 10°C.
 
I also determined the accuracy of the readings (CPU and GPUs). It is'nt good, and cannot be using the Arduino Mega, due to the 16MHz clock and the PWM signals frequencies :
 
I measured (using the Arduino, to be verified using the f-meter) :
CPU PWM frequency = 20.5 kHz
780ti PWM frequency = 29.5 kHz
 
PWM signal analysis is done with counters (signals hi and lo state)
 
CPU : 1 period = 36 steps
Delta T = 55°C, delta duty cycle = 80%
80% and 36 steps per period -> 2°C resolution
 
780ti : 1 period = 25 steps
Delta T = 55°C, delta duty cycle = 80%
80% and 25 steps per period -> 3°C resolution
 
It is *VERY* bad ! Accuracy cannot be greater than resolution (at least 0.5°C needed for display). The only way to go is to replace the Arduino Mega (16MHz) with a Arduino Due (84MHz). 84MHz would give 0.5°C resolution.
 
I choosed the Mega 2560 because it uses 5V logic (easier). I was wrong...
 
Replacing the Mega with the Due means that the code I wrote and optimized for PWM reading is useless : the Due can fire interrupts on all digital inputs : far better, and very different methods for duty cycle measurements.
 
The Mega will probably also need very different routines for fan control...
 
Now have to order one and redo from start.

FanDuino v2.0 !
 
I am currently reworking the fan controller project a different way. I dropped the Arduino Mega and the touch screen. The controller has been replaced with a much more powerful Arduino Due and the display with a simple 2x16 LCD. The Due allows as many IRQ inputs as needed, and the higher clock frequency gives a far better accuracy for RPM measurements. It also allows a better control of PWM outputs : just two #define have to be modified in a header in order to get exactly 25KHz : no need to tweak prescalers or other tricky things.
 
The controller will fit in a modded CD reader case. There will be a "motherboard", a 2x16 or 2x20 display, some buttons and a rotary encoder. Most of the parameters will be entered with a Windows app.
 
The perfect case : an old CD reader, easy to take apart. It is a very common model, still avalaible : Cyber Drive 240D, picked in my junk.
 

 
The idea : a "motherboard", designed as a custom breakout board.
 

 
The actual controller, on my homebrew poor man's ELVIS (National Instruments ELVIS is an amazing but extremely expensive breadboard) : Arduino Due + USB module + Bluetooth module. The Arduino Due has two USB ports, but using an external one makes it easier to customize, for example to get an explicit "FanDuino xxx" in the Windows Device Manager. I test with the front push pull only. No need to connect all fans and pump.
 

 
 
 
The Windows app is a tray application. It displays information about CPU, GPUs, fan speeds, temperatures. Unfortunately, there is no mean to change GPUs fans behaviour and turn PWM out into a "temp sensor". Using NVAPI, I found that fan controllers are GPU enbeded, and the "end user" NVAPI offers no useful fan function for this project. Maybe the "Non Disclosure" (NDA) version does, but I am sure I will never have access to. One can read some information with the "end user" version : temps, but not power % (it is stupidely reserved to registered developpers. Why ??????? Intel API return this information for i7 and others).
 

 
The fan control is the most useful feature. I coded Arduino routines for automatic calibration. The controller can determine start, max, and stall PWM duty cycle and speeds, ramping and coasting durations, and records the response curves. It communicates with the Windows software.
 
Each and every PWM channel has its own custom control curve, and there is a general cooling slider. It works the same that Afterbuner/PrecisionX, with control nodes. This tab gives a quick view of the fan custom curves : red = fan inactive, magenta to blue gradient : between stall and start speed (need special control), green gradient = normal. The yellow vertical line shows the main control, relative to the custom curves.
 

 
Curves can be displayed clicking the ListView control. Two tabs : control curve and fan response. Here, how I want to control push pulls. On my rig, push pull adds little cooling but lots of noise. So, I want to run the second fan group of the push pull only near the end of control curve : the second fan group will run only when main slider is set from 80% to 100%. I also want the fans not start all together : this rad will start getting air when slider is > 20%. And I dont want the fans to receive a PWM signal of more than 80% (see below for explanations)
 

 
The fan response curve is plotted, and helps to noise optimization. On this curve, one can see control hysteresis (stall vs start). This curve also shows what happens when PWM duty cycle is more than 80% : speed stays nearly the same all the way, and is unstable. The curve does not show the consequence, but blieve me : an unstable fan produces lots of noise. So it must not to be run at more than 75-80% : it will produce only produce noise, not air.
 

 
Coding is not that easy, as I have many C++ classes to be compiled under two environments : Visual C++ and Arduino (probably GCC). Communications through USB and Blutooth are also difficult : I found no suitable libraries, so I have to do my own. And I have no emulator/debugger for Arduino : trial and error is the only way. It is really time consuming.
 
I also began to trace smartmontools sources with the debugger in order to understand how to access SMART information (for temps) through Intel ICHR. Sources are not commented, and very hard to read... There is absolutely no information on the web.