开云体育

Sorry for the delayed, long response.? Ham radio SDR has been a big hobby of mine for the last several years so I have a lot of thoughts I want to share.

On Wed, Nov 15, 2023 at 04:03 AM, Rafael Diniz wrote:

I think SDR Angel is my first goal as "upstream standard SDR
software" as it has a relatively simple API plugin to deal with,

I want to emphasize that I'm personally not focusing on using upstream standard SDR software on sbitx, I'm more thinking about how to structure the current software in a more modular way.? ?I think we just found another reason to want this: to be able to reconfigure the software (preferably at run time) to make it possible to keep the different hardware variants working (DE, with or without SWR meter, etc) without needing to modify the software.

I think the amount of innovation in the current sbtix software base is outstanding and I would not want to do anything that could disrupt this innovation.? I think the hardware platform with its touch-screen user interface is a big strength of the platform, and for what I want to do (portable operation) I'm very interested in the text UI of the current software and to not need to have a keyboard/mouse to use the radio.? It's one of the main reasons I bought this radio rather than continuing to work with other SDRs that I already have.

So, I want to be clear that my comments in the previous post were about modularizing and extending the current software as opposed to replacing it with something like sdrangel.

Having said all of this, I did spend some time looking at sdrangel yesterday.? I had used it in the past and agree with what you say about its excellent plugin architecture.? All of this comes with what I feel is a complex build environment.? I say this in part because I'm not a big user of docker.? I can see why he wants to containerize the program.? The documented build procedures use 'git reset --hard' to point at very specific points in the development of various dependencies of sdrangel so he really can't count on the repo versions matching his expectations.? Using docker for containers is a good way to get an environment he can depend on, at the risk of perhaps falling behind on improvements to those dependencies.

I recall trying to get it to build without docker on one of the platforms he said was a target of his a few years ago, Ubuntu 18.04 on x86-64, and not having success.? I believe I later installed it from binaries after not being able to get it to build.? I just checked and I did not see a binary for Linux on Pi, just for Linux on x86.? Therefore it seems I would need to get it to build in a container on Pi, which I think is feasible yet time consuming.

Another approach could be using the PiSDR image ( ) which has sdrangel along with lots of other interesting SDR software.? It might be easier/faster to install a copy of that to my Pi then add in our sbitx software and configuration changes on top of that.? It is a bit old with its last release January 2022 but not terribly out of date.? It might be nice to clone that repo and update whatever things we need and send a PR back to the project's creator.? ?It would also be nice to eventually have sbitx be one of its supported radios.? Another idea is to extend its concepts and use it to automate the build of our sbitx Pi image instead of having the manual steps in install.txt.

I will say that once sdrangel is installed it appears that getting it to work experimentally for reception should not be that hard given the way its Audio Plugin works.? The wiki page for it ( ) describes how you can set up its channel map to expect samples on the left channel of a stereo sound card.? ?Add that to our existing hamlib netctl support (perhaps with appropriate frequency offset if needed if our signal is not centered in the passband) and I think it "should just work".

The sdrangel author also very helpfully describes how he converts the real samples to I/Q format:

Real samples are taken from the left audio channel and are
heterodyned by the fourth of the sample rate (fs/4) to obtain
complex samples. Therefore the spectrum of the complex baseband is
centered at the fourth of the sample rate (fs/4). As per Nyquist
rule only a bandwidth of half of the sample rate (fs/2) is
available for real signals. Frequencies outside the [0, fs/2]
interval are artefacts and can be eliminated by decimating by a
factor of 2.

?This gives me a recipe I can try with my learning exercises using gnuradio.

I don't like the alsa loopback as it is 48 kHz hardcoded and we
need more for real wideband operation by upstream software, so
direct access seems the way to go.

I think the bandwidth is ultimately limited by the sbitx crystal filter that has a very clever design that uses inexpensive components to get very strong filtering but not a lot of bandwidth.? The topic /g/BITX20/topic/102146436?discusses this, as does .? My thought is you can use protocols/channels that support more than 48 kHz of bandwidth but it's not going to be all that helpful because with sbitx there is only 25 kHz of signal downstream of the crystal filter.

IMO it might be helpful for certain use cases to convert sbitx's signal into a 48 kHz baseband I/Q signal because there is a lot of SDR software that expects that format.? That format goes all the way back to Gerald Youngblood's work in the early 2000s, if not earlier.? ?Farhan's papers mention this work as one of the bases of his work.

links to "A Software-Defined Radio for the Masses" and other old-school papers from the early days of ham radio SDR.? To me it's fascinating how the early screen captures of Gerald's Visual Basic software from 2002 show the roots of what we still see in PowerSDR, SmartSDR, Thetis, etc.? It's also fascinating to me that sbitx's software is one of the few software programs that is going beyond that decades-old paradigm by making digital modes a first class citizen.? Another one of these is SparkSDR which is great, but while it is freely available it is not open source, another positive of the sbitx software.


--
Regards,
Dave, N1AI