The reason for that question is, that this would allow remote control of flrig over TCP/IP. That might be very useful for remote-stations, but also for my setup:
The hamstack is running on a linux host. Flrig does the TRX control there. VaraC runs in a Windows-VM. This makes it neccessary to pass the CAT device to the VM (and back again when switching modes). While that works in general, its very annoying and causes lots of issues when switching modes often. With XML-RPC support, it would be possible to connect to flrig on the host from the VM via TCP/IP and the whole stack including VaraC would be usable synchronously.
P.S: I'm playing around with SDR Devices on the IF-Out and piping the output to virtual sound devices with just one TRX. That gives the ability to listen to different frequencies with different software simultaneously. I would love to have VaraC an "always on" client, that can be put in TX-Mode with one click. Just to clarify, why XML-RPC support would be a great convenience.
I have a different issue. I would like VarAC to control a rig that is not in its rig list. If flrig were a selection in VarAC, VarAC would be able to control any rig listed in flrig, currently about 70 different rigs, without the need to create the rig controls individually in VarAC. This would increase the type of rigs that would work with VarAC and reduce the development effort. The flrig availability in the rig list in WSJT-X is an example of this.
Is it advisable not to use a serial port splitter for this same reason? flrig and VarAC might be usable in parallel by using a port splitter into the rig. Or possibly with a rig that has two ports.
Many of us are using a virtual com port to allow multiple softwares to share the same com port of our RIG. I use VSPE for example.
This way you can have FLRIG manage your rig and you can have other programs that need direct access to the port to access the same com port in parallel without locking each other.
If your com number is #3, then VSPE creates a "virtual" com port, lets say #10 that is mapped to port #3. But since it is virtual you can define many program to use it simultavoiusly.
I use it for Log4OM, VarAC, WSJTX and HRD. All access the same virtual comport.
So a solution is there. Its up to you to do the extra mile or not :)
i think i will pass on this, i have 3 rigs all managed by different instances of FLRig and i have no interest in putting another layer of complexity on top of that for a single piece of software
Hi guys. I'm sorry but I have no plans for intergating with FLRig. OmniRig or direct CAT. what you can do it use virtual com port and redirect both FLRIG and VarAC using Direct CAT together to the same port. I use VSPE.
OmniRig isn't working for me either, and it always hogs the port from other tools that use the radio. FLRig has very configurable commands and you can see what's going on with the radio on your screen (so if you're running remote like me, you know what's going on). FLRig is also pretty well documented. Please reconsider using FLRig.
I have seen in the release update section, that you are working on flrig support. That's great news!
Are you planning to support the XML-RPC interface too? http://www.w1hkj.com/flrig-help/index.html#ssSERVER
The reason for that question is, that this would allow remote control of flrig over TCP/IP. That might be very useful for remote-stations, but also for my setup:
The hamstack is running on a linux host. Flrig does the TRX control there. VaraC runs in a Windows-VM. This makes it neccessary to pass the CAT device to the VM (and back again when switching modes). While that works in general, its very annoying and causes lots of issues when switching modes often. With XML-RPC support, it would be possible to connect to flrig on the host from the VM via TCP/IP and the whole stack including VaraC would be usable synchronously.
P.S: I'm playing around with SDR Devices on the IF-Out and piping the output to virtual sound devices with just one TRX. That gives the ability to listen to different frequencies with different software simultaneously. I would love to have VaraC an "always on" client, that can be put in TX-Mode with one click. Just to clarify, why XML-RPC support would be a great convenience.
I have a different issue. I would like VarAC to control a rig that is not in its rig list. If flrig were a selection in VarAC, VarAC would be able to control any rig listed in flrig, currently about 70 different rigs, without the need to create the rig controls individually in VarAC. This would increase the type of rigs that would work with VarAC and reduce the development effort. The flrig availability in the rig list in WSJT-X is an example of this.
lack of FLRig makes this unusable for me :(
i operate when not in front of my rig, so FLRig lets me see power, SWR and activate tuning cycles remotely, omnirig don't work for me
also having issues with initial setup so looks like a bust for me, will check in now and again to see if FLRig gets supported later
I would love to see Flrig control implemented. It's my goto app to control my rig. Gives me great control of my 7300 and 705.
I'll just add to the vote for FLRIG. =-D
Thanks for all your work on this program. It's been a lot of fun to use.
Hi guys. I'm sorry but I have no plans for intergating with FLRig. OmniRig or direct CAT. what you can do it use virtual com port and redirect both FLRIG and VarAC using Direct CAT together to the same port. I use VSPE.
OmniRig isn't working for me either, and it always hogs the port from other tools that use the radio. FLRig has very configurable commands and you can see what's going on with the radio on your screen (so if you're running remote like me, you know what's going on). FLRig is also pretty well documented. Please reconsider using FLRig.
For now the focus is OmniRig. Next in line will be Hablib.
Frankly speaking - I don't think I'll go with Flrig. Hamlib has it all.
73