HDD Salvage: ST380011A, ST3160815AS, ST3250310AS, WD5000AAKX & HDP725025GLA380

Often paying a visit to a friend can end up becoming a salvage operation. In this case, on my visit, I was informed that there was a stack of hard drives that are surplus to needs and would be disposed. I decided not to let them hit the bin just yet – it would be good to take them home and see if they still worked and what their current SMART stats looked like. There was one catch though – I was not allowed to poke around the data, so respecting the owner’s wishes, I went straight into a full overwrite test.

Seagate ST380011A

We start with a classic Seagate IDE drive, the Barracuda 7200.7 series 80GB model, ST380011A. This one has firmware 3.06 and is Made in Singapore probably around 2003. The top metal cover is somewhat shiny – some of the models had “matte” covers while others had a propensity to grow bad sectors.

The PCB shows exposed chips – older models often had a “seashield” cover over the PCB to prevent accidental damage. Later models took the “Western Digital” route of putting the components on the other side of the PCB.

The drive is of the regular half-height thickness, equipped with the regular IDE/Molex sockets and a jumper block for configuration.

Testing of this drive was done on a native IDE port on an older computer running Windows XP. The drive had an impressive 42760 hours under its belt but with no reallocations and just 6 start-stop counts. This seems to be a drive that may have been used on a continuously-running server of sorts. After testing, there was no significant change in the vital signs indicating the drive is still healthy.

On the full surface test, writes ranged from 55.9MB/s down to 28.6MB/s with an average of 44.8MB/s with a 12.9ms access time. Reads ranged from 55.9MB/s down to 29.1MB/s, averaging 45.1MB/s with a 15.5ms access time.

Seagate ST3160815AS

The second drive is a Seagate Barracuda 7200.10 series drive with a 160GB capacity, model ST3160815AS. This drive has a SATA interface and was Made in China with firmware 3.AAD. It appears to be dated to sometime in 2007.

As mentioned earlier, the later drive PCBs mounted the components on the other side, reducing the chance of damage. The use of higher integration and SMD components results in smaller PCBs.

This particular drive is a reduced-height model, indicating it has fewer platters internally and is probably a low-cost model.

The drive was tested through an Asmedia-based USB 3.0 bridge board. Unlike the drive above, this unit had 433 reallocations already with zero pending sector count. This indicates the drive probably has some damaged areas and is probably less reliable. It has 17074 hours on the clock with 1160 power cycle counts, which makes this drive around middle-aged and probably used in a workstation scenario. No further bad sectors grew after testing, so the drive is probably not unusable.

Testing the drive saw some uneven transfer rates towards the outer tracks which is probably where the bad sectors have been reallocated from. The drive had a write throughput ranging from 75.2MB/s down to 36.5MB/s with an average of 60.2MB/s and an access time of 7.33ms. When reading, the throughput ranged from 75.3MB/s down to 36.5MB/s with an average of 60.3MB/s and an access time of 15.0ms.

Seagate ST3250310AS

The third drive is a 250GB version of the above, with firmware 3.AHC, also Made in China. This drive is an OEM drive for HP as indicated by the labels.

It too is a reduced height drive with a slightly different spindle motor it seems. The 160GB drive comes from the WU plant (presumably Wuxi) whereas this one comes from the SU plant (presumably Suzhou) which is shut down as of 2017.

The drive is relatively young, seeing just 8494 hours of operation and 1227 power-on cycles. The figures show the drive to be healthy – note that the extra attribute shown in CDM after certification is a “bug” with the USB bridge from time to time.

Compared to the 160GB drive above, it seems the 250GB model is quite a bit quicker. Write speeds ranged from 125.5MB/s down to 59.4MB/s, averaging 100.3MB/s with 8.55ms access time. Read speeds ranged from 125.8MB/s down to 60.5MB/s, averaging 100.9MB/s with a 19.7ms access time. This suggests that maybe despite the drives being of the same generation, the platter density may be different as both drives are a 2-head/1-platter design.

Western Digital WD5000AAKX

The above is a Western Digital Caviar Blue WD5000AAKX, dated 30th June 2011 and is another HP OEM drive.

This 500GB drive has the regular height and a design which is consistent with most Western Digital drives.

According to its SMART data, it is quite young at just 5829 hours and 721 cycles. Accordingly, its vital signs were all clear even after a full test.

The drive managed write speeds from 100.9MB/s down to 54.4MB/s averaging 83.9MB/s with a 7.54ms access time. Read speeds of 101MB/s down to 54.5MB/s, averaging 84.6MB/s with 15.5ms access time were recorded. Despite being twice as big as the drive above, the performance actually is poorer despite having the same spindle speed.

Hitachi HDP725025GLA380

The final drive is one that I haven’t commonly seen – Hitachi drives are pretty rare due to their lower market share but their reliability post-DeathStar era seems to have been pretty good. This one was pulled from a Dell server if I remember correctly – a HDP725025GLA380 dated June 2009 with firmware 5BA, made in China.

It features a standard SATA interface, but the drive itself is rather strange – the bottom half is “reduced height” and instead a bulging cover is used. This is something that I haven’t seen on other Hitachi products before – most of them have flat covers and a normal height cast base.

The PCB is rather small with the chips exposed at the bottom. It seems one chip does most of the work on this drive.

Against all expectations, this drive has 23340 hours under the clock, making it an “old” drive. It has 1240 cycles, which appears to be a bit high for a server, but nonetheless, the drive seems to have healthy vital signs even after testing.

Tested write speeds ranged from 125.5MB/s down to 59.4MB/s with an average of 100.3MB/s and an access time of 8.55ms. Read speeds ranged from 125.8MB/s down to 60.5MB/s with an average of 100.9MB/s and an access time of 19.7ms. Unlike older Hitachi drives that had adaptive zone bitrates – this one appears to have rather steady zone bitrates resulting in a flat stepped curve rather than the “yo-yo” curves of DeskStars and TravelStars of the past.


Given that all of these drives are from a business-like operational scenario, supplied by OEMs, it is a bit of a surprise that four of the five still seem to be healthy – passing a full overwrite and read-back without any reallocations. Even the one that did have reallocations did not grow any new bad sectors, so could be usable in case one was extremely desperate. I suppose there is a survivorship bias here – the truly dead drives would have been thrown out long ago. But now I’ve gained a few old drives – useful for an occasional “dump” of archival data or for experiments with older computers.

It’s rather interesting to see how the drive throughput has changed over the years – while it hasn’t kept pace with improvements in CPU/GPU processing speed, or even RAM bandwidth, it has shown some improvements linked with increase in aerial density.

Bonus: Surprise element14 T-Shirt

Instead of starting a new post here, I wrote about my surprise element14 T-Shirt I received this week on my blog at element14. But in case you were interested in how I look like with the shirt on … here’s the image:

Posted in Computing, Salvage | Tagged , , , | Leave a comment

Field-Day Mysteries: Hexin 2108E Serial Device Server, CPU86 ROMs & Conner CP-3040 SCSI HDD

My recent trip to the CCARC Field Day at Wyong resulted in the purchase of a stack of random bits and pieces. The fun is, as expected, sorting through the stuff in detail, learning about it in the process and getting it working in some way if possible. With the “as-is” nature of the items, it’s almost certain to encounter some strange behaviour … so what sort of mysteries await?

Hexin 2108E Serial Device Server

For better or for worse, my busy little fingers couldn’t resist picking up this Hexin 2108E serial device server. I actually find putting serial devices onto the network quite convenient and this unit was so clearly a rip-off of the Moxa NPort 5110 I looked at earlier, I wondered if it was even any good. The case, the colouration, the LED position … everything was familiar yet … somehow strange.

The server is practically self-contained – give it Ethernet, power and a serial device and off it goes. But what’s inside, I wondered?

Removing two screws, one on each side, allows the top cover to pop off.

It reveals a base PCB with a module sitting on top. The main IC in charge of the action is obscured by a holographic label.

Looking at the rear of the PCB, there seems to be a lot of dried flux residue and some unpopulated areas, which may be for a different (RS-422/488) version. The PCB is marked HX0704. The board itself already looks poor, as close examination shows an error in the PCB resulting in the green LED’s positive leg needing to be “poked through” the hole and soldered to an adjacent leg.

Looking briefly at the design, it seems that the power input is reverse-polarity protected through a diode, filtered through L1 and a few capacitors and then regulated through a switching converter consisting of U1 (an On Semiconductor MC34063). The module houses the main microcontroller, a 3.3V AMS1117 linear regulator, a 25MHz timing crystal for the Ethernet and a 22.1184MHz crystal for the microcontroller for exact baud rate division. There seems to be an external Toshiba TC55257DFTI-70V 32kiB SRAM, with an HC373 transparent D-Type latch for the interface. The module also contains the necessary Ethernet magnetics. The output of the module drives a MAX232 Serial Line Driver to obtain the necessary drive voltage, while being protected by four TVSS diodes on the rear.

The module itself has mcuweb.com written on it, but it seems they are defunct. Underneath the label, the chip is unmarked – it probably has all its markings ground away, but I suspect it’s probably nothing special – perhaps a low-powered ARM chip (e.g. the NXP LPC-series).

Configuring the unit is a load of fun – downloading the software from Hexin’s site provoked a number of warnings of potential malware – scans above using VirusTotal showed the configuration utility was detected by a lot of engines but these were generic heuristic detections (likely false alarms) due to commonalities between the configuration software and trojans (e.g. use of packers, network access requests).

It seems the unit had been configured away from its original defaults – set to with a baud rate of 9600 and non-standard ports. Already, we can see just how restrictive this clone is – it doesn’t have functional DHCP, nor a web interface for configuration.

In fact, in the four screenshots from Wireshark above, we can see configuration is based on a broadcast mechanism with everything in plain-text. There is no password against reconfiguration at all. While the unit claims to have VCOM mode capabilities, no VCOM drivers are supplied either and documentation is sparse. While it may look vaguely like the Moxa, its capabilities are pale by comparison.

I quickly tried to reconfigure it to what I needed – an address I could rely on, a port number I could remember and a baud rate from “this side of the 20th century”. But then I ran into a snag – I was only getting garbage from the unit. Setting it back to 9600bps, it seemed to work but not particularly reliably. Something is going on … time to crack out the oscilloscope.

We have a problem … look at that! At 9600bps with random data fired into the converter, it shows a voltage level that swings between about -0.2V and up to roughly 8V. There is also quite a long rise to the waveform too. That’s not what serial is supposed to look like – no wonder it’s tripping up devices. At 115200bps, it was practically unrecognisable as being UART. Note that above, I got the polarity of the UART decoder configuration wrong – so ignore the decoded data trace below.

Putting my thinking cap on, it looked suspiciously as if the negative part of the waveform was clamped and the positive was facing some gross capacitance-style loading. I suspected either a fault with the TVSS diodes, a bad MAX232 or bad capacitors. I probed the TVSS diodes and found one was basically shorted through. Getting out the hot air gun and removing that one diode didn’t fix it either.

I then suspected that perhaps all the TVSS diodes are bad even though they didn’t measure bad on a handheld DMM. Perhaps at higher voltage, they exhibit other behaviour or capacitance. I got out the hot air gun again and removed all the TVSS diodes.

While they are nice to have to protect the unit from ESD or induced voltages from distant lightning, their omission for indoor “at home” use is probably not a big problem in itself.

But now, the unit works as expected – the above is 115200bps showing a good swing from -9V to +9V and a very square waveform as it should be. No problems with the decode either, especially now that the decoder polarity is set correctly.

This still doesn’t solve the strange oddity that the unit has – it seems to echo everything that is sent to it back to the sender … and only sends things after a certain number of characters are received or a CR/LF is received. Without the configurability to tweak this, it can only be used for certain applications where these issues can be worked around.

Perhaps the $10 I paid for it was too much … given its capabilities and its condition. At least it’s no longer complete junk … although it is still pretty trashy.


Going along the car boot sales, I spotted some expansion cards I wanted to buy. The seller decided to take some money in exchange for me hauling off the whole box (including some cards I had no idea about), so I eventually agreed and ended up with these curiosities.

The first card of the pair looked very much like a memory card of sorts. The first four chips are NEC SRAM modules, but the next four are EPROMs – two National Semiconductor chips, a Toshiba and a Texas Instruments. A bit unusual to see mismatched EPROM vendors, but the stickers suggest that the EPROMs were used in pairs with MSB on one and LSB on the other – EXT0 and EXT1 suggest these may contain some sort of extension code for the system.

The rear of the board contains some traces, as expected. The board itself appears to be Eurocard sized, which was a fairly popular way to build industrial modular computers in the old days.

Looking at the connector, it seems to have the standardised connector as well – so I suspected it might be something like STEbus, VMEbus or similar. Unfortunately tracing the pin-outs for power already suggest that the wiring is not either one of the buses I had guessed …

It’s interesing to see that the board has jumper headers and instead of using “shunts” as we normally do, these boards have them wire-wrapped for additional rigidity.

Looking for more clues, we turn our attention to the second board which appears to be the heart of the system. This one comes complete with the front cover plate as well. The board has two mismatched EPROMs as well, an NEC and a National Semiconductor one, with the same high/low byte arrangement. It seems to say CPU V31. The pencilled “SN60” might indicate it’s part of a batch of ROMs. The board is indeed a CPU card, marked CPU-86-1 from Elcodata. Looking up Elcodata leads me to some information that seems to place them as a subsidiary of Elcom, and possibly identifying the bus as “AMS Bus”. The board has a serial number of 108021 and features an NEC V30 CPU, which is a clone of the Intel 8088. Judging from the crystal oscillator next to it, it could well be operating at 9.8304MHz but this is definitely a useful rate for division to common UART clocks.

The rear of the board has a lot of thin traces with “squiggly” routing. Some of the traces near the top have been damaged in transport, unfortunately.

The edge has the same standard type of connector, being from the same haul of stuff and having the same handwriting on the labels over the EPROMs, I’m fairly confident they are used together.

There is another crystal oscillator can near the side which is 16MHz, but this seems perhaps a little high for the V30.

The front plate has a button (presumably to reset the CPU) and nothing else. The card “handle” has CPU86-1 marked on it, being such a generic term, it doesn’t turn up much in the way of information.

The only way to cure the curiosity would be to dump the ROMs and examine their contents after reassembling the pairs of images together.

The beginning of the ROM gives us a hint – “MSP 65-EXT-ROM”. Any ideas yet?

Further along, the string “mspcpu” comes up, along with a list of error-descriptor strings. Seems like some compiled program is probably running on the device.

Looking at another ROM, again, “MSP 65-EXT-ROM” is seen, but now the words “Operating Panel” appear with a list of parameters including MEAS, OBS1, OBS2, DARK, OBJEC, REFL, AUX, AF, S1-S8, DISP, ADJU, FUNC, PARM. Based on this, it’s probably from some type of measurement device.

More standard error descriptor strings appear …

This is rather interesting – ROM copyright date of 1989 to CZO. There are a few interesting initialisation message strings, but the clue seems to be Autofocus control – something to do with a camera, but also the words Axiotron Interface.

The nut has been cracked – I suspect CZO stands for Carl-Zeiss Optics and the cards come from an MSP 65 Microscope Stage Platform Controller (one reference in a journal paper). The relevance of Axiotron is that it may have been used with Axiotron microscopes (perhaps even this one). Given that we now know what it is, we should probably still look at some of the other strings …

Judging from the above, it seems the MSP 65 may have also co-ordinated a camera along with some filters.

These error messages seem to be specific for the program.

There are a few more parameters as well. I’m still not sure exactly what the program actually does, but before looking at the ROM, I would have never imagined the cards would have come from some computerised optical equipment!

Conner CP-3040 SCSI Hard Drive

One of the rather interesting finds digging through a box at Salbay Engineering’s stand was a Conner Peripherals CP-3040 SCSI hard drive. While I do have fond memory of Conner drives in Compaq computers being reliable enough and not particularly stellar performers, to encounter one in the wild in 2019 was somewhat unexpected given that they ceased to exist in 1996 having been bought out by Seagate.

This is the drive itself from the top. A nice and clean black top, adorned with two labels. It appears to have been Assembled in Singapore perhaps in Week 28 of 1991, making the drive 28 years old.

Looking from the underside, we can see a very crowded circuit board with relatively “thick” surface mount chips. A Signetics 27C256-15A EPROM holds the firmware, copyright 1990, version SA2.47. The SCSI interface appears to be handled by the Adaptec AIC-610L, with the remainder of the drive’s functionality spread across a number of chips from Motorola, an Asic from Conner, a Plessey ULA and a mixture of other chips. It seems that the head interface involves a number of optoisolators as well. The SCSI interface had a decent amount of bent pins, but to my surprise, the termination resistor packs remain fitted which is good.

From the rear, power is supplied via a standard Molex power connector.

Looking from the sides, I was surprised to see that the top and bottom case halves meet at an angle rather than straight. I suspect other Conner models may have changed this to reduce manufacturing costs.

There are a few jumpers and connectors at the front as well.

So far, there hasn’t been any hint as to what this drive may have been used with, however, a quick search of the model seems to suggest it may have come out of an Apple Macintosh Portable or 40SC External Hard Drive or similar. Most IBM-PCs of the era used either ST-506 interface or IDE.

Powering up, the drive does spin up with a rather noisy whine. It’s even detected with its ID (probably from the EPROM). But when it comes to reading, it returns no mode-pages, no geometry and no data.

So in the end, unfortunately the Conner CP-3040 hard drive was a disappointment. While it did manage to spin-up and get detected on the SCSI bus correctly, it could not respond to mode-page queries and had no geometry at all. As a result, no data recovery seemed possible. Perhaps the low-level formatting had been lost due to demagnetisation, head damage or bearings being too loose causing run-out error. At least it still works fine as a SCSI bus terminator … so I’m not going to take it apart or throw it out just yet.


The stuff you get from a swap meet like the Wyong field-day is very much a mixed bag. Vintage stuff especially can have rather interesting stories to tell, if you delve into it deeply. But half-working and broken things are an invitation to learn, diagnose, troubleshoot and repair, which in itself, could be a rather educational endeavour.

Posted in Computing, Electronics, Salvage | Tagged , , , , , , , , , , | Leave a comment

Project: “Generic” ZM-4 AT89C2051 4-Digit 7-Segment LED Clock Kit

Feeling a little bored and deflated one evening, I decided to open up my drawer of stuff to grab a kit out of there to cheer me up. After all, kit builds have always been rather therapeutic for me – it’s basically like arts and crafts but for an electronics-minded person.

The kit I grabbed as a “generic” LED clock comprising of a 4-digit 7-segment display, controlled by an Atmel AT89C2051 MCS-51 microcontroller. The kit cost just AU$2.30 including postage when I bought it a year ago, so lets see what’s inside, what it’s like to build and how it works.

The Package

Not unexpectedly, it’s in a plastic zip-lock bag with no regards to electrostatic discharge precautions. But most of the time it doesn’t cause any issues …

Unlike other Chinese kits devoid of any information, this one comes with a thermally-printed label that has a basic schematic of the connections and a bill-of-materials. The listed company is SinaSong (HK) Trading Co. Limited, but the domain seems to have no operating website anymore.

Aside from that, there is the bag of components, a PCB and a four-digit seven-segment LED display module.

The PCB is a fairly decent quality fibreglass single-sided PCB with green soldermask and white silkscreening on both sides. The board itself is single-sided when it comes to traces.

Looking at the underside, we see that there is a logo for You Sheng Guang Cai and a marking of ZM-4 860925. Looking around, it seems that this kit has been copied and is available under fairly similar names from other companies.

Judging from the schematic and the pattern, this circuit is almost laughably simple as most of the work is done internally by the Atmel 89C2051 MCS-51 microcontroller clocked at 12MHz. The design is also a bit “naughty” with no reverse polarity protection at all (so make sure you connect power in the correct orientation). The design of the PCB is a little difficult due to the small size of the donut pads, slight intrusion of soldermask and lack of thermal-isolation meaning soldering is probably best done with a fine tip, fine solder wire and steady hand.

The LED module is packed on some foam to protect the pins, however, the other parts do not enjoy such a luxury.

The remaining parts include key-caps for the switches, an IC socket (both luxury items), the pre-programmed Atmel microcontroller, a resistor-pack, loose resistors/capacitors, a transistor, a buzzer-speaker and a crystal.

Unfortunately, it seems that the lock bits on the microcontroller have been set, so there is no possibility to dump the data within.


The first thing to think about is just how many joints are involved in assembling the kit –

LED Module - 12
Resistor Pack - 9
Microcontroller - 20
2x Switches - 8
2x Resistors - 4
4x Capacitors - 8
Transistor - 3
Buzzer - 2
Terminal Block - 2
TOTAL - 68

Construction was pretty much straightforward, with all components being of the through-hole variety. There wasn’t really much in the way stopping you from assembling it in any order.

The above shows the constructed kit after the IC and key-caps had been fitted and the protective films on both screen and buzzer removed. The one downside that is immediately apparent is that the input power terminals are not clearly labelled as to polarity – without any reverse polarity protection on the board, this could result in catastrophe. In my version, left terminal is negative, the right terminal (closest to the board corner) is positive.

The lack of thermal-isolation on the pads and relatively small size of the donut pads as mentioned before add to the difficulty of getting nice solder joints. That being said, with a bit of patience, this is easily overcome.


Getting set-up is probably the most cryptic, as once power is applied to the clock, it starts at 12:59 and pressing either button results in a loud and shrill beep. In fact, setting the clock actually needs a manual of its own – so lets refer to the left button as A and the right button as B.

To enter setting mode, from the clock display hold down button A and you will see a letter on the left and the value on the right. Pressing A will advance through the option left, pressing B will advance through the values.

Menu Option - Range - Description
A             00-23   Clock Hours
B             00-59   Clock Minutes
C             ON/OFF  Hourly Beeps
D             ON/OFF  Alarm 1 Active
E             00-23   Alarm 1 Hours
F             00-59   Alarm 1 Minutes
G             ON/OFF  Alarm 2 Active
H             00-23   Alarm 2 Hours
I             00-59   Alarm 2 Minutes

Pressing button B will toggle the display from HH:MM to MM:SS. Pressing and holding button B allows you to reset the seconds to zero for time synchronisation.

I decided I didn’t like the buzzer or alarms, so I cut the trace leading to the base of the transistor to disable the buzzer. It was easier than desoldering the buzzer and I could “repair” the trace later if I wanted to restore the functionality. There seems to be no way to change the clock display from 24-hour time to 12-hour time that I could see, but that’s fine for me as I’m using it as a UTC time display for now. The clock accuracy depends on the 12MHz crystal – for mine, it appears to gain around five seconds per day which is not that ideal. That’s an error of about 58 parts per million (ppm) which is not unusual – such regular CPU crystals often have an error of 30ppm tolerance with +/- 50ppm stability.

The unit seems to run fine throughout the range of voltage allowed by the microcontroller – at 2.7V, it consumes around 17mA; at 3.6V, 26mA; at 5V, 41mA; at 6V, 52mA. With such an appetite for power, it wouldn’t run for too long on batteries – losing power means re-setting the clock from scratch.


The “Generic” ZM-4 AT89C2051 4-Digit 7-Segment LED Clock Kit is a fairly basic kit which has limited educational potential because almost all its operation is hidden within the pre-programmed MCS-51 microcontroller. That being said, the kit itself was surprisingly good for the price, coming with a schematic on a thermal-print label, a PCB that had silkscreen and solder-resist and parts that included an IC-socket and keycaps.

The construction was slightly frustrating due to the small size of the pads, but with a fine tipped iron, some fine tipped solder and some patience, it is not too difficult to finish. In the end, a basic 24-hour only LED clock with an annoyingly-loud buzzer and two alarms is the result.

Even though it is not exactly practical due to a lack of time back-up and moderately hungry power consumption, it’s no worse than old fashioned mains clocks. I suppose, for AU$2.30 including postage, it’s not even costly given that the cheapest analog clock from IKEA retails for AU$2.49.

Posted in Electronics | Tagged , , , , | 2 Comments