LED's and controlling IC's issue during assembly

[Rusty Shackleford]

I checked the solder joints, I reflowed them, I followed traces, I replaced one of the sockets with a spare I lucked out on having on hand, I don't know what's causing this issue. The bottom two rows of lights aren't working unless I press down on the chips in the corner or I hold my finger across the pins on the back. Should I try pulling the sockets out and soldering the chips onto the board directly? My only guess at this point is I've got bad connection in the sockets but I even replaced one of them and it still didn't help.

heres a video of the issue
https://www.youtube.com/watch?v=b6u5tn45Qcs

[terry-...@glaver.org]

I found that the ICs using the supplied sockets could shift enough up or down that there wouldn't be a good connection on all pins. Try taking the ICs out and make sure that the chip is centered in the socket as you push it down. I decided to replace the kit sockets with Mill-Max ones to avoid the issue entirely.

I haven't looked at the schematic, but also check your soldering of the connector that connects to the Pi's GPIO as well as the 18 or so resistors in that area.

[oscarv]

I suggest removing and reseating the chips in the sockets as the first step.

Also, use a multimeter to check for continuity between the top of the chip pin and the bottom of the solder point.

Let me know if that does not solve the problem: oscar.v...@hotmail.com? (I'll be offline for a day though, travelling)

I've never had issues with these chip sockets so far, they come from Digi-Key, should be of acceptable quality? I know some people prefer machined chip sockets, but IMHO that is a preference more than a need. (Although some hold strong opinions on the matter, I know!)

Kind regards,

Oscar.

[Rusty Shackleford]

removing and reseating the chips was the first thing i tried. i just got done following traces, everything checks out with a meter. if i touch the pins, then pin #3 on either the 74hc138 or the 74hc238 gets all of the lights to function. i also just reflowed all the gpio and resistors since that seems to be a common issue but it had no effect.

[oscarv]

Jesse,

On Saturday, May 4, 2024 at 12:24:42 AM UTC+2 jesse...@gmail.com wrote:

removing and reseating the chips was the first thing i tried. i just got done following traces, everything checks out with a meter.

Also tested for continuity from chip pin at the top to solder pin below it?

 

if i touch the pins, then pin #3 on either the 74hc138 or the 74hc238 g

That is interesting! Here is the trace of those pins to the GPIO:

It is one of the address lines to the 74X38 chips. Basically, the Pi GPIO sends out a 3 (or 4, the enable bit that selects either one of the chips to become active) bit addres, which the chips then translate to one of eight output lines to become active.

That this pin is sensitive to your touch means it is not being driven by the Pi's GPIO. That GPIO pin is either driven low or high, if sensitive to touch it seems to me this signal is floating.

- check from top of pin 3 *on the chip* to the highlighted pin on the GPIO to see if there's a connection. Even better, from the top of pin 3 on the chip to the top of this solder pin on the Pi itself. You never know.

- this can also be a sign of a defective GPIO on the Raspberry Pi itself. Does not happen often, but I've seen it a good few times by now.

There must be some competent EE's on this group as well - please mix in the conversation.

Anyway, not to worry, we will fix it one way or the other. It can't be that hard. If you have a bit of patience, I'd like to debug by email. I've gotten good at it for the other PiDPs, this is the first case on the Ten. Good to hone my remote debugging skills.

Of course I don't know if you are an electronics person. If so, I can also send you the Kicad file if you want. But the prime suspect is this trace, and finger touching having an effect points to a floating signal, i.e., either the Pi's GPIO pin is dead or there's no contact with it.

Kind regards,

Oscar.

[Rusty Shackleford]

email sent, but for those following along at home, I followed it to pin 13 on the pi before I saw you post the image of the trace (of course its that pin), or GPIO 27 as it seems to be labeled online. just out of paranoia i removed the sockets again and followed every trace from the sockets to the GPIO that i could again. i did find a spot i nicked with the cutters and i thought i'd found the culprit when i noticed that, but continuity checked out fine. I'll try out a different pi in a bit and see if that fixes it, if that still doesn't work then i'll try a bodge wire along that trace instead and see if that somehow helps.

update: I tried a pi4 in it, and it worked. i tried the pi5 in it again just to make sure its an issue with the pi, and it worked. or so it seemed. i put it all back together, let it run for a bit, and i noticed the three rows of 7 lights on the left weren't working properly, i could very dimly see them blinking in a pattern whenever the pdpcontrol program was running. the whole panel lights up however when i run pidp10-test, so i know they've got good connection. 

new video of me mumbling:

https://www.youtube.com/watch?v=kneRqxEw3pE

[Karl Schuneman]

With the pi5, what type of power supply are you using?

[Rusty Shackleford]

the official pi branded type c power supply.

[oscarv]

Yes, I found the videos!

I also see that touching Pin 3 is not the only thing that lights up the lower LED rows, flexing/wobbling the PCB also 'helps' light up those LEDs, right?

That looks pretty clear to me, some sort of a dodgy connection from GPIO to the 2 chips that drive the LEDs.

--> broken trace. As in, dodgy trace with a fine, invisible break in it that you will not see with the naked eye perhaps.

You also mention:

>>  i did find a spot i nicked with the cutters and i thought i'd found the culprit when i noticed that, but continuity checked out fine.

More circumstantial evidence, a tiny break in a trace can sometimes be there (no continuity), yet when you pick up the board and it flexes, all of a sudden there is continuity.

Thinking along:

1) So there's 3 address lines that let the Pi determine which row of LEDs is getting power the next fraction of a second. (We're multiplexing, so every second, each row of LEDs is lighted up a fraction of that second consecutively, cycling through the rows)

2) If you touch Pin 3, rows 0,1,2, and 3 get a life all of a sudden. Touching Pin 3, IMHO, means pulling a floating signal to ground. Pin 3 is the highest bit of the 3 'address bits', so if you pull that signal low on the chip by touching it, yes, the bottom two rows of LEDs all light up. It makes sense!

So the diagnosis seems pretty clear to me: for some reason, the GPIO pin that provides this signal is not able to pull pin 3 low. Pin 3 is stuck either High (because there is a short to some other signal), OR it is floating and just happens to float high until you touch it, and the tiny bit of current through your fingers pulls it low. That would also be why sometimes, the upper row of LEDS goes dark when you touch pin 3.

So - my suggestion is to run a bit of wire from the GPIO pin on the picture I sent to the solder point of pin 3. 

- I assume you've multi-metered and find good connection between the solder point of pin 3 on the PCB and the pin on the chip itself on the upper side of the PCB

- and the same for the GPIO pin on the Pi itself to that pin's solder point on the GPIO on the PiDP board.

- as you also established the Pi itself is not defective

---> this MUST be some dodgy trace that most of the time does not continuity, yet when you press/flex/push on the PCB all of a sudden it does. That is what I think I see in your video.

Solder a wire from the GPIO to one of the pin 3 solder points as per the picture. My bet is that this will fix the issue. 

If not, we'll still fix this one way or another :-) So don't worry, I just hope you don't mind taking some time to experiment.

Kind regards,

Oscar.

[oscarv]

Maybe it's a good moment to explain this part of the PiDP-10 circuit. It is very simple, understanding helps debugging thoughts:

The 74HCX38 chips are demultiplexers. You enter a 3-bit binary address on their input, and one of 8 output pins is selected. 3 address lines in, one of 8 signal lines out.

On the left, you see Address pins 0-4, they come out of the Pi. Addr 3 (pin 4 on the LED chip, the 74HC238) basically flips the circuit by enabling EITHER the 74HC238 for the LEDs, OR the 74HC138 for the switches.

The other 3 address pins determine which signal out of the 74HCX38 (which row of 18 LEDS) will be enabled (enabled: either the power to a row of LEDs, or enable reading a row of switches).

As it happens, the 'rows of 18' that power the bottom two rows of LEDs are pins LED0-LED3 (on the right of the schematic). And if your Address 2 signal (pin 3 on the 74HC chips) is not pulled low by the Raspberry Pi, then yes, these LEDs will never get power to light up!

And by extension, you'll never be able to read the corresponding switches either.

So, touching Pin 3 on either chip seems to make your PCB behave perfectly. By extension, this is the one trace that is bad. That's why I am convinced runnign a wire as per the previous post will fix your problem.

Bad traces can be devilishly hard to spot visually. But you mentioned some damage done by a cutter. If the wire trick solves your problem and you don't like a wire as the permenent fix, you could try and scrape off the black coating around the spot where the cutter scratched, and then make a solder blob on the trace. Neater, but I'd prefer the wire solution myself.

Please let me know!

Kind regards,

Oscar.

[Steven A. Falco]

On 5/4/24 12:42 PM, oscarv wrote:
> Maybe it's a good moment to explain this part of the PiDP-10 circuit. It is very simple, understanding helps debugging thoughts:
>
> The 74HCX38 chips are demultiplexers. You enter a 3-bit binary address on their input, and one of 8 output pins is selected. 3 address lines in, one of 8 signal lines out.
>

> Screenshot from 2024-05-04 18-30-26.png
>
> On the left, you see Address pins 0-4, they come out of the Pi. Addr 3 (pin 4 on the LED chip, the 74HC238) basically flips the circuit by enabling EITHER the 74HC238 for the LEDs, OR the 74HC138 for the switches.
> The other 3 address pins determine which signal out of the 74HCX38 (which row of 18 LEDS) will be enabled (enabled: either the power to a row of LEDs, or enable reading a row of switches).
>
> As it happens, the 'rows of 18' that power the bottom two rows of LEDs are pins LED0-LED3 (on the right of the schematic). And if your Address 2 signal (pin 3 on the 74HC chips) is not pulled low by the Raspberry Pi, then yes, these LEDs will never get power to light up!
>
> And by extension, you'll never be able to read the corresponding switches either.
>
> So, touching Pin 3 on either chip seems to make your PCB behave perfectly. By extension, this is the one trace that is bad. That's why I am convinced runnign a wire as per the previous post will fix your problem.
> Bad traces can be devilishly hard to spot visually. But you mentioned some damage done by a cutter. If the wire trick solves your problem and you don't like a wire as the permenent fix, you could try and scrape off the black coating around the spot where the cutter scratched, and then make a solder blob on the trace. Neater, but I'd prefer the wire solution myself.
>
> Please let me know!
>
> Kind regards,
>
> Oscar.

FedEx tells me I'll be getting my kit in a day or two, and all this talk of schematics makes me wonder if the KiCad files will be made available. I've always found those helpful for my PiDP-11 machines, and I'd love to have a set for the PiDP-10. Much better than a pdf, and the board layout files are very helpful when doing mods.

Steve

[oscarv]

Sure! Attached is the Kicad project folder.

[wjegr...@gmail.com]

I assume you don't have an oscilloscope, but if you do, probe the IC pin then go up the connection chain. A voltmeter might even manage, but probably won't respond to the quickly-changing state. As for Oscar's wire suggestion, that would make your build even more realistic. Boards frequently had hardware 'patches' done using a bit of wire and the occasional dangling component. I had a problem with one set of LEDs not working, I had not quite inserted one of the ICs straight, classic bent-under pin. Easily fixed, but this can't be your problem since you've removed and replaced the IC. Well, as long as you looked for a bent pin. Carefully look at the IC when its in the socket to confirm that all pins went into the socket holes.

[Steven A. Falco]

On 5/4/24 02:26 PM, oscarv wrote:
> Sure! Attached is the Kicad project folder.

Thanks, Oscar! Very much appreciated!

Steve

[Rusty Shackleford]

> flexing/wobbling the PCB also 'helps' light up those LEDs, right?

no that doesn't effect it. touching the traces on the back did effect it previously but flexing it did not.

i added a wire running from the IC's to the GPIO just now but it has had no effect on the board.
i'm getting some weird split second flashing on a few of the lights in PROGRAM COUNTER and MEMORY ADDRESS that i didn't notice last night. It seems to be mostly lights 28-35 on the top two rows, but i'm noticing a few other lights doing it now as well. light 0 and 5 in instruction, and light 27 in memory address. and most of the lights in pi request and every other light in pi in progress but those are coming on so dim i can barely see it happening.

heres a timeline of what i've done that i can remember
- assembled and didn't have bottom row lights
- bumped the sockets for the three IC's by accident and noticed lights came back
- pulled chips, reinserted, no effect
- reflowed solder to no effect
- tested traces for continuity which checked out fine
- desoldered the sockets, replaced the socket for the 74hc138 (the socket not the IC), soldered sockets back on again, to no effect
- reflowed the gpio, and resistors, to no effect
- swapped pi5 for pi4, suddenly bottom row lights work but the left rows of 7 lights (PI IN PROGRESS, PI REQUEST, PI ACTIVE, IOB PI REQUEST) dont work or work barely while in the simulation, everything works fine when running the pidp10-test program.
- added wire, from pin 3 of 74hc238 to pi pin 13, to no effect.

video of what the lights are doing
https://www.youtube.com/watch?v=aYBFvHq_7eA
again, everything works fine when I run pidp10-test, i assume those rows on the left not coming on is unusual but maybe i'm wrong since it seems to be working fine now otherwise.
ive removed the bodge wire since it doesn't seem to be doing anything. 

[oscarv]

Jesse,

Sorry for taking 4 days to reply!

Hmm, this sounds like a more devious solder/contacts/etc problem. Would you consider swapping the LED PCBs? I send you mine, you send me yours?

Contact me on oscar.v...@hotmail.com, that is a bit quicker on some days :-)

Only one other thought - when you run pidp10-test, you do quit the PDP-10 simulator (pdpcontrol stop) first, right? If they run together, you do get funny flashes as both try to drive the LEDs at the same time.

I ask because of this line in your post:

>> - swapped pi5 for pi4, suddenly bottom row lights work but the left rows of 7 lights (PI IN PROGRESS, PI REQUEST, PI ACTIVE, IOB PI REQUEST) dont work or work barely while in the simulation, everything works fine when running the pidp10-test program.

I think I misunderstand, or are you indeed saying that *everything* works fine in pidp10-test and the problems are only in the PDP-10 simulator? I can;t imagine that being the casee, but I ask just in case :-)

And one other only thought comes up: this happens without the switch PCB connected as well?

Kind regards,

Oscar.

Kind regards,

Oscar.

[Rusty Shackleford]

its fine, i've been at work the past few days as well and only just now checked for updates myself.
I would be fine swapping led boards, i'll email you to continue with that if thats what you'd like to do.
i do run pdpcontrol stop, yes.
as far as i can tell at this point, *everything* works fine in pidp10-test and only in the simulator do the lights on the left side cease to work as they should.
i've had the switch pcb disconnected for most of my tests. i have had it connected a few times but it made no difference and i didn't expect that it would make a difference anyways so i usually dont bother hooking it up.

[oscarv]

Jesse,

Then let's do a board swap for the LED panel! I get an interesting debugging chance, you get the problem solved.

I am back home on Monday, if you email your postal address to oscar.v...@hotmail.com, I'll respond with mine and get the parcel shipped.

Please do make sure to package the board with some stiff backing, or the mail will destroy it.

Kind regards,

Oscar.