On Thu, Jan 2, 2014 at 9:11 PM, Michael Walker <va3mw@portcredit.net> wrote:

Hi Jim

I'm not sure what you are saying?

While the 888 might work with the V6, the only way around this would be to have Dan bypass the check. I don't see that as a driver issue as the only driver we are using is the one that controls the serial port, and we know that works.

Unless, I am missing something obvious, and that could actually happen based on todays history with the BF480 software! :) Is there an manual override?

Mike va3mw

Mike,

The "device driver" for the programming cable and the "driver" used by CHIRP to interface with a particular radio (or closely related radio family) are two completely different things.

The CHIRP "driver" is a small program or module that interfaces CHIRP with the particular Brand/Model of radio that it was written for. The UV-5R driver/module (uv5r.py), for example, knows how to initiate cloning with 4 different (but closely related) radios.

1 the original UV-5R
2 the UV-5R with BFB291 and later firmware
3 the F-11 from Import Communications
4 the UV-82

What you are calling a check is more like a "roll call". CHIRP asks for each type one-by-one until it gets an acknowledgement. When the acknowledgement is received, CHIRP then knows the radio exactly which type it is dealing with and begins the clone process. If no acknowledgement is received, then the dreaded "Radio did not respond" error is returned.

All I am saying is that most likely all that is needed for the BF-480 (and UV-6) to be supported by CHIRP is to have its "identity" added to the BF-888s driver's "roll call" list.

Jim KC9HI