Connection issues Comport to RT84

[ve3tos]

I have run into a issue with getting my RT84 to connect. I have the cable that came with the Radio and also one of those octopus programming cables (multi radios). The cable that came with the Radio I was able to read from the radio with the Rt84 CPS. I was playing around with Zadig application and it's lost the connection to read the radio. The octopus cable I have not been able to get it to work.

I installed OpenGD77 CPS and haven't been able to get that to work. Using Zadig I got the Comport to come up with the cable(radio), but it's not been able to read anything from the radio.

I am pretty techsavvy but this one has got me scratching my head. Maybe I'm missing a step getting it to work. I have tried a few drivers and maybe thats my problem that I have messed up what driver is being picked up

I'm using Windows 10.

dwSb8jv.png (111.97 KiB) Viewed 3075 times

[VK3KYY]

Why did you use Zadig.

The CPS installs a com driver via a 3rd party installer exe
The DFU driver is automatically installed by windows

Revert all the devices you changed with Zadig back to their original drivers

[G4EML]

I think those multi headed cables have a USB to serial chip in them. That is wrong for the OpenGD77 radios and will never work.

The correct cable is just wires, with no electronics. The USB device is in the radio itself.

[ve3tos]

I did a number of plug the radio in DFU and anytime I saw a driver install in the device manager I uninstalled it . Did this until it seemed to have removed all the other drivers. I uninstalled OPENGD77 CPS and reinstalled it and still not giving me any comports. Below is what the driver comes up with .

Why did you use Zadig.

The CPS installs a com driver via a 3rd party installer exe
The DFU driver is automatically installed by windows

Revert all the devices you changed with Zadig back to their original drivers

[ve3tos]

Noticed that, I have only been using the cable that came with the radio going forward.

I think those multi headed cables have a USB to serial chip in them. That is wrong for the OpenGD77 radios and will never work.

The correct cable is just wires, with no electronics. The USB device is in the radio itself.

[SA0BUX]

I have never noticed that my Windows machines (7/10/11) have installed a DFU driver that works with the CPS automatically, I have
always needed to install the DFU drivers manually, either some from the manufacture or that I installed the latest one from STM that is part
of https://www.st.com/en/development-tools ... 32080.html

Tested on a Windows 11 and removed the driver completely , now I get the "Digital Radio in USB mode" , update driver etc. doesn't resolve it.
I can ofc specify the install path where I have the driver but then it use my downloaded one.

As I said in another thread , the STM DFU driver which has no updates after Windows 10 could be a problem in the future if later Windows versions cease to accept Win10 drivers.

[ve3tos]

Installed ST drivers and same results. Uninstalled GD77 CPS and reinstalled to see if anything changed and no-go.

I have never noticed that my Windows machines (7/10/11) have installed a DFU driver that works with the CPS automatically, I have
always needed to install the DFU drivers manually, either some from the manufacture or that I installed the latest one from STM that is part
of https://www.st.com/en/development-tools ... 32080.html

Tested on a Windows 11 and removed the driver completely , now I get the "Digital Radio in USB mode" , update driver etc. doesn't resolve it.
I can ofc specify the install path where I have the driver but then it use my downloaded one.

As I said in another thread , the STM DFU driver which has no updates after Windows 10 could be a problem in the future if later Windows versions cease to accept Win10 drivers.

[SA0BUX]

If your radio works in DFU mode with Retevis RT84 CPS and Retevis DMR Firmware Download it should also work OpenGD77 CPS Firmware Loader.

Radios with Retevis firmware use the ST DFU driver both for config and firmware updates.
OpenGD77 use another usb serial driver for config and the ST DFU driver for firmware updates in RT84/DM1701 (also RT3S,RT90 etc)

Here is the latest DFU drivers from ST https://www.sa0bux.se/Ham/opengd77/Dfus ... rivers.zip
(Taken from the "en.stsw-stm32080.zip" Dfuse demo programmer.

[VK3KYY]

STM have not thought carefully when they changed their DFU driver

They replaced the DFUSe program with a new program called STCubeProgrammer with a completely different driver.

This means that all existing applications, including the official loaders from TYT/Baofeng/ Retevis will not work if Windows 11 installs the latest STM DFU driver

To complicate things, at the moment Windows 10 seems to install the previous driver, so we can't rewrite the CPS to use the new driver because it won't work on Windows 10

We may have to bundle the old DFU driver as part of the CPS even though I'm not sure about distribution license of the old DFU driver

I can't see a technical reason why STM would have needed to completely change the API to their driver when they released the new version. They could have simply added new functions, but instead they decided cause all existing loaders to stop working


Edit.

Just to make matter more complicated.
STM have not released and examples of how to use their new driver using the C# language, which we use for the CPS and which is used by most new Windows application development

STM themselves seem to be using Java for their STM32CubeProgrammer application, which I presume they used because its cross platform, but that doesn't help us.

Edit 2

For references purposes relating to interfacing to the new driver

https://stackoverflow.com/questions/623 ... 1#62924001

and

https://github.com/jimfred/PyCubeProgrammer_API

[ve3tos]

I think I have it working, will update shortly....