Ben Cahill napsal(a):

Hello Jaroslav,
I'm excited to hear that you got Remote Quisk working over the internet!? That is good news!? Especially with the setup you describe!

I am still playing with it, and it's really exciting, you did pretty good job. I can see big potential here for future extensions, e.g. somebody could write front end web client.

With apologies, I do not know much about the aspects of internet communications that you describe, but I'd like to learn.? The idea of using a domain name sounds like a good idea.? Can you recommend a good source for information on how to set up my Remote computer (Raspberry Pi) to be a Remote Quisk server with a domain name? And, thanks for your other observations and comments.? I'll need to learn some more before I understand them all.

You need some dynamic DNS (DDNS) service provider (like e.g. noip, cloudflare, ...) or own domain name. RPI tutorials are online, e.g.:

The idea is that the client running on the RPI will register the public IP it gets from the DHCP with the DDNS service provider so the DNS will point to the correct IP if somebody tries to resolve it. Of course you need public IP from your internet provider (it's usually for some small additional fee, because IPv4 IPs are sparse today). Static IP and static DNS records will also work, but it's even more expensive solution.

On the quisk side it seems it doesn't need much to fix it. The TCP control channel works correctly even with the domain name. Problem is with the UDP. It's probably missing DNS resolver call somewhere in the code, because the AUDIO streams tries to connect to IIRC some nonsense IP 88.65.0.0 (IP with trailing zeroes). So far I haven't checked the code, no time on the vacation :)

For the spectrogram it will probably need some NAT traversal, because you usually have the control-head behind the NAT, e.g.:

control-head (local IP:192.168.1.2) <--NAT--> router (public IP:44.12.64.35) <--> INTERNET <---> remote-rpi-with-HL2 (public IP:46.12.35.22)

IPs used in the example are just for illustration. If you want to send UDP packet from the 46.12.35.22 to the control-head (192.168.1.2) it will not work, because 192.168.1.2 is the local IP and if you use the public IP 44.12.64.35, the router (44.12.64.35) will don't know what to do with the UDP packet. The solution is to periodically send heartbeat UDP packets (with some arbitrary data) from the control-head (192.168.1.2) to the remote-rpi-with-HL2 (46.12.35.22), e.g. each 10 seconds. Then most of the routers will correctly forward the returning UDP packets with the same port combinations to the control-head (192.168.1.2).

Regarding your issues with digital TX, when using any ac2yd/remote_*.py file, the remote radio expects *any and all* audio used to modulate TX (not just "mic", per se) to come from the Control Head.? This include digital modulation, as well as any audio files you might want to play for TX.? In the current design/implementation, there is no audio mixer to blend sources from the Remote computer with sources from the Control Head, and no option to select Remote vs Control Head TX audio source. As you discovered, to use an audio source that resides on the Remote computer, you must not use any ac2yd/remote_*.py file.? If you want to take a look at the code involved, search sound.c and ac2yd/remote_common.py for "remote_control_slave".

This took me a while to realize what's going there, because I was able to work myself with the USB/CW, but not with the FT8 :)

This does not explain your troubles running wsjtx from the Control Head.? I'll try to set up to try that here ... I confess I have never run any digital modes!? :-0

I am also experimenting with the ROC pipewire streaming modules. Which can easily forward your pipewire/pulse streams over UDP with FEC (forward error correction). An attempt to get it into Fedora:


73! Jaroslav, OK2JRQ

Thanks, and enjoy your vacation!
-- Ben, AC2YD --
On 9/13/22 03:03, Jaroslav ?karvada wrote:

Jaroslav ?karvada napsal(a):

Jaroslav ?karvada napsal(a):

Hi,

I am now on vacation and I am playing with the quisk-4.2.6 AC2YD remote control feature. It's pretty cool, really thanks for it, it fully replaced my VNC/pulse(pipewire) streaming modules hackery. At the moment I have pretty crazy setup:

resort_apartment --poor-resort-wifi--> poor_resort_router --ISDN--> Internet --ethernet--> my_router --my-home-not-so-good-wifi--> host_computer --gbit-ethernet--> HL2

It's all IPv4 and I am on the NAT from the both internet sides (i.e. the resort is behind NAT and my home host_computer is behind another NAT). The great thing is that the remote control works even under such conditions and is very usable.

Problems I have discovered so far:
- in the documentation it should be mentioned which ports are TCP (4585) and which are UDP (4586, 4587, 4588), this would ease the port forward setup on the router.
- clipping is not shown on the control-head (normally the frequency box turns red on the remote), i.e. you don't know when you should lower the gain.
- REMOTE_ADDR currently has to be IP, not the domain name. If the domain name is used, remote control works, but there is no sound, because it tries to UDP connect to the nonsense IP addresses. I think it should also work with the domain name, then you could setup DDNS, port forward and stop hassling with the dynamic IPs.
- even with the port forward set and correct IP in the REMOTE_ADDR, there is no waterfall on the control-head. I think it's because the remote tries to UDP connect to the control-head on the port 4586, but it fails because the control-head is also behind NAT. I think the control-head should send periodically UDP packets to the REMOTE_ADDR:4586, most NAT routers will then correctly return the incoming UDP packets on the same port.

I workaround most of the problems with the OpenVPN UDP tunnel

73! Jaroslav, OK2JRQ

One more problem noted:
- SWR / Power are not displayed on the remote if the control-head is disconnected. The PA current shown on the remote seems to be incorrect. On the control-head (if connected) are displayed correct numbers.

73! Jaroslav, OK2JRQ

Another problem:

- with the no control-head connected if I run SW using QuiskDigitalInput on the remote end, there is no signal going out of the HL2. It seems the HL2 TX OK, but it's like there is a zero volume on the QuiskDigitalInput. I checked the pulse mixer settings and the volume is set to the 100%. The 'Config -> HL2 -> Digital TX0' is set to the 'pulse: Use name QuiskDigitalInput'. Contrary, the QuiskDigitalOutput is working as expected and the RX audio is going through it OK in the DGT-U mode. I am using Fedora 35 and PipeWire.
- with the control-head connected if I run the same SW using QuiskDigitalInput (e.g. wsjtx), but this time on the machine running the control-head, it's even more weird. The quisk correctly signals TX (on both control-head and remote), but the radio doesn't switch to the TX mode and is still receiving - RX audio is going all the time without interruption from the QuiskDigitalOutput.

If I change 'Config -> HL2 -> Hardware -> Hardware file path' back from the 'ac2yd/remote_hermes.py' to the original 'hermes/quisk_hardware.py', the QuiskDigitalInput starts working as expected

73! Jaroslav, OK2JRQ

Hello?Jaroslav,

->> with the no control-head connected if I run SW using QuiskDigitalInput on the remote end,

The AC2YD remote feature was designed to send back demodulated audio, not samples, in order to reduce the bandwidth to a minimum. Running digital modes on the control head would require more data streams for digital in/out. Also, note that recording samples to a file fails for the same reason. And most hardware config settings are inoperative on the control head. I can add some more interaction like a clip indicator, but complete control, such as adding recording samples, is a never-ending list.

Because of the low bandwidth and the time stamps on the CW keying, the AC2YD feature achieves fast classic ham radio over a network. For digital modes, it seems workable to run everything on the remote and control it with remote terminal software because fast response is not required.

Jim
N2ADR

Hello?Jaroslav,

These are excellent improvements and I will add all of them to the next release.

Jim
N2ADR

Thanks for update version 4.2.6

Upgrade on Raspi 4 (Radio HL2) and Linux Mint (Control Head) without any problems. Both Quisk has Large Screen configured.?

Flipping with CWU <-> CWL don't do anything. My knowledge to CW isn't perfect, but I through it should jump up and down the signal frequency?

73 Jan

Hello Jaroslav,

I'm excited to hear that you got Remote Quisk working over the internet!? That is good news!? Especially with the setup you describe!

With apologies, I do not know much about the aspects of internet communications that you describe, but I'd like to learn.? The idea of using a domain name sounds like a good idea.? Can you recommend a good source for information on how to set up my Remote computer (Raspberry Pi) to be a Remote Quisk server with a domain name? And, thanks for your other observations and comments.? I'll need to learn some more before I understand them all.

Regarding your issues with digital TX, when using any ac2yd/remote_*.py file, the remote radio expects *any and all* audio used to modulate TX (not just "mic", per se) to come from the Control Head.? This include digital modulation, as well as any audio files you might want to play for TX.? In the current design/implementation, there is no audio mixer to blend sources from the Remote computer with sources from the Control Head, and no option to select Remote vs Control Head TX audio source.? As you discovered, to use an audio source that resides on the Remote computer, you must not use any ac2yd/remote_*.py file.? If you want to take a look at the code involved, search sound.c and ac2yd/remote_common.py for "remote_control_slave".

This does not explain your troubles running wsjtx from the Control Head.? I'll try to set up to try that here ... I confess I have never run any digital modes!? :-0

Thanks, and enjoy your vacation!

-- Ben, AC2YD --

On Tue, 2022-09-13 at 08:43 +0200, Jaroslav ?karvada wrote:

If I click 'Config -> Config -> The file-play -> ...' to select the
play
file I get SIGSEGV. If I want to change the file, I have to directly
edit the config file quisk_init.json. The same for the record file

works fine here with 4.2.2 on Fedora 36

73 OE6HKE

Jaroslav ?karvada napsal(a):

Jaroslav ?karvada napsal(a):

Hi,

I am now on vacation and I am playing with the quisk-4.2.6 AC2YD remote control feature. It's pretty cool, really thanks for it, it fully replaced my VNC/pulse(pipewire) streaming modules hackery. At the moment I have pretty crazy setup:

resort_apartment --poor-resort-wifi--> poor_resort_router --ISDN--> Internet --ethernet--> my_router --my-home-not-so-good-wifi--> host_computer --gbit-ethernet--> HL2

It's all IPv4 and I am on the NAT from the both internet sides (i.e. the resort is behind NAT and my home host_computer is behind another NAT). The great thing is that the remote control works even under such conditions and is very usable.

Problems I have discovered so far:
- in the documentation it should be mentioned which ports are TCP (4585) and which are UDP (4586, 4587, 4588), this would ease the port forward setup on the router.
- clipping is not shown on the control-head (normally the frequency box turns red on the remote), i.e. you don't know when you should lower the gain.
- REMOTE_ADDR currently has to be IP, not the domain name. If the domain name is used, remote control works, but there is no sound, because it tries to UDP connect to the nonsense IP addresses. I think it should also work with the domain name, then you could setup DDNS, port forward and stop hassling with the dynamic IPs.
- even with the port forward set and correct IP in the REMOTE_ADDR, there is no waterfall on the control-head. I think it's because the remote tries to UDP connect to the control-head on the port 4586, but it fails because the control-head is also behind NAT. I think the control-head should send periodically UDP packets to the REMOTE_ADDR:4586, most NAT routers will then correctly return the incoming UDP packets on the same port.

I workaround most of the problems with the OpenVPN UDP tunnel

73! Jaroslav, OK2JRQ

One more problem noted:
- SWR / Power are not displayed on the remote if the control-head is disconnected. The PA current shown on the remote seems to be incorrect. On the control-head (if connected) are displayed correct numbers.
73! Jaroslav, OK2JRQ

Another problem:

- with the no control-head connected if I run SW using QuiskDigitalInput on the remote end, there is no signal going out of the HL2. It seems the HL2 TX OK, but it's like there is a zero volume on the QuiskDigitalInput. I checked the pulse mixer settings and the volume is set to the 100%. The 'Config -> HL2 -> Digital TX0' is set to the 'pulse: Use name QuiskDigitalInput'. Contrary, the QuiskDigitalOutput is working as expected and the RX audio is going through it OK in the DGT-U mode. I am using Fedora 35 and PipeWire.
- with the control-head connected if I run the same SW using QuiskDigitalInput (e.g. wsjtx), but this time on the machine running the control-head, it's even more weird. The quisk correctly signals TX (on both control-head and remote), but the radio doesn't switch to the TX mode and is still receiving - RX audio is going all the time without interruption from the QuiskDigitalOutput.

If I change 'Config -> HL2 -> Hardware -> Hardware file path' back from the 'ac2yd/remote_hermes.py' to the original 'hermes/quisk_hardware.py', the QuiskDigitalInput starts working as expected

73! Jaroslav, OK2JRQ

jimahlstrom napsal(a):

This is an update to the new Quisk Remote feature by Ben, AC2YD. The frequency is now correctly set when changing bands. Initial menu items are now set. Frequencies stay synchronized when changing from USB to CWU. I changed the graph data from 8 bit to 16 bit.
I improved the config screen visibility when using "Dark" mode.
Jim
N2ADR

I noticed the following problem on Fedora 35. Maybe the problem was there also in older Quisks, I cannot check it now. But it worked OK at least cca. year ago.

If I click 'Config -> Config -> The file-play -> ...' to select the play file I get SIGSEGV. If I want to change the file, I have to directly edit the config file quisk_init.json. The same for the record file

73! Jaroslav, OK2JRQ

Hello Jim,

Congratulations on advancing the beta again and for the improvements. I have run some preliminary tests on this version and note the following


quisk-4.2.6

Would not switch between CW and LSB

Started the remote on 80M
remote is started with cwl selected
Started ctl-head with lsb selected and remote matched ctl correctly. That is it changed to the ctl frequency and mode.
Using favourites,
Switch to a CW favourite both match
Switch to an SSB favourite and remote stays on CW but Ctl correctly changes
Switch to any mode with buttons & both change
This can be reproduced every time.

Setting LNA Gain
The option for initial lna value (Hardware menu) is of course no longer available but would be nice to have. Perhaps it could be set on the remote and read back into the ctl-head?

An Aberration
Started once for me with no graph (sound was OK). have not been able to reproduce this again and a restart of the ctl-head only had everything normal again.

Forward Power calibration
I want to rebuild the power out calibration file again but can not do this from ctl-head. I am not sure where the calibration file is read from whether it is at the remote or at the ctl-head. I have a table at both locations. Maybe I should build a table and manually add it to the config file? I would appreciate some advice here.

@Ben, I have run the client/server over wifi using an ethernet connection for the server and wifi from my laptop for the client. I have not followed your suggestions yet but even so the performance is pretty good with about every 5 or 10 minutes a brief break of 1 sec or so which I suspect is associated with a rescan. I will implement your suggestions, try again and report any difference.

Thanks, Graeme ZL2APV

Jaroslav ?karvada napsal(a):

Hi,
I am now on vacation and I am playing with the quisk-4.2.6 AC2YD remote control feature. It's pretty cool, really thanks for it, it fully replaced my VNC/pulse(pipewire) streaming modules hackery. At the moment I have pretty crazy setup:
resort_apartment --poor-resort-wifi--> poor_resort_router --ISDN--> Internet --ethernet--> my_router --my-home-not-so-good-wifi--> host_computer --gbit-ethernet--> HL2
It's all IPv4 and I am on the NAT from the both internet sides (i.e. the resort is behind NAT and my home host_computer is behind another NAT). The great thing is that the remote control works even under such conditions and is very usable.
Problems I have discovered so far:
- in the documentation it should be mentioned which ports are TCP (4585) and which are UDP (4586, 4587, 4588), this would ease the port forward setup on the router.
- clipping is not shown on the control-head (normally the frequency box turns red on the remote), i.e. you don't know when you should lower the gain.
- REMOTE_ADDR currently has to be IP, not the domain name. If the domain name is used, remote control works, but there is no sound, because it tries to UDP connect to the nonsense IP addresses. I think it should also work with the domain name, then you could setup DDNS, port forward and stop hassling with the dynamic IPs.
- even with the port forward set and correct IP in the REMOTE_ADDR, there is no waterfall on the control-head. I think it's because the remote tries to UDP connect to the control-head on the port 4586, but it fails because the control-head is also behind NAT. I think the control-head should send periodically UDP packets to the REMOTE_ADDR:4586, most NAT routers will then correctly return the incoming UDP packets on the same port.
I workaround most of the problems with the OpenVPN UDP tunnel
73! Jaroslav, OK2JRQ

One more problem noted:
- SWR / Power are not displayed on the remote if the control-head is disconnected. The PA current shown on the remote seems to be incorrect. On the control-head (if connected) are displayed correct numbers.

73! Jaroslav, OK2JRQ

Hi,

I am now on vacation and I am playing with the quisk-4.2.6 AC2YD remote control feature. It's pretty cool, really thanks for it, it fully replaced my VNC/pulse(pipewire) streaming modules hackery. At the moment I have pretty crazy setup:

resort_apartment --poor-resort-wifi--> poor_resort_router --ISDN--> Internet --ethernet--> my_router --my-home-not-so-good-wifi--> host_computer --gbit-ethernet--> HL2

It's all IPv4 and I am on the NAT from the both internet sides (i.e. the resort is behind NAT and my home host_computer is behind another NAT). The great thing is that the remote control works even under such conditions and is very usable.

Problems I have discovered so far:
- in the documentation it should be mentioned which ports are TCP (4585) and which are UDP (4586, 4587, 4588), this would ease the port forward setup on the router.
- clipping is not shown on the control-head (normally the frequency box turns red on the remote), i.e. you don't know when you should lower the gain.
- REMOTE_ADDR currently has to be IP, not the domain name. If the domain name is used, remote control works, but there is no sound, because it tries to UDP connect to the nonsense IP addresses. I think it should also work with the domain name, then you could setup DDNS, port forward and stop hassling with the dynamic IPs.
- even with the port forward set and correct IP in the REMOTE_ADDR, there is no waterfall on the control-head. I think it's because the remote tries to UDP connect to the control-head on the port 4586, but it fails because the control-head is also behind NAT. I think the control-head should send periodically UDP packets to the REMOTE_ADDR:4586, most NAT routers will then correctly return the incoming UDP packets on the same port.

I workaround most of the problems with the OpenVPN UDP tunnel

73! Jaroslav, OK2JRQ

Now both Control Head and Radio HL2 has Large Screen, and I see no errors switching between CWU/CWL or USB/LSB.

But if I switch from USB to CWU the Radio HL2 is left 600 Hz too high.

Control Head 28 200 150 Hz
Radio HL2? ? ?28 200 750 Hz? ?; both shows button CWU as active.

The two Quisk programs will stay apart each other when pushing buttons, until a new frequency is dialed in waterfall or frequency field. Then they synchronize again.

73 Jan

Hi Jim

yes, remote was using Small Screen and Large Screen on the Control Head.
I will a new test with Large Screen on both.

73 Jan

Hi Jim et al,

Many thanks!? After failing to Tx yesterday, I got on the air today with CW, after your timely tip to configure Quisk to *turn on the PA* for the Hermes Lite 2! ? ;-) ? I ran for a few hours with no problems, making a handful of POTA QSOs (including WA on 20m), plus working a special event station in Spain on 20m, and working UT on 40m this evening from my home in New Jersey (East Coast USA).

Listening on an old superhet (no SDR Rx signal processing means no delay) Heathkit HR-10B receiver to actual Tx, it was quick enough that I could pretty much use it as sidetone!

quisk_logfile.txt on both machines (Win 10 laptop Control Head, RaspPi 4 Remote Radio with HLT2) look clean.? I did not exercise the control panel much at all, just operated CWU as usual (nice to be back on the air; it's been a couple months!).

Both ends were connected via WiFi, with control head laptop close to office AP (strong sig), and signal level for outdoor RaspPi at around -70dBm (rig-in-a-box at base of vertical antenna) ... every once in a long while, I would get a short burst of dropped radio sound samples, scratchy/crackly but never debilitating ... this might or might not be because Win 10 laptop may scan every once in a long while, even when using WLAN Optimizer to try to eliminate scanning ... or ???? But it's right in line with what I have experienced with the development prototype over many months; nothing new.

I did not seem to lose any QSOs due to being off frequency, but I would like to check for a good match using a signal generator, as did OZ1OY (thanks for report!) ... I'll try that tomorrow.

BTW Jim, I like the way you handled the radio-specific features, and it's very nice to have the HLT2 LNA and PA/Pwr/SWR info on the Control Head!

Thanks again for a great job integrating all these changes, and more recently for a quick turnaround getting 4.2.5 out the door!

Also, many thanks for the reports from users who have tried the remote feature ... much appreciated!

73/72!!

-- Ben, AC2YD --

Hello Jan,

Are you using the Small Screen version of Quisk on either the local or remote radio? I have not tested that configuration. If you are using Large Screen on both, please tell me what control you were using to get the error message. I want Small Screen to work, but I have not gotten that far yet.

Jim
N2ADR

I did upgrade to version 4.2.5, and thanks for a very user friendly upgrade using pip!

Window size back to -1 on Control Head and using Large Screen layout. Still small fonts on button and others.

Did some tuning around a cw signal from a generator, switching between CWL and CWU, and found that the Remote HL2 radio didn't hit the signal on spot. Also had this on the quisk_logfile.txt on the remote:?

开云体育

Thanks to all for these new features for Quisk.? I am thinking about setting up my old Dell D630 and softrock RXTX with Quisk on the tribander, but need to hook up a different receive antenna for the spotting I am doing with Digiskimmer as I find it interesting to see how propagation is doing.? It has been better this summer.

73 & TNX AGN,

Rob

KL7NA

Hello Jim,

Thanks for the new version and it seems to be working well. I have tried it on air with everything working as it should but have not yet extensively tested it as my brother and XYL are staying and family is overtaking ham radio for the next 3 days. I tried the radio with the client and server on my inside workstation and an effect that I noticed was an echo from the server and client audio on the same machine. Not really a problem as I muted the remote and listened to the ctl head audio. I got reports that my audio on the client/server setup had some (few) little breaks like a loose wire and was not as full as using Quisk alone although my audio settings are the same otherwise nothing to report. I should mention that the server was deliberately set to different screen dimensions from the client but everything still tracked and my client screen remained at the set size as did the server. Even at this early beta stage the radio is going well and the 200 KiB/sec for the network traffic is amazing. I've just got to try wifi which would not really work with Quisk, taking on board Ben's comments on getting the best out of wifi.

I don't know how many times I have said thank you but here goes again and also to you Ben.

73, Graeme ZL2APV