开云体育

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