Issues programming Vertex Standard VX-354 radios

Hello all, a fresh face here. I’ve recently acquired a large selection of uhf radios, mainly all the Vertex Standard VX-354 model. I am looking at changing the programmed settings on the radio as they are still programmed to the frequencies that the previous user used. I have downloaded the CE86 (version 1.31) and I have purchased the USB cable, however, when I try and download the current settings to my PC, to be able to edit them, it tells me that the handset is not connected. I’ve tried this on several different handsets, running as administrator (Windows 10), changing the COM port, installing specific drivers etc but still to no avail.

Was hoping to find someone with the knowledge of how the software works so that I can revive these great handsets and put them back to work again.

Thanks in advance.

Serth

A good place to start would be, if you haven’t already got it, get the user manual and any advanced/programming/tech reference material.

At the very least, you will probably find a reference to how to put the radio into programming mode and sub mode (where it may apply) for the actual transfer. There may be a reference about it in the UM, the other advanced docs will make more detailed and specify references to accessing it’s programming/engineering mode (some radios use the same level of connected access for both).

Until the radio, since it’s probably a virtual USB-Serial link method used, is in the right mode, chances are you won’t get the device manager entry you’re looking for and likewise the virtual port reference.

Even when you figured that stuff out, there’s a chance that a protection got enabled by prev programmer/tech to double ensure the anti-tamper vs reprogramming and if so (software will give a clue if such is enabled), bypassing that is a whole new game that (unlikely) could be as simple as an NVR flush/discharge, but since most equipment uses EPROM or eeprom for such storage along with low level settings, you’re into a headache territory best case.

I’ve no experience of the series, but the above is based on my global experience of ham and commercial and restricted-services specialist gear.

When you get programming issues ALWAYS try at least two other computers. Windows 10 seems so variable. I have one particular radio that will only programme on the computer in my recording studio. In the office are four pcs. None of these will programme it, I use three of those computers to programme radios. I’ve started putting coloured tape on the cables to remind me which one to use. One of customers was ready to give up with one radio and discovered a retevis cps would program it, not the manufactures proper one. I’ve discovered so many wierdnesses over the years. It’s a pain,

Thanks both for your replies. I have tried on multiple machines but still no luck. I have, however, discovered that the CE86 software I downloaded was version 1.xx but I believe I need to run 3.xx to program these specific radios. Struggling to find a source with the download file, and I am loathe to purchase the software as VS were offering it for free, back when they were still operating/operating fully, and I can’t find a contact email for any of them…

@Serth - Sounds a bit like one of the complexities DMR-X users had, where the often quoted methods were based on earlier CPS versions on gear with earlier FW, whereas a lot of the problem rigs had later FW (the radios marked DM-X vs DM1702B) and needed a different CPS revision.

Add what Paul mentions too, and really there’s no end to quirky reasons for comms failures or non-detection of devices.

But all things being equal and having the right match of revisions, it’s a case of run & go or ■■■■ - back in the day, when we used RS232 (real RS232 ports) and Unix/Linux/DOS and DOS/Win3x, it was actually less of a minefield. Especially with non-Win, it was just a matter of software accessing the connected device in a DTE-DTE or DCE-DTE. Connected manner and effectively the whole program you transferred got sent as a batch of plain ASCII plain text or using a binary transfer similar to how we used to upload/download via modems using XModem/YModem/ZModem protocols.

There were no obscure ‘virtual device’ and subsequent translations virtualization requires. It either worked or not, and failure was either through time-outs, power glitches, duff cables (intermittent connections) or wrong comms settings - aside from intermittents, which are always ■■■■, every other combo were easy to diagnose.

Needless to say, I never discarded old serial cards as there’s still a lot of gear that don’t play ball with USB-Serial adaptors.

But irrespective of how the transfer and interchange works, the equipment needs to be in the right mode else even if it appears on Device Manager as a com port or USB device such as a bidirectional printer, in the wrong mode (not in exchange/cloning/programming mode) the software won’t be able to communicate with device.

With real serial or JTAG ports on device, the port was usually live as long as the device was powered, hence why JTAG/TTL serial is the most commonly used device hacking direct route to sniffing and reverse engineering traffic.

Most of those router hacks you see, such as open source f/w replacements would probably never got built without some kind of reverse engineering based on low level access and traffic sniffing.

Good luck, i hope this doesn’t turn into a new DM-X equiv ongoing problem.