"Reset call history" bug and feature request "-i tcp with host parameter"

[oe4ewa]

First: Well done work! I like it :)

1.) Reset Call Hiistory: Performing will leave at least one (the last) entry. Solution: Replace line 1382 in dsd_ncurses.c

• for (short int k = 0; k < 9; k++)
• for (short int k = 0; k <= 9; k++)

2.) -i tcp with host parameter With every pull i have to change from localhost to real remote host inside coding ;(((

regards and 73

[lwvmobile]

1.) Reset Call Hiistory: Performing will leave at least one (the last) entry. Solution: Replace line 1382 in dsd_ncurses.c

Okay, cool, thanks, I'll have it in the next dev update, just made the change.

2.) -i tcp with host parameter With every pull i have to change from localhost to real remote host inside coding ;(((

Yeah, I never got around to making that a user configurable option, was still deep in testing things and honestly, I didn't think anybody used tcp as of yet. When I get done messing around with this DMR trunking stuff (making progress for sure) I'll get around to letting the user specify the address and port for that.

[oe4ewa]

Comment to 2) dsd-fme runs inside a virtual machine whereas SDR++ runs on the physical host. That's the reason.

[lwvmobile]

Okay, I've updated the dev build to accept user parameters as an optional component of -i tcp, so you can either run

-i tcp if you want the default localhost and port 7355, or you can run

-i tcp:192.168.7.5:7356 if you want to configure or change the host address and port. This should also allow users to have multiple VFOs inside of SDR++ each with a different port that another instance of DSD-FME can connect to.

The tests looks good on my end, but I can't test on every single environment, so let me know if it works for you.

[oe4ewa]

Works like a charme :) It may be great, if you adjust rigctl the same way (host:port) as well as the udp part. Just for fun i'd tryed SDR# with plugins "TcpServer" and "gpredict connector". It seems working. The audio part without any problem. rigctl needs more testing.

[lwvmobile]

Okay, what I'm going to do for now is just have it use the same hostname that tcp audio uses, which will default to localhost, but if you specify a different hostname for tcp input, the rigctl client will use the same address. I imagine that will most likely be satisfactory for 99% of cases, the user would either want to remote control the exact same session of SDR++ or SDR# using mentioned plugins.

The other use case is GQRX, which requires the virtual sink since I can't get UDP audio to work, so would default to localhost as the defacto anyways, I don't think anybody would remote the audio from point a to point b with GQRX via other means and intend to remote control it over the network.

A third potential use case would be to use hamlib which can be configured to control a variety of hardware radio devices and scanners, and the server for it uses rigctl, so that could be controlled with rigctl and the disctap input from the scanner into the soundcard would be the audio input.

[lwvmobile]

Alrighty, I'm going to close as completed now; Both features are implemented, and TCP/RIGCTL seems to work exceptionally well from all the testing I could push at it.