Karosium

[Random Teardowns] YU4802 48V/2A power supply

noreply@blogger.com (Unknown) — Sat, 28 Jan 2017 10:16:00 +0000

Device: Cheap 48V 2A power supply (YU4802)
Origin: Aliexpress
Reason for teardown: Preemptive checkup
Impressions: Not bad for the price ($14 shipped)

Blue Power LED on top

⚡ RISK OF ELECTRIC
DO NOT OPEN !
Yeah, but if I don't it's still a risk due to being a 96W $14 power supply from china so.... bring on the risk of electric.


Noname primary-side cap, mismatched screws on the TO-220s but the design doesn't seem to be too terrible at least Based on UC3842 (datasheet)

3 noname secondary side caps, par for the course

I've seen way worse for the same amount of money.

UPDATE:
So after actually using this with a significant load (charging a 50cell 10S5P LiIon battery) I can say that it's really not a very efficient power supply and that it should probably never have been designed into this enclosure. A hundred vent holes and a fan later I'm now reasonably sure it won't burn down.

This is a very similar circuit to what they sell as SLA battery chargers for electric bicycles in cases 4 times this size with vent slots all around. Even so they get stupidly hot and just cook the transformer if the vents are covered up as a friend of mine found out. Primary side shorts straight through leaving nothing intact.
So if you buy this and want to use it anywhere near it's rating then break it apart, get your drill out and turn the case into swiss cheese at the very least but I'd recommend active cooling as well in addition.

The weird fuses in laptop batteries

noreply@blogger.com (Unknown) — Mon, 05 Sep 2016 14:36:00 +0000

I called them "externally triggerable fuse" in my first post. The datasheets call them "Combined Thermal Fuse/Resistor" or "Fuse-Resistance protector".
Chances are your first time seeing one of these will be in a smart battery, it sure was for me.

As an over-current protection device (ie. regular fuse) they're probably only going to trigger during catastrophic short-circuit scenarios. Their main purpose is to provide a way for the microcontroller to physically break the circuit if it detects a potentially dangerous condition like the overheating of the cells and can't stop it by shutting the FETs off. The problem is some firmwares will count the sudden disappearance/reappearance of cell voltages amongst the list of conditions that warrant doing this so if you want to re-cell a pack you might end up with a blown fuse.
Replacing or jumping them is a pain so it's a good idea to connect the Reset pin of the controller to ground before doing anything of the sort to keep it from overreacting.

The rectangular one

The Cyntec 12AH3 / 12AG3 (datasheet) or similar devices will seem like large capacitors on first sight, though the fact that they have 4 terminals might make you think "current sense resistor". Nope!

The black plastic cap attaches to the ceramic body with glue and you can tease it off with a pair or side-cutters, pliers or tweezers. Here's what you see under it:

Left: intact, Right: blown

What you have is a rectangle of "solder" (probably some special alloy) with a resistor/heating element under it in this configuration:

As you can see on the images above, when the device is triggered the thin layer of solder heats up, flows onto the center pad and breaks the connection. The heater is about a 10 ohm resistance so with a 12.6v battery voltage that's 14 watts dissipated on that tiny surface area (or more if the charger voltage is used)

To check this fuse you'd look for continuity on longer sides and for the heater resistance between either contact and Pin 4.
To jump it carefully dab older onto the broken connections. Use low temperature and thin solder. You can probably shave away at it afterwards and the fuse MAY be able to blow again.. unreliably.. and completely of spec.
The best course of action is of course to replace it with a new one once the repair is confirmed.

If the controller is blowing the fuse repeatedly you have an issue in your data or a hardware fault in the controller board or your cell connections.

The 3-legged one

The SEFUSE D6X / D6T (datasheet) is a weird looking thing that doesn't really resemble any other component.

It's the same deal with a different physical construction.

To jump it you break off the cap (if there is one) to find a resin coated square. Then you carefully scrape away at the coating roughly in the middle until you find a tiny via. This is the center point you see in the diagram above. Now you just need to reconnect it to the two leads where the fusible material broke the connection so tin the via and connect it to both leads (ignore the lead for the heater).

Here's a pretty terrible example:

As with the previous one, it's best to get a new one once the repair is confirmed.

Adding the M37512 with Panasonic/IBM firmware

noreply@blogger.com (Unknown) — Tue, 30 Aug 2016 15:29:00 +0000

Just "adding" because this battery controller is already public. You have the datasheet(pdf) which tells you the pin combination to enter the Boot ROM and most of the command set (how was the actual read command missed? weird). Then there are open-source flasher tools like this one. You can also use Google to find the passwords because you WILL need passwords (at least with this firmware) and that is after you set the correct pins to the correct states to enter the boot rom. Overkill? Yeah, overkill.

But since it's all out there it's just a matter of coding up a tool for SMBusb.

Quote:
"Normal microcomputer mode is entered when the microcomputer is reset with pulling CNVSS pin low. In this case, the CPU starts operating using the control program in the User ROM area. When the microcomputer is reset by pulling the P24/SDA2/RXD pin high, the CNVss pin high, the CPU starts operating using the control program in the Boot ROM area"

After setting the pins to desired state and resetting the chip you get:

$ smbusb_scan -w 0x16

------------------------------------

             smbusb_scan

------------------------------------

SMBusb Firmware Version: 1.0.1

Scanning for command writability..

Scan range: 00 - ff

Skipping: None

------------------------------------

[0] ACK, Byte writable, Word writable, Block writable, >Block writable

[1] ACK, Byte writable, Word writable, Block writable, >Block writable

[2] ACK, Byte writable, Word writable, Block writable, >Block writable

[3] ACK, Byte writable, Word writable, Block writable, >Block writable

[4] ACK, Byte writable, Word writable, Block writable, >Block writable

[5] ACK, Byte writable, Word writable, Block writable, >Block writable

[6] ACK, Byte writable, Word writable, Block writable, >Block writable

*repeat for all commands*

Going at this blind would've been pretty terrible. This chip is waiting for the correct passwords and ACKing literally everything until it gets them.
Entering the correct passwords scoured from the internet:

$ smbusb_comm -a 0x16 -c 0xFF -w CDAB -b

$ smbusb_comm -a 0x16 -c 0xCF -w 3412 -b

$ smbusb_scan -w 0x16 -e 10

------------------------------------

             smbusb_scan

------------------------------------

SMBusb Firmware Version: 1.0.1

Scanning for command writability..

Scan range: 00 - 10

Skipping: None

------------------------------------

[0] ACK, Byte writable, Word writable, Block writable, >Block writable

[1] ACK

[2] ACK

[3] ACK

[4] ACK

[5] ACK

*snip*

It still ACKs every command but it's exposing the documented Boot ROM inteface now. Just don't scan it too much because writing the wrong thing to the wrong command will hang the controller and/or the entire bus which the SMBusb won't like too much either. (The Boot ROM in this chip has zero error handling.)

Some coding later:

$ smbusb_m37512flasher -w b0 -p b0 

------------------------------------

        smbusb_m37512flasher

------------------------------------

SMBusb Firmware Version: 1.0.1

------------------------------------

Erasing flash block starting at 0xe000 ...

Done!

Writing memory 0xe000-0xffff ...

Done!

Verifying 0xe000-0xffff ...

Verified OK!

The tool is now a part of SMBusb.

I haven't done research into modification or resetting for this controller yet. Maybe in the future!

Hacking the R2J240 with LGC firmware

noreply@blogger.com (Unknown) — Mon, 29 Aug 2016 16:46:00 +0000

The second battery controller I looked at was the Renesas R2J240-10F020. It's a complete black box with very little information available except for some outtakes from the datasheet on Chinese developer forums. There is very little resemblance to the M37512, an older Mitsubishi/Renesas microcontroller used in earlier battery packs that's fairly well documented.

The first thing you notice is that this chip has the analog frontend integrated (unlike the M37512 or the bq8030) because there's no separate chip for measuring voltages and such. Cells are connected directly to this chip so it's a one-chip solution for building smart batteries.

SBS Report

$ smbusb_sbsreport 

SMBusb Firmware Version: 1.0.1

-------------------------------------------------

Manufacturer Name:          LGC

Device Name:                LNV-42T4911

Device Chemistry:           LION

Serial Number:              41291

Manufacture Date:           2010.01.25

Manufacturer Access:        6001

Battery Mode:               e000

*snip*

Probing around

I started out by measuring voltages on all the pins. Just going by logic I was expecting some sort of differentiation on the various sides of the chip.

To summarize my findings after the first pass:

1-12 is the "main microcontroller side" has the SMBus pins, VCC (and probably RESET and others)
25-36 is connected to current sensing and exposes various built-in voltage regulators
37-48 appears to be mainly unused with a couple of pins at 3.3v, GPIO side?
13-24 has many pins connected directly to "high voltage" from the cells.

I took a 1k resistor connected to ground and started poking the pins with it to find reset. It should be possible to pull reset low through 1k resistor but unlikely on VCC and it shouldn't lead to a complete reset on an unrelated pin. It's also possible to rule out most pins through visual inspection and measurement. So long story short: Pin #12 is Reset.

Next I wanted to see if there's something like a Boot pin that's going to get me a different mode when pulled either low or high during reset so I started up a continuous command scan and started poking at the pins again.

Pulling Pin #4 (also connected to Test Point 1 on the other side of the PCB) low during reset gave me this:

$ smbusb_scan -w 0x16

------------------------------------

             smbusb_scan

------------------------------------

SMBusb Firmware Version: 1.0.1

Scanning for command writability..

Scan range: 00 - ff

Skipping: None

------------------------------------

*snip* 

[f0] ACK, Byte writable

[f1] ACK

[f2] ACK

[f3] ACK

[f4] ACK

[f5] ACK

[f6] ACK

[f7] ACK

[f8] ACK

[f9] ACK

[fa] ACK, Byte writable, Word writable, Block writable

[fb] ACK, Byte writable, Word writable, Block writable

[fc] ACK, Byte writable, Word writable, Block writable, >Block writable

[fd] ACK, Byte writable, Word writable, Block writable, >Block writable

[fe] ACK

[ff] ACK

The chip was ACKing on every command. A deliberate attempt at confusing any would-be attacker perhaps? The write scan however reveals that the chip is actually exposing some real functionality on some of the commands and that a couple of them violate SMBus protocol.

Pin #4 appears to be BOOT (active-low).

Mapping

Mapping out the protocol took a while especially because it doesn't correspond to standard SMBus protocol but I was eventually able to figure out how to read and write to RAM and erase blocks of memory-mapped flash.
Just writing to the appropriate address in ram (after the flash blocks have been erased) writes the flash memory which is convenient.

There are several partitions of flash mapped into RAM and I'm sure I haven't found all of them. The ones I did are included as address&length presets in the flasher tool.

$ smbusb_r2j240flasher -d eep2.bin -p df2

------------------------------------

        smbusb_r2j240flasher

------------------------------------

SMBusb Firmware Version: 1.0.1

------------------------------------

Dumping memory 0x3400-0x37ff ...

Done!

$ xxd eep2.bin

0000000: 0000 0000 0000 0000 0000 ffff ffff ffff  ................

0000010: 4c4e 562d 3432 5434 3739 3700 0000 0000  LNV-42T4797.....

*snip*

$ smbusb_r2j240flasher -d eep3.bin -p df3

------------------------------------

        smbusb_r2j240flasher

------------------------------------

SMBusb Firmware Version: 1.0.1

------------------------------------

Dumping memory 0xc000-0xdfff ...

Done!

$ xxd eep3.bin 

0000000: 0100 0700 b801 b801 1100 0203 0201 01e3  ................

0000010: e6fe e3ae 7000 e0e4 0cc8 0038 3150 14f0  ....p......81P..

0000020: 1530 2a4c 4743 0031 3100 0000 0000 0000  .0*LGC.11.......

0000030: 0000 0000 0000 0000 0000 0000 0000 0000  ................

0000040: 0000 004c 4e56 2d34 3254 3439 3131 0000  ...LNV-42T4911..

0000050: 0000 0000 0000 0000 0000 0000 0000 0000  ................

0000060: 0000 004c 494f 4e01 2d01 2d30 07fa 1031  ...LION

*snip*

In this particular battery pack the static information was stored in df3 and the dynamic in df2, df1 was empty.
Another battery stored dynamic info in df1 so this is going to differ between firmwares/packs.

Just like the bq8030 the static area is protected by a checksum on this controller/firmware as well. I took a shot at it just for kicks and it was pretty simple so I included it in the flasher tool.

$ smbusb_r2j240flasher -w eep3_f.bin -p df3 --fix-lgc-static-checksum --execute

------------------------------------

        smbusb_r2j240flasher

------------------------------------

SMBusb Firmware Version: 1.0.1

------------------------------------

Erasing flash block starting at 0xc000 ...

Done!

Fixing LGC static checksum..

Done!

Writing memory 0xc000-0xdfff ...

Done!

Verifying 0xc000-0xdfff ...

Verified OK!

Exiting Boot ROM and starting firmware.

$ smbusb_sbsreport

SMBusb Firmware Version: 1.0.1

-------------------------------------------------

Manufacturer Name:          LGC

Device Name:                Karosium000

Device Chemistry:           LION

Serial Number:              41291

Manufacture Date:           2010.01.25

*snip*

Reset

Pretty much the same procedure as with the bq8030. Map and modify the dynamic area. Eventually you'll find the error flag. As with the bq8030 the dynamic area isn't checksummed in this controller/firmware either.

Helpful tips:

Again, multiple log entries. The number of 0x00 bytes at the beginning of the section determine the number. Patch the duplicated data in all of them.
You can decrease the number of log entries to 1 for the time of mapping which will make the job a lot easier.
The real cycle count is stored encoded. No idea how. With this particular firmware it was at 0x78-79. Zeroing out the bytes still decreases the cycle count to 5 but the precise algorithm/obfuscation? No clue.
Please don't ask me to fix flash dumps :-)
Good luck!

Notes

No disassembly/ler for this chip. I don't really know what architecture it's based on. If I had to guess I'd say an extended version of the MELPS 7700, an old Mitsubishi architecture that Renesas inherited because trying to load it up in IDA with that core seems to produce something that starts to make sense but fails on invalid instructions. I could be completely wrong though.

If anyone wants to tackle this they could probably find a nice, easy way of getting into the Boot ROM using just SMBus commands.

Hacking the bq8030 with SANYO firmware

noreply@blogger.com (Unknown) — Sun, 28 Aug 2016 22:04:00 +0000

As mentioned in the previous article the bq8030 is the blank version of the bq20z90. If you bought some from Aliexpress they'd come up with the TI Boot ROM and you could use the flashing tool included in SMBusb to upload firmware and eeprom(data flash) to it.
Theoretically you could turn it into a bq20z90 by downloading the firmware from one and uploading that. (The procedure for accessing the Boot ROM on those chips is documented in datasheets and application notes.)

So how would you even start with a BQ8030 running proprietary firmware?

Google. Lots of Google.
Apparently they sell this tool for them::

Now with a SPECIAL! price of ONLY 3 THOUSAND US DOLLARS!! WHAT AN AMAZING DEAL!!!

I gathered everything I could find about this device and while it wasn't much it did provide clues that came in handy later on in the process. Especially this screenshot of the software that comes with it:

There was no way I could figure everything out based on just that but I did take notice of the function bar on the bottom.

Those could very well be SMBus commands right there.. would they have done that? Surely not.
Not really expecting much I tried a word write of 0x0214 to command 0x71 aand.. nothing obvious happened. So I moved on to poking at other things but eventually came back for a second look and that's when I realized:

Command scan starting at 0x70 before sending command

$ /smbusb_scan -w 0x16 -b 0x70

------------------------------------

             smbusb_scan

------------------------------------

SMBusb Firmware Version: 1.0.0

Scanning for command writability..

Scan range: 70 - ff

Skipping: None

------------------------------------

[71] ACK, Byte writable, Word writable

[72] ACK

And after

$ smbusb_comm -a 16 -c 71 -w 0x0214  

$ smbusb_scan -w 0x16 -b 0x70

------------------------------------

             smbusb_scan

------------------------------------

SMBusb Firmware Version: 1.0.0

Scanning for command writability..

Scan range: 70 - ff

Skipping: None

------------------------------------

[71] ACK, Byte writable, Word writable

[72] ACK

[73] ACK

So this actually unlocks an extra command which disappears again when an SBS command is issued (or when doing a full command scan starting from 0.)
The command however is not writable. Reading it returns:

$ smbusb_comm -a 16 -c 73 -r 2 

023d

Interesting but insufficient.

Brick wall meet impatience

I couldn't really get any further with just that information so I started looking at the hardware instead. Having found slides from a TI presentation revealing the connection between the BQ8030 and bq20z90 I opened up the datasheet for the latter (since there's no public datasheet for the former).

Ok, nothing straightforward. No obvious BOOT pin as one would expect with a device that's not meant to be tampered with. But maybe pulling some pin high or low during reset will get me somewhere.

After the first pass no, not really. So maybe we have to set multiple pins into multiple states for it to work. Or maybe there's no such combination at all.
How about I try to abuse N/C pins instead. I have no logical explanation as to why I came to this decision. Maybe I saw a presentation somewhere about blackbox chips and N/C pins years and years and years ago but I could just be imagining things. Either way, about 5 minutes of poking at PIN #28 with a resistor connected to 3.3v in hand and triggering RESET at random intervals while running a continuous command scan:

$ smbusb_scan -w 0x16

------------------------------------

             smbusb_scan

------------------------------------

SMBusb Firmware Version: 1.0.1

Scanning for command writability..

Scan range: 00 - ff

Skipping: None

------------------------------------

[0] ACK, Byte writable, Word writable, Block writable

[1] ACK

[2] ACK

[3] ACK

[4] ACK, Byte writable, Word writable, Block writable

[5] ACK, Byte writable, Word writable, Block writable

[6] ACK, Byte writable, Word writable

[7] ACK, Byte writable, Word writable

[8] ACK

[9] ACK, Byte writable, Word writable

[a] ACK, Byte writable, Word writable

Wow, that worked?
Umm.. ok.. let's just reset for now..

$ smbusb_sbsreport 

SMBusb Firmware Version: 1.0.1

-------------------------------------------------

Manufacturer Name:          ERROR

Device Name:                ERROR

Device Chemistry:           ERROR

Serial Number:              4294967287

Manufacture Date:           1980.00.00

Uh-oh.. Well that's not good!
It seems we're stuck in the Boot ROM. Is the chip fried? It's at this point that I coded up the flash tool to try and read the flash contents. (I wasn't really bothered by the chip dying as this was one of 2 sacrificial controller boards I kept just for messing around with.)
And the results? Apparently we can corrupt (ideally just) the first couple of blocks of flash if we bully PIN #28 while the chip is trying to start up. The good news though? (If we're lucky) We get 99% of the firmware, and thanks to Charlie Miller we have a disassembler(zip) for it.

Did messing with Pin #28 even have an effect? Could it just have been the erratic resetting of the chip that triggered the malfunction? Did I short VCELL+ to Pin28 while messing about? Was there high voltage on VCELL+? Was it just ESD?
No idea. But I did manage to reproduce the result on another chip using the same procedure. So when in doubt and you have nothing to lose, act like a caveman, I guess?
The only good thing about this method is that even if you have 0 knowledge about whether there even IS a method for entering the Boot ROM in the firmware let alone what it is there's still a high chance that you'll get in. How much of the firmware survives is another question.

Disassembly

A couple of hours of staring at unfamiliar assembly code later, here are the relevant parts for entering the Boot ROM with annotations:

cmd_handle_71:  

    ..       

    calls       smb_ACK

    ..

    calls       smbSlaveRecvWord

    move        a, (i3,0x1A)

    or          a, (i3,0x1B)

    jeq         check_71_pass

    move        r2, (i3,0x1B)

    add         r2, (i3,0x19) ; smb_word_LSB

    move        r3, (i3,0x1A)

    addc        r3, (i3,0x18) ; smb_word_MSB

    or          a, r3, r2

    jeq         accesslevel_oreq_40

    move        a, #0

    move        (i3,0x1A), a

    move        (i3,0x1B), a

check_71_pass:

    ..

    move        i1l, (i3,0x19) ; smb_word_LSB

    move        i1h, (i3,0x18) ; smb_word_MSB

    cmp         i1h, #2

    jne         wrong_pass

    cmp         i1l, #0x14  ; is 71 0214?

    jne         wrong_pass

    ..

    jeq         accesslevel_oreq_80

This is the first password check, seem familiar? It's the one that we saw in the screenshot above 0x0214 to 0x71. It sets an access flag that gets checked later on. Basically if (smbSlaveRecvWord(0x71) == 0x0214) { access_level |= 0x80 }; But wait.. It can set two access flags based on whatever (i3,0x1A) and (i3,0x1B) are. Hrmm.. Well I don't know what those are and can't find where they're set so let's assume the first jeq will not jump once we've given the correct first password because it would make sense. We can also see that it checks the word we send against those mystery bytes somehow and if it likes what it sees it sets access flag 0x40 and the mystery bytes to 0.

A little bit further up we find the entry point for the Boot ROM:

cmd_handle_70:

    *snip*

    move        r3, access_level

    and         r3, #0x40

    cmp         r3, #0        ; don't even bother if access

    jeq         cmd_handle_71 ; flag 0x40 is missing           

    *snip*    

    calls       smbSlaveRecvWord

    move        r2, (i3,0x19) ; smb_word_LSB

    move        r3, (i3,0x18) ; smb_word_MSB

    cmp         r3, #5

    jne         wrong_pass

    cmp         r2, #0x17      ; is 70 0517?

    jne         wrong_pass

    *snip* (prepare leaving the firmware safely)

    calls       bootrom_execute

So now we know pretty much what we need to do.

1. Send 0x0214 to 0x71
2. ???
3. Send 0x0517 to 0x70
4. Profit

And we've made the educated guess that Step 2 is really "Send 0x???? to 0x71" so we're pretty much done with the disassembly as 16 bits is way within the realm of bruteforceability and since I had another sacrificial board as well as a battery pack running SANYO firmware I had everything I needed to attempt it.
As it turns out there's another mandatory step between 1 and 2 and it was sheer luck that I left it in my brute force loop. 0x73, the command unlocked by sending the first password needs to be read before entering the second password. Which is...*drumroll*

0xFDC3

After realizing that the first unlocked command is important (why else would they have made it mandatory otherwise) it's not that surprising that when adding the number returned by it (0x023d) to the bruteforced value we get a nice round result: 0x10000 which is probably what the adding in the assembly and the mystery numbers are all about.

So to sum it all up:

1. Send 0x0214 to 0x71
2. Read Word X from 0x73
3. Send (0x10000 - X) to 0x71
4. Send 0x0517 to 0x70

Actually, sending the correct word in Step 3 will unlock several extra commands not just 0x70 for the BootROM entry but they all disappear as soon as you send an unrelated command much the same way as 0x73 does with the first password.

We don't really care about those though because we already have what we wanted:

$ smbusb_comm -a 16 -c 71 -w 0214
$ smbusb_comm -a 16 -c 73 -r 2

023d
$ smbusb_comm -a 16 -c 71 -w fdc3
$ smbusb_comm -a 16 -c 70 -w 0517 

$ smbusb_bq8030flasher -p prg.bin -e eep.bin

------------------------------------

        smbusb_bq8030flasher

------------------------------------

SMBusb Firmware Version: 1.0.1

PEC is ENABLED

TI Boot ROM version 3.1

------------------------------------

Reading program flash

.............................................................

.............................................................

*snip* 

.................................................

Done! 

Reading eeprom(data) flash

...................................................

Done!

$ xxd eep.bin
0000000: ffff 0031 076c 00c8 ffff 11f8 19e0 0355  ...1.l.........U
0000010: 0853 414e 594f 0030 3820 20ff ffff 0407  .SANYO.08  .....
0000020: 0b49 424d 2d34 3254 3532 3531 2020 2020  .IBM-42T5251    
0000030: 044c 494f 4e20 ffff ffff ffff ffff ffff  .LION  

*snip*

Huzzah!

Reset

To actually remove the permanent failure flag we need to look at the eeprom area.
The file is 2048 bytes and it has two sections.

The first 1024 bytes contains the static data (the beginning of which you can see in the hex dump above). It contains all the data set by the manufacturer that never changes during the lifetime of the battery. Design capacity/voltage, serial and model numbers, default settings, etc.
This part is protected by a checksum somewhere which you'll need to find and fix if you want to modify anything in there.

The second part contains the dynamic data. Basically the "log" of the battery with current remaining capacity and similar things that get updated as the battery is cycled. Also, the failure flag.

You pretty much just need to start mapping out the values and then zeroing or FF-ing out the ones that you can't map to anything to see if that fixes it or breaks something else. There's no checksum on the dynamic area so you are free to modify this section all you want. Repeat until desired outcome is reached. That's what I did.
Some helpful tips:

On my specific battery the log starts at 0x500 and has several entries that all need to be modified (mostly duplicate data)
Battery capacity is stored as the remaining capacity reported through SBS divided by 2.
Cycle count is stored as CycleCount-1 (eg.: SBS value: 223, Eeprom byte: 222)
Remaining Capacity Alarm is stored as-is. A good place to start mapping.
It's a good idea to reset the cycle counter. I don't want to start conspiracy theories but... at least with this specific model there's been a lot that died inexplicably around the 200 cycle mark. Coincidence? Probably, but it can't hurt.
Please don't ask me to fix eeprom dumps :-)
Good luck!

And the result:

It took the estimate a charge cycle to normalize. This particular battery lasts 2 hours on constant high CPU load after external recharging and clearing of the fail flag. Not bad for a 10 year old battery in a 12 year old machine and since the other choice was THROW IT AWAY AND BUY A NEW ONE I consider this a win :)

PSA: DO NOT WRITE PROGRAM FLASH. You don't need to rewrite the firmware to recover a battery and there's an issue affecting some platforms/boards that WILL result in a brick if you do, especially if you're using the outdated Windows builds. https://github.com/karosium/smbusb/issues/10
You just need to read/write the data/eeprom flash.

SMBusb - Hacking smart batteries

noreply@blogger.com (Unknown) — Fri, 26 Aug 2016 15:40:00 +0000

Having gone deep down the rabbit hole of researching smart laptop battery controllers I've ended up reverse engineering a couple of them used in ThinkPad batteries. Looking around there's very little software available out there for working with battery controllers in general and most of them cost hundreds or even thousands of dollars. Usually the chips' datasheets aren't even publicly available. (Aside from a few outtakes from chinese developer forums)

So why would you want to mess with a smart battery controller anyway?

Consider the case of one ThinkPad X100e I purchased a few months ago. Battery dead. Querying the controller reveals it's had 43 charge/discharge cycles so the cells are practically new! And yet the controller was in permanent lockout mode due to a single overdischarge condition getting logged. Trying to charge the battery in the laptop resulted in a rapidly flashing charge LED indicating charge failure.

Some people will say "Well that's by design, a single overdischarge turns Li-Ion cells into potential fire-bombs!"

If that was true there would've been a lot more cases of batteries setting houses on fire back in the early 2000s as "0V deep discharge recovery" used to be a feature in some laptop battery pack controllers back then. It's not nearly as bad as some urban legends would have you believe.
Clarification: True 0V discharge kills Li-ion cells and you shouldn't attempt to recover them. The old controllers tried to fix over-discharged cells and they succeeded in the majority of cases because you rarely have a true 0V scenario unless you have a shorted cell or something. The new controllers on the other hand happily commit suicide at over-discharge voltages where cells are still easily and safely recoverable with little to no capacity loss.

Take the battery pack I mentioned above for example. After recharging the cells externally while carefully monitoring their temperature and reprogramming the controller the pack was fine. It ended up with 100% the design capacity lasting 3.5 hours (it's a power hungry AMD system with an ATI GPU)

For the manufacturer, taking no chances from a legal standpoint is understandable but sometimes they can go a little overboard. A 3.5hr battery ending up in a landfill is not the best outcome.

Another reason would be for re-celling the pack. You have some options when the battery of your laptop dies: Replace the whole shebang because it's too slow anyway, replace the battery with a factory one for $100+, buy a chinese knockoff for $20-50 or re-cell with good brand cells for $20-50ish.

As demonstrated in my previous article about laptop batteries, keeping the original controller board has certain advantages such as temperature monitoring and an extra safety feature. It's also a good bet that brand cells will survive more cycles without capacity loss than ChangJiang ones. (I've actually recently tested a 6-cell LG pack at 540 cycles and it held a 1.5Amp load for 80 minutes.. a ChangJiang pack at 230 cycles petered out at 50 minutes. A sample size of two and the CJ pack was lower capacity to begin with (4.4AH vs 5.2) but still...)

Ok, so how do you talk to these controllers?

SMBus, which is I2C's impatient cousin with nasty hard timeouts and bulk transfer modes not standard in I2C along with a RESTART condition in addition to the START and STOP you normally deal with (... or just 1-Wire in more exotic hardware but let's not think about that).

How nasty are the timing constraints? You can implement I2C through a USB serial dongle's flow control pins. You can't implement SMBus because your code, the windows API, driver, USB stack and controller firmware response overhead added up is over the limit (especially if your serial thing uses only USB1.1). You can't keep the clock idle for over 35 milliseconds or the controller drops the conversation.

But don't go TOO fast because SMBus can't go over 100Khz (I2C can do 400). All that rushing and it can't keep up the pace in the long run, figures..

Unfortunately this makes it cumbersome to implement a dumb SMBus interface on a non real-time system like a PC alone (not counting the actual interface between the EC/SMC and the SMBus devices in the system which is usually not accessible directly and/or isn't usable for more involved operations)

Did I mention that different controllers seem to have slightly different timing requirements?

The most well supported interface for speaking with smart battery packs is the Texas Instruments EV-2300. It's a fairly expensive piece of kit but it has the advantage of being able to work with TI's own software which has a myriad of options for the publicly available TI battery controllers running the TI firmware but more on that later.

What's next?

Once reliable SMBus communication is established you will have access to a battery controller that talks the SBS Standard! It's a standard so we're basically done now. We just look at the standard documentation on how to clear any failure condition and reprogram the controller to our desired parameters, easy!

Ha! Yeah, no. The SBS standard only defines the very basic functionality for a smart battery controller. The controller will have something sometimes referred to as a "sealed" mode which is where it's only going to service the limited SBS standard requests. This will be the standard mode for the battery as that's all that laptops need. No touchy on any of the settings that really matter and certainly no clearing of any error conditions.

They'll sometimes have a command to "unseal" and enter full access mode where some or all settings are modifiable with a mixture of standard and unstandard commands. Most of the time this unseal command will be password protected or worse. Some TI controllers are like this while other controllers will only implement a sealed mode for SBS compliance and a completely proprietary bootloader mode to modify flash memory content directly (which may or may not also be entered in a similar way). It's really a mixed bag.

What's similar in all SBS microcontrollers is that getting into the Boot ROM where you can access and modify flash memory is hindered by the firmware that's already running on the device.

TI

Texas Instruments is a BIG player in the smart battery world. They sell their battery management microcontrollers and analog frontends to pretty much everyone making battery packs. Some companies buy the whole package that is, the microcontrollers with TI-developed firmware. The security model mentioned above (sealed/unsealed/bootrom) is actually used mostly by the TI firmware. These pre-programmed micros under the "bq"-line usually have a letter in their model number such az the bq20z90. What's somewhat less known is that the bq20z90 is also sold WITHOUT the TI firmware as the bq8030(DBT). At the very least SONY and Sanyo have opted to buy the bq8030 with the accompanying (super-secret) SDK and develop their own firmware for their battery packs with it.

Did they not trust TI's expertise? Was the firmware too expensive to license? Did the TI firmware not do everything they wanted? Who knows! But the fact is production bq8030s are pretty much complete black boxes as they run a proprietary firmware and don't work at all with TI's own software. Other bq series are sold similarly as both pre-programmed and unprogrammed versions. The bq8050 would be another example though I don't know what the pre-programmed counterpart's model number is.

The EV-2300 will still talk to the chips running 3rd party firmware but the TI software will not work for anything other than simple SBS reporting.
The ONE thing the pre-programmed and unprogrammed chips will always have in common though is the TI Boot ROM. The challenge? Actually getting into it if there's already firmware on the chip. With the TI firmware the method for doing so is fully documented: You need to send two passwords to two SMBus commands. You can even find default passwords that will work in case the pack producer forgot (or didn't care) to change it, such as one particular series of Apple MacBook battery packs. (Charlie Miller did a LOT of work on this including making a cpu module (zip) for IDA to disassemble the proprietary Xemics CoolRISC core and modifying the TI firmware. Go check it out (pdf))

With a Sanyo or SONY or other 3rd-party firmware however, you're on your own! The procedure to access the Boot ROM is not public and neither are the passwords (if there even are passwords). The latter would also be true for most battery packs using the TI pre-programmed chips as pack manufacturers tend not to use the default passwords

SMBusb

So the obstacles to hacking smart batteries are numerous but let's take it one step at a time. First up.. the interface. Introducing SMBusb, a USB SMBus interface based on the Cypress FX2LP CY7C68013A(datasheet) USB Microcontroller or more specifically the dev-board that's available all across eBay for around $5 shipped.

This one here:


Search for: FX2LP board But all FX2LP based boards should work as long their firmware isn't pre-programmed into the EEPROM.

It's open source as far as firmware and software goes, comes with a library so you can easily use it in your own projects and includes a few tools to aid SMBus and smart battery hacking such as:

$ smbusb_scan -a 

------------------------------------
             smbusb_scan   
------------------------------------
SMBusb Firmware Version: 1.0.0
Scanning for addresses..
Skipping: a0 a1 
------------------------------------
[0] ACK
[16] ACK
[17] ACK

Which allows scanning for available devices on the bus and analyzing the command set they expose:

$ smbusb_scan -w 0x16

  * snip *

[2f] ACK, Byte writable, Word writable, Block writable 

[30] ACK 

[31] ACK 

[32] ACK 

[33] ACK 

[35] ACK, Byte writable, Word writable 

[37] ACK 

[38] ACK 

[39] ACK, Byte writable, Word writable 

  * snip *

and

$ smbusb_sbsreport

SMBusb Firmware Version: 1.0.0

-------------------------------------------------

Manufacturer Name:          LGC

Device Name:                LNV-42T4911

Device Chemistry:           LION

Serial Number:              41291

Manufacture Date:           2010.01.25

Manufacturer Access:        6001

Remaining Capacity Alarm:   561 mAh(/10mWh)

Remaining Time Alarm:       10 min

Battery Mode:               e000

At Rate:                    0 mAh(/10mWh)

At Rate Time To Full:       65535 min

At Rate Time To Empty:      65535 min

At Rate OK:                 1

Temperature:                23.05 degC

Voltage:                    21 mV (*)

Current:                    0 mA

Average Current:            0 mA

Max Error:                  0 %

Relative State Of Charge    0 %

Absolute State Of Charge    0 %

Remaining Capacity:         0 mAh(/10mWh)

Full Charge Capacity:       5616 mAh(/10mWh)

Run Time To Empty:          65535 min

Average Time To Empty:      65535 min

Average Time To Full:       65535 min

Charging Current:           0 mA

Charging Voltage:           0 mV

Cycle Count:                529

Manufacturer Data:          fffffff7

(*): This controller is just a bare board with no cells connected.

And also a couple of flashing tools for BQ8030 and R2J240 chips. (Note that there are NO passwords or methods included for entering the Boot ROM on already programmed chips)

Bonus: When you don't need the SMBusb (and you don't feel like learning fx2lib to do something interesting with the dev board) you can still use it as a 16 channel logic analyzer with sigrok. (You may need to compile sigrok from scratch with the VID/PID added in but it'll work)
And chances are you already have an FX2LP device laying around in your drawer in the form of an Altera ByteBlaster clone or one of the many USB logic analyzers that use it. You only need to access the hardware I2C pins for SMBusb to work and an easy point to get at those is the onboard EEPROM which is usually a nice big SO-8.

So where is this project?

Right here: http://www.karosium.com/p/smbusb.html

Notes on the Gobi2000 in a Thinkpad X100e

noreply@blogger.com (Unknown) — Sun, 01 May 2016 13:34:00 +0000

The Qualcomm Gobi2000 is an internal Mini PCI Express 3G modem. It was used in a variety of machines including the Lenovo Thinkpad X100e.
It's a bit unintuitive to set up (to say the least) so I decided to write this post. Maybe it'll help someone else out there.

So right off the bat unless you're a Verizon customer do NOT just install the driver from Lenovo's site because it will default to loading Verizon's firmware. See: https://support.lenovo.com/en/en/documents/migr-75433

If you already did you can uninstall and follow the instructions above or you can open the file: C:\ProgramData\QUALCOMM\QDLService2k\Options2k.txt and edit it.

The text file contains the path to 3 binary blobs which get loaded into the card's ram when the driver loads. Apps.mbn, AMMS.mbn and UQCN.mbn
You just need to change which directory the images are loaded from. \1 is the Verizon firmware. For a full list see the support link above.
Note that to load the generic UMTS firmware you need to load Apps.mbn and AMMS.mbn from \UMTS and UQCN.mbn from \6 because consistency was not the developers' strong suit.

Also unless you're on a CDMA network that doesn't use a SIM card and requires an activation procedure instead do NOT install "Mobile Broadband Activation" either.

DO Install "Hotkey Features Integration" http://support.lenovo.com/en/en/downloads/migr-74261. As far as I could tell it's the only way to enable the WWAN antenna. Fn+F5 brings up the radio power controls. It's also a separate executable so you can create a shortcut for it if you like. The naming is pretty straightforward, look through the installation folder in Program Files.

A note on all the abbreviations you can come across while setting up a 3G connection:
UMTS is the name of the whole 3G network technology, WCDMA is the name of the radio access layer used by UMTS networks. From a setup perspective they're pretty much interchangeable. HSDPA or HSUPA are high speed data services offered on a UMTS network. HSDPA offers faster download and HSUPA offers faster upload speeds. Together they are often referred to as HSPA. HSPA+ and Advanced HSPA+ are further iterations of this technology that offer even faster speeds.
And of course GPRS and EDGE are considerably slower data services running on a 2G GSM network.

Unlike Huawei or ZTE modems the Gobi2000 doesn't have a straightforward way to set which network and data service it should prefer. The automatic selection will be fine in most cases but sometimes you just want to force the setting. Like let's say the 3G network's signal is really weak and flaky but it's still faster than the 2G network that has good signal.
Apparently there is a method with the slow and clumsy Lenovo Access Connections tool but from what I can tell the setting doesn't persist.

I'm fairly certain the Lenovo tool just issues a manual network selection AT command. You can do that yourself (you can even add it as a pre-connection command to the Windows mobile broadband connection. It's there on one of the properties pages)
You can tell the modem to connect to a network by name but it's a better idea to use the network ID because carriers will sometimes name their 2g and 3g networks differently.

AT+COPS=1,2,"#####",0 (where ##### is the network id) will connect to the 2G network of the carrier

AT+COPS=1,2,"#####",2 will connect to the 3G network

To get the network ID you can issue AT+COPS=? to do a network scan (it will take a while) the 5 digit numbers in the list will be the network IDs

You can query the current operating mode with AT$QCSYSMODE?

On the 2G network I got simply GSM as the reply
On the 3G network WCDMA + HSDPA + HSUPA (which Windows listed as HSPA in the network list)
On another 3G network simply WCDMA (which Windows listed as UMTS)

You can also query the current network with AT+COPS?
You'll get something like +COPS: 1,0,"Network-Name",2

Note that the modem will return ERROR for most commands if it doesn't see a SIM card or if the radio is powered off.

UPDATE: It turns out that you have to use the terrible, slow, memory-hog Lenovo Access Connections tool anyway. The built-in Windows connection manager just gives a nondescript connection failed error every time :-(

[Random Teardowns] A couple of laptop batteries (aftermarket vs original)

noreply@blogger.com (Unknown) — Mon, 18 Apr 2016 17:05:00 +0000

Device: Original Lenovo 42T5225 (ThinkPad R61) and Chinese clone of 42T4788 (ThinkPad X100e)
Origin: Various
Reason for teardown: Broken
Impressions: I've recently opened up a few laptop batteries and decided to take some pictures. Keep reading if you've ever wondered just how different the Chinese aftermarket batteries are compared to the originals.

The original battery controller PCB is conformally coated while the clone is bare. Fair enough.

The original is based on the Mitsubishi/Renesas M37512 microcontroller (datasheet)

The clone on the other hand is based on the SINO WEALTH SH79F32 (datasheet)

Nothing terrible so far, right?

Well, if you take another look at the image with the original microcontroller there are two things worth mentioning on there. That component with the two long leads to the right of the micro is an externally triggerable fuse. It can blow during an overcurrent condition as any regular fuse OR the micro can trigger it in case of another hazard condition like say the cells overheating. Which brings us to the small flex cable temperature sensor stuck to the cell on the left side

Now let's see what the clone has in terms of overcurrent or overtemp protection.


Oh...

Zero for two.

So the most the micro could do is (attempt) to shut the FETs off in case of an issue. (If it even noticed it before the cells set themselves ablaze.)

Lastly, let's take a look at the cells themselves.

The original has Japanese made Panasonic cells

The clone has Chinese made ChangJiang (CJ) cells

No surprises here. And it should be pointed out that these aren't necessarily bad or more hazardous than any of the high-end cells. If anything they're just unlikely to handle as many cycles before capacity loss renders them unusable. That said, a fuse and temperature monitoring still wouldn't hurt.

[Random Teardowns] XL4005 5A step-down module with display

noreply@blogger.com (Unknown) — Thu, 29 Oct 2015 13:25:00 +0000

Device: XL4005 constant-current/constant-voltage buck converter with LED display
Origin: eBay / China
Reason for teardown: Project
Impressions: Ok so there isn't much to tear down on this given that it's just two PCBs screwed together with standoffs but oh well.

I got two of these for a project because they're just so cheap now. Supposedly they do 5amps and you get current limiting as well.

Already a bit modified

The modules themselves work reasonably well based on my limited testing. The display/monitor boards are pretty terrible though.

My gripes with them:

Horrible accuracy as-is and no calibration pot. (FWIW you can hook up 10k trim pots to the two unpopulated resistor pads near the LM358 to fix this.)
Horrible resolution and pointless, wasted digits on the 7segment displays. (I'd take an extra digit over the lower-case u moonlighting as V ...)
Painfully slow update-rate
Serial feature poorly documented but also borderline worthless (see below)

All of these issues could be fixed in firmware. I'm almost tempted to get an ST-LINK dongle and reverse engineer the thing but it'd probably take about as much time as reimplementing the whole board using a microcontroller I'm actually familiar with and not bothering with the STM 8S003F3P6 it has which is to say: too long either way to be worth it. Anyone up for the challenge?

As for the worthless serial interface: the biggest issue is that the serial processing code takes too long to run and the micro isn't updating the screen while it's running so you get a really noticeable dip in brightness every time you send a query for voltage or current. And of course they're separate commands which compounds the problem.
If you're continuously polling the board with something you basically won't be able to see anything on the display.

If after all that you still want to use it, here's the info they give you:

Baud Rate : 9600 Bps

BB CC ADDR 00 XX XX CRC ( current return command )

BB CC ADDR 01 XX XX CRC ( voltage returns to the command )

Among

BB CC for the header ( 2 bytes )

ADDR for the module address ( 1 byte )

00 to read the current command ( 1 byte )

01 is a read voltage command ( 1 byte )

XX XX arbitrary value ( 2 bytes )

CRC CRC checksum ( 1 byte )

Not bad. CRC is undocumented though and ADDR varies with board revision. (0 and 1 definitely exists)
Serial is standard 9600bps with no parity, 8 data and 1 stop-bits with no flow-control.

The revision with ADDR 0 may ignore CRC as long as it's not 0 because these have been reported to work with it:

Get current: BBCC00000000B4
Get voltage: BBCC00010000DF

It also doesn't return a CRC in it's replies and returns voltage and current in millivolts and milliamps (so a higher resolution than it displays) which is nice.

ADDR 1 on the other hand checks CRC and also returns it in replies. A brute-force loop later I got two replies with CRC and it was pretty obvious that it's just a simple addition you take the least significant byte of.

So the proper commands for ADDR 1 boards are:
Get current: BBCC0100000088 ( BB+CC+01+00+00+00 = 0188 so 0x88 )
Get voltage: BBCC0101000089 ( BB+CC+01+01+00+00 = 0189 so 0x89 )

Unfortunately this revision of the board returns values in 100 millivolts and 100 milliamps so for 4 volts you only get the value 40 .. FAIL!
And in case you're wondering if there's maybe an undocumented command you could use to get a higher resolution value or maybe a raw ADC value.. there isn't.

So in conclusion:
ADDR1 boards give you a low resolution value in exchange for a flickering or completely unreadable display.
ADDR0 boards give you a higher resolution value and I'm not sure if the flickering is present or not. Anyone know?

Junk 2006 iMac repair - Part 2

noreply@blogger.com (Unknown) — Sun, 20 Sep 2015 23:00:00 +0000

Continued from Part 1.

I checked around for a replacement display and ended up buying a Samsung LTN170X2-L02 (datasheet) for $25 shipped. Bargain.

Another thing the UniMac adapter comes with is a "Y cable" for the inverter since the original screen has 2 CCFL lamps while most 17" laptop displays have 1. This cable simply connects the two outputs together and the combined output to a single lamp.
I'd recommend NOT trying this with any other inverters without checking datasheets and schematics unless you're trying to fry something. It's safe with the particular inverter model used in the iMacs, NOT all inverters universally.


I had several CCFL extender cables left over from a previous buy so I used two of those to make the adapter.


Simple.

So then the display arrived like this:

@!#$

No apparent damage though, so I hooked it all up.

It ain't pretty but it'll do

Moment of truth!

I'll be damned. First try even. Complete with perfect example of why I hate glossy screens.

Not getting any output from the firmware was a bit alarming but it does start working after a few seconds of blackness. Never ended up messing with the EDID. I'm fine with no Apple logo or boot menu on this machine since it's only ever going to run one operating system (which coincidentally isn't even Apple's) anyway.

So now came the most annoying and time-consuming part of this whole project, if you can believe that: Mounting the display.

I wanted to use the original brackets but the holes were all in the wrong place. Not only that but the right side bracket has gaps where the new display had screw holes.. Ugh..
This is starting to sound like an ad but note that the UniMac also comes with universal brackets so for $25 it's not a bad deal considering how much trouble it saves you from... Since I'm a cheapskate though, ghetto measures it is!

Yeah.. It's not pretty. The right bracket was even more of a pain as I had to add plastic L-brackets to fill the gaps in the metal.

If memory serves you need to shim the display around 6-8mms from the left side if you're using the original brackets as a base. I did 5-6 (the nut in the picture above) and it's just ever so slightly not enough. Annoying.

Especially since it's not so bad here:

But once everything was snapped back together it moved a little bit to the left. !@#!

I already added some epoxy to keep stuff from moving so I just left it as-is. It isn't something you really notice unless you know what to look for and I actually couldn't see it when I looked at it a week later.

In hindsight I probably could've just used contact glue or double-sided foam tape to glue the display directly onto the front bezel since it weighs almost nothing. Oh well..

Total cost $55 and a few hours of my time.

Not bad for a compact Core2Duo system that's still more than adequate for email and light browsing.

UPDATE:
Still going strong in 2017. I just (4th of February) took it apart to redo the thermal paste on everything as the Radeon was idling at 71C even with the 80% underclock I had on it since day 1. I really want this to last so it had to be done since if it's 71C now It no doubt would've burst into flame under any sort of load at full clock.

I might eventually have to buy a mobo from an integrated graphics model when (probably not if) this finally gives up the ghost. Applying some expensive "overclocker's" grease I had left from the old days helped somewhat (5-10 degC lower), I hope that buys it another few years at least.

UPDATE:

Still going strong in 2018. I just replaced the Samsung display as the soldering of the CCFL tube failed which led to arcing which made the display's controller chip go into a reset loop or something. First time I've seen that happen. You'd think the display is completely dead and it's just the lamp arcing that's making it do that. I was feeling lazy so I very destructively removed the failed lamp and duct-taped one from the original broken LG display in it's place which worked fine as a temporary fix until I got a new one. (They're even cheaper now than when I did this project so I didn't feel like doing an LED conversion on the Samsung) Bought an AUO display instead for $20 shipped. The Samsung had better colors (IMO) but I've never had any issues with AUOs and color reproduction is not important for this machine so.. here's to hoping it lasts like the others I('ve) own(ed).

UPDATE:

2020: CPU overheating issues. Turned out that the heatpipes in the CPU heatsink have failed. I would not have believed it if someone had told me this happened to them. I removed all the heatsink fins to confirm and neither of the heatpipes were conducting heat at all. A donor machine was purchased and the heatsink and newer looking(less browning from heat) PSU were swapped in.

The "New" PSU promptly died 2 weeks later, old PSU swapped back in.

2021: Old PSU died. We're done with internal PSUs now, it's external PSU bodge time.

Old mac on life support

The DIN-rail thing I had lying around can do 12V/8A while the original PSU did 15.4A. I think I did some measurements with 100% CPU at some point and it should be fine but I figure the industrial thing should have good overload protection anyway.

In the future if a working machine can't be created using remaining donor parts and stuff from my hoard then they're both going to e-waste and my father will get my old IdeaCentre which still works fine (it's original PSU also died several years ago but it was much easier to deal with since it was external from the beginning and it's 19V so it runs off any old 90W laptop charger just fine).

Junk 2006 iMac repair - Part 1

noreply@blogger.com (Unknown) — Sat, 19 Sep 2015 17:13:00 +0000

So my father's browsing PC bit the dust. It was a 15 year old dinosaur with USB1.1, SD-RAM and a Northwood core Pentium 4. Wasted way more time trying to save it than the whole thing is worth. PSU troubles first then nothing working out right with the new (read: only 13 year old) PSU either.
Crappy Molex connectors, ancient barely functioning HDDs, etc. I gave up at the point where it became clear that money would have to be spent in order to get the thing running again. Simply not worth it.

So I went online and bought a BRAND SPANKING NEW ...

Just kidding, I bought this:

A Late-2006 model iMac A1208 (2Ghz Core2Duo, 1gig of ram, 160gig hdd) for $30 shipped, not a terrible deal.

I was pretty confident that I could fix it up on the cheap based on some initial research.

As you can see the screen is broken but that didn't bother me since most (all?) of these were sold with defective LG displays that developed vertical lines after a few years of operation anyway.

Now you'd think you could just install another 17" panel but of course it's never that easy.

The display Apple used in the machine has a "weird" pinout. I'm not sure if there's really a standard or if it's just some manufacturers agreeing to a certain pinout a few years after this machine was released but the majority of compatible displays will have a pinout that's different from the iMac's.

Since most of these machines developed vertical lines and most readily available displays couldn't be used with them an opportunity presented itself for anyone willing and able to design an adapter and so the UniMac was born.

The thing is a pin-swap board that lets people use the original LVDS cable with the new "standard" pinout displays. It also includes an 24C02 I2C eeprom that spoofs an original display's EDID for the firmware (you didn't think Apple would just let you swap parts out like that did you?)

In addition the onboard eeprom also enables using newer displays that don't come with an EDID eeprom at all.

That said...

IF your replacement display has an EDID eeprom then (even though the firmware will reject it) it will work once the machine is booted.. at least with the discrete graphics model.
What this means is you won't get the Apple logo or any other output from the firmware (boot menu, firmware upgrade screen, etc..) but it will work fine within OSX as well as Bootcamp, even in text mode.

If the Intel graphics model doesn't want to work this way or your display doesn't have EDID at all (or you're just really keen on getting video output from the firmware) then you need to get a 24C02 (24C01 might work too) eeprom loaded up with the original display's EDID data and hook that up to the appropriate pins.

The EDID data from my broken display for reference:

00FFFFFFFFFFFF000610589C01010101000F0103802517780AB460A1584E9726
165054000010010101010101010101010101010101019525A04051840C304020
33006FE510000018000000010006103000000000000000000A20000000FE004C
4D3137315730322D544C4231000000FC00436F6C6F72204C43440A2020200009

Also, if you DO have EDID but want to be a perfectionist you could try to find the part the firmware looks for and merge only that with the original EDID data of your display. I'm not sure if it actually makes a difference or not.

Now luckily the original connector has all of the pins in it (ie. it's not the type where unused pins are missing) which makes it ideal for a DIY conversion. So that is what I attempted.


The metal casing is attached to the connector with a few tabs and some glue but you can tease it apart with tweezers.


There's hot glue at the base but it doesn't adhere to much. You can just push it down the wires.


This part it finicky and requires a lot of patience and several different tools. The center part slides out.


Slowly and carefully..

Success

I'm sure there's a production jig/machine for this connector that pushes it together. It's really not made to be disassembled again so just keep that in mind and treat it accordingly. It took me about 20 minutes to pull it apart.

Pin-swap time!


Before


After

I did solder the missing grounds afterwards and just connected them to the exposed ground lead

The pinouts are as follows:

Left is the original LG display and right is the new "standard"

Credit goes to Jim, author of じむのとりあえずやってみたの巻 who has an 8 part series on doing the same thing with no prior knowledge (in Japanese).

All wires are color coded so I've made these additional notes while doing the conversion:

Thick green wires are ground
Orange wires are +3.3V (you'll have one left over after conversion)
Black is DDC Data
White is DDC Clock
Pink is DDC Vcc

LVDS pairs are individually shielded in colored cables (peel back the black cloth-tape further if you can't see them)
These outer cable are:

Green: Even 0
Blue: Even 1
Magenta: Even 2
White: Even Clock
Black: Odd 0
Red: Odd 1
Brown: Odd 2
Yellow: Odd Clock

LVDS inner wires: Green is POSITIVE, Red is NEGATIVE

After all that I put the connector back together and added some tape.

A drop of mineral oil on the pins helped with reassembly.

Now I just needed a new screen.

Continued in Part 2.

[Random Teardowns] VGA to composite converter box

noreply@blogger.com (Unknown) — Tue, 10 Mar 2015 17:33:00 +0000

Device: VGA to composite/s-video converter
Origin: eBay / China
Reason for teardown: Curiosity
Impressions: Feels cheap, looks cheap, is cheap, works well enough.

EM636165-TS7 (datasheet) DRAM

VX1937 (datasheet) one chip solution

[Random Teardowns] Hyundai 30GB USB microdrive

noreply@blogger.com (Unknown) — Wed, 26 Nov 2014 17:46:00 +0000

Device: Hyundai Digital 30GB USB microdrive
Origin: DX / China
Reason for teardown: Died
Impressions: Didn't mind the construction of this but it always took over 30 seconds to enumerate on USB. Maybe I should have sent it back immediately but well.. it did work. Until a few days ago.
This thing is essentially a 1" Samsung Spinpoint HU030HA 30GB ZIF/PATA microdrive and a usb interface board with an obscure Moai M110E interface chip.

The Moai chip appears shorted. Maybe I can buy a ZIF interface board to save the data off the drive at least as it still seems functional.

UPDATE 2015/Dec:

The drive works. I bought a PATA ZIF adapter and a PATA USB HDD enclosure so the original owner can use it once more in a slightly (understatement) bigger form factor. Also: one xmas present down.
I believe most chinese PATA ZIF adapters will work fine with these drives.

Lenovo IdeaCentre A600 Restoration - Heatsink and conclusion

noreply@blogger.com (Unknown) — Tue, 18 Nov 2014 02:12:00 +0000

Continued from the previous post.

So the heatsinks in this thing were toast. Because the machine no longer used an MXM card I didn't have to worry about that one but the CPU cooler was still a big headache.


Remnants...

After all where am I going to find a replacement heatsink for an obscure all-in-one pc for an affordable price no less?

Do I try and get heatpipes and rebuild the heatsink myself? I really didn't want to..

I found an ID number on the demolished remains of the original and to my surprise, actually found a seller on eBay. A clearing house in China that had no idea what it was for and only had it listed by that obscure model number. Haggled the price down from $60 to $25 for 4 pieces including shipping.

Better than spending hours on bending and soldering heatpipes.
They didn't want to sell me just one so now I have 3 extras.. (Though unlikely, if anyone wants one for the price of shipping, contact me on one of the addresses on the right).

Heatsink issue solved!

I thought about replacing the front glass. I even had a glass pane cut and masked for painting.

But then I realized I despise glossy screens so ended up just painting the plastic frame that I would've glued the glass onto. It works for me.

Installed a T9600 CPU, 8 gigs of ram and 2 SSDs. All of which I got from eBay.

Secondary SSD install:

Professional mounting solution

That cable is also hacked since it originally ended in a micro-SATA connector (which is basically a regular SATA connector combined with a smaller power connector that lacks the 12v rail).
I separated the usable SATA connector with a saw and added a standard full-size power connector in place of the weird one. Thankfully 5 volts is all this SSD needs.

I have to say I'm very happy with the performance and how it turned out overall.
I've been using this machine for the past 5 months (including writing these posts) and it's been rock solid.

I'm glad I managed to save it from the landfill.

Lenovo IdeaCentre A600 Restoration - VGA hack

noreply@blogger.com (Unknown) — Sun, 16 Nov 2014 19:22:00 +0000

Continued from the previous post.

I'm sure this project is going to seem dated and futile to many. Why fix a past-generation PC and add an obsolete graphics port? What's the point?

The only thing I can say is that I don't actually need anything better than a higher-end Core2Duo and 8 gigs of ram for what I'm doing so I don't mind older gen hardware. It's also cheap.

The 21" display is an upgrade compared to the 19" 4:3 monitors I used before, but I still didn't mind using those that much and I have 2 of them like I mentioned in the first article, one of which still has "fresh" CCFL tubes.

So if I could keep using that one in conjunction with my "new" PC I'd be fine with that even if it's through VGA.

Looking through the schematics of the motherboard I found that it has unpopulated VGA output circuitry that ends in a set of test points.

You can guess where this is going.

A parts order and some hours later here's the (admittedly pretty terrible) result.

In my defense, these passives are 0402 and I used the same soldering guns I showed your earlier with really thin wire for the tips. I'm surprised I managed to maintain my sanity throughout the process and end up with something that actually works.

It took me a while to come up with a good solution for hooking up something to the test points in a way that isn't totally horrible. This is what I ended up with:

Those final two pins still bother me

Probably could've gotten an FPC connector with pin pitch closer to that of the testpoints but flat flex cable for that was around 5 times the price of this one. Go figure..

On the other end is

FPC connector at end of ribbon cable

It works pretty well even though everything's unshielded.

See the conclusion in the next post.

Lenovo IdeaCentre A600 Restoration - MXM to Onboard Conversion

noreply@blogger.com (Unknown) — Thu, 13 Nov 2014 23:12:00 +0000

Continued from the previous post

Quite a lot of things needed to be changed to get the Intel GPU up and running.

Removing the resistors that disabled the onboard graphics and set up the MXM as default
Reconfiguring the clock generator (moving resistors and jumper links) to output the necessary clocks for the onboard GPU
Moving the backlight logic control circuitry (a few transistors and passives) from the MXM side to the onboard one (which also happened to the one the other side of the motherboard)
Moving the LVDS connector

Backlight control circuit components in their new location

I never invested into any modern soldering tools so this is going to be entertaining.
Behold my extremely professional tools made especially for the LVDS connector.


Two relics and some bent copper wire

Connector in MXM location

Connector removed

Pads cleaned

Connector in on-board location

Note how the sticker magically repaired itself (I'm cheating because I didn't take enough pictures)

Let it be known that I have since bought a proper soldering iron (though no tips that would've helped me with this...)

I did consider just buying and installing another connector instead of moving the original..It's a Hirose DF13-40DP-1.24V-55. I decided against it due to minimum order quantities and shipping costs. There's no way to keep both options alive anyway, so there really isn't much of a point. One of the connectors would be useless without moving a significant amount of components around.

So after doing all that (which took like a week of working on it after work) I had a machine that.. still wouldn't show anything on the display.
Everything seemed fine in dmesg now. The error message was gone and even the panel resolution was detected properly but the backlight just wouldn't turn on.

There is a small board with a capacitive sensor array and a microcontroller in the plastic frame that the protective glass was glued onto. You could touch the glass above it and it would light up to reveal 4 "buttons" (backlight controls and optical drive eject). I didn't have this board connected while testing which turned out to be a mistake. Embarrassingly enough it took me a few days to figure this out.
The board seems to be responsible for the backlight PWM control signal so without it there's no backlight.

After hooking it up I was greeted with a different problem. The inverter shut down after 2 seconds and would not start back up until a power-cycle. This is not a good sign at all and usually points to either the CCFL tubes or the inverter transformers being bad. Urgh!

At this point I was getting pretty annoyed with the project so I left it alone for a couple of weeks contemplating whether I should just toss the whole thing.

In the end I took one of my monitors apart and hooked up the CCFL tubes to it's inverter to make sure they weren't bad. They weren't, so the issue was on the inverter board.

DARFON 4H.V1561.091 inverter board

Not the transformers though, they checked out.
No ic pinout, no datasheet, no schematic. I painstakingly de-soldered and tested 90% of the components of the board separately. Everything checked out.
The least likely suspect - the controller chip - was looking really suspicious at this point. The only problem being that this chip (LX6512CPW) in this package (TSSOP) is simply not sold anywhere.

Replacement inverter boards cost as much as I paid for the whole machine.
Do I give up and hack in a universal inverter board after wasting so much time on this? There's no way it would fit into the case and brightness controls wouldn't work properly. Urgh!

As a final Hail Mary attempt I contacted MicroSemi, explaining the situation. I didn't think they'd really bother with a samples request for a discontinued product used in one-off repair by a hobbyist.

They did!

Brand new LX6512CPW sample in nice plastic case

It works!

Wooo-- wait.. why does that picture look weird?


Hrmm?

Some pixels are the wrong color...

I double and triple checked the LVDS connector visually. Couldn't see anything wrong. Continuity checked the cable, checked out.

After the fourth disassembly and spending an hour looking at it with a magnifying glass and poking at it with a multimeter while double-checking the schematics I finally found it. Barely visible adjacent pin short at the very base of the LVDS connector. @#!$!@%

Couldn't even get it out with solderwick so I ended up having to break it apart with a needle ...

But then it finally.. finally worked.

So now I had a functional machine converted to use the onboard graphics with a repaired inverter. Nice!
Slight problem... I can't use a dual monitor setup with this machine
... or can I?

Check the next post to find out.

Lenovo IdeaCentre A600 Restoration - Intro

noreply@blogger.com (Unknown) — Mon, 10 Nov 2014 11:50:00 +0000

This was a pretty lengthy project so I won't post it all in one go, this is just the beginning.

Some background info:
I've been using the same Core2Duo workstation (actually a ThinkPad on a docking station) with dual monitors for quite a while.
I managed to buy another 19" 4:3 Benq a while back that was the same model (and had the same fault) as the one I repaired back in 2009.
That one was probably close to 10 years old at this point and the CCFLs were beginning to show their age especially when sitting next to the "new" one.


What time does to CCFL tubes

I also sort-of wanted a widescreen monitor and more ram since the ThinkPad topped out at 4 gigs and I was constantly running out of ram while doing work (several browsers, IDEs and a VM running) which was driving me crazy.

One day while browsing an auction site, I found this thing.

A beat-up mangled all-in-one from Lenovo. It kind of piqued my interest because it was in such a pitiful state but could potentially be repaired/modded if everything the seller said about it was true.

So here's a quick initial rundown:

Powers on and stays on but doesn't do much else
Heatsinks forcefully removed with what I would imagine were bolt-cutters (Not a clue why someone would do this.)
Front protective glass chipped but display behind it intact
Two LVDS connector pads on the motherboard labeled "ONBOARD" and "MXM" with only MXM being populated (swappable?)
Supports Core2 mobile CPUs and DDR3-SODIMM (but only up to 8 gigs as I later found out)


What a mess...

The seller tried adding some pins to the unpopulated pads but I won't hold it against him

I did some research and found the motherboard schematics online. According to those this board came in MXM and LVDS editions and it did in fact seem like one could be converted into the other with some (considerable) effort so if the MXM video card turned out to be toast like the seller predicted I could still do that.

Since I never heard anything good about MXM cards I assumed I'd end up doing that from the get-go if the motherboard was salvageable at all.
If not I would've just turned the thing into a monitor with an LVDS/DVI interface board off eBay so it seemed like I could get something out of it one way or another (assuming the display itself was fine)

Haggled a bit but still ended up buying it for more than I wanted to pay. Around $50-ish shipped.

By the time it arrived the chipped front protective glass had cracked lengthwise which I wasn't particularly happy about especially since it did so because of the lack of padding in the package *grumble*.

Thankfully the display seemed to have survived even that ordeal, or at least it wasn't visibly broken.
I did spend several hours removing broken fragments of glass from the plastic frame afterwards which wasn't really that much fun.

Hardware-wise to begin with I wanted to test whether the motherboard was functional at all. The fact that the SuperIO chip's pins were a big mangled on one side didn't bode well... Straightened them just a tiny bit and cleaned up the general area with solderwick.


Don't worry they're not really touching

A few resistors and capacitors were also destroyed presumably by the same incident that damaged the pins so I replaced those as well.
Then I made a bootable Linux thumbdrive, stuck it in, hooked up a keyboard and tried to get the thing to boot off it by blindly guessing at key combinations for the boot source selection menu and watching the activity led on the drive.

At one point I started getting activity so I hooked it up to my LAN, fired up Wireshark on the home server listening for DHCP packets and tried again.
Sure enough the board was successfully booting into Linux and setting up the network, nice!
I SSHed in to check things out.

The board didn't seem to detect the MXM card at all and was trying to fall back to the on-board Intel GPU but had issues initializing it. I don't have the exact dmesg output anymore but it wasn't a terribly friendly error message.

Ran some more tests to make sure everything else was working at least and it seemed like it was.

Decided against trying to fix or replace the MXM card. I just don't trust the things and the onboard Intel GPU is more than enough for a coding workstation anyway.

In order to avoid any potential trouble I'm not going to post any links to or outtakes from the schematics since I'm pretty sure it was never meant to be public. You can find it online if you're interested. Certain parts/components are tagged with abbreviations for the two versions of the board, UMA (Unified Memory Architecture) referring to the system memory sharing Intel GPU and MXM for the obvious.
(For those who don't know: MXM is basically PCI Express x16 in a mobile form factor.)

Printed out all the pages (around 6?) where these appeared and got to work on the conversion.
I'll show you what I did in the next post.

[Random Teardowns] REX-C100 PID Temperature Controller

noreply@blogger.com (Unknown) — Fri, 07 Nov 2014 10:48:00 +0000

Device: REX-C100 PID Temperature Controller
Origin: eBay / China
Reason for teardown: DOA
Impressions: Not impressed to say the least. A mains trace near the connector (which has spring-contacts to horrid quality tin-plated contact pads on the board) blew out on first power-up. Guessing the trace was damaged from the get-go. Overall mediocre quality.

The thing is a lot smaller than what I imagined

Made in Japan. Sure it was.

Power supply and main board

Display board

Some closeups

PS(A): Definitely don't go anywhere near the ratings of the relay unless you solder wires directly to the board.

It is what it is

[Quick Tip] Determining a Type K Thermocouple's Polarity

noreply@blogger.com (Unknown) — Wed, 05 Nov 2014 23:35:00 +0000

Say you took apart a type K thermocouple connector and don't remember which wire was connected to which terminal.

Here's a simple test to figure out the polarity: The negative wire is attracted to a magnet


Neodymium sphere magnet sticks to negative wire

And in case your connectors aren't marked: The wider pin is the negative.

Netbook hinge repair

noreply@blogger.com (Unknown) — Mon, 03 Nov 2014 17:27:00 +0000

What happens when you buy a netbook on auction for a friend, advertised as used in great condition with minimal wear and then the scammy seller sends you a machine that had it's hinge support posts broken off and what's worse: destroyed by a less than useful kludge? Well, if you're like me then after the negotiations have gone nowhere and the seller got the well deserved negative feedback (won't go there) you start thinking of ways to salvage the situation.

Here's the horror show:

You can't see it but basically someone tried soldering the metal threaded inserts into the plastic and once they were either satisfied with their "work" (the thing and beads of solder were rolling around inside the case when I got it..) or they realized the futility of their actions they then proceeded to drown everything in super-glue.

Turns out I should've done my research because the hinge supports were notoriously bad on this model and a large percentage of them that I've seen advertised since have had the same issue (minus the butchery of course)
The machine itself is some off-brand cheapy so got what I deserved and paid for, I guess..

The support posts were beyond hope so after racking my brain for a little while I came up with a following solution:

Cleaned up everything and filed off all the broken and melted parts until the stubs were level.
Drilled and countersunk holes from the top of the case where the posts were (or at least that was the plan but plastic just grips and pulls the drill bit so they both went a bit too deep, eh..)
Added long screws through the countersunk holes and spacers from a plastic tube on the inside (as a prosthetic to replace the broken sections of the support posts)

So now I could tighten the case together by using a nut where the screw went originally.

I also cleaned up the hinges (which were really seized up with grime and some leaked super glue) using dental floss and a tiny amount of mineral oil which worked really surprisingly well.

Did this quite a while ago and the machine (and hinges) have been in constant, daily use for the past 5 months at least. So far they're holding up great.

As an added bonus, the same person who botched up the case also turned out to have replaced the CMOS battery at some point by ripping the spot-welded tabs off the original and and loosely duct-taping them to a new one...

After all that the machine still has some sort of issue that I couldn't figure out but I'm sort of guessing that that's BGA-related so I'm not going to bother with it. It hard-locks under heavy load when cold booted (literally.. once it has warmed up the issue can't be reproduced. *shrug*)

Industrial Mini PC Quick Fix

noreply@blogger.com (Unknown) — Wed, 29 Oct 2014 23:27:00 +0000

Whew, It's been an interesting year.
I am still alive just haven't been doing many things that are a good fit for an entry on this blog.

Here's a quick project from a few months ago.

I wanted a PC that a, wouldn't take up much space b, I wouldn't really care about breaking and c, had an LPT port for left-over DIY interfaces with enough processing power to run their associated tools if I needed them.
A compact old-school hardware hacking PC if you wish.

I ended up buying 3 of these industrial mini pcs for somewhere around $20 if memory serves.
2 wouldn't boot, one was fine.

They had a FabiaTech FB2530 motherboard with a Geode CPU running at 266Mhz, dual ethernet, dual serial (which are pretty useful too), lpt, usb. Fits an IDE laptop HDD or a CompactFlash card for storage.

The issue with the 2 that wouldn't boot ended up being bulging capacitors in the power supply board.

They both started working fine after replacement.

Sold the ones I didn't need so I got to keep one for free. I've used it for a few projects since though it's mostly just been sitting on my desk for the past 6 months.

On the bright side it's really small and isn't much of an eyesore.

Lobotomy of an ancient smartcard reader

noreply@blogger.com (Unknown) — Sun, 22 Sep 2013 00:28:00 +0000

Bought a few of these ancient V-Star smart card readers for around $1 a piece. Manufactured in 98, fits in a 3.5" floppy drive bay, no drivers, protocol documentation lost to time. They are essentially useless at this point except for parts.

There is however a very simple interface that is still somewhat useful today. It basically just provides level shifting and clock to the smartcards and connects them to RS232. I'm talking about the "Phoenix Interface". Beloved accessory of satellite "enthusiasts" of the old days.

The V-Star has a max232 clone on-board that is the heart of the phoenix interface. They also provide the standard clock rate that makes the card's uart run at 9600bps, so it has all the parts needed for the conversion already built in. All I need to add is wires, but I do need to remove the entire "brain" of the reader first.

I'm not going to make a thorough how-to though mainly because of the obscurity of this device (also I'm lazy)
Here is the finished mod and a few notes (with lots of omissions):

After the brain removal I had to force-enable the clock output which just meant pulling the 74HC125 buffer's appropriate Output Enable pin low. Then I had to connect the card's reset control the serial port's RST pin, This involved patching through the original micro's pins and then connecting the appropriate RS232 level input of the max232 clone to the RST pin of the serial port.
Presence detect was a bit of a pain because they did their own thing that I couldn't be bothered to trace down so I separated the switch in the smartcard socket via a few trace cuts, connected it to a weak pullup then to an unused channel on the serial chip (the other end of that channel to the CD pin of the serial port). Then the 1wire UART used by the smart card needed to be connected by using a schottky diode (black SMD thing hanging off the SO ic pad on the bottom picture) and that's about all there is to it. (note the idle state of the serial bus is high and TXD works by pulling the bus low so the diode direction is sender < receiver

Fixing the cable

noreply@blogger.com (Unknown) — Mon, 22 Apr 2013 21:40:00 +0000

So a few months ago I switched from ADSL to cable. The installation didn't really go smoothly as everyone seems to have forgotten about an extra splitter in the attic which was left in the path of the modem.. D'OH!
The tech was already running late on our install and was forced to take half-measures. Because the modem was seeing crappy signal levels (and we didn't know about the splitter at the time) I believe he adjusted the "street amplifier" so we get a stronger signal. This still only kicked the modem into the far edge of their recommended levels however, but off he went to the next job saying that'll do.. and it did for most of the winter the modem was hovering around -5dBmV receive and 53dBmV transmit but as temperatures rose so did signal levels decline and on the first modem desync I was looking at -9/58 which is very far from ideal. 60dBmV is the maximum transmit power the modem can do AFAIK, so it took almost 100% capacity for the outgoing signal to get through

I was looking at the modem's customer-accessible network information page throughout the months and eventually coded a quick php script that Cosm, an online data gathering and graphing system can poll.

The Cosm feed for my modem data can be found here (like removed, see below)

Well after the first desync I realized I had to do something. Getting up to that particular attic section was something I really didn't want to do but the alternative was just way too invasive. What I found up there explained the issues perfectly. A 20 year old coaxial tap (amazingly with F connectors, but they were extremely weathered..) in a small puddle of water. I have absolutely no idea how that happened. There was no water anywhere else except around the input of that tap. Murphy? Or maybe water was coming in through the coax but hopefully that's not the case..
The cable that the modem actually got the signal through was also very low quality and mangled in several places. It looked like something was chewing on it.
There was also an ancient non-F splitter that supplied 3 TVs in the back of the house.

I threw out everything I could see up there, installed new F connectors, relocated the cable modem tap so it connects directly to the incoming cable and installed a high quality splitter for the rest of the house.

The effect from the modem's perspective:

Cosm graphs

From the low end of the threshold to the high end in 123514 easy steps. The signal level might be a teensy bit high now because of the adjustment they made initially but if that causes any problems I'll just have to call and get them to send a tech out to adjust the street amp back to the default level.

I also discovered self amalgamating tape. Specifically that I had some in my drawer for years not knowing what it was. (Don't laugh..) In case you're like me and this is the first time you hear of it: it's great stuff. Also called self-vulcanizing tape or self-fusing tape, you wrap it on something (a cable connection for example) like a bandage overlapping layers of itself while stretching it out and it'll fuse together into a watertight insulating rubber sleeve after a while.

I didn't want to take any chances so I used it on all primary connections.

Attic-shot

As a bonus of the rewiring the in-house network is now perfectly symmetrical.. which I've read is also not a bad thing.

UPDATE: Yes, sadly Cosm had turned into Xively or whatever... Since my data upload was based on Cosm's "Pull" feature and the new thing didn't retain that (while also being severely deficient at presenting data at least at launch) I didn't bother updating my script. Oh well... Good luck at their attempt at monetizing the service I guess.

UPDATE #2: Now pushing data to data.sparkfun.com instead and using imp.guru to plot. You can check it out here

UPDATE #3: I'm now on GPON so no further data :-)

KludgEee

noreply@blogger.com (Unknown) — Mon, 25 Mar 2013 20:27:00 +0000

Couple of years ago I bought a supposedly broken EEE 901 netbook motherboard for $5. Not really sure what I wanted with it. Could've been during a time when I wanted to practice soldering BGAs or maybe I just couldn't pass it up for the price. Either way the motherboard turned out to function perfectly. What now?

The thing ended up at the bottom of one of my junk boxes surfacing from time to time to help test the odd monitor. Then around two weeks ago I realized I have enough junk lying around in random boxes for a functioning PC.
While not doing a very good job at it I'm constantly trying to do something with stuff that's just taking up space and doing nothing because it annoys me. Combining them into a single piece is one way ease that so I finally broke down and decided to build a Trash PC.

Ingredients:
The aforementioned EEE motherboard
1 GB DDR2 SO-DIMM ram
The cheapest Chinese mSATA/SATA converter card I could find (that I had to ghetto-solder a SATA-cable to because it wouldn't fit into the mobo with the connector in place)
Samsung 20GB 2.5" HDD (this was inside a Chinese Xbox HDD. Sold the enclosure for a profit, kept the hdd. Result: 1 (almost) Free HDD!)
Intel 4965ABGN miniPCIe wifi card from a Lenovo laptop, that was the main reason for the previous article.
Antenna connector/cable from a miniPCIe PCIe WLAN adapter card
3 random heatsinks from the junk-box
Random fan from the junkbox
VGA breakout cable from previous scrapped case-build project
The case of an ancient Amstrad Satellite STB from the dumpster
A piece of veroboard and a switch from the junkbox (power button)
A chinese USB IR PC-Remote (actually not bad for $4.38)
A KIS3R33S based 5V reg built on a piece of veroboard (power supply for the HDD)
Random salvaged wires, mounting screws, nuts, a piece of PCB, zipties, epoxy and hot glue!

The idea was basically: The simpler/easier the mounting option the better, the less holes to drill the better, the less time it takes the better. As long as it stays in one piece everything goes.

The end result is inevitably kludgey and trashy but in the end it works, doesn't fall apart from a jostle and only looks as hideous from the outside as the STB case did to begin with so.. All good!

I didn't take any pictures during the build because I wanted to be done with it ASAP that's why there are only ones of the finished box.

With a $13 VGA/Composite converter it might even see some use on an old CRT TV as an IPTV and media player box now. The 900Mhz Celeron CPU is enough for SD streams and SD content.

I measured the DC power consumption on a whim:
Standby: 1.4W, Idle: 16W, Peak: 22W

Intel wifi driver brand-check removal

noreply@blogger.com (Unknown) — Sun, 20 Jan 2013 20:37:00 +0000

It's fairly common knowledge that Lenovo like many other makers uses a bios whitelist to restrict the wireless cards that can be used in their laptops. I've bypassed that with a modded bios on mine a long time ago when I upgraded various parts of the machine and I've had the original Intel 4965AGN lying around collecting dust ever since. The time has come to finally use it somewhere and ... it doesn't work!

Windows complains about failing to start the device. "This device cannot start! Code 10"

Event log contains two entries
5001 - Could not allocate the resources necessary for operation
5006 - The version number is incorrect for this driver

Head-scratching ensues then Linux is booted where the card works flawlessly.
Several other driver versions are installed on Windows yielding the same result.
Time to Google.
It seems like the issue is fairly common and usually appears when people try to use branded cards in different machines than they are originally for.. At this point I'm beginning to suspect that the Intel drivers are specifically blocking the branded cards from working in non-matching machines.
With a very low tolerance for annoying practices like this and a free weekend I load up the driver in IDA.

I have to confess never reaching the source of the issue. I've run out of time and got the driver working so I didn't investigate any further. There could be a less nefarious explanation for the behavior, although the same driver working flawlessly with the card in a Lenovo machine would suggest otherwise.
[Update: Next weekend] -
I can now confirm that the driver checks for a special entry in the DMI table for Lenovo branded cards and checks the manufacturer name of the machine for HP branded ones. It would seem that Lenovo branded cards would work fine in HP machines without any modifications to the driver. I'm not sure that patch #2 below is required at all. Just nop-ing out all the brand-check specific ID comparisons in #1 might/should be enough to get a completely unlocked driver.

There are two areas that I patched.
#1 Seems to be doing something specifically for my card's device ID (0x4230). Since my card doesn't work right now and I'm suspecting that the driver does an extra check for branding on my card (and AFAIK the 0x4230 ID is strictly a Lenovo ID) this seemed fairly suspicious so I nop-ed out the jump at 53DF5

#2 0x4229, a generic ID is receiving some attention here that looks to be the right kind. I want in on that. Changed 0x4229 to 0x4230

A PE checksum fix and a driver reinstall later I had working wifi.

I did have a couple of cases where I had to "powercycle" the card get it to see networks or to connect to one. Not sure if that's due to the patch since I couldn't reproduce the behavior after switching to Intel's PROSet tool to manage the connection. Will update this post if the problem resurfaces but even with that issue the driver was working well once it was connected to an AP even after downloading several hundred megabytes so it could be that this driver just doesn't like being managed by XP directly.

[Update: Few Days Later] - The problem hasn't surfaced since.

Patch info:
File: NETwLx32.sys
Version: 13.4.0.139 (but note that every newer version of the driver seems to contain the same version of this sys at least. Guess it was never developed further)

fileoffset original patch
000002B1 2E 62
000002B2 B8 BB
00043DF6 0F 90
00043DF7 84 90
00043DF8 9F 90
00043DF9 00 90
00043DFA 00 90
00043DFB 00 90
00044103 29 30

Checksum fix included

ps.
This is almost guaranteed to not work with any other card (besides device id 0x4230) as-is but working patches could be created for other cards based on the principle.. maybe.

I'm not responsible for anything you do with this information, you do it at your own risk.
Please don't ask me to patch drivers :)
Leave a comment if this has helped you get your wifi card working.