USB-to-Radio CAT Control not working (wine-mono System.IO.Ports.SerialPort not implemented) about winelink

[djecom1]

Works !!!
Test : VARA HF and Pactor (RaspberryPi400, IC-7100, modem pactor Swiss PTC-II)
Thank you
F4GMU

[KD2ROS]

Success with VARA FM, VARA HF and Packet Winlink!!!! Re installed Winelink after the new import of System,IO.Ports.SerialPort…System: RPi 4 8GB, IC7100, native IC7100 sound card for both VARA FM and VARA HF and a bluetooth Mobilink’d TNC3 for Packet Winlink… Nice work Eric and Esme!!! Thank you!!!! 73 de KD2ROS Kate

…

On Feb 3, 2022, at 11:41 AM, Eric Wiessner (KI7POL) ***@***.***> wrote: New import of System.IO.Ports.SerialPort from corefx (in ***@***.*** <madewokherd/mono@03d7efb>) has now been merged into ***@***.*** <madewokherd/wine-mono@31df919> — Reply to this email directly, view it on GitHub <#17 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQ7BOY57GGHWZ5JRZ57K4G3UZKV4BANCNFSM5JSQNHGQ>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.

[djecom1]

I tried several things to make the serial ports work, but it failed.
Not possible to communicate with my radio and my pactor modem..

[WheezyE]

Until we find & fix the problem in wine-mono, you might be able to work around this by installing .NET 4.6 (to replace wine-mono).

EDIT: First, upgrade box86 to a newer build

sudo apt-get install cmake git -y
commit="ed8e01e"
    
    echo -e "Building and installing Box86 . . ."
    mkdir box86; cd box86
        rm -rf box86-builder; mkdir box86-builder && cd box86-builder/
            git clone https://github.com/ptitSeb/box86 && cd box86/
                git checkout "$commit"
                mkdir build; cd build
                    cmake .. -DRPI4=1 -DCMAKE_BUILD_TYPE=RelWithDebInfo
                    make -j3
                    sudo make install # copies box86 files into their directories (/usr/local/bin/box86, /usr/lib/i386-linux-gnu/, /etc/binfmt.d/)
                cd ..
            cd ..
        cd ..
    cd ..
    sudo systemctl restart systemd-binfmt

Then run this command in the terminal: BOX86_NOBANNER=1 BOX86_DYNAREC_BIGBLOCK=0 BOX86_DYNAREC_STRONGMEM=2 winetricks --force dotnet46 You will have to click a few buttons to install a few versions of .NET until .NET 4.6 installation is complete.

If the installation completes but then the terminal gets stuck for more than an hour, open a new terminal window and type wineserver -k, then re-run the command above. You might have to do that a couple times before dotnet46 is fully installed.

[WheezyE]

After testing the dotnet46 option a bit more: ARDOP may not work

[djecom1]

After many try to install dotnet46, it fails.
I'll try again tomorrow.

[WheezyE]

Thank you for testing things out. I'll try to get an install method for dotnet46 worked into the winelink script pretty soon to make this easier.

This COM port issue is my top priority now that we understand where the HF Channel Selection Browser crash is coming from, but it may take some time to track down and then fix the error (maybe a few weeks or so).

[djecom1]

It works now.
It takes a long time, but after many Attempts, it works with my Icom IC-7100 and my PTC-II pactor modem.
Thank you and I wait for your future install script.

[WheezyE]

I think my dummy load may take some time to arrive in the mail. I'm new to Denver, but just realized there's an HRO in the city, so I might take a trip down there and play with a Pactor modem for a while if they have any to connect to do some software testing. It may take some time to get an opportunity to make a trip though.

In the meantime, I'll try to see what I can find out without trying CAT PTT on my FT-891. I'll try to see if maybe wine-mono just isn't seeing com ports at all or something like that.

[WheezyE]

I found a way to install .NET 4.6 silently, so I'm re-implementing the use of .NET instead of wine-mono for now in 16bdc65 until we can fix more bugs in wine-mono. One downside to this is that ARDOP doesn't work yet... but try testing this new version of the install script and see if COM ports work again.

EDIT: The Channel Selection Browser seems to crash again with .NET4.6. My dummy load arrives on the 14th though, so I’ll be able to keep tracking bugs in wine-mono when that comes in. EDIT 12/15/2021: J/k it's arriving on the 21st. I'm excited to test it out though. EDIT 12/23/2021: Dummy load arrived and I confirmed its SWR yesterday. Holiday stuff might delay testing, but I'll post when I have more info

EDIT: If you want to go back to the wine-mono version instead of the .NET4.6 version, you can still download the older winelink script with this terminal command:
wget https://raw.githubusercontent.com/WheezyE/Winelink/09d2927f742de563d0e9fd886816c095b18a0df3/install_winelink.sh

[WheezyE]

Just a small update: I've re-created the error on my end (in wine-mono) & confirmed that the PTT /channel-selection (CAT control to FT-891) do work on Debian 10 in wine + .NET 4.6 + ARDOP. Next step is to trace the problem in wine-mono and type up a report for Esme (madewokherd).

[WheezyE]

I think I found the error. This pops up in wine-mono right when Winlink reports that the com port is not accessible:

WINE_MONO_TRACE=x WINE_MONO_HIDETYPES=1 wine RMS\ Express.exe
...
[000001b8:] EXCEPTION handling: System.NotImplementedException: The method or operation is not implemented.

Asking wine-mono for more detail on the function that's not implemented gives me this extra info

WINE_MONO_TRACE=E:System.MissingMethodException MONO_INLINELIMIT=0 WINE_MONO_HIDETYPES=1 wine RMS\ Express.exe
...
[00000024:] EXCEPTION handling: System.NotImplementedException: The method or operation is not implemented.

	"<unnamed thread>" tid=00000024 this=04570120 , thread handle : 01df5788, state : not waiting
	  at System.IO.Ports.SerialPort.set_ReceivedBytesThreshold (int) [0x0000f] in <117354a27af94c36af91c072a84e6fb8>:0
	  at (wrapper remoting-invoke-with-check) System.IO.Ports.SerialPort.set_ReceivedBytesThreshold (int) [0x00032] in <117354a27af94c36af91c072a84e6fb8>:0
	  at RMS_Express.Radio.OpenControlPort () [0x000b3] in <25c56d5497bc4490bd1b5395b173c5df>:0
	  at RMS_Express.Radio.SetRadio () [0x0014f] in <25c56d5497bc4490bd1b5395b173c5df>:0
	  at RMS_Express.Radio.SetFrequency (int,string) [0x00021] in <25c56d5497bc4490bd1b5395b173c5df>:0
	  at (wrapper remoting-invoke-with-check) RMS_Express.Radio.SetFrequency (int,string) [0x00033] in <25c56d5497bc4490bd1b5395b173c5df>:0
	  at RMS_Express.ArdopSession.Ardop_Activated (object,System.EventArgs) [0x00823] in <25c56d5497bc4490bd1b5395b173c5df>:0
	  at System.Windows.Forms.Form.OnActivated (System.EventArgs) [0x0001f] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0
	  at System.Windows.Forms.Form.set_Active (bool) [0x000a6] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0
	  at System.Windows.Forms.Form.WmActivate (System.Windows.Forms.Message&) [0x0001a] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0
	  at System.Windows.Forms.Form.WndProc (System.Windows.Forms.Message&) [0x001b8] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0
	  at System.Windows.Forms.Control/ControlNativeWindow.OnMessage (System.Windows.Forms.Message&) [0x00001] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0
	  at System.Windows.Forms.Control/ControlNativeWindow.WndProc (System.Windows.Forms.Message&) [0x000b3] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0
	  at System.Windows.Forms.NativeWindow.Callback (System.Windows.Forms.Message&) [0x00025] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0
	  at (wrapper remoting-invoke-with-check) System.Windows.Forms.NativeWindow.Callback (System.Windows.Forms.Message&) [0x00032] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0
	  at System.Windows.Forms.NativeWindowProc.Callback (intptr,int,intptr,intptr) [0x00037] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0
	  at (wrapper native-to-managed) System.Windows.Forms.NativeWindowProc.Callback (intptr,int,intptr,intptr) <0x00067>
	  at <unknown> <0xffffffff>
	  at (wrapper managed-to-native) System.Windows.Forms.SafeNativeMethods.ShowWindow (System.Runtime.InteropServices.HandleRef,int) <0x00012>
	  at System.Windows.Forms.Control.SetVisibleCore (bool) [0x00061] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0
	  at System.Windows.Forms.Form.SetVisibleCore (bool) [0x000d1] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0
	  at System.Windows.Forms.Control.set_Visible (bool) [0x00001] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0
	  at System.Windows.Forms.Control.Show () [0x00001] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0
	  at RMS_Express.ArdopSession.ShowSession () [0x00000] in <25c56d5497bc4490bd1b5395b173c5df>:0
	  at RMS_Express.Main.StartSession () [0x005fd] in <25c56d5497bc4490bd1b5395b173c5df>:0
	  at RMS_Express.Main.mnuSession_Click (object,System.EventArgs) [0x00000] in <25c56d5497bc4490bd1b5395b173c5df>:0
	  at System.Windows.Forms.ToolStripItem.RaiseEvent (object,System.EventArgs) [0x0001b] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0
	  at System.Windows.Forms.ToolStripItem.OnClick (System.EventArgs) [0x00001] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0
	  at System.Windows.Forms.ToolStripMenuItem.OnClick (System.EventArgs) [0x0001d] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0
	  at System.Windows.Forms.ToolStripItem.HandleClick (System.EventArgs) [0x00051] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0
	  at System.Windows.Forms.ToolStripItem.HandleMouseUp (System.Windows.Forms.MouseEventArgs) [0x000fd] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0
	  at System.Windows.Forms.ToolStripItem.FireEventInteractive (System.EventArgs,System.Windows.Forms.ToolStripItemEventType) [0x00053] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0
	  at System.Windows.Forms.ToolStripItem.FireEvent (System.EventArgs,System.Windows.Forms.ToolStripItemEventType) [0x00103] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0
	  at (wrapper remoting-invoke-with-check) System.Windows.Forms.ToolStripItem.FireEvent (System.EventArgs,System.Windows.Forms.ToolStripItemEventType) [0x00033] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0
	  at System.Windows.Forms.ToolStrip.OnMouseUp (System.Windows.Forms.MouseEventArgs) [0x0007d] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0
	  at System.Windows.Forms.Control.WmMouseUp (System.Windows.Forms.Message&,System.Windows.Forms.MouseButtons,int) [0x001c3] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0
	  at System.Windows.Forms.Control.WndProc (System.Windows.Forms.Message&) [0x005a0] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0
	  at System.Windows.Forms.ScrollableControl.WndProc (System.Windows.Forms.Message&) [0x00043] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0
	  at System.Windows.Forms.ToolStrip.WndProc (System.Windows.Forms.Message&) [0x00128] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0
	  at System.Windows.Forms.MenuStrip.WndProc (System.Windows.Forms.Message&) [0x00056] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0
	  at System.Windows.Forms.Control/ControlNativeWindow.OnMessage (System.Windows.Forms.Message&) [0x00001] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0
	  at System.Windows.Forms.Control/ControlNativeWindow.WndProc (System.Windows.Forms.Message&) [0x000b3] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0
	  at System.Windows.Forms.NativeWindow.Callback (System.Windows.Forms.Message&) [0x00025] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0
	  at (wrapper remoting-invoke-with-check) System.Windows.Forms.NativeWindow.Callback (System.Windows.Forms.Message&) [0x00032] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0
	  at System.Windows.Forms.NativeWindowProc.Callback (intptr,int,intptr,intptr) [0x00037] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0
	  at (wrapper native-to-managed) System.Windows.Forms.NativeWindowProc.Callback (intptr,int,intptr,intptr) <0x00067>
	  at <unknown> <0xffffffff>
	  at (wrapper managed-to-native) System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW (System.Windows.Forms.NativeMethods/MSG&) <0x00012>
	  at System.Windows.Forms.Application/ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop (intptr,int,int) [0x001d7] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0
	  at System.Windows.Forms.Application/ThreadContext.RunMessageLoopInner (int,System.Windows.Forms.ApplicationContext) [0x00282] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0
	  at System.Windows.Forms.Application/ThreadContext.RunMessageLoop (int,System.Windows.Forms.ApplicationContext) [0x0001a] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0
	  at (wrapper remoting-invoke-with-check) System.Windows.Forms.Application/ThreadContext.RunMessageLoop (int,System.Windows.Forms.ApplicationContext) [0x00033] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0
	  at System.Windows.Forms.Application.Run (System.Windows.Forms.ApplicationContext) [0x00006] in <ff4fde3cd5024947a0edb51b0ef7fff6>:0
	  at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.OnRun () [0x00044] in <e344caf534bf4ffb982376a141ed987b>:0
	  at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.DoApplicationModel () [0x00035] in <e344caf534bf4ffb982376a141ed987b>:0
	  at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.Run (string[]) [0x0001b] in <e344caf534bf4ffb982376a141ed987b>:0
	  at RMS_Express.My.MyApplication.Main (string[]) [0x0000f] in <25c56d5497bc4490bd1b5395b173c5df>:0
	  at (wrapper runtime-invoke) <Module>.runtime_invoke_void_object (object,intptr,intptr,intptr) [0x00027] in <25c56d5497bc4490bd1b5395b173c5df>:0

The same COM port works in .NET 4.6 (and I know that this COM port is connected to the radio via checking symlinks in ~/.wine/dosdevices and due to its disappearance when the radio is not connected)

I'll report this in to Esme to see what they think!

Also just posting my other debugging notes here for future reference:

wine-7.0-rc4 devel
using wine-mono 2f50d2c (https://nightly.link/madewokherd/wine-mono/actions/artifacts/131614059.zip)
Winlink Express 1.5.44.0
Set in/out audio devices in ARDOP settings.
FT-891 Transceiver (with dummyload attached directly to radio - no feed line)
FT-891 data baud rate set to 9600
Connect FT-891 to PC (and make sure VMWare has the USB line routed into the VM instead of the host PC)

--------------------------------------------------------

Tested connections using Windows version of Winlink - Push-to-talk (keying up the radio / "PTT") is working when trying to connect to a station with ARDOP.

--------------------------------------------------------

sudo apt install setserial

FT-891 serial connection is named: "silicon cp2105 dual usb to uart bridge controller"
	pi@debian:/dev$ sudo dmesg | grep tty
	[    0.093140] console [tty0] enabled
	[    1.438158] 00:05: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
	[    2.796210] systemd[1]: Created slice system-getty.slice.
	[ 3808.551827] usb 1-2.2: cp210x converter now attached to ttyUSB0
	[ 3808.563798] usb 1-2.2: cp210x converter now attached to ttyUSB1
	
	pi@debian:/dev$ ls tty*
	tty    tty14  tty20  tty27  tty33  tty4   tty46  tty52  tty59  tty8     ttyUSB1
	tty0   tty15  tty21  tty28  tty34  tty40  tty47  tty53  tty6   tty9
	tty1   tty16  tty22  tty29  tty35  tty41  tty48  tty54  tty60  ttyS0
	tty10  tty17  tty23  tty3   tty36  tty42  tty49  tty55  tty61  ttyS1
	tty11  tty18  tty24  tty30  tty37  tty43  tty5   tty56  tty62  ttyS2
	tty12  tty19  tty25  tty31  tty38  tty44  tty50  tty57  tty63  ttyS3
	tty13  tty2   tty26  tty32  tty39  tty45  tty51  tty58  tty7   ttyUSB0
ttyUSB0 & ttyUSB1 were not listed before connecting the FT-891 radio to the VM.

I checked ports in `wine regedit` HKEY_LOCAL_MACHINE\Software\Wine\Ports but this regkey was empty.
So then checked ...
	pi@debian:~/.wine/dosdevices$ ls
	c:  com1  com2  com3  com4  com5  com6  d:  d::  z:
	pi@debian:~/.wine/dosdevices$ ls -l com1
	lrwxrwxrwx 1 pi pi 10 Jan  3 19:03 com1 -> /dev/ttyS0
	pi@debian:~/.wine/dosdevices$ ls -l com2
	lrwxrwxrwx 1 pi pi 10 Jan  3 19:03 com2 -> /dev/ttyS1
	pi@debian:~/.wine/dosdevices$ ls -l com3
	lrwxrwxrwx 1 pi pi 10 Jan  3 19:03 com3 -> /dev/ttyS2
	pi@debian:~/.wine/dosdevices$ ls -l com4
	lrwxrwxrwx 1 pi pi 10 Jan  3 19:03 com4 -> /dev/ttyS3
	pi@debian:~/.wine/dosdevices$ ls -l com5
	lrwxrwxrwx 1 pi pi 12 Jan  3 19:03 com5 -> /dev/ttyUSB0
	pi@debian:~/.wine/dosdevices$ ls -l com6
	lrwxrwxrwx 1 pi pi 12 Jan  3 19:03 com6 -> /dev/ttyUSB1
	
So then I set ARDOP to use COM6 to talk to the radio, but Winlink says it couldn't connect and to check the exceptions log.

The ARDOP exceptions log says this:
	pi@debian:~/.wine/drive_c/RMS Express/KI7POL/Logs$ more RMS\ Express\ Exceptions\ 20220104.log 
	2022/01/04 02:17:56 [1.5.44.0] [Radio.SendASCIICommand] Err:
	2022/01/04 02:18:05 [1.5.44.0] [Radio.OpenControlPort]

Trying to start a winlink connection then plays ARDOP tones, but doesn't trigger the "push-to-talk" (PTT) switch on the radio to send a signal, so a radio connection would end up failing in this case.

--------------------------------------------------------

Then installed dotnet46 and tried again with same version of wine (actually used an old wineprefix, but same difference).
(Installed and updated RMS Express to 1.5.44.0 again too)

Double-checked USB devices connected to wine:
	pi@debian:~$ ls ~/.wine/dosdevices
	c:  com1  com2  com3  com4  com5  com6  d:  d::  z:
	pi@debian:~$ ls -l ~/.wine/dosdevices/com6
	lrwxrwxrwx 1 pi pi 12 Jan  3 19:26 /home/pi/.wine/dosdevices/com6 -> /dev/ttyUSB1
Set up ARDOP in/out sound devices again & set up Winlink>ARDOP>Settings>Radio Setup>FT-891/COM6 again.

Starting up ARDOP, the radio connection seems to work. No exceptions are generated in the ARDOP logs and the ARDOP logs say
	pi@debian:~/.wine/drive_c/RMS Express/KI7POL/Logs$ more RMS\ Express\ 20220104.log 
	2022/01/04 02:38:12 1.5.44.0 *** Ardop WL2K *** ARDOP Winlink session
	2022/01/04 02:38:12 1.5.44.0 *** Ardop WL2K *** Using Yaesu FT-891, COM6, 9600 b
	aud
	2022/01/04 02:38:12 1.5.44.0 *** Ardop WL2K *** Waiting for TNC to initialize...

	2022/01/04 02:38:20 1.5.44.0 *** Ardop WL2K *** Ready to start calling.
Select best channel.
Winlink warns that access is denied and cannot open the port :(
Try pressing start again and no PTT this time either.

-------------------------------------------------------------------
I then checked permissions on the radio's serial port to see if non-root users could access it:
	pi@debian:~/.wine/drive_c/RMS Express/KI7POL/Logs$ ls -l /dev/ttyUSB1
	crw-rw---- 1 root dialout 188, 1 Jan  3 19:50 /dev/ttyUSB1
Guess not!

	sudo adduser <the user you want to add> dialout
Try opening ARDOP again - COM6 access still denied.
	sudo reboot
Try opening ARDOP again - COM6 access still denied, but no more permission errors pop up with winlink.
	sudo usermod -a -G dialout $USER
Try opening ARDOP again - COM6 access still denied, but no more permission errors pop up with winlink.
	sudo reboot
Try opening ARDOP again - COM6 access still denied, but no more permission errors pop up with winlink.
Set COM5, same.
	
I am seeing this in the wine terminal though:
	0024:fixme:comm:set_queue_size insize 4096 outsize 2048 unimplemented stub
	01b4:fixme:comm:wait_on EV_RXFLAG not handled
And I'm seeing this when I set the PTT setting to "FT-891".
	0400:fixme:comm:wait_on EV_RXFLAG not handled
	0400:fixme:comm:wait_on EV_RXFLAG not handled
	0400:fixme:comm:wait_on EV_RXFLAG not handled
	0400:fixme:comm:wait_on EV_RXFLAG not handled
	0400:fixme:comm:wait_on EV_RXFLAG not handled
	0400:fixme:comm:wait_on EV_RXFLAG not handled
	0400:fixme:comm:wait_on EV_RXFLAG not handled
	0400:fixme:comm:wait_on EV_RXFLAG not handled
	0400:fixme:comm:wait_on EV_RXFLAG not handled
	0400:fixme:comm:wait_on EV_RXFLAG not handled
	0400:fixme:comm:wait_on EV_RXFLAG not handled
	0400:fixme:comm:wait_on EV_RXFLAG not handled
	0400:fixme:comm:wait_on EV_RXFLAG not handled
	0400:fixme:comm:wait_on EV_RXFLAG not handled
	0400:fixme:comm:wait_on EV_RXFLAG not handled
	0400:fixme:comm:wait_on EV_RXFLAG not handled

	
Using the channel selection browser: When selecting a channel, the radio changes to that channel! :)

Setting COM5 and PTT "FT-891" works! :D  (Setting to COM6 and PTT "FT-891" doesn't.)

-------------------------------------------------------

Moving back to the wine-mono wineprefix, using same settings, now I get COM port error - see exception log

	pi@debian:~$ more .wine/drive_c/RMS\ Express/KI7POL/Logs/RMS\ Express\ Exceptions\ 20220104.log 
	2022/01/04 03:39:02 [1.5.44.0] [Radio.OpenControlPort]
	2022/01/04 03:39:27 [1.5.44.0] [Radio.SendASCIICommand] Err:
	2022/01/04 03:39:29 [1.5.44.0] [Radio.SendASCIICommand] Err:
	2022/01/04 03:39:41 [1.5.44.0] [Radio.OpenControlPort]

Edit: Here's a picture of the COM port error in wine-mono (doesn't happen in .NET 4.6 - .NET 4.6 can key the radio and change radio frequency over USB aka "CAT control")

Edit: Bugreport submitted to winehq Bugzilla

[WheezyE]

Esme has fixed the PTT problem with RMS Express in wine-mono. I'll update the Winelink script again soon with the new wine-mono version instead of .NET (for quicker install, and for more testing)

[WheezyE]

I'm excited to say I've merged Esme's wine-mono fix into Winelink and switched to wine-mono again (instead of .NET 4.6) to speed up install.

@djecom1 & @KD2ROS, would you be able to try re-installing and testing your equipment again? Thank you for your patience!

Edit: I just found some new troubles with running Winelink on Raspberry Pi OS bullseye (I never tried it before now) and am trying to fix that at the moment. I also realized that I need to test to see if ~/.wine/dosdevices populates properly with USB devices, but I've run out of time for tonight. I'll update this when I double-check to make sure that's working.

[KD2ROS]

Okay....good news is that the channel selection/propagation screen when using VARA HF works completely! However, the one problem I have found is that Winlink cannot open the command port (8300) when starting a session in either VARA FM or VARA HF....Winlink packet works like a champ...

I can open a session in both VARA's and set up the rig, soundcards, ptt, etc...you can successfully ping a Winlink node and autotune in VARA FM and rig control works to select and tune to a channel on VARA HF...the trouble starts when you press "Start" to intiate the communications...I am attaching a pic of the errror message from VARA FM..

.

[WheezyE]

Thank you for your testing! I really appreciate another set of eyes on all this. Also great to hear that packet is working now.

I did some testing and found out that CAT/PTT are working in VARA, but we're running into two bugs here. One is a known TCP port listening bug that we can get around by just restarting RMS Express. Another bug though is related to using an older version of Wine on the Pi. I'll try to update wine to a newer version that works with VARA and box86.

Here are more details regarding the error

Just doing some testing on the Pi today with a fresh install of Raspberry Pi OS Bullseye (32-bit)

Confirmed that my Pi4 is able to connect to the FT-891
If I plug the radio into the Pi, I don't see any COM ports in ~/.wine/dosdevices initially until I close and open wine again. Then the my FT-891's COM ports show up in ~/.wine/dosdevices and show up in RMS Express.

• Typing ls -l shows that com1 is a symlink to /dev/ttyUSB0 and com2 is a symlink to /dev/ttyUSB1 (which are the FT-891's CAT/USB controller ports.
• I can confirm these ttyUSB's are the FT-891 with sudo dmesg | grep tty, which shows some serial numbers that the radio also displays when I connect it to Windows.

Confirmed that my Pi4 is able to control to the FT-891
ARDOP's channel selection browser changes channels on the radio & PTT works when running ARDOP (I didn't end up needing to add my user account to the pi's COM port dialout permissions group).

Reproduced an intermittent, known TCP port bug in ARDOP
Running ARDOP sometimes says that the "Command Port" (then lists a TCP/IP port) to the TNC isn't open, but if I restart ARDOP a few times then I can get that port to connect (this is a bug in wine).

The intermittent, known TCP port bug also occurs in VARA sometimes
I was able to reproduce the behavior where VARA doesn't like to connect to RMS Express sometimes. This behavior happens on the Pi4 and on in my Debian 10 x86 VM (on my laptop). It only happens sometimes. And restarting RMS Express can get around the bug. I'll try to send this bug over to WineHQ to see if they can fix it some time for a better user experience. (WineHQ may not respond though - I asked them about the CPU gauge in VARA last year (almost to the day) and they haven't responded to that bug report yet)

Reproduced/found a VARA connection bug on the Pi4 (but not on Debian VM...)
Once the TCP port connects, VARA seems to be acting very strangely on the Pi. VARA shows that it sees RMS Express, and RMS Express reports that it sees VARA, but it's not controlling VARA correctly on the Pi.

• On my Debian 10 VM on my laptop (without the added layer of box86 emulation complexity). The RMS Express 1.6.0.0 connects just fine to the newest VARA 4.5.7 TNC.
• The Pi is running wine-devel-6.19-bullseye. My Debian VM is running wine-devel-7.0-rc4-buster. Box86 has had some troubles running wine-7.0 though. I think I need to find the latest version of wine that works with box86 and put that into Winelink so that VARA behaves normally again.

[WheezyE]

Strange ... updating to wine-devel-7.1 doesn't fix the connection errors between VARA and RMS Express. I don't think it's a wine-mono problem though since everything works on my Debian 10 VM. I'll keep looking into this.

More trouble-shooting

EDIT: I'm also noticing that the VARA log says that MYCALL KI7POL is being received by VARA for some reason on the Pi, but not in DebianVM (and VARA has KI7POL on its banner in DebianVM, but not on the Pi). Netstat says that ports are open. Changing bigblock in box86 doesn't seem to help. So here's what we know. - wine-6.19+wine-mono-nightly, RMS 1.4.x.x, VARA 4.5.x, bullseye, Pi4+box86_Jan31: VARA finds TCP, doesn't work - wine-6.19+wine-mono-nightly, RMS 1.4.x.x, VARA 4.5.7, bullseye, Pi4+box86_Jan31: VARA finds TCP, doesn't work - wine-6.19+wine-mono-nightly, RMS 1.6.0.0, VARA 4.5.7, bullseye, Pi4+box86_Jan31: VARA finds TCP, doesn't work - wine-7.1+wine-mono-nightly, RMS 1.6.0.0, VARA 4.5.7, bullseye, Pi4+box86_Jan31: VARA finds TCP, receives garbled data - wine-7.0+wine-mono-nightly, RMS 1.4.x.x, VARA 4.5.x, buster, DebianVM: VARA finds TCP, receives data - wine-7.0+wine-mono-nightly, RMS 1.4.x.x, VARA 4.5.7, buster, DebianVM: VARA finds TCP, receives data - wine-7.1+wine-mono-nightly, RMS 1.6.0.0, VARA 4.5.7, buster, DebianVM: VARA finds TCP, receives data

I might try trying different versions of box86 and/or trying to install buster on the Pi again to test that.

Here's VARA's error message on the Pi4, which doesn't appear on the DebianVM

2022-02-02 22:31:12    Wrong command: MYCALL KI7POL

2022-02-02 22:44:07    WARNING: VARA is not connected to any App via TCP Port 8300

EDIT2: VARAChat also seems to be connecting to TCP but sending wrong data

2022-02-02 23:04:14    Wrong command: MYCALL KI7POL

2022-02-02 23:05:57    Wrong command: CONNECT KI7POL N0CALL-2

VARAChat still runs after uninstalling wine-mono, so this is for sure not a wine-mono problem at this point.

EDIT3: box86 Jan 01 2021 works! VARA Chat also triggers PTT and sends tones (if I use the FT-991 settings with RTS+DTR for my FT-891). I'll find the latest version of box86 that works, let Seb know, and email the VARA Chat authors to let them know that the FT-991 settings work for the FT-891.

EDIT4: Just trying to track down the box86 error still

VARA cannot talk to RMS Express over TCP in newer versions of box86 (says it connects though) - freezes after pushing the "start" button in RMS

	01/01/21 works
		12/01/21 works
					12/07/21 works
									12/09/21 (ed8e01ea) works
										12/10/21 (ed8e01ea) works
						*12/11/21 (a1aac43a) unrelated wine error (happens in wine-devel-6.19 & wine-devel-7.1)
							*12/13/21 unrelated wine error
								*12/14/21 unrelated wine error
				12/15/21 nope
			01/01/22 nope
02/01/22 nope
02/05/22 nope

[WheezyE]

Ok ... I think it's fixed now lol. Maybe give it one more shot with another re-install.
The constant reconnecting issue (between RMS & VARA/ARDOP over TCP) can't be helped for now, but hopefully in the future. Try restarting RMS Express if that comes up.

It would be amazing if we could test RMS Express with this new wine-mono fix with lots of different hardware too to see if USB ports are working in general.

[WheezyE]

Thank you for letting us know and for posting your hardware setup!

[WheezyE]

New import of System.IO.Ports.SerialPort from corefx (in madewokherd/mono@03d7efb) has now been merged into madewokherd/wine-mono@31df919

[WheezyE]

Wonderful! Thank you for all of your alpha testing and patience. I really appreciate your help. I’ll close this issue and report some bugs to winehq to try to help the TCP issues (VARA/ARDOP-to-RMS communication)