Monday, January 29, 2018

Producing replacement battery pack for original model Roomba vacuum

BUILDING REPLACEMENT ROOMBA BATTERY

The battery pack for the original model Roomba vacuum is not holding a charge as well as it did when new. The pack is a specially shaped module holding 12 NiMH cells, each producing 1.2V with a capacity of roughly 3000 mAH.

They are chained together to yield 14.2V for the pack, but with no circuitry to distribute load or even out charging, which is why they degrade over time as do most simple-minded serial chains of battery cells. All but one of the serial connections are tack welded metal bridges, the remaining one is a carefully created fusible link tack welded across one pair. This provides overcurrent protection for the pack.

One final aspect of the pack is the inclusion of a varistor, a resistor whose value varies with temperature. This thermistor is wedged in the gap between four adjacent cells. It is used by the charging circuitry to lower the incoming voltage or cut it off if the cells are getting too hot. The pack as a +, a - and a thermistor contact.

Opened battery pack, white fusible link on left, thermistor next to it
My plan was to replace the 12 cells with similar or higher capacity NiMH cells, soldering the metal bridges and one fusible link between cells to place them in series. These new cells had to fit within the original plastic package, in order for the repaired battery pack to fit back in the Roomba.

I found some high capacity battery packs intended for use in remote control cars and other toys. These packs produce 7.2V at 3500 mAH capacity by bridging six cells together. These RC packs are plastic wrapped, with the series connection made inside, and two wires coming out at one end.

RC pack with six 1.2V cells inside
I had hoped to place two of these packs in the original battery package, tie one pack to the other with the fusible link, wedge in the thermistor and close it up so that it now chained 12 cells to produce 14.4V. I found that the RC packs were just a bit too large, particularly the end caps which were wider than the two columns of cells.

RC pack almost fits inside
End cap which is too wide to fit RC packs side by side inside the Roomba package
I considered various means of grinding down the inside of the Roomba package and the end caps of the battery packs, to force them inside together. Even the unwrapped cells themselves are too wide to fit side by side lengthwise. While grinding may work, the most certain method is to fully disassemble the RC packs and find myself with 12 NiMH cells of exactly the right type.

RC pack without endcaps still wider than half the package width
I can solder wires and the fusible link across the terminals to chain them in series. More work but it will fit better and more closely match the original battery construction. I began to work on the end caps of one pack to determine whether that partial method is at all feasible, since it avoids much of the soldering necessary with the full disassembly route.

RC pack with plastic removed, cell to cell connection exposed on right
I found that the cells are tack welded with strips of metal, just as with the original Roomba construction, but the strips of metal are not long enough to fold the cells in alternating directions as is required to have them sit vertically in the Roomba package.

Existing metal plates bridging cells in the RC pack
I had to break off all the metal links from the positive pole of the cells, to separate them and to test their fit inside the Roomba package. I found that they will indeed fit exactly as they should inside when the cells are each stacked vertically. Of course, they must alternate up and down pointing cells and the connections run down one column, cross over at the end and run back on the other column to end up with the correct series polarity.

Test fit of the cells sitting vertically, but not in the alternating direction ultimately needed

I then removed the other end of the metal plates from the negative can of the cells and removed the red and white wires, leaving me 12 unattached cells to begin soldering together. I will have to find and cut some flat metal strips, as the proper diameter wires would take up too much vertical space around the cells. I to source the strips and cut them to length before I can continue with this project.

Sunday, January 28, 2018

HP 2621A terminal successfully connected to Altair 8800 replica (AltairArduino)

BUILDING LINK BETWEEN ALTAIR 8800 REPLICA AND HP 2621A TERMINAL

I switched over to my Bluetooth to serial module, since I was having no luck communicating with the USB to serial module from last week. This module, by Parallax, claims that I can talk to it over the serial link, typing $$$ during its first few seconds to switch it to configuration mode, where I will get a CMD prompt.

With the connection set up from my RS232 12V/TTL shifter module to the Bluetooth module, I can type $$$ and see it echoed back but never get the CMD prompt. Incomplete and vague manuals again. This is the trade-off for inexpensive modules where no budget is available for tech writers or usability engineering studies.

I kept bashing away at it, studying the materials from the maker of the board as I attempted to get it to configure. Even when I can talk to it for configuration through the serial end, I have the much more difficult problem of causing the bluetooth in this unit to communicate correctly with the bluetooth module inside the Altair 8800 replica.

At this point, I would be ready to rip out the bluetooth inside the Altair replica and wire RS232 directly from it to my level shifter board. I was not sure if there is any dialog required between the bluetooth module and the Arduino inside the replica, but I my investigation showed that my serial level shifter card could be easily connected in place of the bluetooth module inside the replica.

I tried one more thing before taking the radical step of removing the radio. I removed a jumper on my new bluetooth module, and got it to answer back properly to my $$$ prompt. It was forced to 9600 but I connected, per the instruction guide, at 115200. It echoed my characters but didn't recognize them internally.

Now I had the task of configuring it properly to connect to the other bluetooth module inside the Altair replica. I took a bit of time to do some serious research and plan out the configuration.

I looked up the bluetooth ID of the internal radio in the replica and set up the new external module to attempt to contact it by that address and with the passcode it wants. I was not sure whether it would pair properly, it was possible I needed to be connected to both sides simultaneously.

The new module, in its auto-master mode, immediately connects to the bluetooth module inside the Altair replica. I was able to switch the replica console over to the serial port (i.e. through the pair of bluetooth modules and then into the PC serial port) using the AltairDuino configuration menu. At this point, all I need to accomplish is the wiring of the serial port itself to the Centronics 50 connector for attachment to the HP terminal.

This was built into a small hobby box - bluetooth module, RS232 level shifter and a connection to a leftover wall wart power supply for the 5V to the modules. The cable was completed, including the essential wire between Centronics pins 14 and 45 that brings +5V to tell the terminal that it has a live link.
Building magic box to link Bluetooth to HP 2621A terminal
I brought everything out to the workshop to do a first test, after a final peek at the HP manuals to be assured they were true RS232 signal levels and not TTL limited. I turned on the terminal, powered up the Altair replica and my magic box.

Altair 8800 replica with power supply
Magic box with Centronics 50 connector on left, power supply on right
It worked right away. I used the laptop over the internal USB link to the replica to start configuration, switch the serial port over to the bluetooth module inside, which was live linked through my magic box to the HP 2621A terminal. I saved the config change and tried a few cycles of plugging in and powering up everything.

It all worked well, so I fired up Zork 1 to test out the terminal running this classic game. Worked great and satisfies my objectives. I can now work with a 1970s terminal to speak to the 1970s era Altair 8800 (replica). I swapped virtual floppy drives to restore a saved game and played for a few minutes.

Altair replica running CPM with Zork 1

HP terminal with the CPM session and Zork 1 running

Saturday, January 27, 2018

Processed more PARC cartridges, validated latest ethernet tool, and worked on Altair replica to HP terminal link

CONNECTING ALTAIR 8800 REPLICA TO HP 2621A TERMINAL

Before I can hook my USB to CDC mode TTL serial to the TTL to RS232 level serial converter and ultimately to the 2621A terminal, I have to talk to the USB device and update its communications settings. That conversation only happens over the wire TTL serial side, with the USB cable disconnected.

I have a DB9 serial connector on one of my computers, which I will use to configure the USB to serial module. I found an old DB9 based serial cable, cut it apart and wired it up to the module, crossing TX and RX. I hooked CTS and RTS together to keep the PC side happy. 

With 5V power applied to the module, I fired up a simple terminal program on the PC and did the configuration. I had to set the BAUD rate to 9600 and the transfer to byte by byte mode, without local echo.  However, when I hooked it up to the PC serial port and tried to communicate, I got nothing. That was true whether RX/TX were swapped or straight. 

I haven't used the PC port before, so there is a possibility that the hardware doesn't work right. I needed to figure out where the problem lies. It is possible it is that I don't have the magic combination set right, among all the darned DCD, DSR, CTS, and RTS signals, thus the port is blocked. 

The quick test was to hook the RX and TX lines from the PC cable together. Immediately, I saw my typed characters echoing back on the terminal program. This proves that the serial port is working, thus I have to focus in on the USB to serial module as the fault or something in my setup. 

Once I have a working link to the Altair replica, either this USB module or a Bluetooth to serial module,  I can wire it to the TTL/12V level shifter board. I looped CTS and RTS to the 12V side of the level shifter, which will in turn be wired to the Centronics 50 connector that will plug into the HP terminal. 

We were in Fry's today to pick up more 99.9% pure Isopropyl Alcohol before cleaning disk cartridges. I took the opportunity to grab a Bluetooth to Serial module as a backup means of linking my Altair to the HP terminal. 

ARCHIVING MORE XEROX PARC CARTRIDGES

Friday morning I aligned the drives with the recently cleaned heads, brought all forty cartridges down to the lab area and began archiving. We had run out of isopropyl alcohol to clean the surface of each disk and the heads, requiring a run to buy more supplies before continuing after lunch.

By the end of the day, we had processed fifteen cartridges, extracting each image and testing it under Contralto. We only had to wipe some fine oxide residue from the heads two times. The result was 13 good disk images.

The reason it wasn't fifteen was twofold. First, we found that one of the 15 cartridges had been previously archived by us, but our little stick on label (A) had fallen off at PARC. Second, we found another of the cartridges had two dings on the surface of the platter - small impact holes that exposed the aluminum underneath the oxide coating.

Those holes would likely cause a head crash, thus the disk was appropriate marked and skipped. These 13 recovered images were delivered to the software preservation archivists at Computer History Museum.

VERIFYING THE VERSION 3 BOARD FOR KEN'S ETHERNET TOOL

Ken put his latest rev of the board through a test program, proving out its full and correct operation. This board included all the pullup resistor and ringing suppression components he had added externally to prior boards.

One snag hit, however. The microSD card with the code for the device had fallen out back at his home, requiring Ken to rebuild the development environment on his laptop and then recompile the code for transfer to a new card. That took the remainder of the morning, before he could conduct the tests above.

Wednesday, January 24, 2018

IBM 1401 reader-print problem fixed; last batch of disc cartridges from Xerox PARC picked up for archiving

WORK ON READ-PRINT ISSUE OF IBM 1401 AT CHM

Today we met at Computer History Museum to work further on the sporadic failure of the 'German' IBM 1401 system, where its 1402 reader will suffer Reader Stop errors while processing certain sequences of read card-print line commands.

The failures occur while the command to read a card is slightly delayed by the 1403 printer logic copying the print line out of core memory. That 2ms delay of the request is enough to cause the reader to accept the feed request, but the clutch itself does not engage. Error checking circuitry detects this fault and halts the reader.

We suspected that timing of some switches activated by cams was the cause of the problem. Last week we adjusted the primary cam that determines when the feed request from the CPU will attempt to latch the clutch and rotate the card feed mechanism. This is RC6 - continuously running cams are named RC and hooked to the motor so they rotate any time the motor spins.

The cams have tight tolerances - the times listed for the switch to make and break must be achieved withing +0 to -2 degrees, ergo the cam makes at 270-272 and breaks at 340-342 degrees. I had that set to 270 and 340 last week, but we found that another cam in series with RC6 was blocking the operation.

Cam RL10 should make at 270 and break at 340, with the same margins, but this was off by at least 5 degrees. RL named cams turn only with the card feed mechanism - once to move cards one station forward.

The path is hopper to read check to read station to stacker, one feed cycle per move. Usually, a different card is at each stage of the path - card 1 is moved to the stacker while 2 is moved to the read station, 3 is moved to the read check station and 4 is next sitting in the hopper.

To get to the RL cams, quite a bit of the top and side cover of the 1402 must be removed, but once we had access, I tested the cam. We found two problems - the duration and the start point.

The number of degrees from make to break should be 70. If the switch is too far from the cam, the duration is shorter than 70, while a switch that is too close to the cam will produce a longer duration. A setscrew, held in place by a jam-nut, determines how far away from the cam that the switch can move. We loosened screws, changed the setscrew and ended up with precisely 70 degrees of contact but the start point was more than 5 degrees to late.

The start point is controlled by the rotational position of the cam around the shaft that spins all the RL cams. Two setscrews hold the cam in place, or when loosened allow it to be spun forward or backward. We moved the cam until we had it making exactly at 270 and, thanks to the duration we adjusted earlier, it broke at exactly 340.

With the setting corrected, we closed up the reader and ran our test programs again. We had a trusty hand program which executed read-print-read-print-read-print-read-halt and then branched back to the beginning. The last read in the sequence would suffer a Reader Stop most times, because the clutch failed to engage during that cycle. 

This program ran a dozen times with error. We replaced the halt instruction with a branch to produce a continuously running loop reading and printing. No failure in many hundreds of cards. We then ran an "80-80" listing program which looped, reading a card and printing its contents on the 1403, again running as many times as we tried it with no errors.

We can declare this problem fixed. At some point, it would be nice to adjust all the other RC and RL cams, making everything conform to the specs, but right now we have no symptoms and could turn the system over to the demonstration team for regular use.

SWAPPING TO LAST BATCH OF XEROX PARC DISC CARTRIDGES

We brought the group of 25 cartridges we recently archived over to PARC and were given all the packs they could locate. We had 36 numbered cartridges, tied to their inventory of disks, plus 3 packs that were labeled but not numbered nor listed on their inventory. Finally, on our way out with the boxes, we were handed a cartridge that was on display behind the Alto in their lobby.

Starting Friday we will work our way through the discs until we have them all processed. The inventory of PARC disks lists 11 more cartridges that they can't locate now, mostly belonging to Alan Kay. If they do find them, then we would have one more batch to process in the future. 

Building connection from Altair replica to HP 2621A terminal, rebuilding original Roomba battery pack

ROOMBA REPAIR

The Original Roomba vacuum cleaner that I repaired recently is working well at my daughter's apartment, but the battery pack inside is a bit old and doesn't give a full 2.5 hours of operation on a charge. 

I bought a used battery on eBay, took it apart, and prepared to replace the bad cells with new ones. Roomba uses 12 1.2V NiMH cells inside the yellow plastic battery enclosure, chained end to end. Once a single cell goes bad the entire pack is bad and they have no charge leveling circuitry inside.


12 cells chained together inside Roomba battery case
There are two additional features inside the pack - a fusible link and a thermistor - that provide protection from short circuits and overheating cells. I will install these on the replacement cells.

Rather than buying 12 sub-C sized cells and soldering all the straps to chain them in series, I bought two 7.2V battery packs designed for remote control cars. These have 6 1.2V NiMH calls in them, provide 3800 mAH compared to the original 3500 spec, and two of these will fit inside the yellow Roomba battery case. 
RC battery packs to replace the original cells
Once they come, I will use the fusible link to connect the two packs together, install the thermistor against one of the cells and close up the pack. 

USB SERIAL TO REAL RS232 CONNECTION TO TIE REPLICA ALTAIR 8800 TO HP 2621A

My parts arrived and now I can begin wiring together everything I need to hook my Altair 8080 replica to a true serial based CRT terminal. The chain connects the Native USB port of the Arduino Due inside the replica to a level shifting board that produces 12V RS232 levels, then hooks this onto the HP terminal using a Centronics 50 connector. 


I removed the DB9 connector on the level shifter board and direct wired it to the Centronics connector. The level shifter has to be wired to loopback CTS and RTS on the RS232 level side, since the USB to TTL device produces only RX and TX, it does not handle RTS and CTS.

My cabling will force DTR active, telling the terminal it is connected and cause the terminal to issue CTS to the far side. This may take a bit of fiddling with the control signals on the terminal to get it talking but eventually it will work.

There are commands I can issue to the USB converter board to set its speed, parity and other parameters, which it will store and retain in its onboard EEPROM. I should probably set the converter to the same speed as the terminal will operate, since there are no pacing signals such as CTS to avoid overruns.

Both of my boards need a source of 5V DC for power, which I can either draw off the replica or furnish with a separate supply. The decision is not yet made. I do want to put all this in a convenient box for neatness and to protect the small boards. 

Tuesday, January 23, 2018

Finished batch of PARC disks, got stand for my HP 2621A terminal

HP 1000 SYSTEM RESTORATION

Stand for 2621A (ET) Terminal

A friend found a base for my ET terminal and gave it to me, along with some cables, a keyboard and boards for the HP 1000 system. All I needed was the terminal and keyboard, the rest went to Marc to support his big HP collection.

FINISHED BATCH OF 25 CARTRIDGES FROM PARC

We finished up the remaining cartridges from the group of disk cartridges we borrowed from Xerox PARC, producing archive images of most of them. A few were already scratched, with two having serious bends to the edge of the platter, but most were read okay.

These old disks have surfaces that are deteriorating - specifically the binder that holds the iron oxide to the aluminum platter is allowing some release of surface powder. These build up on our disk heads and either cause a crash immediately, if sizable, or require us to remove, clean, remount and realign the heads. 

These will be returned to PARC and a new group of 25 cartridges will come over to the lab for archiving in the coming weeks. Eventually everything will be saved from these packs and they can be delivered to the Computer History Museum physical archives. 

Thursday, January 18, 2018

More work on 1401 system read-print issue at Computer History Museum

REPAIRING READ-PRINT ISSUE WITH IBM 1401 DE SYSTEM AT CHM

The focus on Wednesday was on the timing of various cam based switches that form the logic inside the 1402 card reader/punch. We looked in particular at everything involved in clutching the mechanism to turn the rollers and other gear that moves a card forward one station.

Several cam based switches, called circuit breakers (CBs) by IBM, are involved in this process, particularly RC5, RC6, RC7 and RL10. RC numbered CBs are those that run continuously with the main motor, even when the mechanism is not moving a card through the machine. RL numbered CBs will operate only with the mechanism that performs the card feed.

These CBs in turn control several relays, such as the clutch check relay 10, and lead to the activation of the reader stop relay 4. The wiring diagram is somewhere between obscure and impenetrable, as I have mentioned before, but we gradually mastered the portions involved in this problem we are debugging.

The 1402 originally operated by feeding cards in one rotation of the mechanism, always taking 360 degrees of rotation or about 18ms at the rated speed of the reader mechanism. This meant that when a processor request came in to read another card, one could wait between 0 and 18ms before it commenced, depending on where the spinning mechanisms were in their 360 degree rotation.

To increase effective speed, IBM created an early feed feature, dividing each rotation into three equal 120 degree segments. Now, when a CPU request arrives, the wait to honor it varies from 0 to 6ms, only until the next 120 degree segment comes around.

Now, most of the CBs have three lobes, to provide the same logic for each of the three 120 degree segments. The first one we adjusted, RC6, is the primary CB that determines when a CPU request will activate the clutch. One of its three lobes is designed to close the switch (make) at 272 degrees and open (break) at 342 degrees, with a tight tolerance that requires it occur between -2 and 0 degrees of the target value.

The CBs are adjusted two ways. First, the cam itself can be rotated around the axle that turns it, to changes its timing earlier or later in a rotation. Second, the contacts can be raised or lowered from the center of rotation, causing the duration of the activated switch to lengthen or shorten. Adjustment requires that both be controlled to get the make and break timings correct.

Advancing or retarding the cam around its axle is done by loosening two setscrews that hold it to the axle. These require Bristol wrenches, similar to Allen wrenches but having four lobes rather than the hexagonal shape of Allen. We loosened the setscrews but the cam would not move relative to its peers at RC5 and RC7.

We hooked an ohmmeter across the contacts to do the timing, hand rotating the overall mechanism with the timing wheel which is marked with 360 degree lines. First, however, the cam had to revolve on the axle to move its start and stop timing.

It appears that the cam was partly adhered to its peers by corrosion, so that some mechanical force was needed to free it up. The access to the cams is quite restricted, otherwise we could have simply used pliers of some sort to turn it. Finally, I could apply sharp impacts sufficient to break the corrosion but not the mechanisms.

The second adjustment, duration of the switch, is controlled by a screw, a setscrew and a jam hexnut. The jam nut holds the setscrew in its position, while the setscrews is a stop for how high the switch contacts can move. Finally, the screw itself locked the contacts down or allowed them to slide up and down.

I finally got the height of the contacts correct for exactly 70 degrees of make time, then rotated the cam to cause the make to happen right at 270 degrees. It ended precisely on time at 340 degrees, so we were done with this adjustment. The ohmmeter showed the make and break as we slowly rotated the timing wheel.

However, when we turned on the dynamic timer with the reader operating under power, it showed that circuit energizing at 275 degrees but ending on time at 340,. Looking at the schematic and then scoping the circuit, we found that CB RL10 is misadjusted. It is in series with RC6 and since it doesn't make until 275, that delays the activation.

The RL CBs are mounted in a much more inconvenient location in the machine, requiring the removal of part of the top cover near the card hopper before we could reach and adjust them. We didn't have enough time left in the day to do this before the public demonstration started, thus we left it to the next session.

The reason that RC6 and RL10 are in series is that permission to fire the clutch depends on two things. The position of the motor assembly must be in the right 70 degree portion of its 120 degree segment, but also the feed mechanism must not already be in motion from a prior clutching.

Thus, RL10 sits activated when the feed mechanism is idle, allowing RC6 to determine when to start a card read. However, once the feed mechanism is moving, RL10 blocks clutching until the feed is advanced enough. That is, reading a card takes the entire 360 degree rotation to move it forward and past the 12 rows of holes, even though we can start this process at any one of the three 120 degree segments.

Therefore, RL10 imposes the 360 degree cycle restriction after which RC6 determines the next 120 degree segment to permit clutch activation. In addition to this complexity, CBs RC5 and RC7 control the timing of the clutch checking that ensures a clutched feed mechanism actually moved.

When RC6 lets the CPU request activate the clutch, it first energizes clutch check relay 10 then with a slight time delay activates the clutch itself.  RC7 is a set of lobes which control when the error check takes place. This CB makes and breaks opposite to RC6, activating during the span when RC6 is open. These two cannot overlap activation and there is a required gap between the two sufficient to let the clutch engage and begin moving the feed mechanism.

RC5 is another trilobe cam, with the same timing as RC6, but used to activate other relays that ultimately lead to the checking that triggers our reader stop condition. We need to get the timing of RC5, RC7 and RL10 corrected before we can be sure that our reader is working according to its design.