I'm asking for help figuring out the qsy and ptt functions. How that works, etc. Normally those would be profiles defined in rigctld/hamlib, but the way that the sbitx system is setup, it's a limited version rather than the full version and defined configurations like we see with other radios.

Hi, Nate.

Are you comfortable with the level of information in?/g/BITX20/message/108544??

It is showing that QSY works.

The 'rigctl' command line utilitiy plays the role of 'pat', both are hamlib clients.

The sbitx application is a hamlib server, and they are using 'hamlib net rigctl' to communicate.

The rigctl utility does this via '-m 2' on the rigctl command line.

GUI apps such as wsjt-x do this by the drop-down menu box in the 'radio' config tab that needs to be set to 'hamlib net rigctl' instead of Icom/Yaesu/Kenwood/etc.

I presume 'pat' has such a drop down?

You are right that the commands that sbitx will respond to are quite limited, but there is enough there for 'wsjt-x' to work, hopefully the same will be true of 'pat'.

Line 158 in the code listing says any command starting with 'T' and having a '0' in it will be interpreted as 'ptt off'.

Conversely any command starting with 'T' and not containing '0' is interpreted as 'ptt on'.

The code also shows it supports the commands V, v, m, s, t, and q.

These commands are described in the command section of the output of the linux command 'man rigctl'.

The support for 'm' is, ahum, janky, it always says it is USB mode, so the operator better be in USB mode when 'pat' or 'wsjt-x' runs!

I think 'rigctld' will operate the same way it does on other platforms.

After reading the man page, I believe if you run:

$ rigctld -m 2 -r 127.0.0.1:4532

... in its own Terminal, then rigctld will forward any requests it hears to the sbitx application.

You don't need to set any of the rigctl -p / -P? / -d / -D options related to PTT or DCD.

Refer to the following:

The PTT/DCD things only apply if you are working with a (real or emulated) serial port.

Sbitx has no such thing anywhere.

The sbitx app implements "hamlib net rigctl".? It accepts and responds to network packets with QSY or PTT requests, then does the right thing to make those things happen i.e. it asserts GPIO signals that are interpreted by the sbitx hardware that force it in and out of transmit mode, or sends the right signals to the frequency synthesizer chip to change the frequency.

Again, there is no serial port anywhere to be seen, it's all done via network commands.

I'm emphasizing this because several people haven't seemed to understand this, they keep looking to find serial ports that simply do not exist.

So, I think you should be able to start the sbitx app, then start rigctld in a Terminal as shown above, start pat, do what it takes to configure it do 'hamlib net rigct' (or mode 2 if numbers are used to pick rig control mode), then pat should be able to do QSY / PTT.

If not, as the black/white text shows, you can use -v (one 'v') or -vv or -vvv or -vvvv (more v's) on the rigctld command line to get increasing amounts of debug info printed to the screen.

If it doesn't work, it'll probably tell us that 'pat' sent some command to 'rigctld' which got forwarded to the sbitx app, and the sbitx app didn't support the command.

If so, well, then the sbitx code must be changed...?

But there's a good chance it will work, as long as 'pat' only sends simple commands.

We know this because 'wsjt-x' does work.

That's the point I'm trying to emphasize in?/g/BITX20/message/108543?....
?
--
Regards,
Dave, N1AI

I don't want to turn this into an OS war discussion, or a softmodem war discussion. It will not be a mutually productive discussion.

Sbitx is complicated to me.

I'm asking for help figuring out the qsy and ptt functions. How that works, etc. Normally those would be profiles defined in rigctld/hamlib, but the way that the sbitx system is setup, it's a limited version rather than the full version and defined configurations like we see with other radios.

I am absolutely willing to take care of the pat and ardop softmodem. We can even explore other softmodems once we get that piece working, including vara on box86 running in wine, but it's gotta be a crawl/walk/run.

The crawl stage is where we're at, and where I need help.
Who can help me sort out what it'll take to get the ptt/qsy/etc going?

开云体育

开云体育

As I brought up in another thread about 73 Linux, and was eloquently pointed out.
Part of this is also about setting expectations.

There is a VERY GOOD Winlink client available for the Raspberry Pi platform called "PAT" (getpat.io)

It supports the ICS forms (and others) that the Winlink team relies on so heavily, and runs in a web browser for the UI over a fat client that needs WINE.

Just like Winlink, it does not have it's own softmodem built in.

Pick a softmodem. Any softmodem. Rigctl already exists, in a limited fashion. Audio ports have already been defined. (Thx to Mike!)

We just need to get a softmodem going that can support qsy and ptt. The rest is doable.

?

I, personally, am partial to ardop, and piardopc with it's gui, because it's something we can work on.

I have a functioning model of ardop/piardopc/pat/etc on the R-Pi that runs my ICOM for a reference model. We just need to find the specific hooks that are needed to make it work.

I am willing to engage on this topic. I'm willing to host zoom sessions. I'm willing to work my booty off for it, but I can't do it on my own, and I will need help from folks who understand the way the sbitx is working under the hood much better than I do. I'm also willing to write up the step by step process to make it work, and possibly provide a script.

?

But, I've gotta get help.

开云体育

开云体育

Perhaps what we need is a coordinator to bring the work of all the individuals together, and I am not that person.? Mike's closing sentences in his email are a good idea.? When I get some operating experience with my sBIT I may have ideas of things that would be nice, but my RS274 programming background experience doesn't translate to proficiency with other languages.

Gerry Sherman

Sent by the Windows 11 Thunderbird

Hi Gordon, Dave, JJ, et al

In summary, what Gordon and Dave are both saying is that the sBitx doesn't have a staff of paid/unpaid software engineers working to expand it's capabilities or improve its 'marketability'. Aside from Farhan, that is. So either one is asking Farhan to hire some software engineers to address customer requests for new features and improved interoperability with other software commonly used by ham operators, or you are asking more of the participants in this forum to step up and start writing code for the same reason.

Gordon's comment """Gee, I'll get to writing that when I have time" that might not be the best answer, right?" hits at the core issue - if someone here doesn't do the work, then the answer either has to be "this is a true hacker's radio, the community provides features, functionality, and interoperability that's missing" or "we'll get these features when there is a support/software engineering staff for this radio that provides those features." The former response, of course, sounds better but certainly isn't going to attract any audience that wants to plug in the radio and have it all work.

While the sBitx can provide basic functionality "off the shelf," as this thread describes there is missing functionality that buyers may expect if they go by the information on the HF Signals site. And it should also be noted that if you aren't comfortable with setting up a Raspberry Pi or some basic Linux skills, etc., you will soon tire of trying to make this transceiver work. In that regard, the messaging on HF Signals should offer more insights on the fact that this is not exactly a "plug n' play" radio.

So I'll return to my initial comment which hopefully strikes a productive chord: we should collectively encourage Farhan to hire or contract with some software engineers to address current issues and provide a platform that offers some of the features mentioned on this forum. Alternatively, we should work to foster a community of OSS developers to contribute to this platform with guidance from Farhan. I know several of the folks on this forum are working separately to advance this project - it would be wonderful if they could work together to achieve what individuals alone cannot.