Finished building PiDP-10 kit; fixing one switch mounting and replacing one failed LED as my last actions

SOLDERED 74 SWITCHES ONTO THE PCB AND TESTED THEM FOR CORRECT OPERATION

This took some time as I had to first organize the switches into five groups and then for each switch position make sure I installed from the proper group. They are dark blue, light blue and light green on/on toggle switches plus light blue and light green momentary on toggle switches. 

One of the mounting tabs is soldered first to hold all the switches loosely on the PCB. Then each tab is heated and the switch manually pressed down and arranged to form clean lines with symmetry. Once they are positioned, then the center and normally open contacts are soldered to the board; finally, the bottom mounting tab is soldered to give the switch extra mechanical support.

The test software shows which switches are activated, allowing me to check that every one worked properly. 

ASSEMBLED ENTIRE KIT AND FIRED UP THE DEC SOFTWARE

I stacked the acrylic panel in front of the LED board and attached that to the front bezel. The switch PCB was attached to the bottom support and that was then attached to the bezel to form the front of the PiDP-10. After connecting the ribbon cable, the two boards were ready to work again.

I mounted the Raspberry Pi 5 after putting its active cooler on it. This mounts on the back of the LED PCB. A plate covers the back of the RPi. The rear cover fits into place and completes the kit assembly. 

I hooked this up to the monitor, keyboard and mouse, then powered up. The machine booted into its PDP-10 software environment and I tried out a few minor things. 

DISCOVERED ONE LED THAT IS NOT LIGHTING AND ONE SWITCH SITS TOO HIGH

I spotted one of the LEDs that was not lighting. The solder joints are good, thus I believe this was a bad LED. The kit maker has reported a defect rate of .1 to 1% in some batches of diodes they received, which reinforces that belief. The kit comes with seven spare LEDs - once I check that it works properly, one of them will be substituted for the dead light.

One of the switches was sitting a bit too high. It wasn't obvious when toggled in one direction, but when I set the switches in the other orientation it stood out. Rather than switching my desoldering gun over to a large enough nozzle to fit over the big leads of the switch, I used some solder wick to pull out the solder enough to refit the switch. It is now sitting in the correct orientation. 

Comments

Post a Comment

Popular posts from this blog

Bizarre behavior detected in a Raspberry Pi Pico based design and partially understood

ORIENTATION OF THE PRODUCT CAN CAUSE THE PI TO FREEZE AT STARTUP This particular product with a Raspberry Pi Pico would not boot up when sitting flat on the table in its normal orientation, but if tilted or turned it would come right up. When I hooked up a USB serial connection to the debug header, it worked fine even flat on the table.  INVESTIGATION BY DESIGNER AS WELL AS ME I first assumed that I had introduced this problem in the product, but happened to describe it to the maker who was able to reproduce it reliably. I continued to try variations to determine whether it was pressure on a board or component that caused it. I also searched the web for any reports that might cause Pi Picos to fail to boot based on orientation, but found nothing.  The designer found signals introduced on a serial connection trace when sitting in the normal (failing) orientation but not injected when rotated or otherwise turned. Traces were routed from the UART0 on the Pico to a header, for use...
Read more

Incompetent coders - the frustration of using Vivado to build FPGA designs

IDIOT SOFTWARE MUST BE RESTARTED CONSTANTLY TO SEE INPUT FILE CHANGES When I update a source file, often Vivado is somehow working from a cached copy and never notices the changes. It is highly frustrating to fix an issue, rerun a Linter or Synthesis and get the same old errors. The only solution is to shut Vivado down and restart. I remember hitting this many times in past years as I worked with the toolchain, but it has changed from sporadic to nearly constant failure to see the changed timestamp. I can't be the only person running the toolchain under Windows, yet this kind of bumbling misperformance has been a feature for years. 
Read more

Found correct mod for the Arduino Mega 2560 to avoid powering it from USB

Image
USB HANDLING CIRCUITS IN THE MICROPROCESSOR REQUIRE USB VCC TO RUN The reason my first attempt failed, simply removing the poly (resettable) fuse, is that the fuse is between the USB connector and the microchip which needs the USB VCC connected. I had to reinstall the fuse.  BETTER CHANGE IS TO REMOVE A MOSFET THAT ROUTES POWER The Arduino uses a power mosfet and a comparator to decide when the external power is adequate to run the board, disconnecting the USB VCC from the board. It does leave that wire connected to the USB circuitry in the chip, however. With the transistor removed, the USB power never gets to the board so it is always powered by the external (1130) power. This means the board powers up and down with the main system, whether or not a USB cable is connected to anything else. When the board is powered up, the cable is active as a serial connection, exactly what I wanted to happen.  In the picture below, the green circle shows the reinstalled polyfuse. The red c...
Read more