Menu
▾
▴
wsjt-devel
|
From: Lou C. <lo...@gm...> - 2017-12-20 13:44:06
|
Hello, I have observed what appears to be a computer-rig communication error on transmit. I have observed this when either using Tune or in Echo mode - I am just setting this system up so I have spent little time transmitting in other modes (the rig worked fine during one QSO at HF). _________________ Rig: IC-7100, USB CAT control and audio (the rig presents itself as a sound card), manufacturer's shielded cables with ferrites, Serial Port COM3, (which is associated with the driver Silicon Labs CP210x USB to UART Bridge, downloaded from the Icom website). (Both audio input and output are associated with the driver USB Audio CODEC.) TX power set to 0% and the rig going straight to a 500 W dummy load (so probably this is not RF-in-the-shack), 70 cm band. WSJT-X: v 1.8.0 r8193, Echo mode or Tune, Rig set to Icom IC-7100, Com3, 4800/8/2/none, CAT control, rig polling interval set to 1s, Split operation Rig, Mode None, VHF/UHF/Microwave features enabled, Single decode, decode after EME delay. Operating system: Windows 10 Home operating system, 64 bit, v 1709, OS build 16299.125. Computer: i5-4570 CPU @ 3.20 GHz, 8 GB RAM Observations: On selecting Enable Tx in Echo mode, the program keys the rig repeatedly as expected for several cycles, perhaps from 10 s to a minute. Then one of three things happens: 1) the program stops transmittting without an error message, 2) the program stops and produces an error message "Rig Control Error" and under details, "Hamlib error: Communication bus collision while setting frequency", 3) the program stops with a similar error message but details "Hamlib error: Protocol error while setting frequency". Similar errors observed intermittently when keying the rig with Tune. Selecting "Retry" reestablishes the communications with the rig. Similar behavior observed with the "Allow TX frequency changes..." option ticked, although Doppler tracking is off for these tests. On changing Mode to USB, I saw the rig stop transmitting without an error message, and the "Communication bus collision..." error, but also a different one: Rig Control Error - "Hamlib error: Command rejected by the rig while setting frequency". Similar behavior observed when the polling interval was set to 4s. ______________ I have seen a few similar Hamlib errors described by others, but I haven't been able to use the information to stop the behavior I observe. If anyone has any idea of what I am doing wrong, or if this is a real bug, I would be grateful for the advice. Lou N2END |
|
From: Black M. <mdb...@ya...> - 2017-12-20 17:12:38
|
Sounds like USB power problems to me.
Do you have a powered USB hub you could hook up and test?Can you also unplug your ethernet and see if that makes any difference? That's just a quick/easy test to hopefully eliminate that cabling as the problem.
de Mike W9MDB
On Wednesday, December 20, 2017, 7:46:32 AM CST, Lou Crocker <lo...@gm...> wrote:
Hello,
I have observed what appears to be a computer-rig communication error on transmit. I have observed this when either using Tune or in Echo mode - I am just setting this system up so I have spent little time transmitting in other modes (the rig worked fine during one QSO at HF).
_________________
Rig: IC-7100, USB CAT control and audio (the rig presents itself as a sound card), manufacturer's shielded cables with ferrites, Serial Port COM3, (which is associated with the driver Silicon Labs CP210x USB to UART Bridge, downloaded from the Icom website). (Both audio input and output are associated with the driver USB Audio CODEC.)
TX power set to 0% and the rig going straight to a 500 W dummy load (so probably this is not RF-in-the-shack), 70 cm band.
WSJT-X: v 1.8.0 r8193, Echo mode or Tune, Rig set to Icom IC-7100, Com3, 4800/8/2/none, CAT control, rig polling interval set to 1s, Split operation Rig, Mode None, VHF/UHF/Microwave features enabled, Single decode, decode after EME delay.
Operating system: Windows 10 Home operating system, 64 bit, v 1709, OS build 16299.125.
Computer: i5-4570 CPU @ 3.20 GHz, 8 GB RAM
Observations:
On selecting Enable Tx in Echo mode, the program keys the rig repeatedly as expected for several cycles, perhaps from 10 s to a minute. Then one of three things happens: 1) the program stops transmittting without an error message, 2) the program stops and produces an error message "Rig Control Error" and under details, "Hamlib error: Communication bus collision while setting frequency", 3) the program stops with a similar error message but details "Hamlib error: Protocol error while setting frequency".
Similar errors observed intermittently when keying the rig with Tune.
Selecting "Retry" reestablishes the communications with the rig.
Similar behavior observed with the "Allow TX frequency changes..." option ticked, although Doppler tracking is off for these tests.
On changing Mode to USB, I saw the rig stop transmitting without an error message, and the "Communication bus collision..." error, but also a different one: Rig Control Error - "Hamlib error: Command rejected by the rig while setting frequency".
Similar behavior observed when the polling interval was set to 4s.
______________
I have seen a few similar Hamlib errors described by others, but I haven't been able to use the information to stop the behavior I observe.
If anyone has any idea of what I am doing wrong, or if this is a real bug, I would be grateful for the advice.
Lou N2END
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
wsjt-devel mailing list
wsj...@li...
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
|
|
From: Lou C. <lo...@gm...> - 2017-12-20 18:18:51
|
Thank you for the suggestion. I do have a powered USB 3.0 hub., I just
tried it and I see the same behavior ("Bus collision...").
I don't have an ethernet cable - just a wifi card in the computer. I just
tested the radio plugging it into a front USB port away from the wifi card,
but I observe the same behavior.
73,
Lou N2END
On Wed, Dec 20, 2017 at 9:40 AM, Black Michael via wsjt-devel <
wsj...@li...> wrote:
> Sounds like USB power problems to me.
> Do you have a powered USB hub you could hook up and test?
> Can you also unplug your ethernet and see if that makes any difference?
> That's just a quick/easy test to hopefully eliminate that cabling as the
> problem.
>
> de Mike W9MDB
>
>
> On Wednesday, December 20, 2017, 7:46:32 AM CST, Lou Crocker <
> lo...@gm...> wrote:
>
>
> Hello,
> I have observed what appears to be a computer-rig communication error on
> transmit. I have observed this when either using Tune or in Echo mode - I
> am just setting this system up so I have spent little time transmitting in
> other modes (the rig worked fine during one QSO at HF).
> _________________
>
> Rig: IC-7100, USB CAT control and audio (the rig presents itself as a
> sound card), manufacturer's shielded cables with ferrites, Serial Port
> COM3, (which is associated with the driver Silicon Labs CP210x USB to UART
> Bridge, downloaded from the Icom website). (Both audio input and output are
> associated with the driver USB Audio CODEC.)
>
> TX power set to 0% and the rig going straight to a 500 W dummy load (so
> probably this is not RF-in-the-shack), 70 cm band.
>
> WSJT-X: v 1.8.0 r8193, Echo mode or Tune, Rig set to Icom IC-7100, Com3,
> 4800/8/2/none, CAT control, rig polling interval set to 1s, Split operation
> Rig, Mode None, VHF/UHF/Microwave features enabled, Single decode, decode
> after EME delay.
>
> Operating system: Windows 10 Home operating system, 64 bit, v 1709, OS
> build 16299.125.
>
> Computer: i5-4570 CPU @ 3.20 GHz, 8 GB RAM
>
> Observations:
>
> On selecting Enable Tx in Echo mode, the program keys the rig repeatedly
> as expected for several cycles, perhaps from 10 s to a minute. Then one of
> three things happens: 1) the program stops transmittting without an error
> message, 2) the program stops and produces an error message "Rig Control
> Error" and under details, "Hamlib error: Communication bus collision while
> setting frequency", 3) the program stops with a similar error message but
> details "Hamlib error: Protocol error while setting frequency".
>
> Similar errors observed intermittently when keying the rig with Tune.
>
> Selecting "Retry" reestablishes the communications with the rig.
>
> Similar behavior observed with the "Allow TX frequency changes..." option
> ticked, although Doppler tracking is off for these tests.
>
> On changing Mode to USB, I saw the rig stop transmitting without an error
> message, and the "Communication bus collision..." error, but also a
> different one: Rig Control Error - "Hamlib error: Command rejected by the
> rig while setting frequency".
>
> Similar behavior observed when the polling interval was set to 4s.
> ______________
> I have seen a few similar Hamlib errors described by others, but I haven't
> been able to use the information to stop the behavior I observe.
>
> If anyone has any idea of what I am doing wrong, or if this is a real bug,
> I would be grateful for the advice.
>
> Lou N2END
>
>
>
>
>
>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot______
> _________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
|
|
From: Bill S. <g4...@cl...> - 2017-12-20 21:30:31
|
On 20/12/2017 13:43, Lou Crocker wrote: > Observations: > > On selecting Enable Tx in Echo mode, the program keys the rig > repeatedly as expected for several cycles, perhaps from 10 s to a > minute. Then one of three things happens: 1) the program stops > transmittting without an error message, 2) the program stops and > produces an error message "Rig Control Error" and under details, > "Hamlib error: Communication bus collision while setting frequency", > 3) the program stops with a similar error message but details "Hamlib > error: Protocol error while setting frequency". Hi Lou, make sure that you have "CI-V Transceive Mode" disabled in your rig's menu. 73 Bill G4WJS. |
|
From: Lou C. <lo...@gm...> - 2017-12-20 22:15:24
|
Bill, Thank you so much for that advice! I shut off the CI-V transceive setting and radio is now going through TX-RX cycles without any problems, even with power set to a finite value. I don't know why that setting was set to on in my radio - maybe that is the default value; I haven't used that feature and I don't even have the interface cable to use the CI-V control. I knew somebody out there would know what was going on. Thanks again. 73, Lou N2END On Wed, Dec 20, 2017 at 4:30 PM, Bill Somerville <g4...@cl...> wrote: > On 20/12/2017 13:43, Lou Crocker wrote: > >> Observations: >> >> On selecting Enable Tx in Echo mode, the program keys the rig repeatedly >> as expected for several cycles, perhaps from 10 s to a minute. Then one of >> three things happens: 1) the program stops transmittting without an error >> message, 2) the program stops and produces an error message "Rig Control >> Error" and under details, "Hamlib error: Communication bus collision while >> setting frequency", 3) the program stops with a similar error message but >> details "Hamlib error: Protocol error while setting frequency". >> > > Hi Lou, > > make sure that you have "CI-V Transceive Mode" disabled in your rig's menu. > > 73 > Bill > G4WJS. > > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > wsjt-devel mailing list > wsj...@li... > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > |
Thanks for helping keep SourceForge clean.
X