Hello Ben,

I upgraded in the weekend to Linux Mint ver 21 which is based on Ubuntu 22.04 and of course is using python 3.10.4 which is working well except for the sliders on the config screen etc. which are displaced but there was also upgrades to gtk3 I believe so that, rather than python, may be the cause. I will report this in a more orderly fashion when I get more time to play with it and pick up on the other screens that may be affected.

On 20/09/22 04:21, Ben Cahill wrote:

I also upgraded my Ubuntu desktop to 22.04, and noticed that provides Python 3.10.4, also outside the range Jim recommends.? I don't know if that could cause any problems, but it sounds as if it is working well for you ...

Using wifi on my laptop with a wireless connection I get fairly frequent breaks (every 30 secs or so) which are more in the nature of a click rather than the long silences with the graphics pulsing as happened in the past with a full spectrum of I and Q. I have done nothing to tune my wifi yet and may be able to get an even better result.

73, Graeme ZL2APV

Hello Ben,?

first some corrections to my text, I have unbutu 20.4 not 22.04 on jetson nano, and use python 3.9 ... sorry for that ... on the RPI4 I think I have python version 3.8!

>> Yes, I do see the segmentation fault on RPi4 raspian when closing Quisk.? This RPi4 is directly connected to HermesLite2.? I see the segmentation fault both when running the remote, as well as the non-remote (traditional) Hermes Quisk radio.? It does not seem to affect behavior while running.? I have Quisk ask me which radio to use when starting up , and I notice that it does not remember which Radio I last used (e.g. Remote HLT2 vs. Local HLT2).

yes, you are right, it doesn't affect the working behavior, I also have Quisk to "ask me" and I think it's working, don't know right now but will check later ...

>> Can you tell us what kind of network you have (ethernet, WiFi, internet?)
for the moment is Ethernet, it is still all in test, I will test later with my win10 tablet by wifi

another thing I detected is the NR2, by the way, is working very well in the control head but I have to switch first on the remote radio because the button is always unavailable, do you also have this?

thank you

Jacinto
cu2ed

开云体育

Hello Jacinto,

Thanks for the report!

Yes, I do see the segmentation fault on RPi4 raspian when closing Quisk.? This RPi4 is directly connected to HermesLite2.? I see the segmentation fault both when running the remote, as well as the non-remote (traditional) Hermes Quisk radio.? It does not seem to affect behavior while running.? I have Quisk ask me which radio to use when starting up , and I notice that it does not remember which Radio I last used (e.g. Remote HLT2 vs. Local HLT2).

NOTE:?? Before installing the new (remote) Quisk on RPi4, I did a full OS upgrade, and noticed that the latest Python for Raspian is 3.7.3 ... I believe Jim recommends 3.8 or 3.9 ... I don't know if this is a factor, but this is a good opportunity to mention it ... again, things seem to work well while running.

I also upgraded my Ubuntu desktop to 22.04, and noticed that provides Python 3.10.4, also outside the range Jim recommends.? I don't know if that could cause any problems, but it sounds as if it is working well for you ... the Ubuntu 22.04 upgrade also provided Quisk 4.1.93.? I have not tested any Quisk on this upgraded machine yet.

I will need to defer to Jim to answer the questions about MIDI.

Can you tell us what kind of network you have (ethernet, WiFi, internet?)

THANKS!

-- Ben, AC2YD --

Hello all,?

it has been a while since I used the quisk software?but this new remote function is really great ... I do have some questions but first I will describe my working system test:

On Mon, Sep 12, 2022 at 08:27 PM, Graeme Jury wrote:

Forward Power calibration
I want to rebuild the power out calibration file again but can not do this from ctl-head.

The power meter calibration is located at the remote radio. The remote just sends the text values to the control head. So go to the remote and on the config/radio/Hardware screen enter "New" as the Power meter calibration.

Jim
N2ADR

On Tue, Sep 13, 2022 at 02:43 AM, Jaroslav ?karvada wrote:

If I click 'Config -> Config -> The file-play -> ...' to select the play file I get SIGSEGV.

I can not reproduce this. Was there an initial bad file name in the JSON file?

Jim
N2ADR

On Thu, Sep 15, 2022 at 11:49 AM, Jaroslav ?karvada wrote:

And maybe add the mixer on the remote, because it's not handy to periodically switch the Hardware file path between the 'ac2yd/remote_hermes.py' and 'hermes/quisk_hardware.py' depending whether the user wants to remotely work SSB/CW or digital

Yes, you are right. I will try to make the remote with hardware file?ac2yd/remote_hermes.py work normally unless a connection from the control head is in progress.

Jim
N2ADR

I have two radios set up in the remote. I tried changing the hardware file which worked just fine but it was more hassle to do this than have another radio setup.

I have been doing a lot of thinking about the remote and am looking at setting up a raspberry pi direct connected to the HL2 and a USB to ethernet module to connect to my network. I currently have an Arduino set up to remotely connect to my office PC where I have an app to turn on radios, switch aerials, monitor the shack battery voltage etc. and I would port this to the Raspberry Pi and use the gpio for these tasks. I thought hard about writing a version of the widget and running these through the quisk remote but have discarded the idea as often I just want to operate something and don't want to have to start the HL2 and remote quisk to do this ... but I may change my mind. I just have to say that so far it is going brilliantly for me although everything is on my local lan and behind my firewall but I'm looking forward to getting the whole remote off site in the future.

73, Graeme ZL2APV

jimahlstrom napsal(a):

On Mon, Sep 12, 2022 at 07:28 PM, Jaroslav ?karvada wrote:
- SWR / Power are not displayed on the remote if the control-head is
disconnected.
If the control head is disconnected, the power must be zero because the control head is not sending Tx samples. Currently, the remote radio is not usable without the control head. I am not sure if this can be fixed. How important is it? To operate at the remote, change the hardware file back to?hermes/quisk_hardware.py. Or create two radios, one for local and one for remote operation.
Jim
N2ADR
_._,_._,_

It's probably not important, I just noticed it and reported. Two radios setup may work for me, it's much faster than changing the HW file

73! Jaroslav, OK2JRQ

On Mon, Sep 12, 2022 at 07:28 PM, Jaroslav ?karvada wrote:

- SWR / Power are not displayed on the remote if the control-head is disconnected.

If the control head is disconnected, the power must be zero because the control head is not sending Tx samples. Currently, the remote radio is not usable without the control head. I am not sure if this can be fixed. How important is it? To operate at the remote, change the hardware file back to?hermes/quisk_hardware.py. Or create two radios, one for local and one for remote operation.

Jim
N2ADR

jimahlstrom napsal(a):

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

Jim,

thanks for info, it makes sense. It would be great to document it. And maybe add the mixer on the remote, because it's not handy to periodically switch the Hardware file path between the 'ac2yd/remote_hermes.py' and 'hermes/quisk_hardware.py' depending whether the user wants to remotely work SSB/CW or digital

73! Jaroslav, OK2JRQ

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