开云体育

Please excuse me if this is a dumb question ... I'm a total noob when it comes to the RPi.? But is there a reason why simply using a 64 GB card isn't advisable?? The cost differential is minor.

Thanks much,
Dave?? AB7E

On Mon, May 29, 2023 at 08:55 AM, loopMasta wrote:

I get 12v at the cathodes of? D30 and D31 ???

To check Q29, I would verify that the gate is close to the input voltage to the sBitx when receiving and close to zero when transmitting.

Q29 gate is 0v

LoopMasta,

The voltages you listed do not make sense.? A zero volt on the Drain of Q28 and 12 volts on the diodes would mean that L27 is open.? Can you verify that there is continuity across L27?

At the same time, you state that there are 0 volts on the Q29 gate when receiving.? That means that Q23 is shorted or grounded.? This would turn off Q28 and allow the drain to rise to 12 volts.

Your issue is that the Pin Diodes are not turning on to let the RF through to the receiver.? When the diodes are on, the voltage on the cathode (banded) end should be zero volts to turn on the diode.? When the diode is in forward conduction mode, it allows the RF signal through.

Sbitx T/R switch truth table			?
?	?	?	?
?	Receiving	Transmitting	?
Q22	Off	On	?
Q23	Off	On	?
Q28	On	Off	?
Q29	On	Off	?
?	?	?	?
When On the drain should be close to the source voltage
When Off, the drain should be much higher than the source voltage
The Gate voltage needs to be higher than 2.5 volts to turn on the MOSFET

Check that the TX signal is at 0 when receiving and that the Q23 drain is at 12 volts,?

73
Evan
AC9TU

开云体育

On Sun, May 28, 2023 at 05:00 PM, Evan Hand wrote:

Hi Evan. Thanks for your answer.

I do not have a V2, so I can not give you actual voltage or oscilloscope waveforms.? Reviewing the schematic and interpreting from my V1 De, I would check that the TX signal changes from close to zero volts while receiving and close to 3.3 volts when transmitting.? That can be measured on the gate of Q22.?

The TX signal is 0v on rx

Using the same process, I would verify that the drain of Q28 is close to zero when receiving and at the HV value when transmitting.? Note that the HV value depends on the power out of the finals.? The minimum should be the supplied voltage to the sBitx (nominal of 12 volts).

Q28 drain is 0v

I would also verify that the two pin diodes' banded ends (cathodes of? D30 and D31) have close to zero when receiving.

I get 12v at the cathodes of? D30 and D31 ???

To check Q29, I would verify that the gate is close to the input voltage to the sBitx when receiving and close to zero when transmitting.

Q29 gate is 0v

You should see the same signal at the BNC input of your signal generator on both sides of C212.? You can trace the signal through the PIN diode switches.

I am not seeing my signal after D31 !!!

Hi All,

I’d vote for a short press of the tuning encoder to execute tuning lock leaving the long press for something else.

A dial lock indicator would be nice.?

Cheers, Scott

It is a bond that cannot be disassembled under the influence of heat.
The thread is a releasable joint, another thing.
And it is precisely the female thread that must be fixed so that it does not release the heatsink when the amplifier stage heats up.
I stick with the longer screw that attaches to the heatsink.
--
Gyula HA3HZ

If someone is having trouble because they cannot copy the image to a 32GB SD card, because there is a few bits less space on the card. I recommend the following:

?

The solution may be to first copy the image to a larger, for example 64GB uSD card (use balenaEtcher prg).
You start the RPi with the 64 GB card, then copy it back to the 32 GB card with the SD Card Copier program.
To the card you couldn't copy to because there wasn't enough space. This is the simplest solution.
You don't need shrink, you don't need linux os. By the way, the sbitx_v2 image takes up about 9 GB of space.

?

Yes, I tried it and it works.

--
Gyula HA3HZ

Hi,

when I unzipped the latest soft for V2 I realized that there is no extension in the file name.
I expected .img or .iso file.
Is it ok to just rename it with .img to be burned correctly on SD card please?

Thanks,
-P #5

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

I am suprised you haven't found any takers so far! I can take a secondary role only

This is very interesting! I am willing to provide any required tech assistance. I alreay have this blog - . I am willingly to a wingman to this awesome map you have created and maintained for 6 years!

I'll bet that knob costs a little more than $10. ?

I've heard about felt on the back of tuning knobs. I tried it on my K-1, but I didn't have a thick enough piece and didn't really want to cut the shaft shorter.

Tom

Thinking about this later, I have heard of people using Elmer's glue for this which would be much cheaper.
I don't know if I've heard of anyone doing it in plastic, but I think it would work.

Tom
W9KKQ

I would like to see this also, at least for the power setting as I have done just that.?
Or I am thinking of adding a 2nd encoder just for volume. If I only had time to work on the software for this!

Somebody has probably posted this before:

Adding weight to the stock tuning knob really makes tuning much nicer. It's amazing the difference.

I filled the voids in the back of the plastic knob with some #8 shot.
Filled the voids about 3/4 of the way, then filled up the void with epoxy.

Use 5 minute (or longer) epoxy that mixes itself in the delivery tube.?

I used #8 bird shot because I had some, and I wanted maximum weighting. Some #6 or #8 nuts would work, Or snip off little bits of 12ga copper wire, cut it about as long as it is round. You want to fill the voids as much as possible. Wad up a bunch of solder in the voids. What ever you can do to get weight in there. Then encase it in epoxy.?

Makes the tuning much smoother and using it to select menu entries is much better. Turns a $2 knob into a $10 knob (literally and figuratively).?

Here's a picture of the epoxy I used and the finished knob. I used 1 minute epoxy because the store was out of 5 minute. Things got a little rushed. You want the epoxy to filter down between the voids and it needs a little time to do that. The epoxy mixes in the tube so you don't have to measure out equal amounts. It comes with two delivery tubes, when you've finished filling the knob, take the delivery tube off and throw it away. The epoxy comes with a black cap, cap the syringes and you can use it (with the other delivery tube) another day.

Be careful not to get anything with epoxy on it in the center hole.

Tom
W9KKQ


W9KKQ