开云体育

The following is pretty standard software developer stuff, but I thought I'd share what I'm looking at, a problem where the text-based UI of my copy of sbitx seems to stop responding when I change bands.? As noted elsewhere this is my own build of the code in 64-bit mode running on Debian 11 / Bullseye.

?

In?, Farhan encourages us to try the gdb debugger to look at the sbitx source code and gives some examples of doing so.

?

To start, I like to use my laptop to debug so I ssh into the sbitx's pi, then I use

?

$ export DISPLAY=:0

?

to get the sbitx program's display to appear on the pi's screen instead of getting tunneled via ssh back to my laptop.

?

Then as per the article:

?

$ cd ~/sbitx

$ gdb ./sbitx

(gdb) run

?

You can hit <Ctrl-C> to give "focus" back to gdb once sbitx starts, then use the "c" command (for continue) to continue running sbitx.

?

My favorite gdb command to learn about what is going on in the application is:

?

(gdb) thread apply all bt

?

which means 'do a back-trace on all threads'.

?

Editing this output for interesting stuff, I find:

?

Thread 9 (Thread 0x7fed7c7e80 (LWP 133933) "sbitx"):

#2? loopback_loop () at sbitx_sound.c:741

#3? loopback_thread_function () at sbitx_sound.c:826

?

Thread 8 (Thread 0x7fedfc8e80 (LWP 133929) "sbitx"):

#2? sound_loop () at sbitx_sound.c:584

#3? sound_thread_function () at sbitx_sound.c:808

?

Thread 7 (Thread 0x7fee7fbe80 (LWP 133924) "sbitx"):

#3? ft8_thread_function () at modems.c:194

?

Thread 6 (Thread 0x7feeffce80 (LWP 133920) "sbitx"):

#1? waitForInterrupt () at /usr/local/lib/libwiringPi.so

#2? interruptHandler () at /usr/local/lib/libwiringPi.so

?

Thread 5 (Thread 0x7fef7fde80 (LWP 133918) "sbitx"):

#1? waitForInterrupt () at /usr/local/lib/libwiringPi.so

#2? interruptHandler () at /usr/local/lib/libwiringPi.so

?

Thread 4 (Thread 0x7fefffee80 (LWP 133916) "sbitx"):

#3? webserver_thread_function () at webserver.c:222

?

Thread 3 (Thread 0x7ff4e53e80 (LWP 133914) "gdbus"):

#2? g_main_loop_run () at /lib/aarch64-linux-gnu/libglib-2.0.so.0

?

Thread 2 (Thread 0x7ff5654e80 (LWP 133913) "gmain"):

#2? g_main_context_iteration () at /lib/aarch64-linux-gnu/libglib-2.0.so.0

?

Thread 1 (Thread 0x7ff59d3cc0 (LWP 133908) "sbitx"):

#2? g_main_loop_run () at /lib/aarch64-linux-gnu/libglib-2.0.so.0

#3? gtk_main () at /lib/aarch64-linux-gnu/libgtk-3.so.0

?

One thing for future consideration is that all the threads running code from the sbitx folder have the name "sbitx" but I think there is a way to set the thread name so (for instance) thread 9 could have the name "loopback" instead of "sbitx".? This would make it a bit easier to see what the code is doing in linux commands such as "ps" and "pstree".

?

The problem I was investigating was that when I try to change bands the text UI stops responding to any inputs.?

?

One thing I notice is when this happens the main thread (#1) is trying to talk to fldigi (again, output is simplified):

?

(gdb) bt

#0? __libc_connect () at ../sysdeps/unix/sysv/linux/connect.c:26

#1? fldigi_call () at modems.c:735

#2? modem_poll (mode=3) at modems.c:924

#3? ui_tick (gook=0x0) at sbitx_gtk.c:3495

#5? g_main_context_dispatch () at /lib/aarch64-linux-gnu/libglib-2.0.so.0

#7? g_main_loop_run () at /lib/aarch64-linux-gnu/libglib-2.0.so.0

#8? gtk_main () at /lib/aarch64-linux-gnu/libgtk-3.so.0

#9? main (argc=1, argv=0x7fffffe5a8) at sbitx_gtk.c:4411

?

I don't know if this is normal, or if this suggests the problem is that it can't talk to fldigi therefor the UI is not responding.

?

It's interesting to me (if I'm understanding things correctly) that there are independent threads for doing a lot of different things but it seems the fldigi work is done in the same main thread used to respond to the user interface so if fldigi stops responding perhaps the UI also stops.? Just a guess.

?

One issue I am seeing is in the output of sbitx as it starts:

?

sh: 1: fldigi: not found

?

I did my own installation and forgot to install fldigi!? Seems the install.txt instructions should mention the need to install and configure fldigi.? So I will give that a try soon and see if that makes the problem go away.

?

Ideally I would like to be able to run the sbitx software in "old school only" mode without running fldigi or the web server/browser, just because I like to keep things simple and not use resources if I'm not using the related functionality.? I shall see if I can't modify the software to do such things.

?

--
Regards,
Dave, N1AI

On Sun, Nov 12, 2023 at 01:13 PM, Mark Erbaugh wrote:

I’m also developing on another computer using SSH to the sBitx.
But I am using VS Code with its Remote-SSH extension. This gives a
GUI interface to GDB as well as aSource code editor that lets
easily jump around the source files and have files open in their
own windows.

Yes, that sounds like a good idea.

--
Regards,
Dave, N1AI

What does the Hermes mean?
--
73,
Mark, N8ME

I will certainly refer to it.

I really like the idea of doing I2C in the kernel rather than in user space.

I like the idea of having a core set of functions that can be started and stopped from the command line.

I personally would like to get to a core set of radio functions with multiple ways for the user to interact with them:

* touchscreen UI (like the current gtk)
* web-based UI (like the current html one)
* command line (like yours, I think)
* network based
o maybe like ka9q radio project
o maybe like open web rx
o maybe like hpsdr protocol 1 and/or 2
o maybe like soapy remote

So, a radio core with many different ways to interact with it.

One or more of these network-based approaches are proof points that the radio user interface can be totally separated from the device that performs the radio functions.

Of course the network could be inside the box, the main idea is to be able to pick and choose the user interface that works best for what the user is trying to do.

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

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

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)