Left Coast Political Scene

  Today we start with an updated Block Diagram of the MHST (Minimalist Homebrew SDR Transceiver). Let us start by tracing the Receive and Transmit Paths. Essentially the Received signal starts at the Analog front end passing through the TR Relay into the Main Board. The received signal is first amplified by the Steerable Amp and then passes this signal stream on to the Band Pass Filter.    From here a simple FT-37-43 transformer splits the received RF signal into two RF signal paths passing one each to the RF input side of the two ADE-1's. There in each ADE-1 a Quadrature LO signal introduced from the Pi Pico converts the RF signals into two audio streams (In Phase and Quadrature -- I & Q).   The next step is the Sound Card which processes the two audio streams into the RPI5 for signal processing and displaying the signals on the HDMI Screen and sending recovered audio to a Headphone/Mic Sound card dongle.  The Optimal Shop Sound Card has both a stereo ...

More progress on the MHST rig and thus some more sharing. I note that when there is nothing but boring words, the interest level drops. This often happens on the weekend posts. So, for this last day of March 2025, hopefully more interesting stuff. The MHST project has two main elements and these are of course the hardware and the software. The more visible of course is the hardware and even then, not much of that. The not so much seen of course is the software. Both are needed to be working for the total rig to work. I posted a video about some of the progress and problems if only to show it was alive. One comment -- hey you have the presence of the opposite sideband image. That was true as the video was done without any adjustments. Contained internally within the QUISK software is a means to compensate for not so perfect hardware where component tolerances do not create the perfect 90-degree phase shift. In fact, you have the capability to make these adjustments over the whole band o...

I am happy to report that I now have the Pi Pico able to work with the RPi5 SBC. The issue was that the package to recognize the Pi Pico has to be manually loaded into the QUISK directory. Once installed what should normally happen is that when QUISK is executed that radio should show up on the menu. It didn't on the RPi5 SBC. It was a mystery as using essentially the same process the radio did show up on the Windows 10 machine.  Then, I decided to closely read the instructions where I spotted something you needed to do differently for the Linux install. Dah RTFM! Suddenly the MHST rig is in the list. I still have a few warts to polish off but a huge step in reducing the size of the rig with the bonus of the features in the Linux form factor versus the Windows 10. One really important Linux feature is the Pulse Audio Control Panel that is loaded in a terminal like this. sudo apt-get install pavucontrol This control panel gives you a whole series of adjustments and selections with r...

A productive day yesterday on two fronts. I visited the XYL at the cemetery to bring some of her favorite flowers and was happy to see that the headstone was installed. I had been told it might take six months. Now no longer an unmarked grave. The second front was the MHST is back on track. As I had suspected it involved the software. This requires a bit of explanation that deals with the two different approaches using the QUISK software. (Windows/Linux) But let us start with some fundamentals of the I/Q implementation which is basically sound cards -- TWO of them. One sound card, typically external, involves the processing of the I/Q data stream to/from the computer. The second sound card handles the Audio output and Microphone input. This often is an external sound card built into a mic/headset dongle. In a Linux implementation using a RPi3, RPi4 or RPi5 there is an issue with using any internal sound cards on the SBC. In the earlier Pi Models, there is an on-board Headphone jack but...

For some strange reason my mind works while I sleep and often, I will awake with an answer to a confounding problem from the day before. That didn't happen last night! Instead, I did think of a new mantra to describe the situation. Things simply do not aright themselves through spontaneous correction. Yesterday was both a Good Day and Bad Day at the bench with the MHST project. First the Good News. I was able to get a HIGH on GP2 when you hit the PTT button on the QUISK panel. It all boiled down to adding a #define statement in the Arduino IDE that cites the Pin title and GPIO Pin Number.  That worked but for as fast as the Pi Pico is (133 MHz) there is a noticeable delay (with no internal delay statements in the code) from button engagement until there is power on the pin and the same is true once the button is released. Thus, not like unkeying the Microphone and you are in receive. More opportunities for going down the rabbit hole. But then the two Bad News Stories. I noticed a w...

One regular blog reader turned to chatGPT with my problem stated in yesterday's blog.  The answer was in the form if you were using Micro-Python or regular Python for coding. Indeed, the pin designations were different from what I had posted. I thought this is the answer. Well sadly none of that compiled in the Arduino IDE. But the exercise convinced me that indeed there has to be something different in the way the pins are named. The ever-curious blog readers would ask -- why does the built in LED code work? In fact, the often-used example in how to code the Pi Pico is the Miyagi LED ON LED OFF tutorial. If that works making a Pin HIGH should work. One possible and likely THE reason -- the built in LED IS NOT a Pin on the Pi Pico and therefore no Pin is specified in the code. This cannot be this hard. Perhaps another run at chatGPT only specifying only show code that can be used in the Arduino IDE. It all comes down to asking the right question to the problem at hand. Well, I mad...