Date   

locked Re: Hamlib 4.5 testing #hamlib

Jim Brown
 

On 8/9/2022 9:45 PM, Tim Dawson wrote:
It's in a solid metal case -*THAT* is far better shielded than plastic or nothing
Not necessarily. Properly laid-out circuit boards using microstrip (traces above a CONTINUOUS "ground" layer) form transmission lines with that layer confines signal return current to the ground layer immediately under the trace, making the circuitry self-shielding. Stripline, (sandwiching the signal layer between a pair of "ground" layers) provides significantly greater shielding. These types of construction are necessary to prevent crosstalk between circuits.

Proper layout is the key -- the ground layer must not be interrupted under a trace, because it's no longer a transmission line.

. . . (there is far more to shielding than just the cable!)

YES. And for cable shielding to work, it must be bonded to the shielding enclosure AT BOTH ENDS, AT THE POINT OF ENTRY. If there's no shielding enclosure, it must be bonded to the ground layer of that microstrip or stripline board.

73, Jim K9YC


locked Re: U.S.A. CQers #band

David Ross
 

F4

David VA3MJR

On 2022-08-09 11:21 p.m., Michael Black via groups.io wrote:
I must be blind...where is "DX Decodes" ?
Mike W9MDB


On Tuesday, August 9, 2022 at 06:36:12 PM CDT, Joe Subich, W4TV<lists@...> wrote:
On 2022-08-09 4:49 PM, Michael Black via groups.io wrote:
> If you're on Windows use JTAlert.  You can turn off North America.

You can also select "DX Decodes" which will display all decodes
from countries *other* that your own no matter what your country.

73,

    ... Joe, W4TV

On 2022-08-09 4:49 PM, Michael Black via groups.io wrote:
If you're on Windows use JTAlert.  You can turn off North America.
Mike W9DMB


      On Tuesday, August 9, 2022 at 03:44:36 PM CDT, w5ec<bhw5ec@...> wrote:
  In most world wide DX contests, most of the CQ decodes are from USA stations which I don't want to contact.
This makes it hard for me to watch the fast moving decodes for elusive DX stations that I do want to contact.
Is there any way to easily and temporarily stop decoding USA stations during the contest and return to normal after the contest?











--


locked Re: Incorrect logged QSO times in WSJT-X Version 2.5.4 when running MSK144 #IssueReport #logging #MSK144

Gary - AG0N
 

On Aug 9, 2022, at 10:45, Michael Black via groups.io <mdblack98@...> wrote:

The times have been based on the transmit messages where it seems it would be better on the received messages.
Obviously, different people were tutored by different people. For those who don’t know, some of us started when logging was REQUIRED. The log contained the both the start and end time of the QSO. What’s a QSO? I have always assumed it is a two way communication. If you are calling CQ, that is not the beginning of the QSO, (but back then it would still require an entry in the log). Today, we don’t require that much detail. I consider the beginning of the QSO to be the beginning of a two way exchange. OK, you send CQ. We’re on 2M MSK144. I hear your CQ 5 minutes later, because there were no meteors that cooperated with the needed path….or I walked in and heard your CQ 5 minutes later and start answering. Pings are few and far behind, and you don’t hear my me for several minutes after I start calling you. The start of the QSO (2-way communication), for me, was the initial 5 minute delay, PLUS the amount of time I called before you heard me. I know people who have tried for days to get 2-way communications established. Your start time would be when you finally heard me calling you and you started sending the response to my call. My start time would be when I first heard your response to my call.

This sort of long delay QSO is very common and has been for decades. QSOs can take HOURS to complete, and yes, even days. It used to be fairly common. Most people don’’t have the patience to do this sort of operation, but in the early days of MS, it was pretty common.

There’s a lot more to consider than what you do on HF, where things are pretty reliable. Think about it.

73, Gary - AG0N


locked Re: Incorrect logged QSO times in WSJT-X Version 2.5.4 when running MSK144 #IssueReport #logging #MSK144

Reino Talarmo
 

From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of Jim Brown
Sent: 9. elokuutata 2022 10:51

Hi Jim and Mike,

It seems that I receive some mails quite delayed and the responses may not match what have been sent between, hi! In any case same responses inline.

On 8/8/2022 10:16 PM, Reino Talarmo wrote:
With all respect of your problems you are actually introducing a third working related time "Caller's Start Time".
No, I did not. What I said is that the logging software sets the caller's "Start Time" under the conditions I described can often be 30-90 minutes before the QSO actually takes place, it takes place over
1-2 minutes, and the DX logs it when HE responds to the caller. In the conditions I described, these Starting Times are 30-90 minutes apart.

That caller's "Start Time" is a totally wrong start time! The proper one is, when the caller gets a response from the DX (minus 15 s or perhaps minus 30 s, but that's irrelevant compared to 30 min tolerance). Before that caller has only tried to start a QSO; almost same as a CQ'er would set start time, when he starts calling CQ, well not really. Only a received response is a start of a real QSO. It is close to the time DX logs as well, isn't it!

[I think that this is not only a wsjt-x problem. Some logging programs could mark a start time once you just type the call sign of the DX.]

Yes, but it doesn't matter. What matters is that they log the Start Time of the QSO within 30 minutes of each other. This is a STANDARD, which in the context of this discussion, is poorly conceived, but it is the STANDARD, and we have to live with it.
So start time is passed, when you have received first response from the DX (Tx2 or Tx3 depending what you sent). That time will also be the one DX is considering as the start time as you pointed. (With the same principle DX station should set start time for each caller in a pile-up to those he happens to decode each station first time.)

I think that Mike is now implementing Start time using this principle.

Of course there are additional delays, when messages are lost. But seldom more than 30 minutes! The lost message problem exists also at the definition of the end time. On the other hand FT8 AP helps at that time quite a lot and messages get though easier.

GN and 73, Reino OH3mA


locked Re: Incorrect logged QSO times in WSJT-X Version 2.5.4 when running MSK144 #IssueReport #logging #MSK144

Joe Subich, W4TV
 

All of this assumes no repeated messages ...e.g., the "missing 73"
and the need to repeat the RRR or RR73 messages which is currently
the subject of much debate on the FFMA list.

Frankly, the software should automatically log the end time when
R-02, RR73 or RRR are *first sent* (depending on the sequence) as
sending an acknowledgement of the receipt of the unique information
(signal report or grid square) defines a completed QSO, *whether or*
*not* the other station acknowledges receipt of the acknowledgement.

There can be a one sequence difference in the end time for stations
on even/odd sequences but that will not be an issue for LotW since
the LotW "matching window" is triggered on start time.

73,

... Joe, W4TV

On 2022-08-09 2:10 PM, Michael Black via groups.io wrote:
Without the HTML formatting...
The times have been based on the transmit messages where it seems it would be better on the received messages.
I'm working on it right now so the reception of TX1, TX2 or TX3 will set time to the start of the period (i.e. will subtract the time periods involved)
We have to allow for tail-ending, plus those who skip TX1.
So...this tail-end sequence with an RR73 ending the QSO (no extra 73)
130000 W9MDB K9YC RR73
130015 K9YC OH3MA -03
130030 OH3MA K9YC R-02
130045 K9YC OH3MA RR73
Start time should be 130015 on both sides of the QSO
Stop stop should be 130045 on both sides of the QSO since the logging window pops up on RR73
A subsequent
140000 OH3MA K9YC 73
will not change the QSO stop time.
Then we have the non-tail QSO
130000 CQ K9YC CM87
130015 K9YC OH3MA -03
130030 OH3MA K9YC R-02
130045 K9YC OH3MA RR73
Same logic applies -- start time should be 130015 on both sides based on the 1st message received.
Mike W9MDB


locked Re: Incorrect logged QSO times in WSJT-X Version 2.5.4 when running MSK144 #IssueReport #logging #MSK144

Jim Brown
 

On 8/9/2022 9:45 AM, Sam Birnbaum via groups.io wrote:
Would it be possible for you in the next contest using msk144 to uncheck the Auto log option and use the prompt me to log option for a few QSO's and see if that changes the time off value.
This issue has NOTHING to do with Contesting.

73, Jim K9YC


locked Re: Incorrect logged QSO times in WSJT-X Version 2.5.4 when running MSK144 #IssueReport #logging #MSK144

Reino Talarmo
 

-----Original Message-----
[Re-formatted as my email did not recognized all line breaks.]
The times have been based on the transmit messages where it seems it would be better on the received messages.
I'm working on it right now so the reception of TX1, TX2 or TX3 will set time to the start of the period (i.e. will subtract the time periods involved)
We have to allow for tail-ending, plus those who skip TX1. So...this tail-end sequence with an RR73 ending the QSO (no extra 73)
130000 W9MDB K9YC RR73
130015 K9YC OH3MA -03
130030 OH3MA K9YC R-02
130045 K9YC OH3MA RR73
Start time should be 130015 on both sides of the QSO
Stop time should be 130045 on both sides of the QSO since the logging window pops up on RR73
A subsequent
140000 OH3MA K9YC 73
will not change the QSO stop time.

Then we have the non-tail QSO
130000 CQ K9YC CM87
130015 K9YC OH3MA -03
130030 OH3MA K9YC R-02
130045 K9YC OH3MA RR73
Same logic applies -- start time should be 130015 on both sides based on the 1st message received.
Mike W9MDB

-----End of the Original Message-----

Thanks Mike,
I agree the start time, when there is no repetitions nor missing messages.
The end time will be different, when RRR is used as then also 73 comes into the play.

Most probably automation cannot deal with interleaved QSOs as it is a message driven system without a state memory, I think. Although the end times of interleaved QSO should work, but the start times may not be correct.

73, Reino OH3mA


locked Re: Incorrect logged QSO times in WSJT-X Version 2.5.4 when running MSK144 #IssueReport #logging #MSK144

Sam Birnbaum
 

Hi John,
Ok. I just saw Mike's email and concur with the logic of starting the QSO time the first time a "reply" is decoded.
That would follow the same process/logic as in Phone and CW modes.
73,

Sam W2JDB

-----Original Message-----
From: John P <j.m.price@...>
To: main@WSJTX.groups.io
Sent: Tue, Aug 9, 2022 2:15 pm
Subject: Re: [WSJTX] Incorrect logged QSO times in WSJT-X Version 2.5.4 when running MSK144 #IssueReport #logging

Sam... i don't use the autolog on 6 meters in non-contest ops, so my data has examples of both; off for 6 meter QSOs and on for 2 meters.

The problem has to be in how WSJT-X determines the start time.

--
John P.
WA2FZW


locked Re: Incorrect logged QSO times in WSJT-X Version 2.5.4 when running MSK144 #IssueReport #logging #MSK144

 

Guess you can't edit messages here!

Seems to me contest mode QSOs are a whole different can of worms!

--
John P.
WA2FZW


locked Re: Hamlib 4.5 testing #hamlib

Chuck Moore <wd4hxg@...>
 

Tim
I travel a lot. So I carry a Pelican case with transceiver, power supply, laptop and antenna.
I also have a Spud Gun under the back seat of the truck for popping a tennis ball with
attached monofilament line to pull up dipole supports.

There were several goals:
(1) Eliminate the speaker or line audio out from the radio to the Rigblaster.
(2) Get rid of the lashup cable from the rigblaster to the microphone connector on the radio.
(3) Use a single USB connection which would carry digital data for audio and control between the laptop and xcvr
(4) Use the RS-BA1 Icom software for on screen command of the radio.

When operating at a camp ground or hotel room or in the cab of the truck I drive,
minimizing the number of widgets and their connections is critical. It seems that
the number of problems that can be expected is proportional to the number of
connections square and perhaps even the number of connections exponentiated
by the number of connections. 3.5 mm audio plugs/jacks, DIN connectors, RCA
jacks etc are not a good mix when operating portable.

There were other choices available which were smaller, but the 7300 was an SDR
box, minimized connections, provided 100 watts for regular SSB QSO's, had its
own internal antenna tuner, another attractive feature and eliminated the need for
me to drag along a VSWR meter.

All seem like desirable features and would help keep the needed Pelican case
size down to something that does not look like Keystone Cops running a surveillance
operation when dragging the box into a hotel.

Regards

Chuck WD4HXG


locked Re: Hamlib 4.5 testing #hamlib

Tim Dawson
 

It's in a solid metal case - *THAT* is far better shielded than plastic or nothing . . . (there is far more to shielding than just the cable!)

On August 9, 2022 11:33:05 PM CDT, "Michael Black via groups.io" <mdblack98@...> wrote:
You call it shielded but I'll bet if you measure pin 4 on the USB connector to the case and shield it will be shorted.
So all that RF hitting the cable and case rides right into the inside of the USB cable.
Check my list of ill-behaving equipment on my qrz page.https://www.qrz.com/db/w9mdb

Mike W9DMB



On Tuesday, August 9, 2022 at 11:28:42 PM CDT, Tim Dawson <tadawson@...> wrote:

For what it's worth, I use one of these for multiple rigs, and have been solid:

https://www.amazon.com/gp/product/B008U3OVHW/ref=ppx_yo_dt_b_search_asin_title?i

This device may not be cheap, but does multiple ports (4), has the FTDI chipset, is fully metal enclosed (shielded) as well as using separate power from the computer. This and two SignaLinks run my two rigs (simultaneously, if desired) and I never have to worry about drivers and other nonsense no matter what radio I connect - it just works. Looking att the CI-V adapter from Icom, it really does not look like anything more than a cheap USB serial with a 3.5mm cable on it, somaking up a DB9 (*NOT* DM9 . . .) to 3.5mm cable for the 7300 should be a quick task.

The SignaLinks also give far better control and status indication than any USB implementation could . . . so, just another person's viewpoint, butI tend to *avoid* "close coupling" processors and RF with cheezy consumer tech like USB when I can get identical functionality externally. Yeah, may still have a partial hop via USB, nut has the ability to add fikters and isolation that direct USB does not. (And, ironically, looks the same on the co,puter - in either case, you see a serial port and an audko device, with al the same settings and controls . . . so, ultimately, direct USB simplifies nothing in software)

I also use an ESD protected, full metal (shielded) USB hub between my computer, the serial devices, and the rig audio interfaces (SignaLink in my case). ( https://www.amazon.com/gp/product/B07G7GP15C/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1 ) This way, any and all shack functiinality comes into the computer on a total of *ONE* USB cable for multiple rigs and other stuff, making computer wiring simple, and the rest stays with the rigs.

On August 9, 2022 10:46:16 PM CDT, "Chuck Moore via groups.io" <wd4hxg@...> wrote:
Not as in a DM9 or DB-25 connector. It does have the C-IV  port
which when used with the C-IV adaptor will provide the traditional
RS-232 lashup that uses the DM-9. That potentially would provide
a work around, but with my laptops I would still have to use a
RS-232 to USB adaptor as there is no DM9 connector on the laptops
providing RS-232 connection. One of the reasons for buying the
7300 was the fact it provided both USB and Codec services on a
single USB cable. No external microphone connection, no back panel
audio cable and no clunky Rigblaster or similar 3rd party interface.
One cable and one cable only for digitized audio and control.

Regards

Chuck WD4HXG




--
Sent from my Android device with K-9 Mail. Please excuse my brevity.










--
Sent from my Android device with K-9 Mail. Please excuse my brevity.


locked Re: Hamlib 4.5 testing #hamlib

Michael Black
 

You call it shielded but I'll bet if you measure pin 4 on the USB connector to the case and shield it will be shorted.
So all that RF hitting the cable and case rides right into the inside of the USB cable.
Check my list of ill-behaving equipment on my qrz page.https://www.qrz.com/db/w9mdb

Mike W9DMB

On Tuesday, August 9, 2022 at 11:28:42 PM CDT, Tim Dawson <tadawson@...> wrote:

For what it's worth, I use one of these for multiple rigs, and have been solid:

https://www.amazon.com/gp/product/B008U3OVHW/ref=ppx_yo_dt_b_search_asin_title?i

This device may not be cheap, but does multiple ports (4), has the FTDI chipset, is fully metal enclosed (shielded) as well as using separate power from the computer. This and two SignaLinks run my two rigs (simultaneously, if desired) and I never have to worry about drivers and other nonsense no matter what radio I connect - it just works. Looking att the CI-V adapter from Icom, it really does not look like anything more than a cheap USB serial with a 3.5mm cable on it, somaking up a DB9 (*NOT* DM9 . . .) to 3.5mm cable for the 7300 should be a quick task.

The SignaLinks also give far better control and status indication than any USB implementation could . . . so, just another person's viewpoint, butI tend to *avoid* "close coupling" processors and RF with cheezy consumer tech like USB when I can get identical functionality externally. Yeah, may still have a partial hop via USB, nut has the ability to add fikters and isolation that direct USB does not. (And, ironically, looks the same on the co,puter - in either case, you see a serial port and an audko device, with al the same settings and controls . . . so, ultimately, direct USB simplifies nothing in software)

I also use an ESD protected, full metal (shielded) USB hub between my computer, the serial devices, and the rig audio interfaces (SignaLink in my case). ( https://www.amazon.com/gp/product/B07G7GP15C/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1 ) This way, any and all shack functiinality comes into the computer on a total of *ONE* USB cable for multiple rigs and other stuff, making computer wiring simple, and the rest stays with the rigs.

On August 9, 2022 10:46:16 PM CDT, "Chuck Moore via groups.io" <wd4hxg@...> wrote:
Not as in a DM9 or DB-25 connector. It does have the C-IV  port
which when used with the C-IV adaptor will provide the traditional
RS-232 lashup that uses the DM-9. That potentially would provide
a work around, but with my laptops I would still have to use a
RS-232 to USB adaptor as there is no DM9 connector on the laptops
providing RS-232 connection. One of the reasons for buying the
7300 was the fact it provided both USB and Codec services on a
single USB cable. No external microphone connection, no back panel
audio cable and no clunky Rigblaster or similar 3rd party interface.
One cable and one cable only for digitized audio and control.

Regards

Chuck WD4HXG




--
Sent from my Android device with K-9 Mail. Please excuse my brevity.


locked Re: Hamlib 4.5 testing #hamlib

Tim Dawson
 

For what it's worth, I use one of these for multiple rigs, and have been solid:

https://www.amazon.com/gp/product/B008U3OVHW/ref=ppx_yo_dt_b_search_asin_title?i

This device may not be cheap, but does multiple ports (4), has the FTDI chipset, is fully metal enclosed (shielded) as well as using separate power from the computer. This and two SignaLinks run my two rigs (simultaneously, if desired) and I never have to worry about drivers and other nonsense no matter what radio I connect - it just works. Looking att the CI-V adapter from Icom, it really does not look like anything more than a cheap USB serial with a 3.5mm cable on it, somaking up a DB9 (*NOT* DM9 . . .) to 3.5mm cable for the 7300 should be a quick task.

The SignaLinks also give far better control and status indication than any USB implementation could . . . so, just another person's viewpoint, butI tend to *avoid* "close coupling" processors and RF with cheezy consumer tech like USB when I can get identical functionality externally. Yeah, may still have a partial hop via USB, nut has the ability to add fikters and isolation that direct USB does not. (And, ironically, looks the same on the co,puter - in either case, you see a serial port and an audko device, with al the same settings and controls . . . so, ultimately, direct USB simplifies nothing in software)

I also use an ESD protected, full metal (shielded) USB hub between my computer, the serial devices, and the rig audio interfaces (SignaLink in my case). ( https://www.amazon.com/gp/product/B07G7GP15C/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1 ) This way, any and all shack functiinality comes into the computer on a total of *ONE* USB cable for multiple rigs and other stuff, making computer wiring simple, and the rest stays with the rigs.

On August 9, 2022 10:46:16 PM CDT, "Chuck Moore via groups.io" <wd4hxg@...> wrote:
Not as in a DM9 or DB-25 connector. It does have the C-IV port
which when used with the C-IV adaptor will provide the traditional
RS-232 lashup that uses the DM-9. That potentially would provide
a work around, but with my laptops I would still have to use a
RS-232 to USB adaptor as there is no DM9 connector on the laptops
providing RS-232 connection. One of the reasons for buying the
7300 was the fact it provided both USB and Codec services on a
single USB cable. No external microphone connection, no back panel
audio cable and no clunky Rigblaster or similar 3rd party interface.
One cable and one cable only for digitized audio and control.

Regards

Chuck WD4HXG




--
Sent from my Android device with K-9 Mail. Please excuse my brevity.


locked Re: Hamlib 4.5 testing #hamlib

fritz1000@...
 

Some people get frustrated and angry when they pay big bucks for something that doesn't perform well. Every time they look at it they want to stomp the damned thing into just the junk that it is.


locked Re: Hamlib 4.5 testing #hamlib

Chuck Moore <wd4hxg@...>
 

Not as in a DM9 or DB-25 connector. It does have the C-IV port
which when used with the C-IV adaptor will provide the traditional
RS-232 lashup that uses the DM-9. That potentially would provide
a work around, but with my laptops I would still have to use a
RS-232 to USB adaptor as there is no DM9 connector on the laptops
providing RS-232 connection. One of the reasons for buying the
7300 was the fact it provided both USB and Codec services on a
single USB cable. No external microphone connection, no back panel
audio cable and no clunky Rigblaster or similar 3rd party interface.
One cable and one cable only for digitized audio and control.

Regards

Chuck WD4HXG


locked Re: U.S.A. CQers #band

Michael Black
 

I must be blind...where is "DX Decodes" ?
Mike W9MDB

On Tuesday, August 9, 2022 at 06:36:12 PM CDT, Joe Subich, W4TV <lists@...> wrote:


On 2022-08-09 4:49 PM, Michael Black via groups.io wrote:
> If you're on Windows use JTAlert.  You can turn off North America.

You can also select "DX Decodes" which will display all decodes
from countries *other* that your own no matter what your country.

73,

    ... Joe, W4TV

On 2022-08-09 4:49 PM, Michael Black via groups.io wrote:
If you're on Windows use JTAlert.  You can turn off North America.
Mike W9DMB

 

      On Tuesday, August 9, 2022 at 03:44:36 PM CDT, w5ec <bhw5ec@...> wrote:
 
  In most world wide DX contests, most of the CQ decodes are from USA stations which I don't want to contact.
This makes it hard for me to watch the fast moving decodes for elusive DX stations that I do want to contact.
Is there any way to easily and temporarily stop decoding USA stations during the contest and return to normal after the contest?




locked Re: Hamlib 4.5 testing #hamlib

Michael Black
 

My QRZ page has two links to USB adapters that break the shield on the USB cable like the IC-7300 needs.  Also usable on most other ham devices that are USB.The A/B adapter can do the other end too but needs a regular USB cable instead of the "printer" USB cable.
Mike W9MDB


locked Re: Hamlib 4.5 testing #hamlib

Russ Ravella
 

Thanks very much Chuck. I’m not a fan of Icom either. Good luck !
Russ KR6W

On Aug 9, 2022, at 8:52 PM, Chuck Moore via groups.io <wd4hxg@...> wrote:

Russ

When I called Icom for help, their tech support recommended using the
Tripp-Lite USB cable with integral ferrite cores molded near each end of
the cable. I found the cables online and ordered a couple. In my case
there was no improvement using them. Best solution I found was to replace
the radio with something other than Icom.

Regards
Chuck WD4HXG





locked Re: Changing your grid square #bearing

Jim Shorney
 

From TQSL release notes Apr 6, 2020:

"Optionally, a station performing roaming operations (multiple gridsquares) can choose to have TQSL assume that the log is correct. When callsign or QTH are provided with the log, TQSL will update the details on the upload to Logbook automatically. This behavior is enabled by selecting “Override Station Location with QTH details from your log” on the “Log Handling” preference page."

73

-Jim
NU0C

On Mon, 8 Aug 2022 08:09:07 -0400
"Larry Banks via groups.io" <larryb.w1dyj@...> wrote:

Hi Phil,

And if you use *LoTW*, don't forget to set up a new *Location *there as
well.

Larry / W1DYJ


locked Re: Hamlib 4.5 testing #hamlib

Larry Banks
 

Does the IC7300 have a serial port?

Larry / W1DYJ

On 8/9/2022 21:05, Tim Dawson wrote:
I don't own one of these, hut I really struggle to come up with a valid reason that using an isolated external interface like a SignaLink and a decent serial interface woild not be a simple, trivial, solution, with no financial beatdown as would be the case buying a new radio.

On August 9, 2022 7:52:24 PM CDT, "Chuck Moore via groups.io"<wd4hxg@...> wrote:
Russ

When I called Icom for help, their tech support recommended using the
Tripp-Lite USB cable with integral ferrite cores molded near each end of
the cable. I found the cables online and ordered a couple. In my case
there was no improvement using them. Best solution I found was to replace
the radio with something other than Icom.

Regards
Chuck WD4HXG




3021 - 3040 of 39792