[Random Teardowns] WILLHI WH7016 Digital Thermostat

Decided to start posting teardown mini-articles from time to time. These will mostly be photos with the odd comment here and there.


The subject of the first in the series:

Device: WILLHI WH7016 Digital Thermostat
Origin: eBay / China
Reason for teardown: Curiosity
Impressions: A solid build for how cheap the thing is.

 

Small update:
Bought another one of these in 2014. Same model from what I could tell but severely diminished functionality(can only set temp to whole degrees even though it measures to .1, no alarm function, hysteresis only works in one direction, single (albeit higher current) relay). Also higher power consumption, lower quality plastic and it feels a lot less responsive. I could swear it also cost more than the first one did, hrmm...

Fujitsu D2151-A1 Conroe Hack

I have a dedicated PC for my Ultrium drive. I've decided to severely cheap out on the hardware for this machine since I only use it a few times a month. So not really giving it much thought I got the cheapest stuff I could find: a Fujitsu D2151-A1 mobo with a Celeron D CPU. As it turned out the Celeron was in fact Prescott based so I was looking at 56C idle temps despite 1 large fan strapped onto the heat-pipe CPU cooler right next to the large PSU fan. The overall power consumption of the system was around 90W.

I was getting over-temp warnings from the Ultrium drive from time to time, which does a fair bit of heating on it's own (though not as much as the CPU)

I've decided to get rid of the Prescott to improve the situation so I got a cheap Celeron 420, which is Conroe based and has about half the TDP of the Prescott.

As is usually the case there was a reason for the hardware being extremely cheap. The Fujitsu mobo couldn't handle the Conroe CPU. It was essentially limited to the old Pentium/Celeron D power hogs. D'oh! But wait.. There's an A2 revision of the board that handles Conroe cores, maybe success is just a bios mod away?

Not really..
It turned out the main reason the mobo didn't support Conroe CPUs is that the Conroes use a slightly different power system design.
There are a couple of key differences.

• The number of VID pins (thus the bit-length of the VID code) that specify the VCore requirements of the CPU has increased from 6 to 7-8. Thus the VID code supplied by the chip can't be used directly by the mobo.
• The VCCIOPLL pin has replaced the VCCPLL pin. They are right next to each other, but VCCIOPLL is not connected in the older system.
• The VRDSEL pin has changed. In the older system it's ground. But it should not be connected to ground anymore.

This is about the first time I considered just giving up. But I thought what the heck. Sounds like fun. Worst case scenario I break some cheap hardware. And the above info came from pinmodding posts I already found on random forums so I knew how to proceed.

Thanks and credit goes to the original author of this mod who I couldn't really track down due to the first forum of it's appearance having disappeared (from what I could tell).


The green lands should be connected together, the red one should be masked.
Masking is not really an issue. Connecting them together is a horrible experience. Sure you could use conductive ink/paint. It's the best solution if you have some at home. In my case, since I'm not spending $20 on a new mobo I'm also not spending $15 on conductive ink.
You could also use copper or aluminum tape but the roll I have didn't have conductive glue so it was useless here.
I did try very hard to superglue both cleaned up copper tape and tin foil but in the end the top (VID) block of the mod refused to work properly so I gave in and soldered a piece of wire through all of them, heh.
Since the VCCIOPLL foil mod "stuck" and worked as expected I didn't feel a need to replace it with solder. The result looks completely horrible but.. it does work.



The 3 green lands on the side are for MSID (Market sector id) pins.. It didn't seem to have any effect for me so I ended up removing the short.

The mobo started up.. and what I got was:
"Genuine Intel(R) 800Mhz"
and a microcode warning.
Well that's to be expected I thought. I'll just update the microcode and have it detect the CPU's correct speed and that's it.

Not so much.. The microcode update did zilch to solve the speed issue, and I also couldn't boot any modern operating system. Linux died on trying to start the kernel. Windows died after loading up acpitabl.sys (DOS worked fine though.)

Well that's not good, but maybe I can use the BIOS from the A2 revision of the board which does support this CPU and that'll be it. It took a lot of effort, where I initially socketed the bios and was planning to use an external programmer since neither Fujitsu's tool or the standard Phoenix tools wanted to allow flashing raw images without any checks but several hours later I found that flashrom works pretty great. Now I just needed an A2 bios, but Fujitsu packs them into their own proprietary format.. How do I get a raw image? Turns out someone has already solved this problem too: Veit Kannegieser coded up an unpacker (search for "SNIPAC" here ) Nice. (Link fixed in 2020. Let me know if it's broken again.)

UPDATE Sept. 2016: 

Thanks to Dieter I can now correct an omission in this article.

Quote:
"Decode the D2151_A2.OCF file with Veit Kannegiessers phoenixdeco (e_snipack.exe)
snip the bytes at address 00 to 0x6F (112 dec) at the beginning of the produced file
And snip one byte at it's end. The resulting file must have a length of 524.288 bytes."
After removing the first 112 bytes the file should start with 0xF0, 0xF6 and after removing the byte from the end the file size should equal 524288 bytes (0x80000). You can use a hex editor or if you have GNU tools in your OS just do: dd if=unpacked.bin of=biosraw.bin bs=1 skip=112 count=524288

That should give you a flashable file.
You should also do a full erase on the flash chip first before flashing the new image. I don't remember if this was necessary for me but it definitely works this way.
Hint: If you brick the board by restarting after a failed write or something you might still be able to use the floppy-disk based recovery feature ( assuming you still have one :-) ) 



I was fully expecting to get a brick when I pressed the reset button but surprisingly the A2 bios started right up without any errors. Complained about missing microcode patch which I updated again, but sadly.. The CPU was still running at 800Mhz. On the bright side Windows booted up fine now. Yay! Progress!

I looked around and saw that the FSB was at 100Mhz instead of 200Mhz. So that's what I needed to change. The problem with this board is that neither does it's bios allow any manual configuration of the FSB nor does it have a clock generator chip that is programmable through SMBus, so software solutions are.. not really possible besides hacking the BIOS which seemed too complicated to be worth it. I did notice that this board has Industrial revisions which have their own bioses (D2151-Sx) so I tried flashing the S2 bios but that didn't have any relevant settings either so I took a look at the clock generator chip. It's a CY28410.

According to the datasheet it has 3 pins (FS_A, FS_B, and FS_C) that control the FSB frequency like so:


(MID I suspect stands for middle, the pin is in MID when it's at 1.2V)
So since the FSB was at 100Mhz I was looking at the first configuration.

There are a few ways to go about changing this. I MIGHT have considered pin lifting if the 3 pins were right next to each other on one corner of the chip, but they're basically all over the place, so I would've definitely ended up damaging the board or the chip, but more likely both.


So I decided to just find where the pins are connected and cut the traces.
FS_C is at the top and disconnecting it is relatively easy since the trace doesn't go under the chip, It's only a bit of a pain because of how short it is but it's fairly easy to cut accurately with an xacto knife. I cut it and the speed jumped to 1.06GHz (0-0-1, 133Mhz * 8 = 1064Mhz)


Both FS_B and FS_A run under the chip though.. Argh..
I managed to trace FS_B to a quad 10K resistor pack to the right of the clock generator chip. I removed the resistor pack. The top resistor seemed to be unrelated so I put a single 10k 0805 there.
The bottom resistor from the pack was never used. The second was connected to FS_C but I've already cut that so it's irrelevant. The third one was FS_B.

Now as for FS_A it's on a trace that starts from a via to the left of the resistor pack goes under the pack(doesn't connect to any of it's pads) and disappears under the capacitor like so:



I just cut that near the via. The pins have a weak internal pull-down (probably.. since I'm not seeing random FSB configurations popping up after just cutting the traces) so this means that since I've cut FS_C and FS_A they are now both logic low meaning 0.

Since FS_B was 0 to begin with we should now be at 0-0-0 which is 266Mhz FSB, and indeed a startup confirms the CPU is at 2.13GHz (266Mhz x 8 = 2128Mhz) . Now I just needed to pull FS_B high to reach 200Mhz, which will result in 1.6Ghz, the stock speed of the Celeron 420. I did consider leaving it OCed mainly because I'm lazy and not having to connect a pullup means less work but the system wasn't running stable with it. Could've been the 533Mhz RAM's fault. Overclocking wasn't really my objective so I didn't investigate further. I proceeded to add the pullup instead.

FS_B has a trace connecting to another via supposedly going off to wherever it's controlled from originally. I cut that trace and soldered a piece of Kynar wire to the resistor pack's pad, which should now be connected directly to the FS_B pin. I then put a 10k resistor on top of a ceramic cap's shoulder (because it was the easiest place to get 3.3V from) and connected the wire to the resistor pulling the FS_B pin high.

And as the startup confirms:



SUCCESS!



System seems stable, and the CPU idles at 40C without any fan of it's own (just the PSU fan running) which is a great improvement over the Prescott space heater.

Later I've also found this alternative version of the pinmod:

here that may work just the same and trades some of the pin shorting for masking which is never a bad thing.

UPDATE Sept. 2016:  

Fujitsu D2164-A1

Dieter (who also commented below) managed to apply this method to the D2164-A1(1). A board used in the Esprimo 5905 slim-case machines.

These ones

Note that while these boards do use a standard ATX24 connector Dieter says they don't work with off the shelf power supplies. On the bright side, at least they don't damage them if you try.

The boards don't look that similar but apparently they're similar enough in hardware for the D2151 bioses to work on the D2164. This bypasses the issue of the D2164 not having a revision that supports Core2/Conroe CPUs to take the BIOS from. You can just use the D2151-A2/S2 bios instead.

First the pinmod:
You can follow my butchery above or use conductive ink as mentioned. Maybe you can find a good DIY recipe if you search around nowadays. Dieter chose a similar solution:

Then, the clock generator has to be modified. The chip is identical on both boards but the layout differs somewhat.

Dieter's clockgen mod with pin lifting instead of trace cutting

So if you wish to go the trace cutting route you'll need to do a bit of detective work first. Shouldn't be too hard.

Next do a full erase on the flash chip first (important) and then flash the D2151-A2(or S2) bios you've prepared aand..

Huzzah!

Thanks, Dieter!

Repair: HP Ultrium2 Drive

Being the digital hoarder that I am I routinely end up with several hundred gigabytes I no longer actively need but don't want to just delete. The options when it comes to modern day large volume data archival are limited. The more straightforward choices are HDD, BluRay or DVDs. None of those are really reliable in the long run. The recoding layer in optical media deteriorates too fast and HDDs are generally unreliable if left idle for extended periods of time. So a good long time ago I bought an ancient DAT drive which I used for about a year then upgraded to an Ultrium1. Usually these enterprise grade backup devices are crazy expensive when released, then 5-10 years later they're within my budget :) The hard part is finding one that hasn't been used to death in some server-farm somewhere. Rarely drives bought as spares then never used go up on eBay which can turn out to be a killer deal, but otherwise It's basically a lottery. My first Ultrium1 drive did have some use in it, but nothing serious. I was happy enough with it and now have about 1TB archived all in all on LTO-1 tapes (they're 100GB per tape). About a week ago while browsing eBay I found an LTO-2 drive for $55+international shipping (which was $56, heh..) so I bought it.



The drive is an HP C7379 double-height drive. (My LTO-1 was a single height).
Now I assumed that the double-height drives are more robust mechanically and more reliable electronically because I took apart the single-height drive a few times and things are really cramped in there which I went ahead and blamed some of the stability issues on that I had with it over the years (without any real evidence).

So the new drive arrives and I put it in my archival machine for testing. I insert the first cartridge and even before the insertion process is complete the Tape Error LED starts flashing. Not good!

I proceeded to do a cleaning run, but the Tape Error came up for the Cleaning Tape as well. Hrmm..

My first assumption was that the CM (Cartridge Memory, an RFID-like wireless EEPROM inside every LTO cartridge) is not being read properly because the LED started flashing even before the spooling sequence begun. The drive didn't even open the cartridge door to take out the leader pin before the error came up. (The way Ultrium works is basically the cartridges have a single roll of tape in them the end of which is glued onto a metal pin. The drive physically pulls the metal pin along with the tape out of the cartridge and starts spooling the tape onto an internal drum. In contrast with VCR where you have two drums inside the cartridge, in Ultrium one of the drums is in the drive.)

So basically since the tape never even touched the heads when I got the errors, and there was no apparent mechanical failure during the load sequence, the CM reader became the prime suspect.

Thankfully double-height drives are much more serviceable than the single-heights. The CM reader module is a separate daughter-board labeled Philips FCMWP PCA. (WP stands for Write-protect since this board also connects to the optical gate and mechanical arm responsible for detecting write protection.)


So I took the board out and began to troubleshoot it. I was planning to capture the SPI communication to get a better picture of what's going on, but since I didn't have a 3.3v micro to do it and I was too lazy to bother with level shifting I decided to try other things that while more invasive I had the tools on hand for.
I desoldered the CM reader chip LTRCC10. This chip is a black-box. No information about it seems to be available anywhere. Actually that could be said for most Ultrium drive hardware. The only worthwhile material is the HP Ultrium Technical Reference Manual (google CRCM2161 to CRCM2167). Anyway, I traced the pins on said chip and the daughter-board to some extent.
The SPI stuff should be correct, the rest could be totally wrong, but maybe it'll be of some use to someone:

LTRCC10: (Pin numbering as silkscreening on the daugtherboard. (Pin1 ----- Pin16))
1: GND, 2: RF, 3: 5V Vcc, 4: RF, 5: GND, 6: XTAL1, 7: GND(? double-check), 8: XTAL2,
9: SPI Clock, 10: SPI In,11: SPI Out, 12: SPI Chip Select, 13: GND, 14: RF, 15: RF, 16: GND
I had no interest in the RF pins so whatever pins connected to the passives associated with RF I just labeled as such. If you want to build a CM reader with this chip you'll have to investigate them on your own, but you'll need a working drive anyway to reverse engineer the SPI protocol.
The LTRCC10 works at 3.3v SPI despite the 5V Vcc. Not sure if it would tolerate 5V SPI.

Daughterboard header :
1: Optogate Common?, 2: Onboard Optogate, 3: Write-protect Optogate, 4: 5v (CM Reader VCC and Optogate VCC), 5: EEPROM SPI Chip Select, 6: SPI In, 7: SPI Out, 8: GND, 9: SPI Clock, 10: CM Reader SPI Chip Select, 11: 3.3v (EEPROM Vcc)

The drive didn't really seem to be affected by the absence of the CM reader chip and continued to produce the exact same symptoms. I also tried disconnecting the EEPROM, which made the drive unable to boot up.

So I soldered both of the chips back in, then hooked up the reader board to my good LTO-1 drive's SPI bus, since it had the same LTRCC10 CM reader chip. I wanted to see if it produces any RF activity when it receives the correct read command. I cobbled together a radio detector (based on this) using a germanium transistor (as a diode), a 1nF capacitor and a +-50uA analog panel meter.



This test concluded that the reader chip did "something" at least, however the drive still failed to read CM. I assumed the reader chip was not the cause of the problem and left it alone.

At this point the only things left on the daughter board were the various passives that I tested with a multimeter for the most part and a 13.56Mhz quartz.
The operating frequency for the CM reader should be 13.56Mhz according to this document. I did a few insertion tests while lightly holding the quartz and managed to get the tape loaded without an error twice. This confirmed that the quartz was bad.

I had no 13.56Mhz quartz (suitable or otherwise) on hand so I tried the closest value I got which was 12Mhz. The difference of 1560Khz is way out of the +/- 7 Khz tolerance in the spec but... It seems to work just fine. I don't get any tape errors and it reads the cartridge name from the CM correctly. Unless it starts acting up during testing I'm going to leave it alone.



So that's one LTO drive (bought as functional) that had to be repaired. A success story I guess since I basically started the repair without any hopes of success after the seller refunded the price (minus shipping) as a last Hail-Mary attempt before selling it for parts to recoup some of my loss. It was mostly luck that I managed to fix it. Had the CM reader chip been defective for example the drive would've been beyond repair since there's no way to get replacements for that other than having a friend in a Chinese component warehouse or buying a broken drive. The drive also possibly still has some other issues.. if I want to do an assessment test in HP Tape Tools the drive locks up and the SCSI card driver eventually BSODs Windows unless I manually reset the drive. It does however appear to read and write tapes successfully.. for now.

Equalizing battery bank charger V2

The related projects:

LPH7779 Nokia display board
LTC4151 voltage and current measuring board
Mini 5V Step-down board
and the charger boards from Equalizing battery bank charger V1

came together in the V2 charger.

I chose a smaller box for this one. Screwed the PCBs to bakelite carrier boards and stacked the carrier boards on top of each other through 4 posts made from threaded rod like so:


From top to bottom we have Charging, Measurement then Power supply levels.

Charging basically just has the UC2906-based charger boards from V1
Measurement has a completely overkill ATMega16 (only thing I had at home) that drives the display, and talks the to LTC4151 Voltage and current measurement board through I2C.
Power supply has simple filter/buffers for the 3 separate charger boards and the 5v step-down for the uC and display.

Bottom level and measurement level:



Measurement level:



Power supply level:

The wiring isn't exactly pretty but whatever.

The finished charger looks like this:



I added few extra features to it in the end. The AtMega can be programmed through the DB9 connector on the back. The UART is also exposed there, and periodic measurements are printed (in case I ever want to do any charge characteristic graphs or something).

Here's the first test run on my old e-bike battery bank:


Bascom code for the measurement and display can be found here

(I'd give credit for the LPH7779 code but I don't remember where I found it)