Added PIHPSDR TCP support

[g0orx]

I noticed that the current version of PIHPSDR does not support connection via TCP/IP. I am not sure when this changed as the original version I has TCP/IP support only.

I have made some changes to add a TCP rig_cap to pihpsdr.c and and added an additional model RIG_MODEL_HPSDR_TCP.

-- John Melton g0orx/n6lyt

[mdblack98]

All rigs are supposed to be able to use TCP now. What happens when you run this? rigctl -m 2040 -r 127.0.0.1:4532 -vvvvv Adjust the port for OpenHPSDR's port. Mike W9MDB On Wednesday, June 10, 2020, 10:26:26 AM CDT, John Melton <notifications@github.com> wrote: I noticed that the current version of PIHPSDR does not support connection via TCP/IP. I am not sure when this changed as the original version I has TCP/IP support only. I have made some changes to add a TCP rig_cap to pihpsdr.c and and added an additional model RIG_MODEL_HPSDR_TCP.

…

-- John Melton g0orx/n6lyt You can view, comment on, or merge this pull request online at:   #290 Commit Summary - Added PIHPSDR TCP support File Changes - M include/hamlib/riglist.h (1) - M rigs/kenwood/kenwood.c (1) - M rigs/kenwood/kenwood.h (3) - M rigs/kenwood/pihpsdr.c (199) Patch Links: - https://github.com/Hamlib/Hamlib/pull/290.patch - https://github.com/Hamlib/Hamlib/pull/290.diff — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[g0orx]

The problem is when used with wsjtx it only has the Serial connection showing.

…

-- John

On Wed, 10 Jun 2020, 16:41 Michael Black, ***@***.***> wrote: All rigs are supposed to be able to use TCP now. What happens when you run this? rigctl -m 2040 -r 127.0.0.1:4532 -vvvvv Adjust the port for OpenHPSDR's port. Mike W9MDB On Wednesday, June 10, 2020, 10:26:26 AM CDT, John Melton < ***@***.***> wrote: I noticed that the current version of PIHPSDR does not support connection via TCP/IP. I am not sure when this changed as the original version I has TCP/IP support only. I have made some changes to add a TCP rig_cap to pihpsdr.c and and added an additional model RIG_MODEL_HPSDR_TCP. -- John Melton g0orx/n6lyt You can view, comment on, or merge this pull request online at: #290 Commit Summary - Added PIHPSDR TCP support File Changes - M include/hamlib/riglist.h (1) - M rigs/kenwood/kenwood.c (1) - M rigs/kenwood/kenwood.h (3) - M rigs/kenwood/pihpsdr.c (199) Patch Links: - https://github.com/Hamlib/Hamlib/pull/290.patch - https://github.com/Hamlib/Hamlib/pull/290.diff — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#290 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJEH5KTSOM5EK4LHCMI6JLRV6SS3ANCNFSM4N2PXO3A> .

[mdblack98]

You can put a network address in there too in the serial port box. Mike On Wednesday, June 10, 2020, 10:51:39 AM CDT, John Melton <notifications@github.com> wrote: The problem is when used with wsjtx it only has the Serial connection showing.

-- John

On Wed, 10 Jun 2020, 16:41 Michael Black, ***@***.***> wrote: All rigs are supposed to be able to use TCP now. What happens when you run this? rigctl -m 2040 -r 127.0.0.1:4532 -vvvvv Adjust the port for OpenHPSDR's port. Mike W9MDB On Wednesday, June 10, 2020, 10:26:26 AM CDT, John Melton < ***@***.***> wrote: I noticed that the current version of PIHPSDR does not support connection via TCP/IP. I am not sure when this changed as the original version I has TCP/IP support only. I have made some changes to add a TCP rig_cap to pihpsdr.c and and added an additional model RIG_MODEL_HPSDR_TCP. -- John Melton g0orx/n6lyt You can view, comment on, or merge this pull request online at: #290 Commit Summary - Added PIHPSDR TCP support File Changes - M include/hamlib/riglist.h (1) - M rigs/kenwood/kenwood.c (1) - M rigs/kenwood/kenwood.h (3) - M rigs/kenwood/pihpsdr.c (199) Patch Links: - https://github.com/Hamlib/Hamlib/pull/290.patch - https://github.com/Hamlib/Hamlib/pull/290.diff — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#290 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJEH5KTSOM5EK4LHCMI6JLRV6SS3ANCNFSM4N2PXO3A> .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[dl1ycf]

The point is, that pihpsdr can do both TCP and serial. In this case, one must choose the model as "Serial" and hamlib then automatically falls back to TCP if the "port" is either of the form "a.b.c.d:e" or of the form ":e". Note that "localhost:e" does not work.

This is a limitation of hamlib: a serial rig can fall back to TCP but a TCP rig cannot do serial.

Note further, that recent changes in piHPSDR make an increased time-out in the pihpsdr rig model necessary (see my pending pull request).

Yours DL1YCF.

[mdblack98]

Color me confused. What's different about choosing the TCP version you propose? Don't you still have to put the network address in there? Does seem WSJT-X should allow localhost and do either the real DNS lookup or just substitute 127.0.0.1 for it. I'm just  a little resistant to adding a rig that the system is already capable of doing unless there's a distinct advantage.  Maybe just because it can take the default address? Have you compiled this in WSJT-X and it has some better behavior? Mike On Thursday, June 11, 2020, 10:34:07 AM CDT, dl1ycf <notifications@github.com> wrote: The point is, that pihpsdr can do both TCP and serial. In this case, one must choose the model as "Serial" and hamlib then automatically falls back to TCP if the "port" is either of the form "a.b.c.d:e" or of the form ":e". Note that "localhost:e" does not work. This is a limitation of hamlib: a serial rig can fall back to TCP but a TCP rig cannot do serial. Note further, that recent changes in piHPSDR make an increased time-out in the pihpsdr rig model necessary (see my pending pull request). Yours DL1YCF. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[mdblack98]

It's only a semantic difference in WSJT-X.  It doesn't really make any difference if WSJT-X says "Serial" or "Network" -- it's same input box. Perhaps WSJT-X should just call the box "Device" or such and then it won't matter.  Especially since serial is not the only thing rigs are capable of anymore.  Serial over TCP is also supported. Mike On Thursday, June 11, 2020, 10:34:07 AM CDT, dl1ycf <notifications@github.com> wrote: The point is, that pihpsdr can do both TCP and serial. In this case, one must choose the model as "Serial" and hamlib then automatically falls back to TCP if the "port" is either of the form "a.b.c.d:e" or of the form ":e". Note that "localhost:e" does not work. This is a limitation of hamlib: a serial rig can fall back to TCP but a TCP rig cannot do serial. Note further, that recent changes in piHPSDR make an increased time-out in the pihpsdr rig model necessary (see my pending pull request). Yours DL1YCF. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[dl1ycf]

What John's solution is after is to allow "input boxes" such as "localhost:19090" . The current hamlib "serial to TCP" fallback mechanism cannot cope with that.

So in the current situation if put into the input box (that is, the string in rigport.pathname)

/dev/ttyUSB0 ==> hamlib will try to open serial port (fine)
:19090 ==> hamlib will try to open TCP (fine)
192.168.1.50:19090 ==> hamlib will try to open TCP (fine)
localhost:19090 ==> hamlib will try to open serial port (BAD).

The problem is that until recently, the last option worked when the piHPSDR backend was still TCP-only, so some users might get frustrated why things don't work that used to work.

Alternative:

Of course one could consider an improved "fallback" mechanism in src/rig.c (line 636ff) which falls back to TCP also in the case we have in the input box (aka rigport.pathname) strings like

localhost:19090
my.machine.com:19090

This then would also apply to all other "serial rigs" which are connected via TCP so other users might benefit as well (I know that TS-2000 is frequently used over TCP).
Please check this, but to me It seems this would solve the problem addressed by John and at the same time eliminate the headache (new machine model) of Mike so might be worth considering.

[mdblack98]

Other fixes preclude the need for this. TCP connections now work on all rigs.