On Thu, Nov 16, 2023 at 12:43 PM, Rafael Diniz wrote:

my specific goal, to be clear, is to decouple the UI and features
from the low level radio control, so then to allow other software
to also be able to run without constraints (like the one posed by
the alsa loopback).

I'm still curious but I'm not sure I understand, do you want to:

1. use sbitx's user interface code to control a different radio
2. use a different UI to control sbitx's radio
3. both (a) and (b)

On Nov 16, 2023, at 13:44, Aaron K5ATG <Aaron@...> wrote:

?I'm trying something like this:?

But I'm putting it inside the case of a cheap Dynamic microphone so I can use my mic boom. Here is the mic case I'm using:


I'm waiting on some audio cables to come in. I don't know if it will work or not but I will post the results. I'm kind of flying blind with it because I really don't know anything about microphones.?
--
'72

Aaron?

Rafael, that is already in place. The low level controls are all through a single call : sdr_request.
The commands can also be issued over tcp/ip under Hamlib's NET rigctl. See hamlib.c
- f

On Thu, Nov 16, 2023, 11:13 PM Rafael Diniz <rafael@...> wrote:

Thanks for your insights, Dave. I agree SDRAngel build and
dependencies
are not trivial, but this is easily solvable, and also agree Ashhar
software is great and by no means I want to replace Ashhar
software, but
my specific goal, to be clear, is to decouple the UI and features
from
the low level radio control, so then to allow other software to
also be
able to run without constraints (like the one posed by the alsa
loopback).

Btw, with regards to samplerate, with the current sBitx, where I
can see
signal up to 30-something kHz, and a passband around 25 kHz (in a
soundcard operating at 96 kHz in the sbitx), for "direct passtru",
it is
just not possible to keep the whole bandwidth with just 48 kHz
samplerate.

Cheers,
Rafael

On 11/16/23 15:44, Dave, N1AI wrote:

> 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
>
>

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