A few of you are probably familiar with my experiences with the DE version of the sBitx. There have been quite a number of different things happening which, by Occam¡¯s razor, are in my opinion for the most part likely explained by unexpected spurious oscillations, some of which I have actually documented. My most recent trouble was solved by putting in a new Raspberry Pi 4. The previous one toggled the PTT line when pressed (pin 23 on the digital board connector) but there was no voltage on the TX line when PTT was pressed (pin 27). Putting in a new RPi 4 solved the problem. I now have 26 volts P-P on the 2N2219a driver collectors (Q15) and now I need to install new IRFZ24N finals (one had shorted).
This is the third Raspberry Pi that has failed during normal operation. The Pi was seated in the socket, the digital board as well, and so that error can be ruled out. Two others previously had also failed, and each of those had problems with the I2C lines (bit banged, I know) communicating with the Si5351a. I use one of these now as an OctoPrint server for 3D printing, so at least that one functions even though I can¡¯t use it for the sBitx.?
At this point I have to assume that for whatever reason in my particular sBitx I run the risk in the future of damaging the TX line from a working Raspberry Pi, or the SDA/SCL lines to the Si5351a, or perhaps some other GPIO line on the Raspberry Pi. How would one protect the vulnerable lines from voltage transients? Back to back 1N4148 diodes? Bypass capacitors? Optical isolators? I am running on my 4th Raspberry Pi, the fifth if you include one with the onboard 3.3V regulator fried by an error on my part. Does anyone have any suggestions? I¡¯m awaiting the delivery of a new sBitx v2 that will hopefully be less eventful, but I have put too much effort into this Developer¡¯s Edition to leave it alone. As always, thanks everyone for your wonderful help.
Jack
N6LN
John Terrell, N6LN