I have some notes and suggestions that may be helpful to some of you. If you already know some of these points, fine.
I have the V2 working. At first the factory SD card wouldn't function. (First boot caused "Kernel Panic.") I used the downloaded new V2 .img because going to github and doing ./update never worked for me. I had to change blown finals twice probably because of overdriving. (I did that probably one or two dozen times with the Developer's Edition for various reasons.) Now after tweaking hw_settings.ini (something you really must do) the output is limited to about 30 watts or less for each band. The file is in the /home/pi/sbitx/data directory. I use ssh to open it in a Raspberry Pi terminal and edit it by doing a sudo nano hw_settings.ini and changing the "scale" coefficients for each band. The numbers can range from 0.001 to 0.01 or so, depending on your rig and band. Be careful. Change it by 20% up or down, and then save and close it each time you want to see the results. It's re-read only when the sbitx program starts again so you have to quit the sbitx program and restart it to see the change. Again I keep the maximum power output below 30 watts to avoid blowing finals but on the higher bands you might top out at less than that; set the "scale" on those higher bands so that it plateaus to 6-16 watts or whatever just as the Drive number reaches the max of 100. The Drive control will be more useful that way instead of topping out at a low Drive number.
Protect the finals. The rig will not tolerate an absent or poorly matched load. In the latest case of IRFZ24N failure my old worn out BNC male connector going to the dummy load had the center pin pushed in to where there was an open circuit. It looked fine until the finals blew. Double check everything. And if (when) you blow finals remember to replace them with matched pairs. I have seen MOSFETs from Amazon, DigiKey and Mouser have input capacitances and threshold voltages vary by a factor of two between different sources. Thankfully they're inexpensive. I check them with a simple transistor tester I got on eBay for less than $15. It is absolutely essential. Remember to re-adjust the PA_BIAS potentiometer whenever you replace finals so that the current draw to the rig on PTT (Mic = 1, Drive=1 on USB) increases from baseline to 200-250 mA more on SLOW clockwise turn of the PA_BIAS potentiometer. Start with it at full counterclockwise. (Make sure you aren't adjusting the RV1 potentiometer--that one should stay around 12:00 or 1:00. Leave it alone.)
Both the Developer's Edition and the V2 have a quirk where the Raspberry Pi sometimes doesn't send the audio through to the codec chip (WM8731) and then when the sbitx program starts there's no sound, no signal or radio noise and the waterfall is a solid bright yellow. (You can start one of the noisy games or go to YouTube to prove that the default audio system and speaker work.) This has been a problem that several others have noted. It seem to have at least three causes which at first made it difficult to analyze.
1) One of the first things to remember is that if you quit the sbitx program (at least when you start it from the command line) is that the fldigi programming may still be running. If you restart the sbitx program by clicking the icon instead of strting it with ./sbitx on the command line it seems to pick up where it left off and use the already running fldigi process (which is intrinsic to the whole sBitx SDR anyway). But if you start the sbitx program again on the command line it seems to start a second fldigi process and can't find the audio stream because it's already being used by the other fldigi process that's already running. So if you're having trouble with the audio look to make sure you don't have two fldigi processes running simultaneously! You can tell by looking at the top row of the screen that shows the programs running. (That row also shows icons for starting sbitx and terminal programs, and they look the same as the icons that represent the running programs, which is an important distinction that might lead to some confusion.)
2) I like to use a larger monitor than the 7 inch DSI screen. If an HDMI monitor is connected to the Raspberry Pi at boot the RPI detects the HDMI monitor and decides to send audio to the HDMI port and not the Codec chip. Some HDMI monitors may not have sound, but mine does, and half of my trouble here was solved by going to the HDMI monitor and setting the sound to "mute." The simplest way, however, to use the large monitor is not to connect it directly to the rig but to have an internet connection to the Raspberry Pi and log into the sbitx webserver at whatever its LAN address is and use port 8080. That was a good addition in the V2 software.
3) Still, it's not uncommon to start the sbitx program and see no sound or signal. Many of us manage to get it to start properly by rebooting the entire rig. Evan AC9TU notes that disconnecting all power and waiting a few seconds works. It's as though the codec chip needs to be discharged completely in order for it to restart and connect the audio properly. (n.b. I have found that when I do this I have to also disconnect any HDMI connection from the Raspberry Pi as well. The HDMI connector from the monitor in my setup provides some voltage, about 4.2V, to the Raspberry Pi, and also the "Digital Board" part of the circuit in both the Developer's Edition and the V2, so the codec chip may not therefore reset by simply turning the main power switch off.)
4) Also it has been suggested that a line in /boot/config.txt should be changed from "dtoverlay=vc4-kms-v3d" (no quotes) to "dtoverlay=vc4-kms-v3d,noaudio" and I have done that. But the rig still sometimes needs to be restarted to get the audio working.
There has got to be a way to solve this definitively.
Also, I suggest that if you have a Developer's Edition (mine is with upgrade #2) you do what I did and install some protective zener diodes on four of the GPIO pins on the Raspberry Pi, and another mod on a couple of voltage regulators, one on the mainboard and one on the digital board. At least early on in my experience with the Developer's Edition rig there were uncontrolled oscillations which were probably what caused the failure of some of my GPIO pins. I use 3.3V zener diodes on SDA-BB, SCL-BB, TX and PTT lines. It's easy to piggyback them on at the Digital Board where the 40-pin right-angle connector plugs into the main board on pins 39, 37, 27 and 23 respectively, with anode to ground, by scraping the green enamel from the pcb. It has accessible gold plated pins. The regulators in question are the two AMS1117 chips that provide 3.3V to the Si5351 chip on the mainboard and the other AMS1117 on the Digital Board. Apparently taking 13.8V down to 3.3V is too difficult for this delicate chip. They can simply fail and open or worse, short and send 13.8V through to the downstream parts expecting 3.3V. Ever seen an Si5351 glow orange and explode? So I use LDO regulator chips to first bring the 13.8V down to 5V, and use the 5V output as input to the AMS1117 chips which then feed 3.3V to the other components. Works like a charm. I use a 78L05 for the main board Si5351 because it's smaller and a LM7806 (7805 is fine, I just had a 6 volt unit in my junk box) for the Digital Board because the leads fit the space better. The regulator mods are more difficult because you have to cut or desolder and lift and bypass the input pins for the AMS1117s. It's worth the effort. Trust me. I have seen several successive failures in each case leading to four damaged Raspberry Pi 4s and both AMS1117 locations requiring the replacement of four total AMS1117 units and three Si5351 chips. I have become pretty good at SMD soldering in the process. By the way, both the zener protection of the Raspberry Pi PTT GPIO pin (protecting that one pin may be sufficient) and 5V intermediary LDO regulator protection of both AMS1117s has already been incorporated into the design of the circuit board in the V2, which happily hasn't had any of those failures seen in my DE unit.
Finally, I have seen software failures from previously working SD cards that were solved by burning new images onto the same SD cards. Each time I feared a hardware failure but luckily it wasn't so serious. The latest time was this afternoon. How were the images corrupted? My guess is that I shut off power without doing a clean software shutdown of the Raspberry Pi. Sometimes this is necessary if the 7-inch DSI gets locked up, in which case I recommend instead shutting down the software safely by ssh-ing in from a remote terminal and doing "sudo shutdown -h now" before turning off the power rather than having to burn another SD card. If the Raspberry Pi is in the middle of a "write" when the power stops the SD card may have corrupted data on it. When you do
get an image working properly, save it to another computer! Also, I save the fine-tuned hw_settings.ini file separately as hw_settings.ini-bak which I can transfer to any of my several SD cards for my sBitx rigs by using Filezilla. It saves an enormous amount of effort. And remember to do the V2 power meter calibration (if you have the V2 rig, or have done the SWR bridge modification for the Developer's edition). It protects the rig from putting out over 40 watts, which is the easiest way to get into trouble and cause a problem.
I'm looking forward to improvements to the iambic keyer. Until then I'm using my trusty K3NG keyer, which is a wonderful project itself if you like to build things.
Jack
N6LN
John Terrell, N6LN