Thanks for this Dave
AS expected replacing your Device with my II worked at treat.
Signal to noise level output not great and is worse in the headset than it is on the sbitx speaker, however its not great there on mine anyway. Turning the volume up on the sbitx just seems to make it worse. The usable volume range is such that there is almost no audio until the volume control reaches a setting of 50+, a reasonably comfortable audio setting of about 86 is required to listen to the sbitx speaker.?
Word of warning for anyone following this thread and using the 64-bit OS. if you boot the sbitx up with the USB headset plugged in, the sbitx app will not start,, unplug the headset and reboot again if this happens.
On the stock v3 sbitx I had a slightly different experience in that if I booted the radio up with USB headset connected, the headset would work in parallel with the sbitx speaker. Adjusting the volume on the rig makes no diference to the audio out of the USB headset currently. The headset has its own volume control in my case, this also changes the volume on the sbitx speaker as well in my case.

this command produces better output in my headset than I get from the sbitx speaker:

arecord -D "plughw:CARD=Loopback,DEV=1" -f cd | aplay -D "plughw:CARD=II,DEV=0"

Just need to increase the volume to it now, perhaps using the rig volume control to allow the headset volume control the local control for fine adjustment

A step in the right direction me thinks

Still testing
Regards
Paul G0KAO

Hi Dave,

I've being using gnuradio-companion too for simple testing.

I committed some .grc files here, which might be useful:


Cheers,
Rafael

Hi Dave!

And you can do something similar to test the tx, just enable the audio tx path with my sbitx-core (for example) and use "ptt_on" command:


Then you'll be able to slowly rise alsa Master volume until you see power. Play something like this:

ffmpeg -f lavfi -i "sine=frequency=24000:sample_rate=96000:duration=0" -ac 2 -map_channel -1 -map_channel 0.0.0 -f alsa? hw:0,0

Farhan sbitx is very bloated for simple testing.

Cheers,
Rafael

Double or triple LOG saving
I would like to prevent double or triple saves from multiplying in my LOG file.
This happens when another 100 watt weak signal is superimposed on my 10 watt signal.
Then the station can't pick up anything from my signal.
These cases occur in the crowded band, when one period appears to be a clear frequency,
while in the next another finds the empty space. In this case, the connection that normally takes 2 minutes can take up to 6 minutes.
In this case, the program will enter the connection in the LOG at least three times.

I look for the option in vain with AltGray-Q and R combination (\r) to see if my transmission frequency is still empty, if it stops in the next moment.
--
Gyula HA3HZ

Yes, this is a good idea, the Compression level should be adjustable.
It's a shame that the availability of LOG has changed since the current working LOG, so it is not available with tools.
--
Gyula HA3HZ

开云体育

Looking good, curious, is the Compression level setting a hidden setting not available on the front panel?

More discoveries and features to be added to sBITX Manager at some point!





-JJ

And here it is working on the sBitx..

My Apologies.. here are the CORRECT sound card settings..

Here are the settings for JS8Call..








-JJ

On Mon, Jan 29, 2024 at 06:09 PM, Nate Moore wrote:

The use case involves pat/winlink with ardop, js8call, and all the modes that don't exist as part of the sbitx software package.

Following your directions to attempt to get wsjtx going still has me at a dead stop

In general, I expect to see hamlib running, as well as rigctl running.

?

It looks like the sbitx executable itself has these functions baked in, rather than building off the existing packages?

?

Or, again, am I completely not understanding what's being conveyed?

Here is the procedure:

1. Start sbitx and wait at least 30 seconds for it to build the network loopback connection
2. Set the mode to digital
3. Open your third-party app
4. Configure as seen in the screen shots below.

You can also check the port status with: netstat -lntp

Here are the settings..







As far as the rig.xml file is concerned.. I have been meaning to convert it to a standard xml format at some point and rewrite hamlib.c to work properly.. Just haven't travelled down that rabbit hole yet :)? I am happy to see someone else who is interested in this like me!

FWIW - You can change the inet address on line 207 in??to 0.0.0.0 and recompile the sbitx code to make the current hamlib instance routable outside the transceiver.. It is a very temperamental connection, so be warned. It was one of the first things I tried before I created?.?


-JJ

On Mon, Jan 29, 2024 at 07:20 PM, Nate Moore wrote:

Looks like we need a rig.xml () or to at least define what the values are so we can take advantage of them?

I have set up fldigi from scratch when I moved off of the Buster image that came from the radio and went to Bulleye.

The setup is basic:


?
Again I suggest you check the address:port settings.

You should be able to do the most basic stuff like changing frequencies and switching from rx to tx but not much more.

Once that exists then flrig can ride on top of fldigi (which is already functional) and then the rigctl functions from other packages can proceed as per normal, passing it on down the line to get to the sbitx SDR.

We do know the audio ports, we just need the serial ports for controlling the radio.

Once you get to sbitx, there isn't a lot of functionality there to be had.? It may not be able to answer some of the questions flrig ( or grig, for that matter ) ask.

There is no serial port to be had or to be used.? It's hamlib net rigctl or nothing.

--
Regards,
Dave, N1AI

On Mon, Jan 29, 2024 at 07:09 PM, Nate Moore wrote:

In general, I expect to see hamlib running, as well as rigctl running.

I did, too.

You might want to use this forum's search feature to look for posts by N1AI about the software's robustness and completeness.

TBH I don't think it'd be a big challenge to do a full hamlib implementation, and was surprised that no one has done one yet.

It looks like the sbitx executable itself has these functions baked in, rather than building off the existing packages?

Yes.? If you can read code as JJ said you can look at??and see what it has, or what it lacks.

Did you use the address 127.0.0.1:4532 to connect ?

With sbitx running on my radio, I can use this address and use the 'f' command to get the current frequency back:

?
--
Regards,
Dave, N1AI

On 1/18/2024 2:27 PM, David Cutliff wrote:

I finished the sBITX? V3 case. I found the enclosure on AliExpress. I cut some holes, made some 3-d printed parts and put it together.? The radio is now safe from falling objects and fat fingers.

On Mon, Jan 29, 2024 at 04:44 PM, Paul wrote:

Question - is Loopback_2 used by sbitx?

I don't think so.? gives:



So we have plughw device 0 used for the codec, 1 and 2 used for loopback, leaving the third loopback (numbered 3) unused.


The same search gives a hint of how they get used and how they get created:



Line 20 creates three of them, placed at indices 1,2,3.

Line 14: I found it was important to use the full address:port ( 127.0.0.1:4532 ) not just 127.0.0.1?

I edited the wiki page posted earlier so it has this update.

If yes, could we use this one to route analogue audio I/O from card 0 (audioinjectorpi) on SBITX to another audio I/O device such as a USB headset or Bluetooth headset?

Yes.? Below is a proof of concept.

After connecting my USB headset I ran the command again:

pi@sbitx:~ $ aplay -l | awk -F \: '/,/{print $2}' | awk '{print $1}' | uniq

audioinjectorpi

Loopback

Loopback_1

Loopback_2

II

?

Mine gives:

These suggest it looks promising, the devil is in the detail

Great, I get to play satan!

I am trying to avoid the use of PulseAudio as that has been replaced in newer distributions using Pipewire and Wireplumber, however both of these sit on top of ALSA. Based on this will focus my efforts on using Alsa if possible to minimise complication. Might not be possible but it is a starting point with help from the references above.

Research continues - if I get the answer and tested, it will be added here to begin with and then the wiki page as a Howto
If anyone already solved it then please add to the topic.

I've done a small proof of concept to play sound from sbitx's loop device out to my usb sound card.

What I did to try to make progress was to set up and test wsjt-x using the settings in the wiki page posted earlier.

That told me what device names to use.

Then I tried a few things but in the end what worked for me was to set up a gnuradio flowgraph using its audio source and audio sink.

This is what it looks like:


?
The stuff in the bottom right shows the variables I created, the same stuff is in the text under each variable block.

To be honest I guessed incorrectly based on what wsjt-x refers to as sound card input vs output.??

I used the 'QT GUI Sink' to show a FFT and waterfall of the data and changed names around and it worked.

This is what is known as the FAFO method (f-around, find out).

Then to show it worked, I moved over to the linux CLI and did:

$ arecord -D "plughw:CARD=Loopback,DEV=1" | aplay -D "plughw:CARD=Device,DEV=0"

Looks like we need a rig.xml () or to at least define what the values are so we can take advantage of them?

Once that exists then flrig can ride on top of fldigi (which is already functional) and then the rigctl functions from other packages can proceed as per normal, passing it on down the line to get to the sbitx SDR.

We do know the audio ports, we just need the serial ports for controlling the radio.

?

(Or, again, am I way off base? )

The use case involves pat/winlink with ardop, js8call, and all the modes that don't exist as part of the sbitx software package.

Following your directions to attempt to get wsjtx going still has me at a dead stop

In general, I expect to see hamlib running, as well as rigctl running.

?

It looks like the sbitx executable itself has these functions baked in, rather than building off the existing packages?

?

Or, again, am I completely not understanding what's being conveyed?

The challenge - I and many other users want to be able to use a headset for the phone modes in the sbitx e.g. USB headset or a Bluetooth headset.
Logically the problem is similar to the routing of audio for the digital modes from the audioinjectorpi sound card to/from the software used for the digital modes.

The soundcards identified in the sbitx using the command aplay -l | awk -F \: '/,/{print $2}' | awk '{print $1}' | uniq?generates on the sbitx:

Think I might have been working it too hard with too many windows open trying to solve an audio routing challenge, swapped the 2GB pi out for my 8GB pi as it was grinding to a halt.
Audio challenge is trying to allow the use of a headset, either USB or Bluetooth for SSB, working on USB solution first. Think I have a possible method but not sure, still researching
Regards
Paul G0KAO