#mac Support for Icom radio Silicon Labs a big issue getting bigger all the time #mac


km6hk@...
 

Icom radios use Silicon Labs VCP Driver packages.
and now that package (after a recent uprgade of my mac to macOS Catalina Version 10.15.7)
shows this message


K3JRZ
 

Silicon Labs has updated drivers for Big Sur 11.x.

On Thu, Feb 4, 2021 at 15:11 km6hk via groups.io <km6hk=iCloud.com@groups.io> wrote:
Icom radios use Silicon Labs VCP Driver packages.
and now that package (after a recent uprgade of my mac to macOS Catalina Version 10.15.7)
shows this message




--

Thanks & 73,

Jeff
K3JRZ
100WAAW #404

--

Thanks & 73,

Jeff
K3JRZ
100WAAW #404


km6hk@...
 

I have the latest driver and still get the error message from macOS;


Ria, N2RJ
 

The error is not fatal. You need to go in your settings under security
and allow it. This is pretty standard for Mac.

On Sun, Mar 7, 2021 at 2:22 PM km6hk via groups.io
<km6hk=iCloud.com@groups.io> wrote:

Silicon Labs has updated drivers for Big Sur 11.x.

https://www.silabs.com/developers/usb-to-uart-bridge-vcp-drivers



I have the latest drivers installed. They still generate the error fro the macOS:

https://i.postimg.cc/W1MLqLjP/Silicon-Labs.png






K3JRZ
 

Latest driver version is 6.

Use that link to go to a forum post about issues with the original 6.0 release. On that page is a link to the 6.01 drivers that worked for me. If there is anything newer I don’t know.

73.

Jeff
K3JRZ



On Sun, Mar 7, 2021 at 14:31 km6hk via groups.io <km6hk=iCloud.com@groups.io> wrote:
I have the latest driver and still get the error message from macOS;





--

Thanks & 73,

Jeff
K3JRZ
100WAAW #404


km6hk@...
 

Thanks Jeff K3JRZ...

I downloaded the 6.1 and will give it a try.. I think we are in bleeding edge territory here.  There is also some sort of issue with the way Icom intergrated that SL Chip. On that radio  Icom has designed / implemented it  to remain the status of the chip "live" even if you turn off the  radios front panel power switch to the radio, even  when the front panel switch is in the OFF physical position.    The radio  will still respond like a "Wake-On-LAN" even if the radio is OFF.  It is sort of nice becase if your start the WSJT software with a turned off radio it will WAKE the radio and return it to service.  But all that is is just a parlor trick. There is no need for it. Icom never should have implemented it in that manner. Also a bad side efffect is that the Icom lets the SL Chip show all the now stacked up  open USP ports / chanels from each previous use, so you get this huge' stack of active open USB ports.  - when you try to bring the total system back up then  WSJT sees that stack and gets very confused. So I think Icom is a little over their head with that type of low level programming and screwed it up on the IC7100.   ~ To reset the SL Chip and destroy the stack on the IC7100 you have to ~fully remove~ the power cable (or cut the power supply off), just turning off the radio will not do it !!!

So it is a mess. I may have to get a junker HP laptop on eBay and dedicate it to run WSJT.


Bill, W8BC
 

I am not sure if this helps, but as I understand it both Catalina and Big Sur have drivers built in for Icom rigs. I am using my 705 with Big Sur and did not install a driver.
--
Bill
W8BC


km6hk@...
 

Thanks Bill, W8BC

well yes and no. I assume you are talking about "/dev/cu.usbserial-141410"  i am not sure where that driver comes from, it is unclear if Apple has placed it in the system or if it got onto your machine from some other load of an other device that you have used. Typically it is used in Arduino powered hardware. Youmight have it from a load of something like a weather station or a doorbell or whatever..
 
it may  work as a driver for our SL usb device, if it works then fine.. : to list the devices attached to you mac drop to a terminal window and run:
" system_profiler SPUSBDataType "
 
it may show: (or maybe not hihihi...)
 
CP2102 USB to UART Bridge Controller:
 
                  Product ID: 0xea60
                  Vendor ID: 0x10c4  (Silicon Laboratories, Inc.)
                  Version: 1.00
                  Serial Number: IC-7100 02005373 B
                  Speed: Up to 12 Mb/s
                  Manufacturer: Silicon Labs
                  Location ID: 0x14143000 / 18
                  Current Available (mA): 500
                  Current Required (mA): 100
                  Extra Operating Current (mA): 0
 
but just because the device is attached it is not certain that the driver  "/dev/cu.usbserial-141410" (I say again, a driver of unknown origin or functionality) will correctly and reliably run the device in a trouble free manner.   If it is running the SL Chip and WSJT is happy with it then GREAT !  If not then you are involved in the "great driver hunt"
 
 Hardware Drivers in OS X are typically in the form of Kernel Extensions and the primary location is /System/Library/Extensions/ however they can also be within an Application Bundle.  To see what Kernel extensions are loaded use the " kextstat " command in Terminal.  You can look for it there.
 
Or you could open a tech support ticket with SL.  ~No, Wait.. I will save you the trouble. I have done that and got this nice generic "go to hell" response from them:
 
=============
Hi KM6HK,
 
Thank you for contacting to Silicon Labs technical support. This reply is in regards to the SF case 00260351.
 
According to your information, your product is ICOM RADIO (model IC7100), that is a third party product which integrates Silicon Labs product. And, it sounds like you are experiencing problems with this product due to some update from Mac OS. In this case, we ask that you contact the original manufacturer of the product, and if necessary, those companies can work with Silicon Labs to resolve this issues. This policy is explained and there are other tips and techniques described in the following knowledge base article: 
 
https://www.silabs.com/community/interface/knowledge-base.entry.html/2014/10/03/troubleshooting_apr-10iL.html
 
Have you contacted the manufacturer of your device for assistance with this matter? 
 
Thank you, and please let me know if you have any questions. 
 
Best Regards,
Vuong Ngo
==================
 
 


Bill, W8BC
 

On Mon, Mar 8, 2021 at 12:47 PM, <km6hk@...> wrote:
I assume you are talking about "/dev/cu.usbserial-141410"
I am using /dev/cu.usbmodem143201
for both WSJT-X and MacLoggerDX, a Mac logging program. I am not aware that I have installed any special programs beyond MS Office, a database called FileMaker and a Bible software program called Accordance. But I cannot be sure about that. Oh, yes, Graphic Converter. Certainly, there could be others.

So far everything has run smoothly.

I bow to your expertise on this since all this is beyond me. When I first started using WSJT-X back in December I was looking to load the Silicon Labs driver, but was told my numerous folks that both Catalina and Big Sur had drivers built in for my 705 and other Icom rigs. I got this from DL2RUM, of RumLog software and others. Here is what the MacLoggerDX site says: 

Native DriverKit Support:

Apple released Big Sur with built-in support for many (but not all) serial devices.

Big Sur DriverKit currently supports the following devices without any 3rd party driver: 
  • FTDI: Most devices tested so far with standard VID/PID including...
    • KX3
    • K9JM CI-V Router
    • WinkeyUSB
    • Generic UART cables
    • dext in development.

  • Silicon Labs:
    • CP2102 (Icom IC-7610, IC-7300, IC-9700, TS-590 etc.) 

  • Prolific: Most devices tested so far.

Big Sur 
DriverKit does not currently support the following devices without a 3rd party driver:
  • Silicon Labs 
    • CP2105 (Yaesu FT-991, FTdx101, etc.)

  • Keyspan/TrippLite USA-19HS

I wish we had a very definitive word on this situation with the Mac. I see that some folks are having problems figuring out what to do. Thanks again for your input.
--
Bill
W8BC


km6hk@...
 

On Mon, Mar 8, 2021 at 03:31 PM, Bill, W8BC wrote:
I wish we had a very definitive word on this situation with the Mac

I think you have hit on the core of this issue for us end users, that is that the developers  of the software and makers of the hardware that incorporates the product from the chip manufacturers,  all of them are just not documenting how the end user should correctly approach configuring their release versions. The details of necessary drivers and end user configuration details is just not documented at the release point of a final product intended to be run by end users. There is something off center about that.    In all fairness to them, I understand that there is no budget ($$) for this. For example, the release of WSJT for mac is a volunteer effort with Zero cash flow, as far as Icom is concerned they have never represented that a IC7100 will talk to a mac OS so that lets them 'off-the-hook', and SL is saying 'hey we just make the chips we can not possibly track every use that it is put to as the numbers of eventual implementations are huge'..   so everyone  (including Apple) runs for cover, and that leaves us end-users in the real world to fend for ourselves and patch together something that 'sort-of works'.   -Luckily, it is just a hobby.  :-)

It is interesting that your machine is showing 143201. So there seems to be a numbered sequence of drivers showing up on these machines.  Humm, it does seem that Apple might be folding these drivers into its releases. But they do not admit to any numbered sequences like that in any documentation that I can find. They play the same game as SL, that is: if you ask them and they say "don't ask us".. That has got to be the most irritating part of all this, as I DID pay Apple for their hardware.


Bill Somerville
 

On 09/03/2021 04:02, km6hk via groups.io wrote:
On Mon, Mar 8, 2021 at 03:31 PM, Bill, W8BC wrote:
I wish we had a very definitive word on this situation with the Mac

I think you have hit on the core of this issue for us end users, that is that the developers  of the software and makers of the hardware that incorporates the product from the chip manufacturers,  all of them are just not documenting how the end user should correctly approach configuring their release versions. The details of necessary drivers and end user configuration details is just not documented at the release point of a final product intended to be run by end users. There is something off center about that.    In all fairness to them, I understand that there is no budget ($$) for this. For example, the release of WSJT for mac is a volunteer effort with Zero cash flow, as far as Icom is concerned they have never represented that a IC7100 will talk to a mac OS so that lets them 'off-the-hook', and SL is saying 'hey we just make the chips we can not possibly track every use that it is put to as the numbers of eventual implementations are huge'..   so everyone  (including Apple) runs for cover, and that leaves us end-users in the real world to fend for ourselves and patch together something that 'sort-of works'.   -Luckily, it is just a hobby.  :-)

It is interesting that your machine is showing 143201. So there seems to be a numbered sequence of drivers showing up on these machines.  Humm, it does seem that Apple might be folding these drivers into its releases. But they do not admit to any numbered sequences like that in any documentation that I can find. They play the same game as SL, that is: if you ask them and they say "don't ask us".. That has got to be the most irritating part of all this, as I DID pay Apple for their hardware.

Bill,

please do not state that the WSJT-X development team have not specified how to select audio and CAT control devices. This is very straightforward as WSJT-X uses the devices offered by the operating system, if they are not presented then there is no documentation we can add within the domain of WSJT-X that will fix that.

Please refer to the manufacturers of any hardware such as rigs with built in USB connections for support if the relevant interface devices are not presented by the operating system.

73
Bill
G4WJS.


scott@kb5uzb.radio
 

I think you just did exactly what he was talking about. Which makes sense. Everyone supports things up to the edge of their domain. This is expected due to the expense that would be incurred by trying to support every possible use case for your device/driver/software/etc.

The challenge with that model is that when something goes wrong with an integration it's very difficult for an end user to determine where the real issue is and the hardware and software developers tend to lean on "it must the other guy's issue, our stuff does what we designed it to" without a lot of guidance in the troubleshooting realm. (Dang, that was a long sentence). It's in those grey areas of integration where we depend upon forums like these. And a boatload of trial and error.


Bill, W8BC
 

On Tue, Mar 9, 2021 at 05:19 AM, Bill Somerville wrote:

Bill,

please do not state that the WSJT-X development team have not specified how to select audio and CAT control devices.

Bill Somerville,
I assume you are referring to me. I do not believe I said any such thing. At least, I know I did not intend to do so. If my words implied or indicated such, then please forgive me. When I said, "I wish we had a very definitive word on this situation with the Mac," I was referring to whether or not the drivers for using WSJT-X are already included in the Mac operating systems, Catalina and Big Sur. I have been told by a number of folks that they are,  and thus there is no need to install another driver. Some Mac users on this forum, if I understand what they are saying, have not found that to be the case. That is what I was referring to about a "definitive word."
 
--
Bill
W8BC


km6hk@...
 

On Tue, Mar 9, 2021 at 08:18 AM, scott@... wrote:
And a boatload of trial and error.
Yes, I agree,  it is up to the end user to trial and error his way through this moving target mess:  
 
The developers themselves can not keep up across all the platforms  in which these USB chips are used:  That is just an impossible task for which there is no budget.  Note the time date stamps here: some drivers are released one day and two days later a follow in revision is released (12/02/19 - 12/6/19 for example) 
 
This  following list is just from SL, it does not even include the now supposed interspersed  Apple contributions (that I guess Apple is spinning up in house and dropping in releases themselves, again without any announcement & documentation ???) 
 
Just a side note:  If you think that the  end-user solution is simple, i.e. you just use the latest driver release and you are good to go, well guess again folks, why do you think all revision instructions carry the famous warning "back up your installation before proceeding."   MY FOLLOWING COMMENT IS IMPORTANT !!:  I have found that there are destructive interactions if certain multiple drivers are loaded, for example, I had rev: SL5.3.5 loaded and did get it to work for a short period of time with a fresh boot of the macOS and a power off state of the IC7100, But if the Apple /dev/cu.usbserial-141410 was side loaded, the whole system went into cripple mode, in that case when sometimes after a boot of the mac things would work, other times, not.   it was almost random just a guessing game "will WSJTX work today?, oh, darnm it's got a case of driver indigestion, let it rest for a while and try again.. hiihihi :-)  Or experiment with removing drivers one a time, and adding others.. FYI: at this time (on my system, your milage may vary)  i have removed ALL SL  drivers and only able to get the system to work from a full power off state using  only /dev/cu.usbserial-141410.
 
 
Release Dates
-------------
 
CP210x Macintosh OS VCP Driver 6.0       - December 18, 2020
CP210x Macintosh OSX VCP Driver 5.3.5    - February 25, 2020
CP210x Macintosh OSX VCP Driver 5.3.2    - January 27, 2020
CP210x Macintosh OSX VCP Driver 5.3.0    - January 20, 2020
CP210x Macintosh OSX VCP Driver 5.2.4    - December 13, 2019
CP210x Macintosh OSX VCP Driver 5.2.3    - December 6, 2019
CP210x Macintosh OSX VCP Driver 5.2.2    - October 2, 2019
CP210x Macintosh OSX VCP Driver 5.2.1    - September 9, 2019
CP210x Macintosh OSX VCP Driver 5.2.0    - July 11, 2019
CP210x Macintosh OSX VCP Driver 5.1.1    - July 1, 2019
CP210x Macintosh OSX VCP Driver 5.1.0    - May 23, 2019
CP210x Macintosh OSX VCP Driver 5.0.10   - March 27, 2019
CP210x Macintosh OSX VCP Driver 5.0.9    - February 13, 2019
CP210x Macintosh OSX VCP Driver 5.0.7    - December 17, 2018
CP210x Macintosh OSX VCP Driver 5.0.6    - September 17, 2018
CP210x Macintosh OSX VCP Driver 5.0.5    - July 13, 2018
CP210x Macintosh OSX VCP Driver 5.0.4    - January 19, 2018
CP210x Macintosh OSX VCP Driver 5.0.3    - November 21, 2017
CP210x Macintosh OSX VCP Driver 5.0.2    - October 12, 2017
CP210x Macintosh OSX VCP Driver 5.0.1    - Aug 25, 2017
CP210x Macintosh OSX VCP Driver 5.0      - Aug 3, 2017
CP210x Macintosh OSX VCP Driver 4.11.2   - June 16, 2017
CP210x Macintosh OSX VCP Driver 4.11.1   - May 26, 2017
CP210x Macintosh OSX VCP Driver 4.11.0   - May 2, 2017
CP210x Macintosh OSX VCP Driver 4.x.17   - March 23, 2017
CP210x Macintosh OSX VCP Driver 4.x.16   - Feb 3, 2017
CP210x Macintosh OSX VCP Driver 4.x.15   - December 19, 2016
CP210x Macintosh OSX VCP Driver 4.x.14   - November 3, 2016
CP210x Macintosh OSX VCP Driver 4.x.13   - August 31, 2016
CP210x Macintosh OSX VCP Driver 4.x.12   - June 15, 2016
CP210x Macintosh OSX VCP Driver 4.x.11   - May 26, 2016
CP210x Macintosh OSX VCP Driver 4.x.10   - April 6, 2016
CP210x Macintosh OSX VCP Driver 4.x.9    - March 28, 2016
CP210x Macintosh OSX VCP Driver 4.10.8   - March 2, 2016
CP210x Macintosh OSX VCP Driver v3.1     - December 6, 2012
 
 
CP210x Macintosh OS Driver Revision History
--------------------------------------------
Version 6.0
Adds VID/PID for NECYD NLTAIR cp2105
Supports macOS Big Sur with implementation of DriverKit extension
Version 5.3.5
Adds VID/PID for QIVICON ZigBee Device, eq-3 HmIP USB, and BitronVideo Zigbee
Addresses additional flow control bug.
Version 5.3.2
Adds a lock to syncrhonize power event handling, state changes, 
and driver unload to prevent an error.
Version 5.3.0
Corrects an issue with state maintenance for the CTS, DSR, DCD lines.
Version 5.2.4
Corrects a compatbility issue with MacOS 10.13 and earlier
Version 5.2.3
Corrects issues with the installer.
Version 5.2.2
Adds VID/PID for RF Code.
Version 5.2.1
Fixes a problem with the installer that prevents it from working
correctly wiht MacOS 10.15 Catalina.
Version 5.2.0
Fixes a bug in the installer that prevented it from working properly
on MacOS 10.11 and 10.12
Fixes a bug in the driver that could corruption requiring a reboot 
if an attempt was made to unload the driver while a device was plugged
in and using it
Version 5.1.1
The driver now has a new installer intended to reduce user confusion 
Added VID/PIDs for ST Link.
Version 5.1.0
The driver is now Notarized for support of MacOS 10.14.5 and up. 
See Apple Developer documentation about Notarization for more information.
Added VID/PIDs for DECAGON DEVICES.
Version 5.0.10
Added VID/PID for Sony Corporation.
Version 5.0.9
Added VID/PID for TAMRON Co., Ltd.
Version 5.0.7
Added VID/PID for GWinstek.
Version 5.0.6
Added Alternative Silicon Labs VID/PID Sets.
Version 5.0.5
Added VID/PID for RS DYNAMICS.
Version 5.0.4
Added VID/PID for PICARO.
Version 5.0.3
Added VID/PID for Lunatico Astronomia.
Version 5.0.2
Added VID/PID for Sony Corporation.
Version 5.0.1
Bug fixes.
Version 5.0
Adds support for GPIO control.
Updated for compatibility with MacOS 10.11 Kernel driver APIs. 
This is a significant update to this driver.
Version 4.11.2
Added VID/PID for Notch Dock.
Version 4.11.1
Added VID/PID for HUSBZB-1: GoControl QuickStick Combo.
Version 4.11.0
Fixed an issue that would cause the CP2102N to hang when a user space application disconnects while the device is receiving data.
Version 4.x.17
Added VID/PID for METER USB.
Version 4.x.16
Added VID/PID for Zero-Click.
Version 4.x.15
Added VID/PID for NETGEAR.
Version 4.x.14
Added VID/PIDs for Planar UltraRes.
Added VID/PIDs for Coolon USB.
1Version 4.x.13
Added VID/PIDs for Brim Brothers Ltd.
Added VID/PIDs for 3D Tek
Version 4.x.12
Added VID/PIDs for Juniper Networks, Inc.
Added VID/PIDs for FluxData, Inc.
Version 4.x.11
Corrected VID/PIDs for Findster Technologies, SA.
Version 4.x.10
Added VID/PIDs for Mark-10 Corp.
Version 4.x.9
Added VID/PIDs for Findster Technologies, SA and for CMA.
Version 4.x.8
Added VID/PIDs for ETS-Lindgren.
Version 4.x.7
Added VID/PID for Sekonic and DASCOM.
Minor fix to postflight script for 64 bit 10.8 and below OS's.
Version 4.x.6
Added VID/PIDs for Vorze and Cadex Electronics.
Version 4.x.5
Added VID/PIDs for California Eastern Labs and Micro Computer Control Corp.
Version 4.x.4
Added VID/PIDs for Zonge International, AES GmbH, SPORTident GmbH
Version 4.x.3
Added VID/PID for Aruba Networks, Inc.
Version 4.x.2
Added VID/PID for ARKRAY, Inc.
Version 4.x.1
Added VID/PIDs for BodyCap, RTKWARE, and West Mountain Radio
Added uninstaller script to DMG
Installer now runs uninstaller script before executing install - removes older versions using previous naming scheme
Dropping support for OS X 10.4.  If you require OS X 10.4 support, please install version 3.1 of the VCP driver
Version 4.x.0
Added OSX 10.9 and 10.10 driver support with signed kernel extension
Updated version numbering - 2nd digit represents target OS versions
4.7 - OSX 10.7 and older, 32 bit
4.8 - OSX 10.8 and older, 64 bit
4.10 - OSX 10.9 and 10.10, 64 bit, signed kext
Updated version numbering - 3rd digit represents VID/PID updates.  Customers not needing the new VID/PID do not need to update drivers for 3rd digit changes.
Installer will now only install the proper matching kernel extension instead of both the 32 bit and 64 bit versions.
Version 3.1
Added support for CP2108
Version 3.0
Corrected issue where transmission would stop when a 0 length packet was sent
incorrectly on aligned packet boundaries
Version 2.9
Corrected issue with Baud Rates not being set properly if they were greater 
than 230400 on PPC or Intel platforms
Corrected an issue where a device might get stuck when coming out of sleep mode
Corrected an issue on PPC where Baud Rates were not getting set properly
Added enhanced support for sleep, now reads state on sleep and writes state on
wake to provide smoother and more stable state transitions
Version 2.7
Corrected issue with initial Stop Bits value
Corrected issue which seen which switching between 32 and 64 bit mode and trying
to use the driver in each mode
Added in a clear stall to be more complete in invalid control transfers
Version 2.6
Corrected all known Kernel Panics for 10.4/5/6 for surprise removal and data
transmission
Corrected an issue with data drop while using XON/XOFF flow control
Corrected RTS/DTR toggling sync issue
Version 2.2
Corrected Kernel Panic in Snow Leopard which would randomly occur after
transmission
Modified DTR pin to toggle on open and close instead of on insertion
Modified driver to load without showing the Network Connection Dialog
Modified driver to allow toggling of RTS and DTR pins
Added 64 bit support for Snow Leopard
Version 2.1
Corrected device strings that were changed in the 2.0 release back to the
format used in pre-2.0 drivers
Version 2.0
Driver architecture updated.
Version 1.06
Corrected a bug which causes a Kernel Panic with a Baud Rate of 0, yileding
a Divide-By-Zero erro
Version 1.04
Updated to support newer versions of Mac OSX
Version 1.02
Updated to support the Intel platform through a universal binary that
also supports PowerPC.
Version 1.00
Initial Release
 


Bill Somerville
 

On 09/03/2021 18:03, Bill, W8BC via groups.io wrote:
On Tue, Mar 9, 2021 at 05:19 AM, Bill Somerville wrote:

Bill,

please do not state that the WSJT-X development team have not specified how to select audio and CAT control devices.

Bill Somerville,
I assume you are referring to me. I do not believe I said any such thing. At least, I know I did not intend to do so. If my words implied or indicated such, then please forgive me. When I said, "I wish we had a very definitive word on this situation with the Mac," I was referring to whether or not the drivers for using WSJT-X are already included in the Mac operating systems, Catalina and Big Sur. I have been told by a number of folks that they are,  and thus there is no need to install another driver. Some Mac users on this forum, if I understand what they are saying, have not found that to be the case. That is what I was referring to about a "definitive word."
 
--
Bill
W8BC

Hi Bill,

no, I was replying to this message:

https://wsjtx.groups.io/g/main/message/23083

73
Bill
G4WJS.


Frederick Kent
 

I’m having a terrible time trying to get WSJTx going. The problem so far is with getting the CP210X driver installed correctly in my iMac computer.  The driver installs OK like it supposed to do in extensions and from what I’ve learned from others is that it needs to be listed in a utility terminal “ls /dev” for the WSJTx to recognize it. It is not. I’ve tried to load the  latest version of the driver for Mac from the SLab website and a legacy version that others have recommended to no avail. I’ve had many eMail conversations with SLab and Apple on the phone and Icom emails.. Has anyone ever had a similar problem and offer any advice on a solution to this issue?


Buddy Morgan
 

I had not used my Mac (2.6 GHz 6 Core i-7, with 16 Gb of RAM, running Big Sur 11.4), with WSJT, in several months. I installed 2.4, got the shared memory error message - which I corrected. Downloaded the latest drivers, from the Silicon Labs website. Followed all the directions, both the drivers and WSJT. I wanted to use my Mac with my new IC 705. Set up WSJT, for the '705. Worked first time. Please note that on the "Radio" Tab, in the WSJT software, the port for the radio now reads: /dev/cu.usbmodem142201 - which is much different, the familar "slab" devices, that I previously saw in the dropbox.

Buddy WB4OMG


-----Original Message-----
From: Frederick Kent <nd4dx@...>
To: main@WSJTX.groups.io
Sent: Sun, Jun 20, 2021 2:51 pm
Subject: Re: [WSJTX] #mac Support for Icom radio Silicon Labs a big issue getting bigger all the time

I’m having a terrible time trying to get WSJTx going. The problem so far is with getting the CP210X driver installed correctly in my iMac computer.  The driver installs OK like it supposed to do in extensions and from what I’ve learned from others is that it needs to be listed in a utility terminal “ls /dev” for the WSJTx to recognize it. It is not. I’ve tried to load the  latest version of the driver for Mac from the SLab website and a legacy version that others have recommended to no avail. I’ve had many eMail conversations with SLab and Apple on the phone and Icom emails.. Has anyone ever had a similar problem and offer any advice on a solution to this issue?





David VK3DRH
 

Hi Frederick,

An alternative is not to use the Silab drivers.

With the changes Apple made to MacOS extensions with Catalina (or was it Mojave?), I de-installed the Silab drivers and now let MacOS use it's inbuilt drivers. I've not had a problem and can connect seamlessly to any of my Icoms ('7610, '9700 and 'R8600). I have a 2017 tbMBP with Big Sur.

73,    David VK3DRH


Ray
 

I agree. I am using Mac installed drivers with no issues, IC 7100 and IC 7300. When I upgraded the Mac OS it uninstalled the previous drivers that are no longer needed. RUMlogNG 

Ray
W8LYJ


Frederick Kent
 

That sounds great David, but how does one get these Apple OS drivers that are now with the Catalina OS to install or whatever do work with the WSJTx? I've been struggling with getting
WSJTx to work off and on for years, and feel like a complete idummy that something the rest of the world finds so easy to be a complete disaster to me. Thanks for any help you can offer. Fred ND4DX
the WJ