开云体育

On Sat, Mar 9, 2024 at 01:13 PM, Jon / W2JON wrote:

I added this modification to my radio. and it works vert well.?
I did need to turn the sox level up to 50 for my headset but other than that it is a very straight forward and useful add on
I just threw a .sh script to my desktop to fire it off.. when the headset is unpluygged the process dies clean?

I whipped this up.. Need to figure out the routing of USB Mic to it now..




I believe all future development should focus on the USB audio interface since there is a wide variety of USB audio devices that could be used without worrying about voltage and impedance matching. I have both a gaming USB headset and Sabrent USB soundcard that work with sBitx now.??



-JJ

Not got the microphone part of the headset working yet and from initial tests that may take a bit longer but hopefully not too long :-)
In principle the command should work in the opposite direction in that we record from the USB microphone and direct it to the loopback interface that would be used for the mic output from the digital software.

I have now modified my /etc/rc.local file to have the following line in to remove the excess loopback interfaces:
sudo nano /etc/rc.local
add the following if not already exists or leave your own as it exists to your preference, this is my approach you can use different names if you want
modprobe snd-aloop enable=1,1 index=1,2 id=sbitxdigiout,sbitxdigiin

Note that the default as supplied line looks like:? ??modprobe snd-aloop enable=1,1,1 index=1,2,3 //this provides 3 loopbacks named Loopback, Loopback_1 and Loopback_2 with Loopback_2 being unused.

sudo nano /etc/modprobe.d/alsa-base.conf command to ensure that the base config fixes the USB device with an interface ID and the priority for the default interface to ensure audio works?
Ensure these lines are added to this file to achieve the correct priority:
options (efault) index=-2? ? ? ? ? ? ? ? ? ?//note the line is correct without the 'd' in default, this sets the priority for the default audioinjectorpi card to be top of the list
options snd_usb_audio index=5? ? ? //this sets a priority and index reference for the USB device so we can refer to it as hw:5 or plughw:5 or CARD=5?

Following these changes my interface list looks like:

or using a different view:

In principle a startup script to run sbitx with USB support might look like:

pi/home/sbitx/sbitx
arecord -D "plughw:CARD=Loopback,DEV=1" -f cd | sox -v 25.0 -t wav - -t wav - | aplay -D "plughw:CARD=3,DEV=0"??
the command required to take the USB microphone input to the 2nd Loopback interface that feeds the radio, need to work this out yet. While my logic makes sense, the reality doesn't work with the headset I have.

The PTT would be a manual switch using the onscreen TX/RX buttons where permitted for the mode being used or wire a PTT switch to the physical microphone input for now.
Assumes that sox is already installed of course

Regards
Paul G0KAO

if you renamed the Loopback interfaces as I did then the digi software interfaces will need to be reconfigured to use the new names, the DEV value doesn't change, it is just the CARD = value that needs to change to reflect the new names for the loopback devices, mine works fine with the new names, to illustrate:

Original config for line out to JTDX for me was plughw:Loopback,DEV=1
now with my config it is plughw:sbitxdigiout,DEV=1

Original config for line in from the JTDX was plughw:Loopback_1,DEV=0
that is now plughw:sbitxdigiin,DEV=0

I had FT8 contact this morning using JTDX with that config this morning UK time, if you look at pskreporter for my call you will see where I was being heard this morning running 2w from sbitx, even managed to be heard east coast America, pleased with that from a mag loop sat on the lounge window sill :-)

if you used different names for the loopbacks then just replace as appropriate

Hope that makes sense and helps

Regards
Paul G0KAO

As an aside, I have wired a pc headset to the mic and earphone sockets, making a harness to take the pc headset 3.5mm TRRS plug and split it between the 3.5mm stereo connectors on the radio.
The little box used to take the socket and split the connectivity has a ptt push button added and a 15k resistor as per Gordon's comments elsewhere in this group so that I can use a new electret on the boom of the headset as the original mic output from the headset was not high enough. I already had the headset so no cost other than the new electret which I had already fitted to the stock supplied mike and used over a number of activations until it suddenly stopped working. It forced me to move the electret to the pc headset. Have had a couple of contacts with it on 40m from home, just need to try it out in the field now on activations.
just monitoring ft8 on 20m again

Regards
Paul G0KAO

Just realised my typo mistakes, the configs should read plughw:CARD=Loopback,DEV=1 etc and not as I typed in the message above, make sure CARD= is added to the appropriate config entries

Thanks for the overview Paul. I'm running the same as you now.

Bit of an update for the microphone path from USB headset, could be my headset but doubt it.
Looking back over notes and other posts about the audio paths I found this test command that had been submitted by another user:

arecord -Dplughw:CARD=audioinjectorpi,DEV=0 -t wav -f S32_LE -r 96000 -c 2 -| sox -t wav -b 32 -e signed -c 2 - -t wav - remix 2 gain 10 | aplay -D plughw:CARD=audioinjectorpi,DEV=0 -

If you run this command without the sbitx app running from within the terminal window, you will hear what you say into the microphone echoed into the earpieces of the headset connected to the physical connections with a slight delay. You can use a headset and the fist mike if that is what you have in order to do this test.

I repeated the test using my USB headset (my Headset called II in the card listings, or 5 could be used instead as the index to the device in my case):
To run the next command you do need the sbitx app running.
arecord -Dplughw:CARD=II,DEV=0 -t wav -f S32_LE -r 96000 -c 2 -| sox -t wav -b 32 -e signed -c 2 - -t wav - remix 2 gain 10 | aplay -D plughw:CARD=5,DEV=0 -

The audio picked up by the microphone is played in the earpiece of the headset with a slight delay.

Logic says that if we replace the aplay interface with the same interface used by the digital software CARD=Loopback_1,DEV=0 or in my case CARD=sbitxdigiin,DEV=0 then in theory the audio from the microphone should be transmitted out of the sbitx via the same path as the digital software uses.

Sadly this does not appear to be the case for me, I hear my voice echoed back to me but nothing goes out of the radio into the dummy load :-(

I have tried various combinations but just don't seem to be able to get the USB mike audio into the sbitx app yet.

Regards
Paul G0KAO

Just to add, you don't need the sox section of the command, it works the same i.e. audio in from mic is echoed into the earpiece without any delays

pi@sbitx:~ $ arecord -Dplughw:CARD=5,DEV=0 -t wav -f S16_LE -r 96000 -c 2 -| aplay -D hw:CARD=2,DEV=0 -

Pau, would you have any different results if you match the resample rate of arecord with the sbitx input loopback sample rate?

Have tried all combinations I can think of, the basic issue is I think a software one. The software is not written to take alternative sources of input other than the digital software via the loopbacks when the digital mode is selected on the sbitx. I think ultimately the application will need to be altered in order to accept alternative microphone inputs for SSB modes.
The software as written from my observations anyway, doesn't lend itself to changes to modules as there isn't for example, a specific I/O module that could be altered to add/remove inputs/outputs to feed the rest of the radio software.
I think this could make a big difference if a specific I/O module could be created that allowed a choice of I/O especially for SSB modes which is where it matters the most to provide the needed flexibility. However this is probably a major surgical operation for the software and beyond my current capabilities.
I have a physical headset I can use but disappointed I could not make a full USB capability work, for the moment anyway.
The fist microphone supplied failed on me on a portable activation, suspect it is either connector or cable issue as the insert I used worked fine on the headset I have now modified with it.

I am going to take a break from this issue for now and continue to put the radio through its paces on SSB using a pc headset connected to the connectors on the side.

Regards
Paul G0KAO

On Sun, Mar 10, 2024 at 01:51 PM, Paul wrote:

Have tried all combinations I can think of, the basic issue is I think a software one. The software is not written to take alternative sources of input other than the digital software via the loopbacks when the digital mode is selected on the sbitx. I think ultimately the application will need to be altered in order to accept alternative microphone inputs for SSB modes.
The software as written from my observations anyway, doesn't lend itself to changes to modules as there isn't for example, a specific I/O module that could be altered to add/remove inputs/outputs to feed the rest of the radio software.
I think this could make a big difference if a specific I/O module could be created that allowed a choice of I/O especially for SSB modes which is where it matters the most to provide the needed flexibility. However this is probably a major surgical operation for the software and beyond my current capabilities.
I have a physical headset I can use but disappointed I could not make a full USB capability work, for the moment anyway.
The fist microphone supplied failed on me on a portable activation, suspect it is either connector or cable issue as the insert I used worked fine on the headset I have now modified with it.

I am going to take a break from this issue for now and continue to put the radio through its paces on SSB using a pc headset connected to the connectors on the side.

Regards
Paul G0KAO

I understand where you are coming from. This product seems like a never-ending platform for improvements and it stinks that we seem to hit brick walls at every turn. I am thankful that you started the thread to get our gears turning and experiment with different options.?


-JJ

On Mon, Mar 11, 2024 at 11:29 AM, JJ - W9JES wrote:

This product seems like a never-ending platform for improvements

JJ and others ... I thank you for your input and support of this amazing project ... personally I am enjoying the learning curve ...

I thought that it may help to read what "the boss" recently said in this thread -->?Re: Remote SSB TX (WebUI) (groups.io)

looks like changes are on the way ... let's stay tuned ...
?
--
Pete VK3PYE

On Sun, Mar 10, 2024 at 08:24 PM, Peter VK3PYE wrote:

JJ and others ... I thank you for your input and support of this amazing project ... personally I am enjoying the learning curve ...

I thought that it may help to read what "the boss" recently said in this thread -->?Re: Remote SSB TX (WebUI) (groups.io)

looks like changes are on the way ... let's stay tuned ...
?
--
Pete VK3PYE

I am happy to announce that I have successfully routed USB speaker audio AND USB microphone audio to the sBitx using my 64 bit beta 2 build. I am currently building an app for this and will share it when ready for the masses.



-JJ

Hi Scotty
There isn’t a simple answer to your question really. Before I say any more, it might be worth creating a separate thread for your question if it is related to the sbitx specifically, that way you will get some more specific answers from a wider selection and more experienced than I :-)
It depends really what you want to learn about, I think elsewhere links have have been posted for good books on C/C++ programming which I think is the main language used for the sbitx. There is more to learn about the computing aspects of the sbitx besides the programming language used for the app itself, for example understanding basic Linux commands to use within the terminal window on the Raspberry Pi itself, scripting to create startup scripts to maybe combine running the sbitx with some commands to facilitate using a USB headset as an example.
In a way the sbitx is a great way to learn about the computing side of things as well as the radio side and how they work or could work together in a way that suits the user without being prescriptive.
Sorry I didn’t answer your question directly but it is a tricky one because ultimately it depends on what and how much you want to learn, Google really is your best friend in this regard, it is my goto tool to solve a particular problem at the point of need. This way I learn from solving the problem I have and then pick up other knowledge along the way.
Hope it helps
Paul G0KAO

Hi Scotty,

I agree with Paul that a separate topic would be a good idea.? It is impolite to "hijack" another's topic.? Follow-up questions would be best done on that new topic.

To get started on the software side, I would suggest starting with the Raspberry Pi (RPi) documentation and help topics:

This will help you with the tools available on the RPi and introduce you to the basic Linux OS used by the sbitx.

The C/C++ help is also available online.? Search for that.? Note that the sbitx uses the gcc compiler, so help tools specific to that compiler would be the best.

The digital signal processing theory would be another topic that could help understand how the SDR parts of the sbitx work.? I use this:


The above is a firehose of information.? Any follow-up should be on a new topic.

Have fun and learn a lot!

73
Evan
AC9TU

More progress!

/g/BITX20/message/109845?


-JJ

Here is the app for testing.. Download it then change it to be executed by Anyone.

Let me know how it works or doesn't work. This is ONLY for the 64 bit build. Make sure you have sox installed or it will fail. sbitx must be opened first. Your USB mic or speaker or headset must be connected before powerup.

-JJ

Awesome! I’ll grab it first thing in the morning!