At a minimum just be able to set the frequency and possibly go into transmit mode.

4) Use the 'rigctl' command to send hamlib commands to the sbitx application

5) The following set my sbitx's frequency to 7070 kHz

$ rigctl -m 2 -r 127.0.0.1:4532 F 7070000

Interpretation:
> -m 2 means mode 2 which is hamlib net rigctl
> -r 127.0.0.1:4532 connects to sbitx's hamlib implementation (see earlier post)
> F is the frequency command
> 70700000 is frequency in Hertz

6) Do 'man rigctl' then move forward till you see 'rigctl Commands' to get a list of the commands that should work (but most don't).

7) Cross check this with $HOME/sbitx/hamlib.c to see what is actually possible (hint: not a lot)



So you can see the 'T 1' command puts the radio into transmit and 'T 0' takes it out.

As we used to say in the early days of open source, UTSL (Use the Source, Luke!).

?if there is a way to access the sound card so much the better but external sound cards can be used. ?

Ashhar, I'm not familiar with "Net Rig Conttrol"? ? Is this related?to "rigcat" which is one of the options in FLDGI?? ?

• "rigcat" came from the authors of "fldigi"?
• "net rig control" came from "hamlib" which came from a different group
• it's more correct name is "hamlib net rigctl" based on the "rigctl" program provided by the hamlib-utils package you can install on the Pi
• both "rigcat" and "hamlib" support a programming interface that supports many different kinds of radios underneath
• "wsjt-x" chose to support "hamlib"?
• "wsjt-x" is massively popular
• because of this, most people want/need "hamlib" to work
• SDRs don't have actual serial ports
• the easiest way for a SDR to support "hamlib" is via a local network TCP/IP connection
• the SDR's code can respond to the 127.0.0.1 "localhost" address at a specific port
• the SDR's code then reads commands and writes responses to/from the network
• the applications (e.g. "wsjt-x") include the "hamlib" library in their run time code
• the hamlib support gets configured by user input to either use net rigctl or an actual radio serial port
• based on this choice the hamlib code calls the right functions to get the desired behavior
• "fldigi" supports either rigcat or hamlib so hamlib appears to be the more universal choice

This is a screen shot of wsjt-x selecting hamlib net rigctl:




You can see the "localhost" TCP/IP address (127.0.0.1) followed by ":" then by the port number used by sbitx to support rigctl (4532).

This is a screen shot of fldigi's rig control choices in its config dialog with hamlib selected:


?
Note on the left that you can use hamlib or rigcat or other approaches.

Note the sbitx hamlib.c file is lifted from the 'gqrx' SDR application's source code and isn't a full implementation of hamlib net rigctl.

Sbitx itself does not implement rigcat.? I presume you can set up flrig to be a "rig control gateway" that can use hamlib to talk to sbitx, but I presume the limited implementation of hamlib on sbitx means this probably doesn't work very well.? I did try the "grig" linux program and found it wasn't very useful because sbitx's hamlib support is limited to just the things wsjt-x needs to operate and not much more.

The sbitx community should find a better "radio side" implementation of hamlib net rigctl to lift.? I haven't looked at other open source projects to figure out if there is a better one to lift, but pretty much every SDR radio app that wants to work with wsjt-x needs to have one.? I have used "quisk" with hermes lite 2, maybe it has better support, I don't know.? Also looking at linhpsdr and/or pihspdr may provide a better implementation.

--
Regards,
Dave, N1AI

I don't see any reason why you can not use other ALSA devices. You can - just make sure the order they are brought up so not to confuse userland.

Again, sorry if I'm digging up an old thread, but the topic popped up again.

I think the right approach is not to rely on order of bring up, the answer is to use more specific names.

Use?"plughw:CARD=audioinjectorpi,DEV=0" instead of?"hw:0,0" and you'll always get the Wolfson codec and not someone's HDMI speakers or USB headset.

I wrote about this in??




This is another area where a quick PR could put this to bed quickly.

My problem is like yours, in that my code base has diverged from the afarhan sbitx github repo so much that it's hard to do PRs now.

But maybe I'll find the time to do a PR anyhow, we shall see.

Then we'll see how long it takes for that PR to be merged.

?
--
Regards,
Dave, N1AI

pi@sbitx:~/sbitx $ ./sbitx 
sbitx v3.02
ALSA lib pcm.c:8570:(snd_pcm_recover) underrun occurred
ALSA lib pcm.c:8570:(snd_pcm_recover) underrun occurred
ALSA lib pcm.c:8570:(snd_pcm_recover) underrun occurred
ALSA lib pcm.c:8570:(snd_pcm_recover) underrun occurred
synchronised to unspecified at stratum 3 
   time correct to within 70 ms
   polling server every 512 s
Checking for valid NTP time ...Syncing RTC to 2024-01-31 02:31:28
Mode: LSB
Mode: LSB
Mode: USB
Mode: CW

I just saw you added to the fft code the support for "wisdom" file. How is it created?

I don't understand why we need to create some fft parameters in runtime, during initialization, from the received signal, as far as I understand (sorry my ignorance in DSP matters).

this was on the SBITX speaker, not the headset

hence the headset is more comfortable to listen to once I can get the volume/gain level right and ideally adjustable,

the headset volume is restricted by the amount of gain controlled by the loopback device used to test

so headset volume adjusted to max and it was easy enough to listen on 40m SSB earlier today even weak signals were audible in the headset compared to listening on the sbitx speaker which is a good improvement really.

The logical next step (for playback anyway) now is to get the audio out of audioinjectorpi

into a separate loopback (maybe the unused spare perhaps) as well as the ones used for digital so as not to upset the digital functions that seem to work well so far but volume control fixed in those, need it to be variable in the new Loopback.

While I can figure out and read code to some extent I am not a programmer, logically, I would probably copy the code that drives loopback 0(hw:1,0) from hw:0,0 and use it to drive loopback 2(would be hw:3:0) so that hw:0,0 plays audio output to both loopbacks at the same time. That way the changes to drive another audio device can be made in isolation related to the new loopback device.
Repeat this process again for the Capture side of things if needed but just focusing on play for now.

I did install gnuradio with a view to trying to draw this but bit of a learning curve :-)

The art of drawing in text? :-)
hw:0,0 >>>>>> Loopback,DEV=0 (hw:1,0) >>>>>>>> Loopback,DEV=1 (hw:1,1)? >>>>>>>>>>> Digital Software input
hw:0,0 >>>>>> Loopback_2,DEV=0 (hw:3,0) >>>>>> Loopback_2,DEV=1 (hw:3,1) >>>>>>>>>> Alternative Audio Device input i.e. USB Headset

Sort of makes sense to me but happy to be corrected

开云体育

Why not create an emulation of either a Yaesu or ICOM radio so this radio can be used immediately? ?The uBitx series had this, which made it very attractive

?

Gordon KX4Z?

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

Ideally mic gain ahould be increased and compression only used if really needed and at a fairly low level so wondering how I change the compression setting without the aid of the panel. Bringing it out to your panel makes it more accessible to get adjusted right.

Great work on developing this toolbox panel

Regards

Paul G0KAO