Call Search
     

New to Ham Radio?
My Profile

Community
Articles
Forums
News
Reviews
Friends Remembered
Strays
Survey Question

Operating
Contesting
DX Cluster Spots
Propagation

Resources
Calendar
Classifieds
Ham Exams
Ham Links
List Archives
News Articles
Product Reviews
QSL Managers

Site Info
eHam Help (FAQ)
Support the site
The eHam Team
Advertising Info
Vision Statement
About eHam.net

donate to eham
   Home   Help Search  
Pages: [1]   Go Down
  Print  
Author Topic: Programming radios through USB - which cable? Which port?  (Read 5755 times)
KI6KQD
Member

Posts: 5




Ignore
« on: November 02, 2013, 12:15:01 PM »

Whenever I try to program my VX-7R with VX-7 Commander, I get a

Run-time error '8002':

Invalid Port Number.

I'm running Windows 8.1 on a three-month-old Dell Inspiron XPS8700. I can't run VX-7 Commander (or FTB8800 for that matter) on my old machine now running Win 8.0 - that machine doesn't even recognize the interface cable, since it won't install the driver software. Both interface programs used to work on the old machine with Win 7.

Any suggestions - which com port should I be addressing, should I use a different interface cable (got the one for VX-7R on ebay), should I use a different VX-7R memory interface program?

I really don't want to re-program all my rigs by hand. I've moved to a different state, and that's why I'm going through all this. I have an MSEE degree and years of design experience with analog I.C.s, but trying to get software to respond to a 'phantom' COM port through USB has me stumped.

Thanks.
Logged
KK6GYJ
Member

Posts: 10


WWW

Ignore
« Reply #1 on: November 04, 2013, 01:24:33 PM »

Hello,  I do not have Yaesu radios,  But I did some checking on Jim Mitchell's web site,  I do not see any reference to Windows 8 support.  I also did not see an email address to contact him.  If you could run VX-7 commander on Windows 7 then more than likely it is not a cable issue but more than likely a driver issue.

I would try CHIRP I checked their site and someone did report an issue with Windows 8,  Maybe this issue has been fixed with a newer version of CHIRP

Interface seems similar.

Good luck with your programming

73

Joe KK6GYJ
Logged

// ------------------------------------------------------------
Old C Programmers never die, they just get a new function pointer
WD8KNI
Member

Posts: 173




Ignore
« Reply #2 on: November 06, 2013, 01:37:26 AM »

Don't know what works from one version of Windows to another..  Most times Microsoft is not compatible with itself.. with that said,

Make sure you have the proper driver installed for the USB/Serial device you are using.  Many devices are sold and listed as a Proliant chipset, but are not.. found that out the hard way.. The correct driver is critical, check with the manufacturer.

From that point forward, you may have to just try other com ports.  I have seen USB/Serial devices that are set up as Com Port 5 and respond to 8.. 

It is a mystery..  Unix/Linux for me..  I keep a virtualized windows 7 partition around to start when I need to program a radio.  good luck.. Fred
Logged
KK6GYJ
Member

Posts: 10


WWW

Ignore
« Reply #3 on: November 06, 2013, 10:29:03 AM »

Another thing you might want to try.  Connect the radio to the programming cable.  Open the device manager, Open the Ports (COM & LPT) tree and see if your phone is displayed in the list of devices.  If it is, a Com Port should be listed.  If the phone is not listed then more than likely it is a device driver issue.

If you have access to a friend with Windows 7 or earlier, try out the above steps to make sure it is not a cable issue.

If your phone can be seen on the earlier Windows OS, than more than likely it is a driver issue.

I would try CHIRP as I indicated above.

Thanks

73

Joe KK6GYJ

Logged

// ------------------------------------------------------------
Old C Programmers never die, they just get a new function pointer
N1DVJ
Member

Posts: 532




Ignore
« Reply #4 on: November 14, 2013, 04:45:01 AM »

Well, I don't have your machine and your hardware...

But USUALLY when old stuff won't work on new machines, it's the screwed up programmers at fault.

Ok, to be fair, it's the brain dead original concept of how com ports worked on early PCs that really at fault.  Then it's compounded by programmers who update their programs but still use the original brain dead routines to talk to a com channel.

I have YET to find a program that won't work when I install it generically but WILL work when I go into the computer and free up a low com port so the program can grab it. 

Come on people (programmers) get with the program.  Since Win95 it's actually EASIER to open the com port similar to how you do a file, and then you can use ANY com port with simple tricks.  Even virtual ports over a network.  (Like having your PC in your shack attached to your radio, then run the software on your laptop to COM123 virtual over your home network.  Just be careful of delays)

Over the years I've found I can divide software that uses COM ports into definite groups.

Those that use COM1 and 2 only

Those that use up to COM3 and 4 but only with IRQ tricks

Those that use up to COM8 but no more

Those that use up to COM9 but no more

Those that use up to COM99 but no more

Those that use up to COM255 but no more

I've been told there's two more dividing lines, but I haven't tried yet from personal experience.  One at COM768, and one at COM999. 

The jumps at 9, 99, and 999 are apparently because of an issue with 'string length' when the port is defined in some high level languages like Delphi.  COM99 to COM100 adds 1 to the string length.

If you are having trouble using com ports, try dropping below one of the cutoff lines I just mentioned and see if that works.
Logged
N1DVJ
Member

Posts: 532




Ignore
« Reply #5 on: November 14, 2013, 04:55:08 AM »

Oh, another gotcha.  This seems to be more of a problem with Vista and later, including the WIN7 and WIN8 variants.

Sometimes a 'prompt' screen will be put up when installing drivers.  However, with Vista and later there seems to be a conflict with priorities or focus.  As a result, a 'prompt' to press enter to otherwise interact with a driver install can be placed BEHIND the install screen.  Since the computer is prompting you, and you aren't responding, it appears to freeze.  If you kill the install, the prompt screen disappears and you never realize all was right with the world, it was just waiting for you.  I've seen this happen with some of the 'custom' cables that use generic chip sets but with a custom attribute descriptor space.  I've also seen it with some languages and development systems. 

It's an easy fix.  If something won't install and the computer looks frozen, try to 'drag' the install window out of the way and see what might be behind it.  Then you can click on the install prompts and it should proceed.

And another small issue...  Some older software really chokes with the size of the drives on current machines.  Software that wants to make sure there's 10Meg of space to install just goes into fits when it see 200000Meg of space free.  The math can blow up and crash the system.  It's not the computers fault, it's the programmer!  In that case, sometimes it's easier to just install to a custom partition, or even a flash drive, to run the program.  (Although with flash drives commonly running in the Gigabyte sizes, it may not be that simple!)
Logged
Pages: [1]   Go Up
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!