I've chosen to connect it to the PSU through a speed reduction adapter (included in the box by Noctua). Hence, it's running at a fixed speed of 1600 RPM (down from its default 3000 RPM). With this setup, it's close to noiseless.
The computer case is an "Antec 25 Solo II", and there is one 120mm fan in the front (Noctua, sucks air in), and one at the back (blows air out). Both are running at a heavily reduced speed, and are very quiet (barely audible).
The GFX card is an Asus Radeon R7 240 (2GB version), which isn't generating much heat.
Below are numbers from my system, including from the "x5k_temp_no_serdes_working" tool. The computer were on for about an hour upfront.
Temperatures: Motherboard: +37 °C CPU........: +56 °C PCIe-Switch: +59 °C
Temperaturen ************ PCB 37ÐÑC CPU 56ÐÑC PCIe 59ÐÑC
Berny on os4welt make pretty good suggestion which seems fits to the picture : it's not the last "Serders" value missed, it just the Xena value missed completely (can't be read, or just bug in MCU volts parsing somewhere dunno), but if we take any of your outputs, like for example last from JOS, and imagine that Xena is missing, then all puts on the place where it should be , see :
And then everything fines are just fine as written in TRM.
So it looks like just there is just a bug and we didn't have in return Xena values, and have in return not 52, but 48 bytes. And it, not last Serdes missing, but Xena ones :)
I think there is no XenaXorroA and no XenaXorroB, but there is 1 XenaXorro entry. I can see no reason why 2 different voltages go to only 1 Xorro slot, and its this reason why I do not think that the Xena line is the problem. Using your comment as a guide, I would say it looks like this;
CPLD 3350mV XenaXorroA 3330mV XenaXorroB NO ! DO NOT USE! Shift then all values down! PCIe 1000mV Xena 1000mV 3,3V Schiene 3330mV 2,5V Schiene 2490mV Ethernet 1200mV Platform 1030mV CoreA 1090mV CoreB 1090mV DDR3 1490mV Serdes 1810mV
To properly get this confirmed we need someone with access to the original tech docs the TRM was created from to confirm if there are meant to be 12 sets of data, and if that's true then they need to point out which of the current 13 headings in the TRM is wrong.
And by the way, I got a USB-TTL cable for MCU Debug Header (so another UART with some info bringing on the other kind of serial port, which you didn't have with the usual serial port), and that what I have:
Initializing clocks... CLKGen0 configured OK CLKGen1 configured OK Releasing HRESET_n PEX ready for configuring. Configuring PEX switch The processor is out of reset!
See, there is also _no_ Xena voltage output. Mean it can't be read, or shouldn't, or when there is no Xena device attached return nothing (while should IMHO still return 0x0000 or something). That proves a theory that those values just didn't get back from MCU.
Interesting also that the "MCU debug header" didn't return back temperature rails as written in TRM, and, what is that "Processor is out of reset!" I want to know :)
@defs
See, from "MCU debug header" is Xena values missing as well, both Xorro ones are there.
@derfs We can't say if the order is wrong as well. Maybe from the MCU Debugger interface it just outputs in the wrong order, or reorder. Through for what to do so indeed...
Anyway, XenaXorroB and Xena in Docs have 1.0v, so not a big deal if the order is wrong as well, but yeah, if there wasn't reordering in the MCU debug output (why it should ..) then you are right: wrong ordering, wrong naming and instead of 13 fields we have only 12.
@All After few weeks and based on all the info we got there, Javier made an x5000 docky for AmiDock which can work and as minidock (so on top of your workbench title bar) and as usual "big" docky.
Mason help us with all the images, so docky looks clean and good. By default in the main docky image, you got a temperature of the CPU, but once you click (single click or double-click, that all controlled via tooltypes) you have a window showing everything: temperature PCB, CPU, and PCIe, all voltages (that include skipping non working Xena output as we find out lately), and Fan speed (if Fan connected to the PSU directly and not to Motherboard, it will say "not connected to MB" ).
You also can control via tooltypes colors of text, background, font names, and sizes, save window position or not when moved (so you will have it opens at the place you need), control WARNING color (i.e. if it will be more than 90C then it all will be RED, by you can control your "warn" value). And so on.
The docky is awesome. Thanks guys for this. I have the following issues though: 1. If I add it to amidock, then remove it, make some changes on it's tooltype and add it again to amidock, it always locks amidock, and after a while the system get's unstable and have to reset. 2. When I have that docky, I see my CPU going to 100% every sec, based on what CPU dock gives me, which is weird. Does it need so much CPU on an X5000 to get those reading and show them on the docky? Is it possible to set it to update every 5 or more seconds?
@walkero As i remember, reading in the docky happens not every sec, but every 5 sec only (at least for me it is).
But yeah, there was issue like quering of the data from this docky raise 100% of cpu loading. Javier deal with it by quering only parts at one time (i.e. firstly temp/fan, then voltage), and for me, that did the trick and i didn't have 100% cpu loading.
But sure, that was just workaround, and issue somewhere else in the dockie's code, as shell version didn't have this issue even if we query all the values at the same time. Only strange that for you it query every 1 second , maybe its your own tooltype settings ? As it should be 5 by default or something.
@Skateman Yeah, remind me exactly the same issue I had before and which Javier workaround by querying not all the values at one time, but one by one. Which still, didn't fix probably the main issue.
With the X-Dock version, Andy helps us pretty well with it: it was a wrong place where we asking for querying of values, probably with AmiDock it also something about, just where...