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

[WheezyE]

if you have a known channel that you like to use you are able to type in the callsign, center frequency and dial frequency...when you start the session, it proceeds but, sends you the message that it cannot open the com port that is specified in your session settings, so it will not send the channel data that you typed in to the radio or operate the PTT...the session proceeds as is normal but fails because the radio cannot respond...

when the session window opens and the session communications with the pi start, I get the following error message..."Unable to open radio serial port COM2. See exceptions log."...COM2 is the correct port for my IC7100 radio and works appropriately in VARA FM using Winelink...

• Check COM port connection with wine-mono
• Check COM port connection with dotnet46 [x] Order a dummyload to test radio PTT with

[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. "" 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 :0 at System.Windows.Forms.Form.set_Active (bool) [0x000a6] in :0 at System.Windows.Forms.Form.WmActivate (System.Windows.Forms.Message&) [0x0001a] in :0 at System.Windows.Forms.Form.WndProc (System.Windows.Forms.Message&) [0x001b8] in :0 at System.Windows.Forms.Control/ControlNativeWindow.OnMessage (System.Windows.Forms.Message&) [0x00001] in :0 at System.Windows.Forms.Control/ControlNativeWindow.WndProc (System.Windows.Forms.Message&) [0x000b3] in :0 at System.Windows.Forms.NativeWindow.Callback (System.Windows.Forms.Message&) [0x00025] in :0 at (wrapper remoting-invoke-with-check) System.Windows.Forms.NativeWindow.Callback (System.Windows.Forms.Message&) [0x00032] in :0 at System.Windows.Forms.NativeWindowProc.Callback (intptr,int,intptr,intptr) [0x00037] in :0 at (wrapper native-to-managed) System.Windows.Forms.NativeWindowProc.Callback (intptr,int,intptr,intptr) <0x00067> at <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 :0 at System.Windows.Forms.Form.SetVisibleCore (bool) [0x000d1] in :0 at System.Windows.Forms.Control.set_Visible (bool) [0x00001] in :0 at System.Windows.Forms.Control.Show () [0x00001] in :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 :0 at System.Windows.Forms.ToolStripItem.OnClick (System.EventArgs) [0x00001] in :0 at System.Windows.Forms.ToolStripMenuItem.OnClick (System.EventArgs) [0x0001d] in :0 at System.Windows.Forms.ToolStripItem.HandleClick (System.EventArgs) [0x00051] in :0 at System.Windows.Forms.ToolStripItem.HandleMouseUp (System.Windows.Forms.MouseEventArgs) [0x000fd] in :0 at System.Windows.Forms.ToolStripItem.FireEventInteractive (System.EventArgs,System.Windows.Forms.ToolStripItemEventType) [0x00053] in :0 at System.Windows.Forms.ToolStripItem.FireEvent (System.EventArgs,System.Windows.Forms.ToolStripItemEventType) [0x00103] in :0 at (wrapper remoting-invoke-with-check) System.Windows.Forms.ToolStripItem.FireEvent (System.EventArgs,System.Windows.Forms.ToolStripItemEventType) [0x00033] in :0 at System.Windows.Forms.ToolStrip.OnMouseUp (System.Windows.Forms.MouseEventArgs) [0x0007d] in :0 at System.Windows.Forms.Control.WmMouseUp (System.Windows.Forms.Message&,System.Windows.Forms.MouseButtons,int) [0x001c3] in :0 at System.Windows.Forms.Control.WndProc (System.Windows.Forms.Message&) [0x005a0] in :0 at System.Windows.Forms.ScrollableControl.WndProc (System.Windows.Forms.Message&) [0x00043] in :0 at System.Windows.Forms.ToolStrip.WndProc (System.Windows.Forms.Message&) [0x00128] in :0 at System.Windows.Forms.MenuStrip.WndProc (System.Windows.Forms.Message&) [0x00056] in :0 at System.Windows.Forms.Control/ControlNativeWindow.OnMessage (System.Windows.Forms.Message&) [0x00001] in :0 at System.Windows.Forms.Control/ControlNativeWindow.WndProc (System.Windows.Forms.Message&) [0x000b3] in :0 at System.Windows.Forms.NativeWindow.Callback (System.Windows.Forms.Message&) [0x00025] in :0 at (wrapper remoting-invoke-with-check) System.Windows.Forms.NativeWindow.Callback (System.Windows.Forms.Message&) [0x00032] in :0 at System.Windows.Forms.NativeWindowProc.Callback (intptr,int,intptr,intptr) [0x00037] in :0 at (wrapper native-to-managed) System.Windows.Forms.NativeWindowProc.Callback (intptr,int,intptr,intptr) <0x00067> at <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 :0 at System.Windows.Forms.Application/ThreadContext.RunMessageLoopInner (int,System.Windows.Forms.ApplicationContext) [0x00282] in :0 at System.Windows.Forms.Application/ThreadContext.RunMessageLoop (int,System.Windows.Forms.ApplicationContext) [0x0001a] in :0 at (wrapper remoting-invoke-with-check) System.Windows.Forms.Application/ThreadContext.RunMessageLoop (int,System.Windows.Forms.ApplicationContext) [0x00033] in :0 at System.Windows.Forms.Application.Run (System.Windows.Forms.ApplicationContext) [0x00006] in :0 at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.OnRun () [0x00044] in :0 at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.DoApplicationModel () [0x00035] in :0 at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.Run (string[]) [0x0001b] in :0 at RMS_Express.My.MyApplication.Main (string[]) [0x0000f] in <25c56d5497bc4490bd1b5395b173c5df>:0 at (wrapper runtime-invoke) .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 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.

[djecom1]

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

[WheezyE]

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

[WheezyE]

New import of System.IO.Ports.SerialPort from corefx (in https://github.com/madewokherd/mono/commit/03d7efb1da676fcf29c1446637ea9dfc5c436b2e) has now been merged into https://github.com/madewokherd/wine-mono/commit/31df9194e1647f0e30b764e9dbe3acc1df1e0847

[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 @. https://github.com/madewokherd/mono/commit/03d7efb1da676fcf29c1446637ea9dfc5c436b2e) has now been merged into @. https://github.com/madewokherd/wine-mono/commit/31df9194e1647f0e30b764e9dbe3acc1df1e0847 — Reply to this email directly, view it on GitHub https://github.com/WheezyE/Winelink/issues/17#issuecomment-1029180310, 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.

[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)