DXLab Commander Server #727
Conversation
This is an initial attempt at a proof of concept. We often see requests for ways to use other applications that need rig control, but if using rig control in QLog it is limited to the typical single connection of the serial port. This adds a basic DXLab Commander Server to QLog so applications like wsjtx can be set to talk to port 52002 using the DXLab Commander radio option. I was curious if it would work and this does seem to be a possible option to be considered.
|
Honestly, I had thought about implementing a "Server" a long time ago. I gradually moved from considering Rigctld to the TCI server. But I have to say, if we go this path, it might get quite complicated. Why do I think so? When I was thinking about implementing Rigctld, I eventually dropped the idea because it’s poorly documented, and unfortunately, the authors tend to change various parameters quite often. I wouldn’t be able to keep up with that. Then I tried TCI. That’s a very nice protocol. I don’t know why it hasn’t become more widespread, because in my opinion it has great potential. Unfortunately, implementing all of it in QLog would be a significant amount of work. It’s not just about getting WSJTX working — among other things, it would also require implementing audio transfer, which is also part of TCI protocol. I’ve also looked into DXLab. But all of these approaches (rigctl, TCI, DXLab) have one problem: the connection will not be used only by WSJTX, which has quite a limited set of commands. The operator will expect QLog to essentially act as a full-fledged proxy between the application and the rig, with the entire set of commands. And this is the reason why I haven’t implemented it yet. Implementing the whole command set, or even most of it, would mean significant changes to the Rig class. And here’s the question: is this really a feature for a logging application? I think not. I know it would save many operators the trouble of configuring another application like rigctl, flrig or something similar, but those applications are specialized in providing rig connection services. QLog should not be replacing them. I would rather help FLrig develop and modernize the GUI than implement this in QLog.That’s my opinion, which I can, of course, change if there’s a compelling argument. Keep this PR open for now. Maybe I will change my opinion. |
|
Yes I agree about rigctld server and TCI (it is a great protocol) being not the ideal choices for something like this, they are truly meant to duplicate a rig and all. I had thought this method was a better option, since it is much simpler and documented. It my opinion it was originally implemented for basic interoperation between applications not a full scale rig control method. I do understand the reservation. It was just an idea I had the other day and I was curious if it could be easily implemented for a proof of concept to consider. |
|
What made you move toward being the server instead of connecting to a DXLab Commander server? With qlog just being a client... same as connecting to rigctld. |
|
As much as I hate to say it, a lot of other logging applications offer that to ease connectivity to WSJTX and other applications. I felt like something like this would be good or the other option I thought about but haven't worked on a POC would be like a checkbox in QLog/HamLib to launch and connect to a rigctld session. Instead of trying to build our own rigctl server just launching it. |
|
Michael is right. Operators don’t want to run additional applications to control the rig. There have already been several such requests here to implement "Rig" Server. Honestly, I think this doesn’t belong in a logging application, but the rest of the world seems to think otherwise. |
|
I went over to the Huntsville, Alabama hamfest this weekend and just got home. But before I left I did play a little with getting QLog to have a checkbox for hamlib to launch and connect to a rigctld instance, I did get it to work, not with out issues but it was likely my poor coding. But it did work enough to make this it may be the better option than this server. Since it would be less maintenance for us since rigctld would be doing all the work. I think the really hardest part would be how to have the rigctld application added and signed on MacOS and however Linux may want it. All of the command line parameters are already accounted for and just needed to be passed. I hope this makes sense what I am saying. |
This is an initial attempt at a proof of concept. We often see requests for ways for operators to use other applications that need rig control, but if using rig control in QLog it is limited to the typical single connection of the serial port or trying to walk someone through using rigctld. This adds a basic DXLab Commander Server to QLog so applications like wsjtx can be set to talk to port 52002 using the DXLab Commander radio option. I was curious if it would work and this does seem to be a possible option to be considered. It does support two way frequency updates, mode setting and PTT. If the rig supports power reading it should pass through as well.