Re: [wsjt-devel] WSJT-X vs JTDX sensitivity comparison

[Roeland Jansen via wsjt-devel]

then, like always -- use the right tool for the right job?

On Wed, Sep 15, 2021 at 11:12 AM Jim Brown via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> On 9/14/2021 11:43 PM, Laurie, VK3AMA via wsjt-devel wrote:
> > That has been my experience as well. On the surface JTDX offers a
> > greater number of decodes, but many were false decodes.
>
> If I made the QSO and it shows up on LOTW, it wasn't a false decode!
> And, BTW, WSJT-X is not without false decodes. In my experience, a lot
> more than JTDX.
>
> 73, Jim K9YC
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] VFO's and sub-VFO's

[Roeland Jansen]

ICOM does call their VFOs like this:

If there is a single RX in the rig, like the 7300, you have VFO A/B so you
have two VFO slots.
if you have two receivers, Main and Sub are used. And Both Main and Sub
have VFO A and B (like the 9700) so you have four VFO slots.


On Sun, Apr 4, 2021 at 6:35 PM Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Like I said it's all rig dependent.
>
> Icom called their stuff Main/Sub where others used VFO A/B
>
> Then things got complicated after that.
>
> Conceptually VFOA=Main VFOB=Sub
>
> Mike W9MDB
>
>
>
>
> On Sunday, April 4, 2021, 11:23:31 AM CDT, Claude Frantz <
> claude.fra...@bayern-mail.de> wrote:
>
>
> On 4/4/21 3:18 PM, Black Michael via wsjt-devel wrote:
>
> Hi Mike and all,
>
> > You find "VFOs.txt" in the main hamlib directory that tries to
> > describe the abstraction.The differences are rig-dependent along with
> > rig mode.
>
> It was exactly the contents of this file which has triggered my question.
>
> > Life isn't simple:-)
>
> Oh yes ! You are right. But my question remains open: What is the
> difference between a VFOx and a subVFO ? Is it simply a matter of
> definition or is there a difference in the function too ?
>
>
> Claude (DJ0OT)
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] IC-9700 tester

[Roeland Jansen]

mine is still available if you need it. Be sure to mail me before so that
the USB connection is available since we only use ether here

On Wed, 3 Mar 2021, 23:36 Black Michael via wsjt-devel, <
wsjt-devel@lists.sourceforge.net> wrote:

> Anybody with an IC-9700 that wants to volunteer for some testing with
> hamlib?
>
> Mike W9DMB
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] ANNOUNCEMENT: update_wsjtx_log.py released

[Roeland Jansen]

I have read the whole story. In defense for what Dave stated -- note that I
am not a native speaker --
I just was reading lack of. missing, imperfection.

Not FAULT FAILURE SHORTCOMING etc.

Below is a definition of deficiency. I don't think that Dave has *any*
reason to state that wsjtx is a failure or whatever.
I believe it's in the head of the people who complain about the wording.

Or are we going to be woke here as well, really?


a lack or shortage.
"*deficiencies in* material resources"
Similar:
insufficiency
lack
shortage
want
dearth
inadequacy
deficit
shortfall
scarcity
scarceness
scantiness
paucity
absence
undersupply
sparseness
deprivation
meagreness
shortness
exiguity
exiguousness
Opposite:
surplus

   - a failing or shortcoming.
   "for all its deficiencies it remains his most powerful play"
   Similar:
   defect
   fault
   flaw
   imperfection
   weakness
   weak spot/point
   inadequacy
   shortcoming
   limitation
   failing
   Opposite:
   strength
   - the amount by which something, especially revenue, falls short; a
   deficit.
   "a budget deficiency of $96 billion"








On Sat, Feb 27, 2021 at 11:22 AM Neil Zampella  wrote:

> .. and I rest my case.
>
> Neil, KN3ILZ
> On 2/26/2021 9:44 PM, Dave Slotter, W3DJS wrote:
>
> You're pretty brave behind your keyboard.
>
> It's a wonder with remarks like yours that anyone bothers to develop and
> release software for free.
>
> On Fri, Feb 26, 2021, 10:02 PM Neil Zampella  wrote:
>
>> Virtue signalling and insulting  think I see who the bully is here.
>>
>> Neil, KN3ILZ
>> On 2/26/2021 5:45 PM, Dave Slotter, W3DJS wrote:
>>
>> If you haven't written code or actually CONTRIBUTED then your opinion is
>> worthless to me. Go take your bullying somewhere else.
>>
>> On Fri, Feb 26, 2021, 6:22 PM Neil Zampella  wrote:
>>
>>> I agree with Marco.Its not a 'deficiency' if its not in the design
>>> parameters of the program.This is why there are third-party programs,
>>> and scripts like your's to ENHANCE the use of the program.
>>>
>>> Neil, KN3ILZ
>>> On 2/26/2021 3:34 PM, Dave Slotter, W3DJS wrote:
>>>
>>> My opinion my words. You're welcome to your opinion that I don't agree
>>> with.
>>>
>>> On Fri, Feb 26, 2021, 3:17 PM Marco Calistri  wrote:
>>>
 Il 26/02/21 13:48, Dave Slotter, W3DJS ha scritto:

 Fellow hams and users of WSJT-X:

 I am pleased to announce the creation and immediate availability of a
 Python script to address some of the deficiencies of WSJT-X not providing a
 method to automatically look up callsigns and missing grid squares and fill
 them in.


 --
 Dave Slotter, W3DJS 


 Despite I'm not in anyway related to the devs team @WSJT-X, I think
 that the term "*deficiencies*"  you have used on your message intro,
 being totally inappropriate.

 Sorry for sharing my very personal opinion, but I felt the necessity to
 do it.


 ---

 *73 de Marco, PY1ZRJ (former IK5BCU) *
 ___
 wsjt-devel mailing list
 wsjt-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wsjt-devel

>>> ___
>>> wsjt-devel mailing list
>>> wsjt-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>>
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Valid DXCC checking feature

[Roeland Jansen]

wholeheartedly agree Tom

On Tue, 9 Feb 2021, 13:31 tom,  wrote:

> Against it.
>
> There are too many callsigns being issued for numerous reasons -
> anniversaries / covid / 1st etc.  Having the software check (and keep
> having to get internal lists updates from other sites) is not really
> practical.
>
> I can’t think of an easy way to detect pirates - non-dxcc you have the
> overhead and issues as mentioned above - there is no ‘100% verifiable’ list
> of genuine callsigns - also no way to tell that the GM8MJV you are working
> is in fact me - it’s a valid callsign - someone may  be using it - a pirate
> but unable to detect it.
>
> Would be better off concentrating on detecting and blocking the robots and
> flag those.
>
> Tom
> GM8MJV
>
>
> > On 9 Feb 2021, at 10:37, Anders Strange 
> wrote:
> >
> > Would it be an idea to implement a 'Valid DXCC' checking and 'Pirate
> Detection' feature?
> >
> > The problem is that pirate callsigns like the Dxx from the Donetsk
> region in Russia show up as new/unknown DXCC's. It would be fairly easy to
> implement a check against the ITU list and the valid DXCC list and make a
> new color for 'possible pirate' or something.
> >
> > What do you think?
> >
> > 73's
> > Anders / OZ3ACB
> > ___
> > wsjt-devel mailing list
> > wsjt-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSPRD Directory Check Missing

[Roeland Jansen]

I back Rud on this:  the issue though is that if something else (for
whatever reason) calls wsprd, imho it should be better to handle this
to be on the safe side?

R.

On Wed, Dec 2, 2020 at 11:05 PM Bill Somerville 
wrote:

> On 02/12/2020 21:55, Rud Merriam wrote:
>
> Hi Bill,
>
> I realize that is the default. But if they pass in a directory there is no
> check if the directory exists. There should be a error in that case.
>
> One reason I'm mentioning this is I'm not sure how much wsprd code is
> carried over to other wjst code where it could be a bigger issue.
>
> 
>
> Also, in 'readc2file' the variable definition 'char* c2file[15];' should
> not be pointer. It should be ' char c2file[15];'. In the later 'fread' it
> should be passed as an address:
>
> nr = fread( , sizeof(char), 14, fp);
>
> The original is a pointer to a 15 char c-string that doesn't exist.
> Fortunately, it is never used. It just eats the filename from the beginning
> of the file.
>
> -73 -
> *Rud Merriam K5RUD*
>
> Hi Rud,
>
> WSJT-X invokes wsprd as a sub-process. It always calls it with an existing
> data directory.
>
> Thanks for the note about the .c2 file reader. I will fix that.
>
> 73
> Bill
> G4WJS.
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X defect report - Incorrect tab 2 grid message

[Roeland Jansen]

sudo remove tab2 

On Wed, 29 Jul 2020, 09:36 Neil Zampella,  wrote:

> I have no problem with removing that for the next version.  Would save a
> lot of time by you and the other developers during contests answering
> questions about why something was not logged properly. Tab 1 gives
> the user a full visual display of what they are sending, and should be
> receiving, which would eliminate other 'issues' about the way a QSO
> progresses.
>
>
>
> Neil, KN3iLZ
>
> On 7/28/2020 10:28 AM, Joe Taylor wrote:
> > Hi Andy,
> >
> >> Any valid call with a valid suffix will fail to generate a Tab 2 Grid
> >> message.
> >>
> >> Clear DX Call and DX Grid fields
> >> Select Message Tab 2
> >> Press Grid message button - generated message is blank.  As expected.
> >> Enter "CALL" in DX Call field and press Grid - generated message is
> >> " {my call} {my grid}".  As expected.
> >> Enter "CALL/7" in DX Call field and press grid - generated message is
> >> " {my call} {report}".  Not as expected.
> >> Select Message Tab 1 - Observe  " {my call} {my grid}" was
> >> correctly generated.
> >
> > I can confirm the behavior you describe.
> >
> > Tab 2 was originally introduced as as aid to users of JT65-HF. It's
> > more or less what those users were accustomed to.
> >
> > Tab 2 is currently deprecated, at least by your developers.  We never
> > use it, seldom test it, and generally wish it would go away.  It does
> > not fit comfortably into the many ways WSJT-X has evolved since the
> > advent of FT8, FT4, and other things yet to come.
> >
> > Would there be huge howls of protest if Tab 2 were permanently
> > removed? If so, should we pay attention to them?
> >
> > -- 73, Joe, K1JT
> >
> >
>
> --
> This email has been checked for viruses by AVG.
> https://www.avg.com
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] 7610 Split issue

[Roeland Jansen]

Not sure if the 785x works the same but if so... all is online here
Mike.

On Sun, Jun 14, 2020 at 5:36 AM Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Hi Jon,
> Would you be willing to let me connect up to your computer and do some
> debugging?
> I think we may already have this fixed but would like to confirm for the
> 7610.
>
> Mike W9MDB
>
>
>
>
> On Saturday, June 13, 2020, 10:24:55 PM CDT, Jon Anhold 
> wrote:
>
>
> Working the VHF contest with the IC-7610 on 6m.
>
> Using N1MM SO2R, two instances of WSJT-X running w/N1MM integration.
>
> I'm not certain if this is an n1mm issue or a WSJT-X / hamlib change or
> issue.
>
> In the past, if I recall correctly, when WSJT-X is set to use "Rig" for
> split mode, the rig stays in split most if not all of the time.
>
> Now, when in receive mode, the rig is not in split, and it gets put into
> split mode on TX, sometimes.
>
> Sometimes it doesn't, and the radio ends up TXing on the primary VFO.
>
> I'm not sure how to replicate it, since it seems somewhat random, but it's
> happened enough to be really frustrating.
>
> 73 de KM8V
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Coming soon: WSJT-X 2.2.0-rc1

[Roeland Jansen]

>Your name and call??

the name would be in the from line and I was not aware of the need for a
call sign but hey..


Roeland Jansen, PA3MET

>Starting with WSJT-X v2.2.0, reception of one of the specialized EU VHF
>Contest messages will cause trigger a message asking whether you should
>switch to using EU VHF Contest messages.  The switch will not be automatic.


that's good news! Thanks for the heads up.



On Fri, May 8, 2020 at 9:11 PM Joe Taylor  wrote:

> On 5/7/2020 02:35, Roeland Jansen wrote:
> > regarding the EU VHF contest mode:
> >
> > it appears that even if it's unchecked the software does switch to
> > contest mode. when you happen to
> > get a reply (?) or klick on someone who uses that mode. I think that is
> > fine and fair enough.
> > However, it stays in that mode even when it was initially directed not
> to.
> >
> > During ft8 activity contests, people use also other software that does
> > not even have the EU VHF contest mode.
> > This means that if the switch has been made, you need to recognize it,
> > reset it in the menu and call again.
> >
> > That's the thought on this?
>
> Your name and call??
>
> Starting with WSJT-X v2.2.0, reception of one of the specialized EU VHF
> Contest messages will cause trigger a message asking whether you should
> switch to using EU VHF Contest messages.  The switch will not be automatic.
>
> Obviously, to send or receive the specialized EU VHF Contest messages
> you must use WSJT-X or some other software that supports these messages.
>
> -- 73, Joe, K1JT
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Coming soon: WSJT-X 2.2.0-rc1

[Roeland Jansen]

regarding the EU VHF contest mode:

it appears that even if it's unchecked the software does switch to contest
mode. when you happen to
get a reply (?) or klick on someone who uses that mode. I think that is
fine and fair enough.
However, it stays in that mode even when it was initially directed not to.

During ft8 activity contests, people use also other software that does not
even have the EU VHF contest mode.
This means that if the switch has been made, you need to recognize it,
reset it in the menu and call again.

That's the thought on this?



On Tue, May 5, 2020 at 6:24 PM Joe Taylor  wrote:

> Hi all,
>
> This message is to let you know of some important WSJT-X development
> plans.  We plan to make a first candidate release of WSJT-X 2.2.0 next
> Monday, May 10.
>
> WSJT-X 2.2.0-rc1 will be a beta-quality release candidate providing a
> number of new features and capabilities.  These include:
>
>- Improvements to the decoders for five modes:
>
>FT4: Corrected bugs that prevented AP decoding and/or multi-pass
>decoding in some circumstances.  The algorithm for AP
>decoding has been improved and extended.
>
>FT8: Decoding is now spread over three intervals.  The first
>starts at t = 11.8 s into an Rx sequence and typically yields
>around 85% of the possible decodes for the sequence.  You
>therefore see most decodes much earlier than before.  A second
>processing step starts at 13.5 s, and the final one at 14.7 s.
>Overall decoding yield on crowded bands is improved by 10% or
>more.  (Systems with receive latency greater than 0.2 s will see
>smaller improvements, but will still see many decodes earlier
>than before.)
>
>JT4: Formatting and display of Averaged and Deep Search decodes
>has been cleaned up and made consistent with other modes.  JT4
>remains the digital mode of choice for EME and other extreme
>weak-signal work on microwave bands.
>
>JT65: Many improvements for Averaged and Deep Search decodes and
>their display to the user.  These improvements are particularly
>important for EME on VHF and UHF bands.
>
>WSPR: Significant improvements have been made to the WSPR
>decoder's sensitivity, its ability to cope with many signals in
>a crowded sub-band, and its rate of undetected false decodes.
>We now use up to three decoding passes.  Passes 1 and 2 use
>noncoherent demodulation of single symbols and allow for
>frequency drifts up to ±4 Hz in a transmission.  Pass 3 assumes
>no drift and does coherent block detection of up to three
>symbols.  It also applies bit-by-bit normalization of the
>single-symbol bit metrics, a technique that has proven helpful
>for signals corrupted by artifacts of the subtraction of
>stronger signals and also for LF/MF signals heavily contaminated
>by lightning transients.  With these improvements the number of
>decodes in a crowded WSPR sub-band typically increases by 10 to
>15%.
>
>   - New format for "EU VHF Contest" Tx2 and Tx3 messages
>
>When "EU VHF Contest" is selected, the Tx2 and Tx3 messages
>(those conveying signal report, serial number, and 6-character
>locator) now use hashcodes for both callsigns.  This change is
>NOT backward compatible with earlier versions of _WSJT-X_, so
>all users of EU VHF Contest messages should be sure to upgrade
>to versiion 2.2.0.
>
>   - Accessibility
>
>Keyboard shortcuts have been added as an aid to accessibility:
>Alt+R sets Tx4 message to RR73, Ctrl+R sets it to RRR.
>
>As an aid for partial color-blindness, the "inverted goal posts"
>marking Rx frequency on the Wide Graph's frequency scale are now
>rendered in a darker shade of green.
>
>   - Minor enhancements and bug fixes
>
>"Save None" now writes no .wav files to disk, even temporarily.
>
>An explicit entry for "WW Digi Contest" has been added to
>"Special operating activities" on the "Settings | Advanced" tab.
>
>Contest mode FT4 now always uses RR73 for the Tx4 message.
>
>The Status bar now displays the number of decodes found in the
>most recent Rx sequence.
>
> Release candidate WSJT-X 2.2.0-rc1 will be available for beta-testing
> for one month starting on May 10, 2020.  We currently plan a General
> Availability (GA) release of WSJT-X 2.2.0 on June 1, 2020.
>
> For those looking even farther ahead: We are well along in the
> development of two new modes designed for the LF and MF bands.  One
> mode is for WSPR-like activity and one for making 2-way QSOs.  Both
> use Low-density Parity Check (LDPC) codes, 4-GFSK modulation, and
> two-minute T/R sequences.  The QSO mode reaches threshold SNR
> sensitivity around -31 dB on the AWGN channel, and the WSPR-like mode
> 

Re: [wsjt-devel] ICOM IC-7300, no luck connecting from either a Windows machine or a Mac

[Roeland Jansen]

>
> What is *CI-V Transceive*?
>
> All Icom rigs equipped with CI-V offers the option of enabling/disabling *CI-V
> transceive*. What is this?
>
> With CI-V Transceive set to *on*, two things happen:
>
>- the rigs transmits data over the bus when frequency or mode changes;
>- the rig reacts to data sent over the bus which is adressed not only
>to it's own adress but also to a special adress meaning "all rigs 
> connected"
>
> With CI-V Transceive set to *off*, the behaviour changes:
>
>- the rig doesn't send data when you turn the dial or change mode;
>- the rig reacts only to data sent to it's specific adress, data sent
>to "ALL" is ignored.
>
> So in most circumstances you will have CI-V Transceive set to on, at least
> as long as there is only one rig connected to a PC. If more than one rig is
> connected over the same interface (converter) to a PC, it might be useful
> to turn this option off in all but one rig.
>
> Please note that some logging programs require you to turn off the CI-V
> Transceive function, check the documentation of the software.
>


I have three rigs connected (USB, not via a converter) and all three have
it on. YMMV. But hey if you want it off for the OP, fine.
We'll have to wait for the rates and such if he now can talk to the rig I
guess.
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] ICOM IC-7300, no luck connecting from either a Windows machine or a Mac

[Roeland Jansen]

ok. that one went too fast out of the machine.

update to v1.30

civ baud rate 19200, not auto -- auto looks so nice but may fail
civ address 94  -- check that it's in wsjtrx the same
civ transceive on (there is no need to switch it off)
civ usb remote address 00
civ output for ant off
civ usb port unlink from remote
civ ubsb baud rate 115k2
civ usb echo back on


in wsjtx: select right comport
use 115200 as baud rate not auto as stated above
8 data bits
2 stop bits
handshake none
ptt method cat
mode data/pkt
split ops none


most of the issues are bound to rates that might be confusing and
linu/unlink settings.


above works for  apple stuff, linux and windows.



On Sat, Apr 11, 2020 at 3:21 PM Roeland Jansen 
wrote:

>
> first of all -- update to v1.30 which is the latest f/w that I know of.
>
>
> Secondly,
>
> CIV:
>
> CIV baud rate
>
> On Sat, 11 Apr 2020, 14:34 Frank Birch,  wrote:
>
>> Ensure the Baud rates are the same. I’m able to run at highest.
>> Are you connecting direct to the USB port - no hub.
>> Stay safe, be well
>> 73
>> Ve4fbz
>>
>> > On Apr 11, 2020, at 8:13 AM, sourceforge@from.ec wrote:
>> >
>> > Hi, all. I'm trying to get my ICOM IC-7300 connected for rig-control
>> and digital modes.
>> >
>> > I've installed the drivers (from SiLabs on my Mac, and directly from
>> ICOM on my Windows box); but on both machines, with just about every
>> combination of configuration options I've tried, I get this error:
>> >
>> >> Rig failure
>> >> Hamlib error: Communication bus error while getting current frequency
>> >
>> > On my Windows machine, the ICOM shows up as "COM3" (i.e. that's the
>> only menu option); and on my Mac, it shows up as all four of
>> /dev/cu.SLAB_USBtoUART, /dev/tty.SLAB_USBtoUART, /dev/cu.usbserial-4224411,
>> and /dev/tty.usbserial-4224411. (i.e. all four of those disappear when the
>> radio is disconnected.)
>> >
>> > Here's a screenshot of my Windows configuration, as well as some pics
>> of the ICOM's settings (all reset to factory-settings, and I've tried every
>> combination I can think of ...): https://imgur.com/a/mg9BcAd
>> >
>> > I'm a fairly competent(?) programmer, but this has completely baffled
>> me. I've tried everything I can think of, so any help is very welcome.
>> Happy to attempt any debugging-steps that y'all can suggest, too!
>> >
>> > ~ Elliott Cable, KL4JC
>> >
>> >
>> > ___
>> > wsjt-devel mailing list
>> > wsjt-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
>>
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] ICOM IC-7300, no luck connecting from either a Windows machine or a Mac

[Roeland Jansen]

first of all -- update to v1.30 which is the latest f/w that I know of.


Secondly,

CIV:

CIV baud rate

On Sat, 11 Apr 2020, 14:34 Frank Birch,  wrote:

> Ensure the Baud rates are the same. I’m able to run at highest.
> Are you connecting direct to the USB port - no hub.
> Stay safe, be well
> 73
> Ve4fbz
>
> > On Apr 11, 2020, at 8:13 AM, sourceforge@from.ec wrote:
> >
> > Hi, all. I'm trying to get my ICOM IC-7300 connected for rig-control
> and digital modes.
> >
> > I've installed the drivers (from SiLabs on my Mac, and directly from
> ICOM on my Windows box); but on both machines, with just about every
> combination of configuration options I've tried, I get this error:
> >
> >> Rig failure
> >> Hamlib error: Communication bus error while getting current frequency
> >
> > On my Windows machine, the ICOM shows up as "COM3" (i.e. that's the only
> menu option); and on my Mac, it shows up as all four of
> /dev/cu.SLAB_USBtoUART, /dev/tty.SLAB_USBtoUART, /dev/cu.usbserial-4224411,
> and /dev/tty.usbserial-4224411. (i.e. all four of those disappear when the
> radio is disconnected.)
> >
> > Here's a screenshot of my Windows configuration, as well as some pics of
> the ICOM's settings (all reset to factory-settings, and I've tried every
> combination I can think of ...): https://imgur.com/a/mg9BcAd
> >
> > I'm a fairly competent(?) programmer, but this has completely baffled
> me. I've tried everything I can think of, so any help is very welcome.
> Happy to attempt any debugging-steps that y'all can suggest, too!
> >
> > ~ Elliott Cable, KL4JC
> >
> >
> > ___
> > wsjt-devel mailing list
> > wsjt-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] wsjtx, rsba1, hamlib, for the fun of it. because we can.

[Roeland Jansen]

for the shits and giggles


just took the liberty to config a windows laptop downstairs, connected via
rsba1 to one of my rigs, the 7851.
The 7851 is available over te lan and is also controlled over it's USB port
with rigctld.
wsjtx is configured to talk to net rigcontrol.

At the rig's end a linux machine is connected over USB but as said in the
previous post -- any system will do that runs rigctld from hamlib.

https://youtu.be/BofxsrBYjQI

The TRX was set at < 5W so no QSOs were obviously made. It works with the
7300 and 9700 as well. No reasons to believe that the 7610
won't work.

the TX tones were for testing used to show that the audio can be routed to
the rig remotely.
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.1.1 GA release

[Roeland Jansen]

what rig type did

On Mon, Nov 25, 2019 at 9:45 PM Jon Anhold  wrote:

> I'm not sure why yet, but when I upgrade to 2.1.1, I get the following
> error on startup:
>
> [image: image.png]
>
> 73 de KM8V
>
> On Mon, Nov 25, 2019 at 1:43 PM Joe Taylor  wrote:
>
>> The WSJT Development Group is pleased to announce the general
>> availability (GA) release of WSJT-X Version 2.1.1.
>>
>> WSJT-X 2.1.1 is a bug-fix release that addresses regressions in the
>> v2.1.0.  The new version executes properly on Macintosh machines running
>> macOS 10.15 (Catalina).
>>
>> A list of program changes since WSJT-X 2.1.0 can be found in the
>> cumulative Release Notes:
>> http://physics.princeton.edu/pulsar/k1jt/Release_Notes.txt
>>
>> Upgrading from earlier versions of WSJT-X should be seamless.  There is
>> no need to uninstall a previous version or move any files.
>>
>> Links to installation packages for Windows, Linux, and Macintosh are
>> available here:
>> http://physics.princeton.edu/pulsar/k1jt/wsjtx.html
>>
>> You can also download the packages from our SourceForge site:
>> https://sourceforge.net/projects/wsjt/files/
>> It may take a short time for the SourceForge site to be updated.
>>
>> WSJT-X is licensed under the terms of Version 3 of the GNU General
>> Public License (GPL).  Development of this software is a cooperative
>> project to which many amateur radio operators have contributed.  If you
>> use our code, please have the courtesy to let us know about it.  If you
>> find bugs or make improvements to the code, please report them to us in
>> a timely fashion.
>>
>> We hope you will enjoy using WSJT-X Version 2.1.1.
>>
>>   -- 73, Joe, K1JT, for the WSJT Development Group
>>
>>
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] logging

[Roeland Jansen]

as said, it is is in the logging directory. be sure you don't hide file
extensions under Windows

On Wed, 30 Oct 2019, 15:49 Carl Buehler,  wrote:

> WSJT-X 2.1.0  logging still a concern. The wsjtx text log continues to
> save contacts. I downloaded and installed the program but no .adi or
> similar file appears to be created in the tab 'open log directory'.  Should
> this be somewhere in the program or be able to generate it for LOTW?
> Thanks much.
> -k9za
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Two recommendations

[Roeland Jansen]

I am with Mike on this, been there, done that. Really annoying.

On Mon, 5 Aug 2019, 18:13 Black Michael via wsjt-devel, <
wsjt-devel@lists.sourceforge.net> wrote:

> If you install 2.1.0 over 2.0.0 for example you end up with two listings
> in the App manager.
> If you try to uninstall 2.0.0 it fails.  The only fix is to reinstall
> 2.0.0 so you can uninstall itthen reinstall 2.1.0
> It's the setup that has the version number in the name that causes the
> problem.  If the version number were left out of the installation the
> problem would also go away as it would just be an "upgrade" at that point.
>
> We've found people with numerous program entries.  The simple solution is
> to install in a separate directory.  The users are responsible to uninstall
> the old version which will successfully work which should be mention when
> the announcment is done.  Much easier to uninstall then try to fix
> duplicate entries.
>
> For the INI file you don't see how a backup might be good?  Numerous
> problems with corrupt config files preventing startingdowngrading to
> previous version problemsall sorts of reasons to have a backup.  Manual
> backup may be best plus the one-time copy if there is no backup.
>
> Mike
>
>
>
>
>
> On Monday, August 5, 2019, 09:09:59 AM CDT, Bill Somerville <
> g4...@classdesign.com> wrote:
>
>
> On 05/08/2019 14:53, Black Michael via wsjt-devel wrote:
> > #1 Make the default installation path use the version number
> > (including RC candidates) do avoid all the duplicate entries one gets
> > in the application manager.
>
> Mike,
>
> WSJT-X expects multiple installations to be made by more sophisticated
> users, like beta testers. The installation path is not the key to the
> registry entries. Your suggestion would achieve nothing but filling the
> average user's disk with redundant files. The registry entries for the
> uninstaller are benign and very small, why do you think they are a
> problem? You should instead be asking MS why they changed Windows at v10
> such that orphaned programs and features entries were no longer
> automatically cleaned up!
>
> >
> > #2 Make a "Backup" menu entry to allow backing up the INI file and
> > create a backup by default if it doesn't exist.
> What does this achieve?
>
> >
> > de Mike W9MDB
>
>
> 73
> Bill
> G4WJS.
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] qtpulsestream: at first transmission audio reverts to internal device, bug/feature?

[Roeland Jansen]

hi,
the following is something I have seen since 2016 or so and while I always
fix it by hand, it makes me wonder if it's a bug, feature or otherwise.
- I have wsjt-x started and both rx and tx point to the pcm2901 codec of
the icom transceiver(s). I decode just fine etc. However, at first
transmission is see the following:
- Directly when tx is asserted, the qtpulsestream reverts back to the
internal rx device.
- Obviously any subsequent decode is pcked up via the microphone. You can
see it happen live when running pavucontrol.
- If I force it back to the pcm2901 codec, all works, this can be done
during the tx cycle.

So, I generally just hit tune for a second, I use pavucontrol (or the kde
version) to fix the input and all keeps working.
e.g. startup wsjtx:  qtpulsestream: pcm2901
   tune/tx: qtpulse switches to internal
   change back by hand once fixes it for the lifetime of wsjtx.

Walter, DL8FCL has noted this behaviour as well (he's the maintainer of the
wsjtx package for opensuse) and uses the same way to 'fix' it.
In the past well before 2016, it was working well.

Roeland
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Lid operators or bad design?

[Roeland Jansen]

I sometimes just used to forget. I have made a habit to keep the TX freq
now.


On Sun, Jul 28, 2019 at 6:20 PM Claude Frantz 
wrote:

> On 7/28/19 6:00 PM, Ron WV4P wrote:
>
> Hi Ron, Andy & all,
>
> > Way to much credit has been given to the ability of Operators. Hold TX
> > should be checked by default and Deep in the menu to turn it off...
> > Then, upon rebooting it should again default to on.
>
> In addition, I recommend to check, from time to time, if this holded own
> TX frequency is still a judicious choice.
>
> > On Sun, Jul 28, 2019, 10:58 AM Andy Durbin  > > wrote:
> >
> > Everyone who uses WSJT-X for FT8 must have noticed the number of
> > operators who answer a CQ and then, when the QSO is complete, call
> > CQ on the same frequency.
>
> Infortunatly, I have observed this behaviour too often, also.
>
> Best wishes,
> Claude (DJ0OT)
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Contest confusion

[Roeland Jansen]

I have thee configs with different codec/civ/etc (9700, 7300, 7851) myself
and all three required a restart of wsjtx. If that is the same as with
this... I would not thing the option would be too good to use.


On Tue, 23 Jul 2019, 05:22 Rich Zwirko - K1HTV,  wrote:

> Your idea of switching from the contest configuration to the one used for
> normal operation looks good on paper, but there is a problem. When the
> normal configuration comes up, the callsign of the station you were working
> is replaced by the call of the last station you worked with the normal
> operating configuration. None of the message boxes will have the callsign
> of the station your were just working.  And I'll bet a doughnut that most
> guys won't remember who they were working after switching to the 'Normal'
> WSJT-X configuration.
>
> If after 2 or 3 repeats from the other station, the best thing to do is to
> switch sequences and start calling CQ. If you stay in the same sequence and
> call CQ, you will end up responding again with calls and report to that
> same station, unless he aborts the QSO.
>
> 73,
> Rich - K1HTV
>
> = = =
>
> From:   Laurie, VK3AMA <_vk3a...@vkdxer.net>
>
> Simple and only requires a single mouse click. Setup two configurations
> in WSJT-X, one for you desired contest and the other non-contest. Once
> setup, it is a single click using the "Configuration" menu to switch
> between contest and non-contest.
>
> de Laurie VK3AMA
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Contest confusion

[Roeland Jansen]

that certainly does. a contest is in cw easier than ragchewining, esp at
high speed as most of the things to exchange are 'known values'.


On Mon, Jul 22, 2019 at 11:18 PM Larry B. via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> However, 59 or 599 serves the human brain as a very good synchronizing
> sound, so that we can easily copy the "real" exchange that come after it.
> At least it does for me, especially on CW.
>
> 73 -- Larry -- W1DYJ
>
>
>
>
> -Original Message-
> From: Ed Muns
> Sent: Monday, July 22, 2019 16:32
> To: 'John Kludt'
> Cc: 'WSJT-Dev'
> Subject: Re: [wsjt-devel] Contest confusion
>
> Hi John.
>
> Excellent question!  In most instances today RST is meaningless, whether
> contesting, DXing or everyday operating.  However, there are still some of
> us old-timers who learned ham radio with true RST reports.  We were
> educated
> about the meaning of each number and tried to apply the appropriate RST to
> each report which was a key part of the first transmission in each QSO.
>
> Over the ensuing decades RST has evolved to a perfunctory '599' in most
> QSOs.  Sometimes we're too embarrassed to send '599' when we're struggling
> to finish a weak DX QSO and we will sent '559' or '229' or whatever.
> Mostly, it is a mindless '599'.  Now, with WSJT-X we have true, accurate
> SNR
> and it's still mindless, in the sense that we don't have to think about
> it.
> The software determines the correct SNR.
>
> Thus, ham radio has a free opportunity to return to its roots when RST was
> meaningful and exchange meaningful SNR reports.  Readability and Tone
> don't
> have much value in the WSJT-X modes, but signal strength adds interest and
> some substance to each QSO.  I'm a strong advocate of supporting SNR in
> WSJT-X QSOs.
>
> Ed W0YK
>
> -Original Message-
> From: John Kludt 
> Sent: 22 July, 2019 03:34
> To: e...@w0yk.com
> Cc: WSJT-Dev 
> Subject: Re: [wsjt-devel] Contest confusion
>
> Ed,
>
> I have only one question - what is so sacred about a signal report?  Most
> are bogus, anyway.  Our old section manager used to laugh about "You are
> 59
> or 599" frequently followed by "again, again."
>
> John
>
> Sent from my Verizon Motorola Smartphone
> On Jul 22, 2019 00:01, Ed Muns  wrote:
> >
> > Great tip, Laurie.
> >
> > This is a good technique if one can reasonably assume that the majority
> of
> > QSO partners sending a signal report will not complete the QSO, or log
> it,
> > if the contester only sends a Grid Square.
> >
> > IOW, if a contester set to NA VHF Contest mode connects up with a
> > "non-contester" set to normal mode (Special Activity unchecked), and both
> > are configured for Auto Seq, then the QSO will complete without any
> > operator
> > intervention.  However, the contester will not have sent a signal report
> > to
> > the non-contester.  That may be an issue, because the non-contester may
> > continue to send his SNR message, hoping to elicit an SNR in return.
> Or,
> > he
> > may not log the contact because he never received an SNR from the
> > contester.
> > This may not be a problem for the contester, because the non-contester is
> > unlikely to submit a Cabrillo log, so the contester will avoid a NIL.
> >
> > Back to your tip of setting up two instances of WSJT-X, one with NA VHF
> > Contest mode enabled and one with Special Activity unchecked.  This is a
> > good technique for the contester to get another QSO in the log that
> > otherwise would not happen, IF the assumption is the majority of "mixed"
> > QSOs as described above will not complete successfully because the
> > non-contester is concerned that he didn't receive a signal report.
> >
> > The contester has to decide whether to power through the QSO in the NA
> VHF
> > Contest mode, or to on-the-fly switch to his "SNR Configuration" that
> uses
> > the standard non-contest message sequence and indeed sends an SNR
> message
> > to
> > the non-contester.
> >
> > Ed W0YK
> >
> > -Original Message-
> > From: Laurie, VK3AMA <_vk3a...@vkdxer.net>
> > Sent: 21 July, 2019 16:04
> > To: wsjt-devel@lists.sourceforge.net
> > Subject: Re: [wsjt-devel] Contest confusion
> >
> > On 22/07/2019 7:16 am, Jim Brown wrote:
> > > so I quickly switched out of contest mode to work him. :)
> > >
> > > What I WOULD like is to able to do this without going to Settings
> > > Advanced. All those clicks loses a TX cycle.
> > >
> > > 73, Jim K9YC
> >
> > Simple and only requires a single mouse click. Setup two configurations
> > in WSJT-X, one for you desired contest and the other non-contest. Once
> > setup, it is a single click using the "Configuration" menu to switch
> > between contest and non-contest.
> >
> > de Laurie VK3AMA
> >
> >
> >
> > ___
> > wsjt-devel mailing list
> > wsjt-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> >
> >
> >
> > ___
> > wsjt-devel mailing 

Re: [wsjt-devel] Contest confusion

[Roeland Jansen]

yes that is exactly what I meant.

On Mon, Jul 22, 2019 at 10:07 PM John Kludt  wrote:

> Roeland,
>
> Agree.  In the CQWW VHF contest the rules make it clear the signal report
> is *not* part of the exchange.  Maybe that is your point - can't quite
> tell from your email.
>
> John
>
> On Mon, Jul 22, 2019 at 10:07 AM Roeland Jansen <
> roeland.janse...@gmail.com> wrote:
>
>>
>> contest stations generally only want valid contacts (according to the
>> contest rules) to prevent
>> a penalty. That also is a thing.
>>
>> On Mon, Jul 22, 2019 at 2:31 PM Ryan Tourge 
>> wrote:
>>
>>> A bit prissy to exclude a station that lacks a signal report. You both
>>> ack'd each other. obviously the call took place.
>>>
>>> On Mon, Jul 22, 2019 at 6:53 AM Fred Price  wrote:
>>> >
>>> > Ed,
>>> >
>>> > You do know that if you are using LoTW to confirm your QSO's then all
>>> that is needed for a valid QSO is:
>>> > Exchange of calls
>>> > Band
>>> > Date
>>> > Time +/-30 minutes
>>> >
>>> > So it makes no difference if your signal report is a SNR or a grid
>>> square. However since it is your station it is your choice on how you log.
>>> > Have fun n enjoy after all it's not life of death it's just a hobby.
>>> >
>>> > Fred
>>> > N2XK
>>> >
>>> > On Jul 22, 2019 12:01 AM, Ed Muns  wrote:
>>> >
>>> > Great tip, Laurie.
>>> >
>>> > This is a good technique if one can reasonably assume that the
>>> majority of
>>> > QSO partners sending a signal report will not complete the QSO, or log
>>> it,
>>> > if the contester only sends a Grid Square.
>>> >
>>> > IOW, if a contester set to NA VHF Contest mode connects up with a
>>> > "non-contester" set to normal mode (Special Activity unchecked), and
>>> both
>>> > are configured for Auto Seq, then the QSO will complete without any
>>> operator
>>> > intervention.  However, the contester will not have sent a signal
>>> report to
>>> > the non-contester.  That may be an issue, because the non-contester may
>>> > continue to send his SNR message, hoping to elicit an SNR in return.
>>> Or, he
>>> > may not log the contact because he never received an SNR from the
>>> contester.
>>> > This may not be a problem for the contester, because the non-contester
>>> is
>>> > unlikely to submit a Cabrillo log, so the contester will avoid a NIL.
>>> >
>>> > Back to your tip of setting up two instances of WSJT-X, one with NA VHF
>>> > Contest mode enabled and one with Special Activity unchecked.  This is
>>> a
>>> > good technique for the contester to get another QSO in the log that
>>> > otherwise would not happen, IF the assumption is the majority of
>>> "mixed"
>>> > QSOs as described above will not complete successfully because the
>>> > non-contester is concerned that he didn't receive a signal report.
>>> >
>>> > The contester has to decide whether to power through the QSO in the NA
>>> VHF
>>> > Contest mode, or to on-the-fly switch to his "SNR Configuration" that
>>> uses
>>> > the standard non-contest message sequence and indeed sends an SNR
>>> message to
>>> > the non-contester.
>>> >
>>> > Ed W0YK
>>> >
>>> > -Original Message-
>>> > From: Laurie, VK3AMA <_vk3a...@vkdxer.net>
>>> > Sent: 21 July, 2019 16:04
>>> > To: wsjt-devel@lists.sourceforge.net
>>> > Subject: Re: [wsjt-devel] Contest confusion
>>> >
>>> > On 22/07/2019 7:16 am, Jim Brown wrote:
>>> > > so I quickly switched out of contest mode to work him. :)
>>> > >
>>> > > What I WOULD like is to able to do this without going to Settings
>>> > > Advanced. All those clicks loses a TX cycle.
>>> > >
>>> > > 73, Jim K9YC
>>> >
>>> > Simple and only requires a single mouse click. Setup two configurations
>>> > in WSJT-X, one for you desired contest and the other non-contest. Once
>>> > setup, it is a single click using the "Configuration" menu to switch
>>> > between contest and non-contest.
>>> >
>>> > de Laurie VK3AMA

Re: [wsjt-devel] Contest confusion

[Roeland Jansen]

contest stations generally only want valid contacts (according to the
contest rules) to prevent
a penalty. That also is a thing.

On Mon, Jul 22, 2019 at 2:31 PM Ryan Tourge  wrote:

> A bit prissy to exclude a station that lacks a signal report. You both
> ack'd each other. obviously the call took place.
>
> On Mon, Jul 22, 2019 at 6:53 AM Fred Price  wrote:
> >
> > Ed,
> >
> > You do know that if you are using LoTW to confirm your QSO's then all
> that is needed for a valid QSO is:
> > Exchange of calls
> > Band
> > Date
> > Time +/-30 minutes
> >
> > So it makes no difference if your signal report is a SNR or a grid
> square. However since it is your station it is your choice on how you log.
> > Have fun n enjoy after all it's not life of death it's just a hobby.
> >
> > Fred
> > N2XK
> >
> > On Jul 22, 2019 12:01 AM, Ed Muns  wrote:
> >
> > Great tip, Laurie.
> >
> > This is a good technique if one can reasonably assume that the majority
> of
> > QSO partners sending a signal report will not complete the QSO, or log
> it,
> > if the contester only sends a Grid Square.
> >
> > IOW, if a contester set to NA VHF Contest mode connects up with a
> > "non-contester" set to normal mode (Special Activity unchecked), and both
> > are configured for Auto Seq, then the QSO will complete without any
> operator
> > intervention.  However, the contester will not have sent a signal report
> to
> > the non-contester.  That may be an issue, because the non-contester may
> > continue to send his SNR message, hoping to elicit an SNR in return.
> Or, he
> > may not log the contact because he never received an SNR from the
> contester.
> > This may not be a problem for the contester, because the non-contester is
> > unlikely to submit a Cabrillo log, so the contester will avoid a NIL.
> >
> > Back to your tip of setting up two instances of WSJT-X, one with NA VHF
> > Contest mode enabled and one with Special Activity unchecked.  This is a
> > good technique for the contester to get another QSO in the log that
> > otherwise would not happen, IF the assumption is the majority of "mixed"
> > QSOs as described above will not complete successfully because the
> > non-contester is concerned that he didn't receive a signal report.
> >
> > The contester has to decide whether to power through the QSO in the NA
> VHF
> > Contest mode, or to on-the-fly switch to his "SNR Configuration" that
> uses
> > the standard non-contest message sequence and indeed sends an SNR
> message to
> > the non-contester.
> >
> > Ed W0YK
> >
> > -Original Message-
> > From: Laurie, VK3AMA <_vk3a...@vkdxer.net>
> > Sent: 21 July, 2019 16:04
> > To: wsjt-devel@lists.sourceforge.net
> > Subject: Re: [wsjt-devel] Contest confusion
> >
> > On 22/07/2019 7:16 am, Jim Brown wrote:
> > > so I quickly switched out of contest mode to work him. :)
> > >
> > > What I WOULD like is to able to do this without going to Settings
> > > Advanced. All those clicks loses a TX cycle.
> > >
> > > 73, Jim K9YC
> >
> > Simple and only requires a single mouse click. Setup two configurations
> > in WSJT-X, one for you desired contest and the other non-contest. Once
> > setup, it is a single click using the "Configuration" menu to switch
> > between contest and non-contest.
> >
> > de Laurie VK3AMA
> >
> >
> >
> > ___
> > wsjt-devel mailing list
> > wsjt-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> >
> >
> >
> > ___
> > wsjt-devel mailing list
> > wsjt-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> >
> >
> > ___
> > wsjt-devel mailing list
> > wsjt-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] clock patch

[Roeland Jansen]

be aware of that if a) is 500 ms ahead and b) is 500 behind, the time skew
is already 1 second between the signals.

Anything more than a few ms is not good imho. Anyways, use whatever deems
suitable for you.



On Wed, Jul 3, 2019 at 4:33 PM Hasan al-Basri 
wrote:

> Yep, I'm aware of the potential latency issues, again, 500 ms is quite
> acceptable for the X suite...and I see far better than that.
>
> I haven't seen anywhere close to 500 ms errors against GPSDO (not usb)
> with my USB GPS. ..and that's with days of data collected and subject to
> statistical analysis. See the attached graphic.
>
> Not perfect, but way better and way cheaper than most other alternatives,
> especially if stuck away from home. 73, N0AN
> Hasan
>
>
> On Wed, Jul 3, 2019 at 9:16 AM Roeland Jansen 
> wrote:
>
>> the issue is not the device but the USB protocol -- it's well known for
>> latency issues. It's super that it works for you.
>>
>> We have in .nl a few synchronized receivers and transmitters for
>> repeaters and no way USB can be used there.
>>
>> But hey -- if it works for you, it's ok. But be aware of the mentioned
>> issues. And 500+ms wrong times are seen more.
>> I would not even consider it myself.
>>
>>
>> On Wed, Jul 3, 2019 at 3:57 PM Hasan al-Basri 
>> wrote:
>>
>>> Not all USB based GPS have issues. Not all software is the same.
>>> NMEATime2 does not show the issues you describe with a USB GPS. while the
>>> BKT software does. (for me)
>>>
>>> This one, from Amazon works. I have two of them.
>>>
>>> GlobalSat BU-353-S4 USB GPS Receiver (Black)
>>>
>>> The above USB based GPS used with NMEATime2, is certainly accurate
>>> enough for all the WSJT-X suite of programsand many of us have the DT
>>> to prove it.
>>>
>>> Please don't throw the baby out with the bath water, with a pursuit of
>>> unnecessary perfection.
>>>
>>> 73, N0AN
>>> Hasan
>>>
>>>
>>> On Wed, Jul 3, 2019 at 3:07 AM Matthew Miller 
>>> wrote:
>>>
>>>> Beware those GPS receivers – I got one (unstable latency was throwing
>>>> me off by as much as 550mS on NTP) and I found that when I tried to set up
>>>> ntpd to use GPS it was showing jitter of around 0.8 seconds.
>>>>
>>>>
>>>>
>>>> Further research, USB GPS is a BAD IDEA because there is often
>>>> buffering in the serial-USB converter chips as well as overhead with the
>>>> USB protocol.  Depending on what port you use it may also be connected thru
>>>> one or more hubs adding additional overhead and latency.  You may not “see”
>>>> a hub but many computers now have internal USB hubs for touchpad, keyboard,
>>>> webcams, touchscreens, Bluetooth, and a variety of other “built in”
>>>> features that now all hang off internal hubs.
>>>>
>>>>
>>>>
>>>> If you are going to go with a proper GPS time sync you really need a
>>>> non-USB serial GPS and PPS input…which is not trivial.
>>>>
>>>>
>>>>
>>>> Its not cheap, but I solved my problem with one of these…its plug and
>>>> play then just set your computer to point at its IP address.  I now have a
>>>> reliable source that indicates it has only 0.5mS jitter and 3mS latency
>>>> even going thru multiple network switches and a fairly busy WiFi network.
>>>>
>>>> https://timemachinescorp.com/product/gps-time-server-tm1000a/
>>>>
>>>>
>>>>
>>>> There are also other cheaper DIY Raspberry Pi projects (which have some
>>>> of their own challenges I didn’t feel like dealing with right now) that can
>>>> be built for under $100 to make a stratum-1 time server that works without
>>>> Internet but PLEASE PLEASE do not tell people to use USB GPS for time, its
>>>> going to increase the problems not fix them!
>>>>
>>>>
>>>>
>>>> -Matt / KK4NDE
>>>>
>>>>
>>>>
>>>> *From:* Neal Pollack [mailto:nea...@gmail.com]
>>>> *Sent:* Wednesday, June 26, 2019 12:08 PM
>>>> *To:* WSJT software development
>>>> *Subject:* Re: [wsjt-devel] clock patch
>>>>
>>>>
>>>>
>>>> Only some are due to lack of internet.
>>>>
>>>> USB GPS receivers are now approx $12 USD on Ebay.  I have tested a few
>>>> and they work fine with NM

Re: [wsjt-devel] clock patch

[Roeland Jansen]

e
>> of help content about time sync'ing options.
>>
>>
>>
>> Cheers,
>>
>>
>>
>> Neal
>>
>> N6YFM
>>
>>
>>
>> On Wed, Jun 26, 2019, 3:16 AM 
>> wrote:
>>
>> Send wsjt-devel mailing list submissions to
>> wsjt-devel@lists.sourceforge.net
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>> or, via email, send a message with subject or body 'help' to
>> wsjt-devel-requ...@lists.sourceforge.net
>>
>> You can reach the person managing the list at
>> wsjt-devel-ow...@lists.sourceforge.net
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of wsjt-devel digest..."
>>
>>
>> Today's Topics:
>>
>>1. Re: Clock patch (DG2YCB, Uwe)
>>2. Re: Clock patch (Roeland Jansen)
>>3. Re: Clock patch (Bill Somerville)
>>
>>
>> --
>>
>> Message: 1
>> Date: Wed, 26 Jun 2019 11:36:58 +0200
>> From: "DG2YCB, Uwe" 
>> To: "'Black Michael'" , "'WSJT software
>> development'" 
>> Subject: Re: [wsjt-devel] Clock patch
>> Message-ID: <004801d52c02$b33f1430$19bd3c90$@gmx.de>
>> Content-Type: text/plain; charset="utf-8"
>>
>> I?ve not yet seen the results, but your this approach really looks like
>> something which could bring a substantial progress regarding the timing
>> issue.
>>
>>
>>
>> Reason why I am supporting a warning message is that, besides field days,
>> I saw dozens of OMs/YLs who are not aware at all that system time of their
>> PCs needed to by synced. Alone two examples yesterday. Contacted both.
>> Seemed to be both are ?old? men, with no computer skills. One replied the
>> following: ?I am no longer a very young man (84 years old) who tries to
>> tamper with the new methods; with a total ignorance of the English
>> language??. If we like it or not: That?s the reality! Of course we could
>> let FT8, FT4, etc. be something only for the tiny community of
>> well-educated, scientifically trained OMs with good to excellent computer
>> skills. But if we want to make QSOs with more OMs/YLs, then WE need to do
>> something which helps THEM to overcome the hurdles.
>>
>>
>>
>> 73 de Uwe, DG2YCB
>>
>>
>>
>> Von: Black Michael via wsjt-devel [mailto:
>> wsjt-devel@lists.sourceforge.net]
>> Gesendet: Mittwoch, 26. Juni 2019 06:19
>> An: WSJT Software Development
>> Cc: Black Michael
>> Betreff: [wsjt-devel] Clock patch
>>
>>
>>
>> This patch shows a message if 80% of DT values are >= 0.5 seconds.
>>
>>
>>
>> https://www.dropbox.com/s/8j7qao9wa4wmzdm/clock.patch?dl=1
>>
>>
>>
>> I picked the 50% point of FT4's 1 second tolerance but perhaps a slightly
>> larger value might be appropriate.
>>
>>
>>
>> I think most, if not everybody, can get the > 20% < 0.5 seconds without a
>> problem.
>>
>>
>>
>> Even with my rather extreme latency of 300-400ms I don't trigger this.
>>
>>
>>
>> de Mike W9MDB
>>
>>
>>
>>
>>
>> -- next part --
>> An HTML attachment was scrubbed...
>>
>> --
>>
>> Message: 2
>> Date: Wed, 26 Jun 2019 11:55:47 +0200
>> From: Roeland Jansen 
>> To: WSJT software development 
>> Subject: Re: [wsjt-devel] Clock patch
>> Message-ID:
>> <
>> caj2u8oytzmmcmcauqppc9d3hk+6jxw1nxnvht-5auv5t5wt...@mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> I did not look at the patches Mike sent but:
>>
>> https://time.is/
>>
>> gives you how good/bad the time  is. If you start up:  do check like this
>> and refuse to go on if the timeskew is too large.
>> Add a link how to fix in the message and you force people to fix it.
>>
>> (not that people read notices)
>>
>> just my bad idea.
>>
>>
>> On Wed, Jun 26, 2019 at 11:41 AM DG2YCB, Uwe  wrote:
>>
>> > I?ve not yet seen the results, but your this approach really looks like
>> > something which could bring a substantial progress regarding the timing
>> > issue.
>> >
>> >
>> >
>> > Reason why I am supporting a warning mes

Re: [wsjt-devel] Clock patch

[Roeland Jansen]

you are right it does. On the other hand do you really want people to be
off on time?

You could consider instead of b0rking out -- if there is no internet, warn
and go on.

Then you have three groups:

a) groups of people that understand that any system without correct time
settings should not be switched on for a start.
and they have good timing. this group is totally OK

b) the peope without internet because they are on a weird idland without
internet --> they can go on. this group is totally OK

c) people who have internet and have the time wrong. Those will be stopped
dead in the tracks. this group is NOK

I know it's a bastard operator from hell solution but sometimes forcing
people helps.

and it's just an idea... just an idea



On Wed, Jun 26, 2019 at 12:20 PM Bill Somerville 
wrote:

> On 26/06/2019 10:55, Roeland Jansen wrote:
> > I did not look at the patches Mike sent but:
> >
> > https://time.is/
> >
> > gives you how good/bad the time  is. If you start up:  do check like
> > this and refuse to go on if the timeskew is too large.
> > Add a link how to fix in the message and you force people to fix it.
> >
> > (not that people read notices)
> >
> > just my bad idea.
>
> Hi Roeland,
>
> doesn't that miss the point that many of the poor time sync situations
> are where the user has no Internet connectivity?
>
> 73
> Bill
> G4WJS.
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Clock patch

[Roeland Jansen]

I did not look at the patches Mike sent but:

https://time.is/

gives you how good/bad the time  is. If you start up:  do check like this
and refuse to go on if the timeskew is too large.
Add a link how to fix in the message and you force people to fix it.

(not that people read notices)

just my bad idea.


On Wed, Jun 26, 2019 at 11:41 AM DG2YCB, Uwe  wrote:

> I’ve not yet seen the results, but your this approach really looks like
> something which could bring a substantial progress regarding the timing
> issue.
>
>
>
> Reason why I am supporting a warning message is that, besides field days,
> I saw dozens of OMs/YLs who are not aware at all that system time of their
> PCs needed to by synced. Alone two examples yesterday. Contacted both.
> Seemed to be both are “old” men, with no computer skills. One replied the
> following: “I am no longer a very young man (84 years old) who tries to
> tamper with the new methods; with a total ignorance of the English
> language…”. If we like it or not: That’s the reality! Of course we could
> let FT8, FT4, etc. be something only for the tiny community of
> well-educated, scientifically trained OMs with good to excellent computer
> skills. But if we want to make QSOs with more OMs/YLs, then WE need to do
> something which helps THEM to overcome the hurdles.
>
>
>
> 73 de Uwe, DG2YCB
>
>
>
> *Von:* Black Michael via wsjt-devel [mailto:
> wsjt-devel@lists.sourceforge.net]
> *Gesendet:* Mittwoch, 26. Juni 2019 06:19
> *An:* WSJT Software Development
> *Cc:* Black Michael
> *Betreff:* [wsjt-devel] Clock patch
>
>
>
> This patch shows a message if 80% of DT values are >= 0.5 seconds.
>
>
>
> https://www.dropbox.com/s/8j7qao9wa4wmzdm/clock.patch?dl=1
>
>
>
> I picked the 50% point of FT4's 1 second tolerance but perhaps a slightly
> larger value might be appropriate.
>
>
>
> I think most, if not everybody, can get the > 20% < 0.5 seconds without a
> problem.
>
>
>
> Even with my rather extreme latency of 300-400ms I don't trigger this.
>
>
>
> de Mike W9MDB
>
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] official ICOM response to ALC deflection on their rigs

[Roeland Jansen]

nothi.g more nothing less, it just indicates that any deflection in the ALC
zone is ok.

And that is contrary to the beliefs some specialists here state.

I believe the manufacturer and the manuals more.



On Fri, 14 Jun 2019, 13:56 Tom M0LTE,  wrote:

> How is this any more complicated than set rig TX power to 100%, connect a
> dummy load, then reduce audio drive level so power meter reads less than
> 100% in the middle of the passband?
>
> Tom M0LTE
>
> On Fri, 14 Jun 2019 at 07:39, Roeland Jansen 
> wrote:
>
>> "However, the action of ALC meter depends on balance between the
>> modulation level setting of your transceiver and the audio output level of
>> your PC.
>> Please adjust them with seeing the ALC meter.
>>
>> As you already know, if the ALC meter indicates within the ALC zone,
>> there is no problem.
>>
>>
>> Best Regards,
>>
>> 
>> Icom World Support Center"
>>
>> so:
>>
>> --> As you already know, if the ALC meter indicates within the ALC zone,
>> there is no problem. <--
>>
>> ---
>>
>> This is icom specific and for ssb-d modes where a PC injects the audio
>> into the TRX.
>> (e.g. wspr, ft8, ft4 etc etc)
>>
>>
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] official ICOM response to ALC deflection on their rigs

[Roeland Jansen]

"However, the action of ALC meter depends on balance between the modulation
level setting of your transceiver and the audio output level of your PC.
Please adjust them with seeing the ALC meter.

As you already know, if the ALC meter indicates within the ALC zone, there
is no problem.


Best Regards,


Icom World Support Center"

so:

--> As you already know, if the ALC meter indicates within the ALC zone,
there is no problem. <--

---

This is icom specific and for ssb-d modes where a PC injects the audio into
the TRX.
(e.g. wspr, ft8, ft4 etc etc)
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FT4 & FT8 and ALC

[Roeland Jansen]

so we agree that we should follow the manuals of the manufacturers?

On Wed, Jun 12, 2019 at 4:56 PM Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> I finally got a reply from Kenwood for the TS-990S -- this quite likely
> applies to all the Kenwood's with the red ALC zone.
> The bottom of the meter is 0dB ALC.  I would maintain once you see the
> "beings to swing" you back off a bit for no swing.
> You won't find the PSK31 words in the multi-lingual manual...it's in the
> English manual (and perhaps the other individual languages).
> It tells you to set the rig for almost no ALC indication.
>
> de Mike W9MDB
>
> Regarding the ALC 0dB and +6dB, refer to the picture below.
>
>
>
>
>
> In the TS-990S instruction manual, it is mentioned as follows.
> -
> In the case of operation in the digital mode such as PSK31 using
> a PC, you must adjust the audio output level from PC until the ALC
> meter of the transceiver begins to swing.
> -
> The level "begins to swing" is not zone max (+6dB) but threshold 0dB.
>
>
> On Thursday, June 6, 2019, 01:09:07 AM CDT, Wolfgang 
> wrote:
>
>
> There is a common belief that became an internalized misentrepretation:
>
> "NO ALC", or even "ALC is bad", this can not be applied to all rigs. On a
> Kenwood rig the manual says, you should not go (drive) the rig beyond the
> red bar.
>
> For example, the Kenwood TS990 audio input setting to "no ALC" will result
> in an Power output that goes down to indeterminable value, compared to the
> Po setting on the front panel knob & meter.
>
> So please consult your rigs manual, the designers gave you the right info.
>
>
> 73 de Wolfgang
> OE1MWW
>
> --
> Amateur radio is the most expensive type of free-of-charge communication!
> Amateurfunk ist die teuerste Art der kostenlosen Kommunikation!
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Observation on decoding

[Roeland Jansen]

Mike,



I am pretty sure that ICOM knows about how their TRX work; There is no
value attached to the ALC meter so it could be a dB level, or a voltage it
displays, or whatever.
I also have quoted the manuals and if I stay within the limits ICOM
suggests, all is fine and dandy; see below and please download and check
yourself too.

On all four below mentioned manuals, "ALC range" is the line at the meter.
If you stay within that range you are OK.

7300
http://www.icom.co.jp/world/support/download/manual/pdf/IC-7300_ENG_Full_7.pdf
page 65: When operating in the SSB data mode, adjust the device’s output
level within the ALC zone.
7610
http://www.icom.co.jp/world/support/download/manual/pdf/IC-7610_ENG_CD_1a.pdf
page 40:  When operating in the SSB data mode, adjust the device’s output
level to be within the ALC zone.
785x
http://www.icom.co.jp/world/support/download/manual/pdf/IC-7850_7851_ENG_IM_3.pdf
 page  117:  When operating in the SSB data mode, adjust the PC’s output
level so that the ALC meter reading doesn’t go outside the ALC zone.
9700
http://www.icom.co.jp/world/support/download/manual/pdf/IC-9700_AdvancedManual_ENG_0.pdf
page 18:  When operating in the SSB data mode, adjust the device’s output
level within the ALC zone.



so maybe the _possibility_ is that the way Kenwood, Yaesu, et al, show ALC
different. Also note the recommendation is to adjust the PC output and not
drive 100% and have the TRX settings changed.


and having said that, the tests and measurements so far, while limited as
the R equipment is at the club and not here, show so far that all is fine
and dandy for ICOM users.

Roeland

On Thu, Jun 6, 2019 at 5:33 PM Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> You won't see the harmonics until you have a fairly good bit of clipping
> going on.  They start at a very low level and increase as the clipping gets
> worse.
>
> Harmonics always exist...
>
> Why can't the manuals simply tell you where 0dB ALC is?   What a
> concept.
>
> You want ALC for phone...it doesn't matter there and maximizes your
> power.  I think all they did in the manual was copy one section to the
> other.
>
> Any clipping/compression at all will degrade your signaleven if you
> can't see it.
>
> You want 100% level audio (with very few exceptions on some rigs with old
> audio setups) coming from computer->soundcard.  You adjust the gain in the
> receiver and external soundcard if you have one (Signalink, RigBlaster,
> etc) to limit the power.
> As I recall I've only had one rig where we couldn't get 90-95 watts with
> no ALC.
>
> Mike
>
>
>
>
>
> On Thursday, June 6, 2019, 9:19:30 AM CDT, Roeland Jansen <
> roeland.janse...@gmail.com> wrote:
>
>
>
> In the *Icom manual* it states, “When operating in the SSB data mode,
> adjust the device's output level to be within the *ALC* zone.” So
> contrary to the old rule that *ALC*fluctuation is bad, that is not the
> case with these new SDR transceivers.  (from someone else's view)
>
> The ALC zone is in this case anywhere between no deflection and
> approxumately half way. There is a line drawn and outside of that line,
> you're getting in trouble.
>
> I tested this with the 7851 (200W out) and an IC7300 w/o antenna and it's
> as clean as it gets. Overdriving far beyond the line, results in side
> skirts that you easily can see at the scope.
> (and then they are S1..2 while the carrier is at 9+40).
>
>
> the copy/paste I did was from the 7851 manual
> The 7300:
>
> In the SSB mode, touch the TX meter to select the ALC meter and adjust
> until the meter reading swings between 30 to 50% of the ALC scale
>
> and 50% is halfway where the red zone ends. Now the red zone is the line
> as mentioned before so you only need to keep it in th ALC zonde and not
> beyond.
>
> I do have the mod levels of all the transceivers default and vary the
> output with the slider in the wsjtx s/w
>
>
> now. for the fun of it
>
> 9700 USB mod level 50% as per default.
> TX slider is at -20.1 dB
> ALC is now at the end of the red line so just in the limit; Output is
> 10.3W on 23. output looks clean.
> At -37.2dB there is no deflection of the ACL anymore, output is 5.9W at 23.
>
> The 7300 shows similar values where ALC is deflected and the 7851 does not
> "see" garbage
>
> 7851
>
> USB level as per default 50%
> TX slider is at -20.4 dB
> ALC is at the end of the red line, in limit, output is 207W; the 7300
> scope as rx does not see garbage left/right
> At -36.8 dB ALC starts deflecting; Output is 206W.
>
>  Don't know if that gives you some insight.
>
>
>
>
>
>
> On Thu, Jun 6, 2019 at 2:18 PM Black Michael via wsjt-devel <
> wsjt-devel@lists.sour

Re: [wsjt-devel] Observation on decoding

[Roeland Jansen]

In the *Icom manual* it states, “When operating in the SSB data mode,
adjust the device's output level to be within the *ALC* zone.” So contrary
to the old rule that *ALC*fluctuation is bad, that is not the case with
these new SDR transceivers.  (from someone else's view)

The ALC zone is in this case anywhere between no deflection and
approxumately half way. There is a line drawn and outside of that line,
you're getting in trouble.

I tested this with the 7851 (200W out) and an IC7300 w/o antenna and it's
as clean as it gets. Overdriving far beyond the line, results in side
skirts that you easily can see at the scope.
(and then they are S1..2 while the carrier is at 9+40).


the copy/paste I did was from the 7851 manual
The 7300:

In the SSB mode, touch the TX meter to select the ALC meter and adjust
until the meter reading swings between 30 to 50% of the ALC scale

and 50% is halfway where the red zone ends. Now the red zone is the line as
mentioned before so you only need to keep it in th ALC zonde and not beyond.

I do have the mod levels of all the transceivers default and vary the
output with the slider in the wsjtx s/w


now. for the fun of it

9700 USB mod level 50% as per default.
TX slider is at -20.1 dB
ALC is now at the end of the red line so just in the limit; Output is 10.3W
on 23. output looks clean.
At -37.2dB there is no deflection of the ACL anymore, output is 5.9W at 23.

The 7300 shows similar values where ALC is deflected and the 7851 does not
"see" garbage

7851

USB level as per default 50%
TX slider is at -20.4 dB
ALC is at the end of the red line, in limit, output is 207W; the 7300 scope
as rx does not see garbage left/right
At -36.8 dB ALC starts deflecting; Output is 206W.

 Don't know if that gives you some insight.






On Thu, Jun 6, 2019 at 2:18 PM Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Gary -- I've work on a dozens of rigs...probably including all the ones
> you have.
>
> If you are unable to get at least 90W with no ALC then something in your
> audio path is incorrect.
>
> I'd like to work with you and ensure that either my directions need
> updating or your settings need updating.
>
> Did you follow the procedure in the document I sent?  That has worked on
> every rig/audio combo I've tested which is over 300 operators now.
>
> Can you call me an we can hook up and figure this out?  Gotta' make sure
> the info I'm putting out is as inclusive as possible.
>
> 321-690-2551
> Mike W9MDB
>
>
>
>
> On Thursday, June 6, 2019, 1:24:58 AM CDT, Gary - K7EK via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
>
> Absolutely. I own six different Icom HF rigs. All of them put out
> minuscule power unless there is a significant deflection on the ALC meter.
> The no ALC warning does NOT apply to all rigs. I agree with RTFM. You
> cannot go wrong.
>
> Best regards,
>
> Gary, K7EK
>
> Radcliff, KY (EM77at)
>
>
> Sent from BlueMail 
> On Jun 5, 2019, at 15:42, Ron WV4P  wrote:
>
> Contrary to common belief..  You better feed that 7300 some ALC if you
> want it to perform. All radios are NOT the same and some need ALC. Ron,
> WV4P
>
> On Wed, Jun 5, 2019, 2:34 PM Tom Ramberg via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
> Sorry for posting this in the wrong thread. Now Trying to delete it and
> repost-
>
> OH6VDA Tom
>
> Sendt fra min iPad Air 2
>
> 5. jun. 2019 kl. 22:26 skrev Tom Ramberg < oh6...@yahoo.com>:
>
> I just checked my computer soundcard settings and followed your procedure
> to set up the radio, the computer and the tranceiver, resulting in a
> seemingly dramatic enhancement of operation efficiency. For one thing
> (operator error, no doubt), I've never checked that the sound card sample
> rate was  48kHz 16-bit before, and of course it was not. Thanks a lot!
>
> 73 de Tom OH6VDA
>
> Sendt fra min iPad Air 2
>
> 5. jun. 2019 kl. 15:01 skrev Black Michael via wsjt-devel <
> wsjt-devel@lists.sourceforge.net>:
>
> For the IC-7300 you want the ALC meter to show no action at all.  So if it
> ever bumps up at all you've got too much audio going into the rig and need
> to back off the USB Mod Level.
>
> You should be able to transmit 100W with no ALC (or very close to 100W).
>
> That is the goal of all rigssome of the newer rigs will show < 0dB ALC
> (e.g. K3) though so it pays to learn what your ALC meter is really telling
> you.  The way you do that is set your rig for 100W, WSJT-X power slider at
> -3dB, computer audio out at 0dB, then adjust rig/external sound to show 50W
> tranmit power going out.  That should be 0dB ALC and shows you what to
> expect when transmitting close to the 100W.  Many rigs cannot do 100W with
> no ALC so have to back off to 95W maximum or such.  So as you gradually
> increase the power slider in WSJT-X (use the up cursor key) watch your ALC
> as you approach 100W.  If you start seeing ALC you have to back off the
> audio level at the rig or external 

Re: [wsjt-devel] Observation on decoding

[Roeland Jansen]

I own a 7300, 7851 and 9700. The ALC just deflects a small bit to have 100%
power -- just tried.

When it comes to side skirts and double decodes -- if you are too
enthousiastic and the ALC is way up, you will indeed see these issues.


The manually states on all the TRX (different wording)

Transmit by using the PC (software).
The [TX] indicator lights red.
When operating in the SSB data mode, adjust the PC’s output level so that
the ALC meter reading doesn’t go outside the ALC zone.

The ALC zone is
http://www.icom.co.jp/world/support/download/manual/pdf/IC-7850_7851_ENG_IM_3.pdf
on page 4-13.


the audio scope and bandscope in center mode also will definitely show if
your levels are too high,


On Thu, Jun 6, 2019 at 8:24 AM Gary - K7EK via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Absolutely. I own six different Icom HF rigs. All of them put out
> minuscule power unless there is a significant deflection on the ALC meter.
> The no ALC warning does NOT apply to all rigs. I agree with RTFM. You
> cannot go wrong.
>
> Best regards,
>
> Gary, K7EK
>
> Radcliff, KY (EM77at)
>
>
> Sent from BlueMail 
> On Jun 5, 2019, at 15:42, Ron WV4P  wrote:
>>
>> Contrary to common belief..  You better feed that 7300 some ALC if you
>> want it to perform. All radios are NOT the same and some need ALC. Ron,
>> WV4P
>>
>> On Wed, Jun 5, 2019, 2:34 PM Tom Ramberg via wsjt-devel <
>> wsjt-devel@lists.sourceforge.net> wrote:
>>
>>> Sorry for posting this in the wrong thread. Now Trying to delete it and
>>> repost-
>>>
>>> OH6VDA Tom
>>>
>>> Sendt fra min iPad Air 2
>>>
>>> 5. jun. 2019 kl. 22:26 skrev Tom Ramberg < oh6...@yahoo.com>:
>>>
>>> I just checked my computer soundcard settings and followed your
>>> procedure to set up the radio, the computer and the tranceiver, resulting
>>> in a seemingly dramatic enhancement of operation efficiency. For one thing
>>> (operator error, no doubt), I've never checked that the sound card sample
>>> rate was  48kHz 16-bit before, and of course it was not. Thanks a lot!
>>>
>>> 73 de Tom OH6VDA
>>>
>>> Sendt fra min iPad Air 2
>>>
>>> 5. jun. 2019 kl. 15:01 skrev Black Michael via wsjt-devel <
>>> wsjt-devel@lists.sourceforge.net>:
>>>
>>> For the IC-7300 you want the ALC meter to show no action at all.  So if
>>> it ever bumps up at all you've got too much audio going into the rig and
>>> need to back off the USB Mod Level.
>>>
>>> You should be able to transmit 100W with no ALC (or very close to 100W).
>>>
>>> That is the goal of all rigssome of the newer rigs will show < 0dB
>>> ALC (e.g. K3) though so it pays to learn what your ALC meter is really
>>> telling you.  The way you do that is set your rig for 100W, WSJT-X power
>>> slider at -3dB, computer audio out at 0dB, then adjust rig/external sound
>>> to show 50W tranmit power going out.  That should be 0dB ALC and shows you
>>> what to expect when transmitting close to the 100W.  Many rigs cannot do
>>> 100W with no ALC so have to back off to 95W maximum or such.  So as you
>>> gradually increase the power slider in WSJT-X (use the up cursor key) watch
>>> your ALC as you approach 100W.  If you start seeing ALC you have to back
>>> off the audio level at the rig or external sound card so the WSJT-X slider
>>> can be at 0dB and no ALC showing.
>>>
>>> de Mike W9MDB
>>>
>>>
>>>
>>>
>>> On Tuesday, June 4, 2019, 12:06:34 PM CDT, Black Michael via wsjt-devel
>>> < wsjt-devel@lists.sourceforge.net> wrote:
>>>
>>>
>>> If you reduce power from WSJT-X (not from the rig) does your ALC drop?
>>> If so...that's too much audio.
>>>
>>> Mike
>>>
>>>
>>>
>>>
>>> On Tuesday, June 4, 2019, 11:57:44 AM CDT, Gene Marsh < w8...@me.com>
>>> wrote:
>>>
>>>
>>> Mike,
>>>
>>> My ALC is ~25% @80W.  But, I have no issues with transmit.  Only
>>> observing the double decode.  Everything else is good.
>>>
>>> 73 de W8NET Miles / “ Gene”
>>> Secretary, Portage County Amateur Radio Service (PCARS)
>>> 3905 Century Club - Master #47
>>> DV2/W8NET in the Philippines
>>> Licensed since 1974
>>>
>>> On Jun 4, 2019, at 12:46 PM, Black Michael < mdblac...@yahoo.com>
>>> wrote:
>>>
>>> I do believe 63% audio on the IC7300 is wayy too much audio.  What
>>> does your ALC meter say?
>>>
>>> de Mike W9MDB
>>>
>>>
>>>
>>>
>>> On Tuesday, June 4, 2019, 11:44:04 AM CDT, Gene Marsh via wsjt-devel <
>>> wsjt-devel@lists.sourceforge.net> wrote:
>>>
>>>
>>> Joe,
>>>
>>> My setup:
>>>
>>> Windows 10 Pro - see the pic:
>>>
>>> 
>>>
>>>
>>> -rc7
>>> IC-7300
>>> USB audio codec @66% volume
>>>
>>> Need more info?
>>>
>>> I will try to save a wav file next time I see it.
>>>
>>>
>>> 73 de W8NET Miles / “ Gene”
>>> Secretary, Portage County Amateur Radio Service (PCARS)
>>> 3905 Century Club - Master #47
>>> DV2/W8NET in the Philippines
>>> Licensed since 1974
>>>
>>> On Jun 4, 2019, at 12:12 PM, Joe Taylor < j...@princeton.edu> wrote:
>>>
>>> Hi Gene,
>>>
>>> I have seen nothing like the duplicate decodes you report.  Please 

[wsjt-devel] (no subject)

[Roeland Jansen]

hi all,


I did mention this briefly a few days ago.

- The build platform is suse leap 15
- issue is active  with wsjtx-2.01/linux   (someone else built it for suse)
- issue is active with wsjtx-2.1.0rc5/linux (built myself)
- no issue with both versions in windows 10 pro

I believe it might be a SUSE issue but I am a bit in the dark where to
start it.

there is NO change at all in the configuration. all same cables etc. It
happens with the IC7300, as well as the IC9700.


RX goes fine with ft8, wspr etc, to the moment where a TX cycle is started.
TX goes fine
but after switching back, the RX codec is not see and the default built-in
mic is used.

(Even then, if theh volume's up a bit I do have a working FT8 and WSPR but
)


It does not happen when I use the same setup with windows 10.


It looks like the RX path to the codec is lost after every TX. If I keep
the setup in RX, it stays working.

If I go into the audio config I still see the audio codec selected. Most of
the time, switching between internal devices by hand and back to the USB
codec path, it works agan ... until a TX cycle is started.


Note -- it is NOT related to RF to cabling etc. The exact setup without
moving cables work just fine under windows. It also happens on a dummy load
and with power set to 0% (which is approx 100 mW on 23 or so)


So if someone could hint me where to look at for a start?

I do see logs like:

warn:2019-04-27T20:42:05.790306+02:00 taplop pulseaudio[3306]:
[alsa-sink-USB Audio] alsa-util.c: Got POLLNVAL from ALSA
warn:2019-04-27T20:42:05.790776+02:00 taplop pulseaudio[3306]:
[alsa-sink-USB Audio] alsa-util.c: Could not recover from
POLLERR|POLLNVAL|POLLHUP with snd_pcm_prepare(): No such device
warn:2019-04-27T20:42:05.810980+02:00 taplop plasmashell[3268]:
org.kde.plasma.pulseaudio: No object for name
"alsa_output.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo"
warn:2019-04-27T20:42:05.812022+02:00 taplop plasmashell[3268]:
org.kde.plasma.pulseaudio: No object for name
"alsa_output.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo"
warn:2019-04-27T20:42:05.812287+02:00 taplop plasmashell[3268]:
org.kde.plasma.pulseaudio: No object for name
"alsa_input.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo"
warn:2019-04-27T20:42:09.883886+02:00 taplop plasmashell[3268]:
org.kde.plasma.pulseaudio: No object for name
"alsa_input.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo"
warn:2019-04-27T20:42:24.085620+02:00 taplop plasmashell[3268]:
org.kde.plasma.pulseaudio: No object for name
"alsa_output.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo"
warn:2019-04-27T20:42:24.085909+02:00 taplop plasmashell[3268]:
org.kde.plasma.pulseaudio: No object for name
"alsa_output.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo"
warn:2019-04-27T20:42:24.086199+02:00 taplop plasmashell[3268]:
org.kde.plasma.pulseaudio: No object for name
"alsa_input.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo"
warn:2019-04-27T20:43:04.281827+02:00 taplop plasmashell[3268]:
org.kde.plasma.pulseaudio: No object for name
"alsa_input.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo"
warn:2019-04-27T20:50:49.397231+02:00 taplop systemd-udevd[767]: Process
'/usr/sbin/alsactl restore 1' failed with exit code 99.
warn:2019-04-27T20:50:49.397239+02:00 taplop systemd-udevd[770]: Process
'/usr/sbin/alsactl restore 0' failed with exit code 99.
warn:2019-04-27T23:11:26.805523+02:00 taplop plasmashell[3471]:
org.kde.plasma.pulseaudio: No object for name
"alsa_output.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo"
warn:2019-04-27T23:11:26.806186+02:00 taplop plasmashell[3471]:
org.kde.plasma.pulseaudio: No object for name
"alsa_output.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo"
warn:2019-04-27T23:11:26.806494+02:00 taplop plasmashell[3471]:
org.kde.plasma.pulseaudio: No object for name
"alsa_input.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo"
warn:2019-04-27T23:11:36.433418+02:00 taplop plasmashell[3471]:
org.kde.plasma.pulseaudio: No object for name
"alsa_input.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo"
warn:2019-04-28T15:12:29.384527+02:00 taplop systemd-udevd[664]: Process
'/usr/sbin/alsactl restore 0' failed with exit code 99.
warn:2019-04-28T15:12:29.384537+02:00 taplop systemd-udevd[703]: Process
'/usr/sbin/alsactl restore 1' failed with exit code 99.
warn:2019-04-30T20:12:02.933894+02:00 taplop plasmashell[3359]:
org.kde.plasma.pulseaudio: No object for name
"alsa_output.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo"
warn:2019-04-30T20:12:02.934406+02:00 taplop plasmashell[3359]: message
repeated 2 times: [ org.kde.plasma.pulseaudio: No object for name
"alsa_output.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo"]
warn:2019-04-30T20:12:02.934664+02:00 taplop plasmashell[3359]:
org.kde.plasma.pulseaudio: No object for name
"alsa_input.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo"
warn:2019-05-03T06:26:11.976851+02:00 

Re: [wsjt-devel] where is 2.1.0-rc5 in git repo?

[Roeland Jansen]

hi Bill,


thanks about the runaway timer... and I'll see if I can find the project
page. Like Chris, I must then have overlooked it Bill.
I built 2.01 myself so I assume that this won't be an issue either.

RFI is not the issue I suppose -- the windows port works fine, under linux
it goes wrong; even 0% power.

>
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] where is 2.1.0-rc5 in git repo?

[Roeland Jansen]

someone built 2.01 for opensuse and a few things happen there

a) after transmit most of the time, if not all the time, the RX device is
lost and is set to internal mic
b) I see runaway tx timer (or something along that text).

I built the stuff myself with the  same issues. So it would be appreciated
if the branch was available for building/testing (and no redis)


On Tue, Apr 30, 2019 at 12:53 PM Bill Somerville 
wrote:

> On 30/04/2019 04:03, Christopher Hoover wrote:
> >
> > I don't see 2.1.0-rc5 in the git at the
> > https://git.code.sf.net/p/wsjt/wsjtx
> >
> > Am I doing something wrong?  (I use git professionally everyday so I
> > think I've pulled the remote properly.)
> >
> > -ch
>
> Hi Chris,
>
> you are not doing anything wrong. Currently the public repo represents
> the official GA release of WSJT-X, that is v2.0.1. We are only pushing
> the master branch to the SourceForge and the v2.1.0 release candidates
> are still on a release branch. When that release branch gets merged to
> master we will push it to SourceForge. The full sources of WSJT-X 2.1.0
> RC5 and the Hamlib snapshot it is built against are available in the
> source tarball available from the project web site and the SourceForge
> files area.
>
> It is not too complex to push the release branch to the Source Forge git
> repo if the development team agree. If you make a credible case for
> doing so I am sure we can comply.
>
> 73
> Bill
> G4WJS.
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] hamlib patches and wsjt-x source code (20190225)

[Roeland Jansen]

in .../src/wsjt.../INSTALL:

"Patching Sources


This build  script includes source patching  capabilities. The sources
for Hamlib and those for WSJT-X may have a patch applied automatically
prior to  configuration and  building.  Any  patches required  must be
contained in  one of  the files  hamlib.patch or  wsjtx.patch. "

If this patch is included in your (so also the main) trunk, I could just
replace the hamlib parts and
have a testbuild with 9700 support.

Roeland

On Tue, Apr 23, 2019 at 3:59 PM Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Looks like there haven't been any updates to the WSJTX default hamlib
> repository since Mar 15 so the latest IC-9700 fixes aren't in there.  I
> believe you are using my fork right now.
>
> What build instructions are you referring to?
>
> de Mike W9MDB
>
>
>
> On Tuesday, April 23, 2019, 8:34:12 AM CDT, Roeland Jansen <
> roeland.janse...@gmail.com> wrote:
>
>
> hi Mike,
>
> sort of. I know I can put the branch I have at the same place but the
> build instructions of wsjt-x talk a bout specific patches that
> are/were not included yet to have wsjt-x working correctly.
>
> Roeland
>
> On Tue, Apr 23, 2019 at 3:17 PM Black Michael via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
> If you mean the IC-9700 specifically that has been incorporated in the 4.0
> branch of hamlib and should appear in the next release of WSJT-X.
>
> de Mike W9MDB
>
>
>
> On Tuesday, April 23, 2019, 7:50:14 AM CDT, Roeland Jansen <
> roeland.janse...@gmail.com> wrote:
>
>
> In the build instructions there have been notes about hamlib not having
> the patches
> merged into their code yet.
>
> Now, we're seeing hamlib v4.x ; Is that still the case that patches are
> not merged?
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] hamlib patches and wsjt-x source code (20190225)

[Roeland Jansen]

hi Mike,

sort of. I know I can put the branch I have at the same place but the build
instructions of wsjt-x talk a bout specific patches that
are/were not included yet to have wsjt-x working correctly.

Roeland

On Tue, Apr 23, 2019 at 3:17 PM Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> If you mean the IC-9700 specifically that has been incorporated in the 4.0
> branch of hamlib and should appear in the next release of WSJT-X.
>
> de Mike W9MDB
>
>
>
> On Tuesday, April 23, 2019, 7:50:14 AM CDT, Roeland Jansen <
> roeland.janse...@gmail.com> wrote:
>
>
> In the build instructions there have been notes about hamlib not having
> the patches
> merged into their code yet.
>
> Now, we're seeing hamlib v4.x ; Is that still the case that patches are
> not merged?
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] hamlib patches and wsjt-x source code (20190225)

[Roeland Jansen]

In the build instructions there have been notes about hamlib not having the
patches
merged into their code yet.

Now, we're seeing hamlib v4.x ; Is that still the case that patches are not
merged?
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] wsjtx-1.6.0.r6263-1.21.x86_64 opensuse RX dies after TX,

[Roeland Jansen]

On Wed, Jun 1, 2016 at 3:15 PM, Walter Fey  wrote:

> OpenSUSE Leap 42.1 with Gnome does not show this behavior.
> So it seems to be a KDE (Phonon) problem.
>
>

if we can get a finger on what happens with phonon we could see if we can
getr rid of the work-arounds.
I may have a few strings to pull there. But then, need to be sure what
happens.
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] wsjtx-1.6.0.r6263-1.21.x86_64 opensuse RX dies after TX,

[Roeland Jansen]

On Tue, May 31, 2016 at 10:24 PM, Walter Fey  wrote:

> Hallo,
>
> The same issue comes up on a Fedora 23 installation with KDE.
> After the first transmission pulseaudio is switching the input to the
> first audio device instead of the one selected by WSJT-X. This can
> easily be corrected with pavucontrol and all subsequent transmissions do
> not change the input anymore until the next stop and startup of WSJT-X.
>
> I made this test with the fedora_23 version from my repository
> http://download.opensuse.org/repositories/home:/dl8fcl:/test/
> in a VirtualBox VM.
>
>
I also can confirm that with leap42.1 and pavucontrol I can get around the
TX/RX part.
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] wsjtx-1.6.0.r6263-1.21.x86_64 opensuse RX dies after, switch to TX (Roeland Jansen)

[Roeland Jansen]

On Tue, May 31, 2016 at 1:49 AM, Bill Somerville <g4...@classdesign.com>
wrote:

> On 30/05/2016 15:00, Roeland Jansen wrote:
>
> I will build a SUSE VM and see if I can reproduce the issue, if I can I
>> will try and track down what is happening and if we can work around it.
>>
>
> that would be cool. If I can test/help .. let me know.
>
> Hi Roeland,
>
> I have a working OpenSUSE Leap VM running but it is not much good for
> testing as the USB audio from my rig interface is distorted. I think this a
> VM problem that I may not be able to solve but I am able to receive
> something. So far I cannot reproduce he issue with my build. I will try
> tomorrow with the binary package that Walter DF8FCL posted and see if that
> has the issue.
>
>
> Hi Bill.


first of all, the toggling of the monitor button does not help -- this was
suggested as a small test by Michael.
I did not have time to manually pavucontrol the stuff. I do have time to
prep my normal, fast laptop today
so that I can switch between them of needed.

I also have vm that can be used for testing as well -- a decent fast one. I
can check if that has distorted
sound as well -- this is vmware.
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] wsjtx-1.6.0.r6263-1.21.x86_64 opensuse RX dies after, switch to TX (Roeland Jansen)

[Roeland Jansen]

On Mon, May 30, 2016 at 12:09 PM, Walter Fey  wrote:

> Hallo Roeland,
>
> The problem comes up when you have more than one audio device connected
> to your openSUSE system.
> The RX of WSJTX is switched to the first audio device after the first
> transmission. You can switch the input back to the correct audio device
> (I use pavucontrol for this) and RX is working again.
> It happens only after the first transmission.
> Install "pavucontrol - PulseAudio Volume Control", make a short tune
> transmission, and than use pavucontrol to switch back to the correct
> audio device. Than WSJTX should receive and transmit as expexted.
>
> All versions of WSJTX, also the very latest ones, have this problem.
> http://download.opensuse.org/repositories/home:/dl8fcl:/test/
>
>
ok, I'll give it a shot too.

If I think about it -- IIRC the device (TX and RX) are defined in the
config so it should always
stay at those devices, even if the power is removed from the rig. (It would
error obviously).

To me it sounds like it's a bug, athough I am not sure how it happens.
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] wsjtx-1.6.0.r6263-1.21.x86_64 opensuse RX dies after switch to TX

[Roeland Jansen]

hi Bill,

>
> how is your rig connected to your laptop? Does the rig go to Tx mode and
> return to Rx mode when it should? Is this only with WSPR Tx or are other
> modes causing the same issues?
>

it's connected via USB. Both CAT and SOUND. They are an IC7100 and/or 7600.
Both show the same.

The rig goes to RX fine; also, if I exit the program and restart, RX is
also back.

I am pretty sure it also dies with JT65 but the problem is that I cannot
test it since I am not home today,
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] wsjtx-1.6.0.r6263-1.21.x86_64 opensuse RX dies after switch to TX

[Roeland Jansen]

all,


in a recent chat with Michael Black, about wsjt and linux I decided to ask
the question here.

I am running opensuse leap 42.1 on a moderately slow laptop.
The version taken is wsjtx-1.6.0.r6263-1.21.x86_64
but the 'official builds' on the website also exhibits the
same issue.

If I start wsjt, all goes fine. RX is good, switching bands is good,
waterfall is good.
However if I switch to one time TX for instance with the WSPR mode, the
following RX always fails, The waterfall all over sudden is 'blank' -- e.g.
does not show sound at all anymore.

If I run the windows executable under windows -- all goes fine and keeps
working.
So it's something with my linux setup and wsjtx-1.6.0.r6263-1.21.x86_64


Michael has asked me to see if switching monitor works but I haven't had
time yet to test.

I also have not yet pulled the latest codebase and compile.

Any ideas?

Roeland, PA3MET
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel