[chirp_users] Another way Chirp can be tripped up by the OS
I've just started using Chirp with a Baofeng UV-5R and a USB serial adapter that Amazon claims is from Baofeng. The adapter has a genuine Prolific chip (or a darn good counterfeit), and Windows 7 Pro 64-bit recognizes it as a serial port; in addition, I can connect TxD to RxD at the radio plugs, open PuTTY, and see looped-back characters I have typed on the console. So far, so great.
However, neither Chirp nor baoclone could open the serial port the USB adapter was assigned to: COM19. Hmmm, 19? Sounds way high for a serial port enumeration. I reassigned the USB adapter to the vacant COM2, and hey presto! Both utilities are able to talk to the radio.
Sooo, beware of high-numbered COM ports.
Incidentally, is it normal for the UV-5R to key up when the serial cable is present? I'm going to make a practice of always having a dummy load connected when programming this radio.
Regards, Steve
On Thu, Mar 27, 2014 at 11:08 AM, Stephen Hersey n1xnxham@gmail.com wrote:
However, neither Chirp nor baoclone could open the serial port the USB adapter was assigned to: COM19. Hmmm, 19? Sounds way high for a serial port enumeration. I reassigned the USB adapter to the vacant COM2, and hey presto! Both utilities are able to talk to the radio.
Are you sure? You typed "COM19" into the Port field and it gave you some sort of error? What was the error message?
Incidentally, is it normal for the UV-5R to key up when the serial cable is present? I'm going to make a practice of always having a dummy load connected when programming this radio.
Welcome to the world of high-quality Chinese radios.
Tom KD7LXL
Stephen,
Incidentally, is it normal for the UV-5R to key up when the serial cable is present? I'm going to make a practice of always having a dummy load connected when programming this radio.
It is my experience that any RF reception breaking squelch on either of the channels during data transfer will likely fault the transfer. The receiver appears to be 'on' during data transfer.
Take the antenna off (instead of a dummy load) and/or tune to quiet channels for data transfer.
I suspect the issue is that any audio signal from the radio receiver get's blended with the data transfer signal being pushed in the thru the microphone jack, thus scrambling the data steam.
73 de Daniel KB3MUN
Incidentally, is it normal for the UV-5R to key up when the serial cable
is present? I'm going to make a practice of always having a dummy load connected when programming this radio.
I suspect the issue is that any audio signal from the radio receiver get's blended with the data transfer signal being pushed in the thru the microphone jack, thus scrambling the data steam.
see also note 3 at http://www.miklor.com/HT/HT-ErrorMess.php#error5 .
73 de Daniel KB3MUN
The cables my company got from Baofeng directly when buying a few hundred private labelled UV-5Rs do not keep the radio keyed when inserted or reading/writing. It keys it momentarily when plugged in, but it should not when fully inserted. It does not have a series PTT (its the sleeve on the 3.5mm), so your cable is incorrectly wired. Additionally, the cables we purchased were counterfeit Prolific chip-based so they required the older 3.2.0 driver (sourced from Miklor).
--Niklas
On Thu, Mar 27, 2014 at 11:08 AM, Stephen Hersey n1xnxham@gmail.com wrote:
I've just started using Chirp with a Baofeng UV-5R and a USB serial adapter that Amazon claims is from Baofeng. The adapter has a genuine Prolific chip (or a darn good counterfeit), and Windows 7 Pro 64-bit recognizes it as a serial port; in addition, I can connect TxD to RxD at the radio plugs, open PuTTY, and see looped-back characters I have typed on the console. So far, so great.
However, neither Chirp nor baoclone could open the serial port the USB adapter was assigned to: COM19. Hmmm, 19? Sounds way high for a serial port enumeration. I reassigned the USB adapter to the vacant COM2, and hey presto! Both utilities are able to talk to the radio.
Sooo, beware of high-numbered COM ports.
Incidentally, is it normal for the UV-5R to key up when the serial cable is present? I'm going to make a practice of always having a dummy load connected when programming this radio.
Regards, Steve
-- Steve Hersey N1XNX n1xnxham@gmail.com
Each of us has strengths and talents that others don't. Whether innate or learned, these are gifts -- and a gift not shared is a sad and lonely thing. Using our gifts for the benefit of all is an ethical obligation for every intelligent being. (The magic only works if you pass it on!)
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
Incorrect wiring? I'm afraid I find that a bit hard to believe. I've traced the circuitry on the adapter, and have compared it to the reference at http://www.miklor.com/UV_Technical.php and I've found the following:
1) The TX, RX, and ground lines are wired to the proper places on the twin plug (data to radio on sleeve of 3.5 mm plug, data from radio on ring of 2.5 mm plug, ground on sleeve of 2.5 mm plug 2) No other plug connections are present. 3) The data out to the radio is through a common-emitter NPN to ground with a 20K pullup to +5V. This last item might be questionable, as most other circuits I've seen are either pulled up to 3.3V or are left open-collector. Removing the pullup resistor didn't change the PTT keying behavior, BTW.
I'm not sure what you mean by "does not have a series PTT (its the sleeve on the 3.5mm)"; as I understand the diagram at miklor, the PTT line is also the serial data line into the radio. Can you clarify?
Thanks, Steve
On Thu, Mar 27, 2014 at 2:35 PM, Niklas Johnson niklas@ruggedradios.comwrote:
The cables my company got from Baofeng directly when buying a few hundred private labelled UV-5Rs do not keep the radio keyed when inserted or reading/writing. It keys it momentarily when plugged in, but it should not when fully inserted. It does not have a series PTT (its the sleeve on the 3.5mm), so your cable is incorrectly wired. Additionally, the cables we purchased were counterfeit Prolific chip-based so they required the older 3.2.0 driver (sourced from Miklor).
--Niklas
On Thu, Mar 27, 2014 at 11:08 AM, Stephen Hersey n1xnxham@gmail.comwrote:
I've just started using Chirp with a Baofeng UV-5R and a USB serial adapter that Amazon claims is from Baofeng. The adapter has a genuine Prolific chip (or a darn good counterfeit), and Windows 7 Pro 64-bit recognizes it as a serial port; in addition, I can connect TxD to RxD at the radio plugs, open PuTTY, and see looped-back characters I have typed on the console. So far, so great.
However, neither Chirp nor baoclone could open the serial port the USB adapter was assigned to: COM19. Hmmm, 19? Sounds way high for a serial port enumeration. I reassigned the USB adapter to the vacant COM2, and hey presto! Both utilities are able to talk to the radio.
Sooo, beware of high-numbered COM ports.
Incidentally, is it normal for the UV-5R to key up when the serial cable is present? I'm going to make a practice of always having a dummy load connected when programming this radio.
Regards, Steve
-- Steve Hersey N1XNX n1xnxham@gmail.com
Each of us has strengths and talents that others don't. Whether innate or learned, these are gifts -- and a gift not shared is a sad and lonely thing. Using our gifts for the benefit of all is an ethical obligation for every intelligent being. (The magic only works if you pass it on!)
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
I mean series PTT as similar to some radios (Motorola and ICOM) where the PTT closes the mic circuit, rather than a separate PTT signal line. I've never had any programming cable continually key the Baofeng radio's transmit function, using any of those Baofeng-supplied cables, a genuine Kenwood KPG-22U, or a DE9-2.5/3.5 homebrew cable I made in the past. Only the momentary TX key when inserting or when not fully inserted. Looking at the same link, there's a dual PTT function for the radios which may be a culprit. Testing by setting A or B specially in CHIRP when writing might show that the PTT is changing to the other displayed channel and transmitting.
According to the cable schematic and your interpretation, its possible for the cable to key the radio. I'm not disagreeing with that, nor that your cable is indeed causing the PTT to key. I'm not familiar how the radio's PTT circuit chooses to ignore serial data, but I'm only claiming I haven't experienced the behavior even in an edge case with validation/programming of large numbers of these.
An interesting side note is that one of the radios would phantom switch from displayed channel A to B bacn and forth a few times when programming, and also would indicate RX audio broke squelch when programming . This was only with a certain Baofeng cable, not the KPG-22u nor any other specific cable.
On Thu, Mar 27, 2014 at 11:55 AM, Stephen Hersey n1xnxham@gmail.com wrote:
Incorrect wiring? I'm afraid I find that a bit hard to believe. I've traced the circuitry on the adapter, and have compared it to the reference at http://www.miklor.com/UV_Technical.php and I've found the following:
- The TX, RX, and ground lines are wired to the proper places on the twin
plug (data to radio on sleeve of 3.5 mm plug, data from radio on ring of 2.5 mm plug, ground on sleeve of 2.5 mm plug 2) No other plug connections are present. 3) The data out to the radio is through a common-emitter NPN to ground with a 20K pullup to +5V. This last item might be questionable, as most other circuits I've seen are either pulled up to 3.3V or are left open-collector. Removing the pullup resistor didn't change the PTT keying behavior, BTW.
I'm not sure what you mean by "does not have a series PTT (its the sleeve on the 3.5mm)"; as I understand the diagram at miklor, the PTT line is also the serial data line into the radio. Can you clarify?
Thanks, Steve
On Thu, Mar 27, 2014 at 2:35 PM, Niklas Johnson niklas@ruggedradios.comwrote:
The cables my company got from Baofeng directly when buying a few hundred private labelled UV-5Rs do not keep the radio keyed when inserted or reading/writing. It keys it momentarily when plugged in, but it should not when fully inserted. It does not have a series PTT (its the sleeve on the 3.5mm), so your cable is incorrectly wired. Additionally, the cables we purchased were counterfeit Prolific chip-based so they required the older 3.2.0 driver (sourced from Miklor).
--Niklas
On Thu, Mar 27, 2014 at 11:08 AM, Stephen Hersey n1xnxham@gmail.comwrote:
I've just started using Chirp with a Baofeng UV-5R and a USB serial adapter that Amazon claims is from Baofeng. The adapter has a genuine Prolific chip (or a darn good counterfeit), and Windows 7 Pro 64-bit recognizes it as a serial port; in addition, I can connect TxD to RxD at the radio plugs, open PuTTY, and see looped-back characters I have typed on the console. So far, so great.
However, neither Chirp nor baoclone could open the serial port the USB adapter was assigned to: COM19. Hmmm, 19? Sounds way high for a serial port enumeration. I reassigned the USB adapter to the vacant COM2, and hey presto! Both utilities are able to talk to the radio.
Sooo, beware of high-numbered COM ports.
Incidentally, is it normal for the UV-5R to key up when the serial cable is present? I'm going to make a practice of always having a dummy load connected when programming this radio.
Regards, Steve
-- Steve Hersey N1XNX n1xnxham@gmail.com
Each of us has strengths and talents that others don't. Whether innate or learned, these are gifts -- and a gift not shared is a sad and lonely thing. Using our gifts for the benefit of all is an ethical obligation for every intelligent being. (The magic only works if you pass it on!)
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
-- Steve Hersey N1XNX n1xnxham@gmail.com
Each of us has strengths and talents that others don't. Whether innate or learned, these are gifts -- and a gift not shared is a sad and lonely thing. Using our gifts for the benefit of all is an ethical obligation for every intelligent being. (The magic only works if you pass it on!)
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
Aren't COM ports virtual? If so it wouldn't matter what the number was as long as the software recognized ports equal to or higher than your port. As far as the radio keying up when the plug is inserted, shut the radio off before you insert the plug. If it does key up then there is a problem with the cable or plug. I've never read of anyone having their radio key up after the plug was inserted.
Also unless you have 19 COM ports in use, any of them could be invalid. I think previous devices remain in the registry after use and the port can be easily forced to use over by your new device.
________________________________ From: Stephen Hersey n1xnxham@gmail.com To: chirp_users@intrepid.danplanet.com Sent: Thursday, March 27, 2014 2:08 PM Subject: [chirp_users] Another way Chirp can be tripped up by the OS
I've just started using Chirp with a Baofeng UV-5R and a USB serial adapter that Amazon claims is from Baofeng. The adapter has a genuine Prolific chip (or a darn good counterfeit), and Windows 7 Pro 64-bit recognizes it as a serial port; in addition, I can connect TxD to RxD at the radio plugs, open PuTTY, and see looped-back characters I have typed on the console. So far, so great.
However, neither Chirp nor baoclone could open the serial port the USB adapter was assigned to: COM19. Hmmm, 19? Sounds way high for a serial port enumeration. I reassigned the USB adapter to the vacant COM2, and hey presto! Both utilities are able to talk to the radio.
Sooo, beware of high-numbered COM ports.
Incidentally, is it normal for the UV-5R to key up when the serial cable is present? I'm going to make a practice of always having a dummy load connected when programming this radio.
Regards, Steve
On Thu, Mar 27, 2014 at 3:19 PM, Milton Hywatt mhywattt@yahoo.com wrote:
Aren't COM ports virtual? If so it wouldn't matter what the number was as long as the software recognized ports equal to or higher than your port.
AFAIK, COM ports are indeed virtual, so this is a puzzle to me. I have seen other software in the past (some of it mine) that had a limited range of port numbering, but that was an artifact of a GUI design. Chirp listed (only) the COM ports that were physically present in the system (COM1 and COM19), so I'm not inclined to think that Chirp was at fault here; I think it's Windows weirdness. To paraphrase an earlier commenter, "Welcome to the world of high-quality Redmond operating systems."
As far as the radio keying up when the plug is inserted, shut the radio off before you insert the plug. If it does key up then there is a problem with the cable or plug. I've never read of anyone having their radio key up after the plug was inserted.
Here's an interesting bit of additional information on the PTT question: If I open the COM port using PuTTY (terminal emulator), then power on the radio with the plug inserted, the PTT does NOT key up. If I then close the PuTTY session, the PTT keys up a few seconds afterward. The trusty DVM indicates that the TX data line to the radio is held at 0V both before and after the PuTTY session, and is high during the PuTTY session (except when I'm sending serial data). When I run Chirp, the PTT keying only happens before the upload or download starts, and resumes a few seconds after it ends.
This suggests that I'm not seeing a bad adapter or cable, but that one or both of the following two things is happening: 1) The much-despised Prolific chip (the real thing, as far as I can tell, or else they did a great job forging the logo and marking) is setting the TXD line to a break state when there's no port session in progress, and/or 2) the Windows 7 64-bit Prolific com adapter driver (version 3.4.62.293) is commanding the adapter's TXD line to a break state when there's no session in progress.
I'll try this out on a 32-bit Win7 system using the canonical Prolific driver version, and see if the break-state shenanigans still happen there.
Also unless you have 19 COM ports in use, any of them could be invalid. I think previous devices remain in the registry after use and the port can be easily forced to use over by your new device.
Indeed, if I need to do that, it would surely be possible.
AFAIK, COM ports are indeed virtual, so this is a puzzle to me. I have seen other software in the past (some of it mine) that had a limited range of port numbering, but that was an artifact of a GUI design. Chirp listed (only) the COM ports that were physically present in the system (COM1 and COM19), so I'm not inclined to think that Chirp was at fault here; I think it's Windows weirdness. To paraphrase an earlier commenter, "Welcome to the world of high-quality Redmond operating systems."
COM19 is perfectly valid, as is COM256.
Here's an interesting bit of additional information on the PTT question: If I open the COM port using PuTTY (terminal emulator), then power on the radio with the plug inserted, the PTT does NOT key up. If I then close the PuTTY session, the PTT keys up a few seconds afterward. The trusty DVM indicates that the TX data line to the radio is held at 0V both before and after the PuTTY session, and is high during the PuTTY session (except when I'm sending serial data). When I run Chirp, the PTT keying only happens before the upload or download starts, and resumes a few seconds after it ends.
This suggests that I'm not seeing a bad adapter or cable, but that one or both of the following two things is happening: 1) The much-despised Prolific chip (the real thing, as far as I can tell, or else they did a great job forging the logo and marking) is setting the TXD line to a break state when there's no port session in progress, and/or 2) the Windows 7 64-bit Prolific com adapter driver (version 3.4.62.293) is commanding the adapter's TXD line to a break state when there's no session in progress.
This is pretty much par for the course with these radios. It tends to be DTR leakage into the PTT circuit, which means regular serial signaling will occasionally cause the radio to transmit. This is, after all, a $20 device you paid $40 for...
I'll try this out on a 32-bit Win7 system using the canonical Prolific driver version, and see if the break-state shenanigans still happen there.
If I were you, I would not waste my time and set the radio to something it can't transmit on before you go into clone mode.
--Dan
Firstly, let me say a big THANK YOU to the chirp developers for building and giving away this excellent tool. It is greatly appreciated, and your generosity and dedication make this corner of the world a better place.
Dan, Thanks for your reply. I was about to take your advice to just select a non-TX channel and live with the odd things being done to the serial port state in the idle condition, but I took one last stab at it and loaded the Prolific 3.2.0.0 driver from Miklor (who deserve thanks as well), and the mystery PTT keying WENT AWAY. Victory is declared!
The moral of the story: Use the Prolific 3.2.0.0 driver in case of any doubt, even if the default driver used by Windows seems to work properly in all other respects.
Don't we just live in age of marvels? Indeed, these radios and interface cables are el cheapo devices and we can't expect polish and perfection from them. However, to be able to buy a decent-quality (if imperfect) radio for less than the price of dinner at a restaurant is rather astounding.
Best regards, Steve
On Thu, Mar 27, 2014 at 7:00 PM, Dan Smith dsmith@danplanet.com wrote:
AFAIK, COM ports are indeed virtual, so this is a puzzle to me. I have seen other software in the past (some of it mine) that had a limited range of port numbering, but that was an artifact of a GUI design. Chirp listed (only) the COM ports that were physically present in the system (COM1 and COM19), so I'm not inclined to think that Chirp was at fault here; I think it's Windows weirdness. To paraphrase an earlier commenter, "Welcome to the world of high-quality Redmond operating
systems."
COM19 is perfectly valid, as is COM256.
Here's an interesting bit of additional information on the PTT question: If I open the COM port using PuTTY (terminal emulator), then power on the radio with the plug inserted, the PTT does NOT key up. If I then close the PuTTY session, the PTT keys up a few seconds afterward. The trusty DVM indicates that the TX data line to the radio is held at 0V both before and after the PuTTY session, and is high during the PuTTY session (except when I'm sending serial data). When I run Chirp, the PTT keying only happens before the upload or download starts, and resumes a few seconds after it ends.
This suggests that I'm not seeing a bad adapter or cable, but that one or both of the following two things is happening: 1) The much-despised Prolific chip (the real thing, as far as I can tell, or else they did a great job forging the logo and marking) is setting the TXD line to a break state when there's no port session in progress, and/or 2) the Windows 7 64-bit Prolific com adapter driver (version 3.4.62.293) is commanding the adapter's TXD line to a break state when there's no session in progress.
This is pretty much par for the course with these radios. It tends to be DTR leakage into the PTT circuit, which means regular serial signaling will occasionally cause the radio to transmit. This is, after all, a $20 device you paid $40 for...
I'll try this out on a 32-bit Win7 system using the canonical Prolific driver version, and see if the break-state shenanigans still happen
there.
If I were you, I would not waste my time and set the radio to something it can't transmit on before you go into clone mode.
--Dan
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
Another Mystery of the UniV5Rse solved. :- )
John
From: chirp_users-bounces@intrepid.danplanet.com [mailto:chirp_users-bounces@intrepid.danplanet.com] On Behalf Of Stephen Hersey Sent: Friday, March 28, 2014 9:37 AM To: Discussion of CHIRP Subject: Re: [chirp_users] Another way Chirp can be tripped up by the OS
Firstly, let me say a big THANK YOU to the chirp developers for building and giving away this excellent tool. It is greatly appreciated, and your generosity and dedication make this corner of the world a better place.
Dan,
Thanks for your reply. I was about to take your advice to just select a non-TX channel and live with the odd things being done to the serial port state in the idle condition, but I took one last stab at it and loaded the Prolific 3.2.0.0 driver from Miklor (who deserve thanks as well), and the mystery PTT keying WENT AWAY. Victory is declared!
The moral of the story: Use the Prolific 3.2.0.0 driver in case of any doubt, even if the default driver used by Windows seems to work properly in all other respects.
Don't we just live in age of marvels? Indeed, these radios and interface cables are el cheapo devices and we can't expect polish and perfection from them. However, to be able to buy a decent-quality (if imperfect) radio for less than the price of dinner at a restaurant is rather astounding.
Best regards, Steve
On Thu, Mar 27, 2014 at 7:00 PM, Dan Smith dsmith@danplanet.com wrote:
AFAIK, COM ports are indeed virtual, so this is a puzzle to me. I have seen other software in the past (some of it mine) that had a limited range of port numbering, but that was an artifact of a GUI design. Chirp listed (only) the COM ports that were physically present in the system (COM1 and COM19), so I'm not inclined to think that Chirp was at fault here; I think it's Windows weirdness. To paraphrase an earlier commenter, "Welcome to the world of high-quality Redmond operating systems."
COM19 is perfectly valid, as is COM256.
Here's an interesting bit of additional information on the PTT question: If I open the COM port using PuTTY (terminal emulator), then power on the radio with the plug inserted, the PTT does NOT key up. If I then close the PuTTY session, the PTT keys up a few seconds afterward. The trusty DVM indicates that the TX data line to the radio is held at 0V both before and after the PuTTY session, and is high during the PuTTY session (except when I'm sending serial data). When I run Chirp, the PTT keying only happens before the upload or download starts, and resumes a few seconds after it ends.
This suggests that I'm not seeing a bad adapter or cable, but that one or both of the following two things is happening: 1) The much-despised Prolific chip (the real thing, as far as I can tell, or else they did a great job forging the logo and marking) is setting the TXD line to a break state when there's no port session in progress, and/or 2) the Windows 7 64-bit Prolific com adapter driver (version 3.4.62.293) is commanding the adapter's TXD line to a break state when there's no session in progress.
This is pretty much par for the course with these radios. It tends to be DTR leakage into the PTT circuit, which means regular serial signaling will occasionally cause the radio to transmit. This is, after all, a $20 device you paid $40 for...
I'll try this out on a 32-bit Win7 system using the canonical Prolific driver version, and see if the break-state shenanigans still happen there.
If I were you, I would not waste my time and set the radio to something it can't transmit on before you go into clone mode.
--Dan
While I too love this ubiquity and cost, I hope we all recognize there is very much a dark side to this, in terms of socio-economic and ecological realities...
From:chirp_users-bounces@intrepid.danplanet.com [mailto:chirp_users-bounces@intrepid.danplanet.com] On Behalf Of Stephen Hersey Sent: Friday, March 28, 2014 9:37 AM To: Discussion of CHIRP Subject: Re: [chirp_users] Another way Chirp can be tripped up by the OS Don't we just live in age of marvels? Indeed, these radios and interface cables are el cheapo devices and we can't expect polish and perfection from them. However, to be able to buy a decent-quality (if imperfect) radio for less than the price of dinner at a restaurant is rather astounding.
See, simple solution. I mentioned that to you as we recommend 3.2.0.0 because it is tried and true with the Prolific or counterfeit cable. Glad you got it sorted out.
Milton
________________________________ From: Stephen Hersey n1xnxham@gmail.com To: Discussion of CHIRP chirp_users@intrepid.danplanet.com Sent: Friday, March 28, 2014 9:37 AM Subject: Re: [chirp_users] Another way Chirp can be tripped up by the OS
Firstly, let me say a big THANK YOU to the chirp developers for building and giving away this excellent tool. It is greatly appreciated, and your generosity and dedication make this corner of the world a better place.
Dan,
Thanks for your reply. I was about to take your advice to just select a non-TX channel and live with the odd things being done to the serial port state in the idle condition, but I took one last stab at it and loaded the Prolific 3.2.0.0 driver from Miklor (who deserve thanks as well), and the mystery PTT keying WENT AWAY. Victory is declared!
The moral of the story: Use the Prolific 3.2.0.0 driver in case of any doubt, even if the default driver used by Windows seems to work properly in all other respects.
Don't we just live in age of marvels? Indeed, these radios and interface cables are el cheapo devices and we can't expect polish and perfection from them. However, to be able to buy a decent-quality (if imperfect) radio for less than the price of dinner at a restaurant is rather astounding.
Best regards, Steve
On Thu, Mar 27, 2014 at 7:00 PM, Dan Smith dsmith@danplanet.com wrote:
AFAIK, COM ports are indeed virtual, so this is a puzzle to me. I have
seen other software in the past (some of it mine) that had a limited range of port numbering, but that was an artifact of a GUI design. Chirp listed (only) the COM ports that were physically present in the system (COM1 and COM19), so I'm not inclined to think that Chirp was at fault here; I think it's Windows weirdness. To paraphrase an earlier commenter, "Welcome to the world of high-quality Redmond operating systems."
COM19 is perfectly valid, as is COM256.
Here's an interesting bit of additional information on the PTT question: If I open the COM port using PuTTY (terminal emulator), then power on the radio with the plug inserted, the PTT does NOT key up. If I then close the PuTTY session, the PTT keys up a few seconds afterward. The trusty DVM indicates that the TX data line to the radio is held at 0V both before and after the PuTTY session, and is high during the PuTTY session (except when I'm sending serial data). When I run Chirp, the PTT keying only happens before the upload or download starts, and resumes a few seconds after it ends.
This suggests that I'm not seeing a bad adapter or cable, but that one or both of the following two things is happening: 1) The much-despised Prolific chip (the real thing, as far as I can tell, or else they did a great job forging the logo and marking) is setting the TXD line to a break state when there's no port session in progress, and/or 2) the Windows 7 64-bit Prolific com adapter driver (version 3.4.62.293) is commanding the adapter's TXD line to a break state when there's no session in progress.
This is pretty much par for the course with these radios. It tends to be DTR leakage into the PTT circuit, which means regular serial signaling will occasionally cause the radio to transmit. This is, after all, a $20 device you paid $40 for...
I'll try this out on a 32-bit Win7 system using the canonical Prolific driver version, and see if the break-state shenanigans still happen there.
If I were you, I would not waste my time and set the radio to something it can't transmit on before you go into clone mode.
--Dan
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
On Thu, Mar 27, 2014 at 2:08 PM, Stephen Hersey n1xnxham@gmail.com wrote:
I've just started using Chirp with a Baofeng UV-5R and a USB serial adapter that Amazon claims is from Baofeng. The adapter has a genuine Prolific chip (or a darn good counterfeit), and Windows 7 Pro 64-bit recognizes it as a serial port; in addition, I can connect TxD to RxD at the radio plugs, open PuTTY, and see looped-back characters I have typed on the console. So far, so great.
However, neither Chirp nor baoclone could open the serial port the USB adapter was assigned to: COM19. Hmmm, 19? Sounds way high for a serial port enumeration. I reassigned the USB adapter to the vacant COM2, and hey presto! Both utilities are able to talk to the radio.
Sooo, beware of high-numbered COM ports.
Incidentally, is it normal for the UV-5R to key up when the serial cable is present? I'm going to make a practice of always having a dummy load connected when programming this radio.
Regards, Steve
I was one of the testers when CHIRP was given the capability of automatically detecting and using COM ports up to COM256. Just to be sure, I set my port to COM256 and it works fine.
My experience with Windows is that after you initially install the driver for the programming cable or change the virtual COM port number to something else, both Device Manager and the balloon popup down by the system tray will tell you what the assigned COM port is. But that COM port really isn't fully available until you unplug the cable from the USB port and then plug it back in the same port.
Jim KC9HI
On Thu, 27 Mar 2014 14:08:04 -0400, Stephen Hersey n1xnxham@gmail.com wrote:
Incidentally, is it normal for the UV-5R to key up when the serial cable is present? I'm going to make a practice of always having a dummy load connected when programming this radio.
It is the case here, with two (non-counterfeit) cables. The rig keys up as soon as the software (any software) activates the serial port.
I have identified two solutions:
1. Connect the unit to the cable (power off!), prepare Chirp so that you only need to click the OK button in order to start the transfer, power the unit on, and click the OK button as soon as the rig's display lights up. The transfer begins and the transmitter doesn't turn on.
2. Put in a receive-only channel (I have local NWS in channel 1, with transmit disabled), set the rig to that channel, plug stuff in, run Chirp, everybody happy.
mdr KL7F
If your PC is using a version of the Prolific driver other than the 3.2.0.0 version Miklor recommends, that may be the root cause of the keyup. My rig stopped keying up when I switched from the (newer, otherwise functional) driver Windows 7 picked to the 3.2.0.0 driver from Miklor. My conclusion is that the newer driver switches the TX line to the break or all-space state when the port doesn't have an open connection. Might only happen with this chipset and driver, I suppose. Your recommended procedure is certainly a good one in any case.
Regards, Steve
On Thu, Mar 27, 2014 at 11:51 PM, Michael Rathbun KL7F@kl7f.us wrote:
On Thu, 27 Mar 2014 14:08:04 -0400, Stephen Hersey n1xnxham@gmail.com wrote:
Incidentally, is it normal for the UV-5R to key up when the serial cable
is
present? I'm going to make a practice of always having a dummy load connected when programming this radio.
It is the case here, with two (non-counterfeit) cables. The rig keys up as soon as the software (any software) activates the serial port.
I have identified two solutions:
- Connect the unit to the cable (power off!), prepare Chirp so that you
only need to click the OK button in order to start the transfer, power the unit on, and click the OK button as soon as the rig's display lights up. The transfer begins and the transmitter doesn't turn on.
- Put in a receive-only channel (I have local NWS in channel 1, with
transmit disabled), set the rig to that channel, plug stuff in, run Chirp, everybody happy.
mdr KL7F
Sometimes half-ass is exactly the right amount of ass. -- Wonderella
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
What is your operating system and cable driver version? Stephen was able to roll back his Prolific driver to 3.2.0.0 for Windows 7 and now the PTT does not activate when using the software.
________________________________ From: Michael Rathbun KL7F@kl7f.us To: Discussion of CHIRP chirp_users@intrepid.danplanet.com Sent: Thursday, March 27, 2014 11:51 PM Subject: [chirp_users] Transmit activated when trying to do a transfer (was Re: Another way Chirp can be tripped up by the OS)
On Thu, 27 Mar 2014 14:08:04 -0400, Stephen Hersey n1xnxham@gmail.com wrote:
Incidentally, is it normal for the UV-5R to key up when the serial cable is present? I'm going to make a practice of always having a dummy load connected when programming this radio.
It is the case here, with two (non-counterfeit) cables. The rig keys up as soon as the software (any software) activates the serial port.
I have identified two solutions:
1. Connect the unit to the cable (power off!), prepare Chirp so that you only need to click the OK button in order to start the transfer, power the unit on, and click the OK button as soon as the rig's display lights up. The transfer begins and the transmitter doesn't turn on.
2. Put in a receive-only channel (I have local NWS in channel 1, with transmit disabled), set the rig to that channel, plug stuff in, run Chirp, everybody happy.
mdr KL7F
participants (10)
-
D. Daniel McGlothin KB3MUN -
Dan Smith -
Jens J. -
Jim Unroe -
John LaMartina -
Michael Rathbun -
Milton Hywatt -
Niklas Johnson -
Stephen Hersey -
Tom Hayward