[wsjt-devel] Double click on empty hash

[Black Michael via wsjt-devel]

Double-clicking does not work on a message when the 1st call is an empty hash.
e.g.<...> W9MDB R-17
Does work OK as long as the hash tags contain a callsign on either call.
de Mike W9MDB
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Mac Mini (late 2014) Problem with 1.9 and 2.0 with Mojave 10.14.2

[David Tiller]

> kern.sysv.shmall: 8129

For what it's worth, that value looks like a typo - it probably ought to be 
8192, a power of 2. 


> On Dec 20, 2018, at 20:13, Jim Kennedy  wrote:
> 
> kern.sysv.shmall: 8129


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

Re: [wsjt-devel] Mac Mini (late 2014) Problem with 1.9 and 2.0 with Mojave 10.14.2

[Matt Henry]

> A couple of weeks ago, I upgraded the Mac OS to the Mojave 10.14.2, but 
> ever since first doing that, both WSJT X 1.9 and 2.0 don’t survive 
> launching.  Both behave in the very same way.

Hi Jim,

Are you connecting to your rig via USB?  If so, you may have the same problem I 
had after upgrading to Mojave.  In my case Mojave's enhanced Gatekeeper was 
blocking the USB virtual com port driver.  To confirm, do the following:

1. Click the Apple icon in the top left, and select About This Mac.
2. Select System Report...
3. Select Software --> Disabled Software

Confirm if any needed drivers/software have been disabled.

73,

Matt
NR3M


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

Re: [wsjt-devel] Mac Mini (late 2014) Problem with 1.9 and 2.0 with Mojave 10.14.2

[Jim Kennedy]

Aloha Chris:

Thanks for the idea.

73,

Jim
K6MIO/KH6

> On Dec 20, 2018, at 3:21 PM, Topher Petty  wrote:
> 
> It could be a config file issue with wsjtx. Try renaming the config to a 
> .conf.bak and re-starting wsjtx, then proceed as if you've installed wsjtx 
> for the first time (enter callsign, location, rig control config, etc)...
> I haven't run into this issue myself, but maybe it's worth a try?
> 
> 73 de AI8W, Chris
> 
> On Thu, Dec 20, 2018 at 8:13 PM Jim Kennedy  > wrote:
> Hi Steve:
> 
> Thanks for you thoughts!
> 
> I did do John, G4KLA's procedure quite some time ago when the Mac Mini first 
> came on line (as it was necessary).
> 
> I have reviewed that again, and the values haven’t change on the Mini, (or 
> the desktop and laptop which are working fine with OS 10.13.6).
> 
> My results are:
> $ sysctl -a | grep sysv.shm
> kern.sysv.shmmax: 33554432
> kern.sysv.shmmin: 1
> kern.sysv.shmmni: 128
> kern.sysv.shmseg: 32
> kern.sysv.shmall: 8129
> 
> The is significantly larger that what is working for you (although the last 
> line is smaller), and the error message is not the same as one that the 
> current message is producing.
> 
> My next step seems to be ripping out 10.14.2 and drop back to 10.13.6, and 
> see if that even has anything to do with it.
> 
> 73,
> 
> Jim
> K6MIO/KH6
> 
> > On Dec 20, 2018, at 12:02 PM, Steven Franke via wsjt-devel 
> >  > > wrote:
> > 
> >> I seem to recall that there was a point, previously, during which some 
> >> Macs needed to have a memory range tricked out.  That was done with the 
> >> Mac Mini, and it then worked fine with earlier versions of both the OS and 
> >> the WJST package.
> >> 
> >> Is that still an issue.  Did the OS update wipe it out?
> > 
> > Hi Jim,
> > 
> > You may need to increase the shared memory allocation if you are running 
> > the stock configuration of MacOS. The instructions can be found in 
> > src/Darwin/ReadMe.txt file, which was prepared by John, G4KLA. Here’s a 
> > relevant excerpt from that file:
> > 
> > 'After the reboot you should re-open the Terminal window as before and you 
> > can check that the change has been made by typing:
> > 
> >  sysctl -a | grep sysv.shm
> > 
> > If shmmax is not shown as 14680064 then ... WSJT-X will fail to load with
> > an error message: "Unable to create shared memory segment”.'
> > 
> > Here’s what I get on this laptop, which is running MacOS 10.14.2 and which 
> > runs WSJT-X just fine:
> > 
> > $ sysctl -a | grep sysv.shm
> > kern.sysv.shmmax: 14680064
> > kern.sysv.shmmin: 1
> > kern.sysv.shmmni: 128
> > kern.sysv.shmseg: 32
> > kern.sysv.shmall: 17920
> > 
> > If your shmmax parameter is smaller than 14680064, I recommend that you 
> > follow the procedure that is explained in the ReadMe.txt file.
> > 
> > Regards,
> > Steve k9an
> > 
> > ___
> > 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] Mac Mini (late 2014) Problem with 1.9 and 2.0 with Mojave 10.14.2

[Steven Franke via wsjt-devel]

Hi Jim,

Before you resort to dropping  back to 10.13.6, have you tried letting wsjtx 
create a new, clean, .ini file? You could either move your old one out of the 
way temporarily or you could start wsjtx from the command line using something 
like this:

cd /Applications/wsjtx.app/Contents/MacOS
./wsjtx -r test

which will create a clean .ini file named "WSJT-X - test.ini”.

Steve k9an



> On Dec 20, 2018, at 7:08 PM, Jim Kennedy  wrote:
> 
> Hi Steve:
> 
> Thanks for you thoughts!
> 
> I did do John, G4KLA's procedure quite some time ago when the Mac Mini first 
> came on line (as it was necessary).
> 
> I have reviewed that again, and the values haven’t change on the Mini, (or 
> the desktop and laptop which are working fine with OS 10.13.6).
> 
> My results are:
> $ sysctl -a | grep sysv.shm
> kern.sysv.shmmax: 33554432
> kern.sysv.shmmin: 1
> kern.sysv.shmmni: 128
> kern.sysv.shmseg: 32
> kern.sysv.shmall: 8129
> 
> The is significantly larger that what is working for you (although the last 
> line is smaller), and the error message is not the same as one that the 
> current message is producing.
> 
> My next step seems to be ripping out 10.14.2 and drop back to 10.13.6, and 
> see if that even has anything to do with it.
> 
> 73,
> 
> Jim
> K6MIO/KH6
> 
>> On Dec 20, 2018, at 12:02 PM, Steven Franke via wsjt-devel 
>>  wrote:
>> 
>>> I seem to recall that there was a point, previously, during which some Macs 
>>> needed to have a memory range tricked out.  That was done with the Mac 
>>> Mini, and it then worked fine with earlier versions of both the OS and the 
>>> WJST package.
>>> 
>>> Is that still an issue.  Did the OS update wipe it out?
>> 
>> Hi Jim,
>> 
>> You may need to increase the shared memory allocation if you are running the 
>> stock configuration of MacOS. The instructions can be found in 
>> src/Darwin/ReadMe.txt file, which was prepared by John, G4KLA. Here’s a 
>> relevant excerpt from that file:
>> 
>> 'After the reboot you should re-open the Terminal window as before and you 
>> can check that the change has been made by typing:
>> 
>> sysctl -a | grep sysv.shm
>> 
>> If shmmax is not shown as 14680064 then ... WSJT-X will fail to load with
>> an error message: "Unable to create shared memory segment”.'
>> 
>> Here’s what I get on this laptop, which is running MacOS 10.14.2 and which 
>> runs WSJT-X just fine:
>> 
>> $ sysctl -a | grep sysv.shm
>> kern.sysv.shmmax: 14680064
>> kern.sysv.shmmin: 1
>> kern.sysv.shmmni: 128
>> kern.sysv.shmseg: 32
>> kern.sysv.shmall: 17920
>> 
>> If your shmmax parameter is smaller than 14680064, I recommend that you 
>> follow the procedure that is explained in the ReadMe.txt file.
>> 
>> Regards,
>> Steve k9an
>> 
>> ___
>> 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] Mac Mini (late 2014) Problem with 1.9 and 2.0 with Mojave 10.14.2

[Topher Petty]

It could be a config file issue with wsjtx. Try renaming the config to a
.conf.bak and re-starting wsjtx, then proceed as if you've installed wsjtx
for the first time (enter callsign, location, rig control config, etc)...
I haven't run into this issue myself, but maybe it's worth a try?

73 de AI8W, Chris

On Thu, Dec 20, 2018 at 8:13 PM Jim Kennedy 
wrote:

> Hi Steve:
>
> Thanks for you thoughts!
>
> I did do John, G4KLA's procedure quite some time ago when the Mac Mini
> first came on line (as it was necessary).
>
> I have reviewed that again, and the values haven’t change on the Mini, (or
> the desktop and laptop which are working fine with OS 10.13.6).
>
> My results are:
> $ sysctl -a | grep sysv.shm
> kern.sysv.shmmax: 33554432
> kern.sysv.shmmin: 1
> kern.sysv.shmmni: 128
> kern.sysv.shmseg: 32
> kern.sysv.shmall: 8129
>
> The is significantly larger that what is working for you (although the
> last line is smaller), and the error message is not the same as one that
> the current message is producing.
>
> My next step seems to be ripping out 10.14.2 and drop back to 10.13.6, and
> see if that even has anything to do with it.
>
> 73,
>
> Jim
> K6MIO/KH6
>
> > On Dec 20, 2018, at 12:02 PM, Steven Franke via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
> >
> >> I seem to recall that there was a point, previously, during which some
> Macs needed to have a memory range tricked out.  That was done with the Mac
> Mini, and it then worked fine with earlier versions of both the OS and the
> WJST package.
> >>
> >> Is that still an issue.  Did the OS update wipe it out?
> >
> > Hi Jim,
> >
> > You may need to increase the shared memory allocation if you are running
> the stock configuration of MacOS. The instructions can be found in
> src/Darwin/ReadMe.txt file, which was prepared by John, G4KLA. Here’s a
> relevant excerpt from that file:
> >
> > 'After the reboot you should re-open the Terminal window as before and
> you can check that the change has been made by typing:
> >
> >  sysctl -a | grep sysv.shm
> >
> > If shmmax is not shown as 14680064 then ... WSJT-X will fail to load with
> > an error message: "Unable to create shared memory segment”.'
> >
> > Here’s what I get on this laptop, which is running MacOS 10.14.2 and
> which runs WSJT-X just fine:
> >
> > $ sysctl -a | grep sysv.shm
> > kern.sysv.shmmax: 14680064
> > kern.sysv.shmmin: 1
> > kern.sysv.shmmni: 128
> > kern.sysv.shmseg: 32
> > kern.sysv.shmall: 17920
> >
> > If your shmmax parameter is smaller than 14680064, I recommend that you
> follow the procedure that is explained in the ReadMe.txt file.
> >
> > Regards,
> > Steve k9an
> >
> > ___
> > 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] Mac Mini (late 2014) Problem with 1.9 and 2.0 with Mojave 10.14.2

[Jim Kennedy]

Hi Steve:

Thanks for you thoughts!

I did do John, G4KLA's procedure quite some time ago when the Mac Mini first 
came on line (as it was necessary).

I have reviewed that again, and the values haven’t change on the Mini, (or the 
desktop and laptop which are working fine with OS 10.13.6).

My results are:
$ sysctl -a | grep sysv.shm
kern.sysv.shmmax: 33554432
kern.sysv.shmmin: 1
kern.sysv.shmmni: 128
kern.sysv.shmseg: 32
kern.sysv.shmall: 8129

The is significantly larger that what is working for you (although the last 
line is smaller), and the error message is not the same as one that the current 
message is producing.

My next step seems to be ripping out 10.14.2 and drop back to 10.13.6, and see 
if that even has anything to do with it.

73,

Jim
K6MIO/KH6

> On Dec 20, 2018, at 12:02 PM, Steven Franke via wsjt-devel 
>  wrote:
> 
>> I seem to recall that there was a point, previously, during which some Macs 
>> needed to have a memory range tricked out.  That was done with the Mac Mini, 
>> and it then worked fine with earlier versions of both the OS and the WJST 
>> package.
>> 
>> Is that still an issue.  Did the OS update wipe it out?
> 
> Hi Jim,
> 
> You may need to increase the shared memory allocation if you are running the 
> stock configuration of MacOS. The instructions can be found in 
> src/Darwin/ReadMe.txt file, which was prepared by John, G4KLA. Here’s a 
> relevant excerpt from that file:
> 
> 'After the reboot you should re-open the Terminal window as before and you 
> can check that the change has been made by typing:
> 
>  sysctl -a | grep sysv.shm
> 
> If shmmax is not shown as 14680064 then ... WSJT-X will fail to load with
> an error message: "Unable to create shared memory segment”.'
> 
> Here’s what I get on this laptop, which is running MacOS 10.14.2 and which 
> runs WSJT-X just fine:
> 
> $ sysctl -a | grep sysv.shm
> kern.sysv.shmmax: 14680064
> kern.sysv.shmmin: 1
> kern.sysv.shmmni: 128
> kern.sysv.shmseg: 32
> kern.sysv.shmall: 17920
> 
> If your shmmax parameter is smaller than 14680064, I recommend that you 
> follow the procedure that is explained in the ReadMe.txt file.
> 
> Regards,
> Steve k9an
> 
> ___
> 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] Wrong band info at times

[Rich Zwirko - K1HTV]

Bill,
 Tnx for the suggestion. The BAT file presently is started 1 second BEFORE
the start of a decode period. I will switch it at least 5 seconds after the
normal :00 seconds start time. Since the first decode after a band switch
is normally flagged with a band switch, the late start won't hurt anything.

The K3 band switching, which also controls which antenna is used, was
mainly done to supply the optimum antenna to the Redpitaya 8 band FT8
decoder. It feeds the FT8 RBN. One of the nodes that propagates FT8 spots
is:dxc.w9pa.net:7374

I had been using the K3 to decode old V1.9.1 users spots, but the switch
over has been so good that I'm only decoding V2.0.0 stations. Congrats to
the whole crew and thanks to you for all of your contributions to the code
and for helping out so many users as they face pilot errors and the
occasional new bug.

73,
Rich  - K1HTV






= = =
From: Bill Somerville 
To: wsjt-devel@lists.sourceforge.net
Cc:
Bcc:
Date: Thu, 20 Dec 2018 15:44:52 +
Subject: Re: [wsjt-devel] Wrong band info at times
On 20/12/2018 15:30, Rich Zwirko - K1HTV wrote:

Any idea as to why WSJT-X is responding this way?

Hi Rich,

WSJT-X in FT8 mode is a block message decoder, messages are accumulated
throughout the whole Rx period and decoded afterwards, no attempt is made
to attribute decodes to a previous band if the frequency is switched part
way through a period.

Your solution is simple, time your band changes to be within the first half
of a receive period. Near enough to the start of period to ensure no
decodes of the old band are possible (in the first half will assure that)
but long enough after the start to ensure that decoding and spotting is
compete for the old band, that depends on your system speed. For FT8 I
would try switching at start of period plus 5 seconds. Doing so earlier
will get more decodes for the new band on the switch over period if your
system is fast enough.

73
Bill
G4WJS.
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Mac Mini (late 2014) Problem with 1.9 and 2.0 with Mojave 10.14.2

[Steven Franke via wsjt-devel]

> I seem to recall that there was a point, previously, during which some Macs 
> needed to have a memory range tricked out.  That was done with the Mac Mini, 
> and it then worked fine with earlier versions of both the OS and the WJST 
> package.
> 
> Is that still an issue.  Did the OS update wipe it out?

Hi Jim,

You may need to increase the shared memory allocation if you are running the 
stock configuration of MacOS. The instructions can be found in 
src/Darwin/ReadMe.txt file, which was prepared by John, G4KLA. Here’s a 
relevant excerpt from that file:

'After the reboot you should re-open the Terminal window as before and you can 
check that the change has been made by typing:

  sysctl -a | grep sysv.shm

If shmmax is not shown as 14680064 then ... WSJT-X will fail to load with
an error message: "Unable to create shared memory segment”.'

Here’s what I get on this laptop, which is running MacOS 10.14.2 and which runs 
WSJT-X just fine:

$ sysctl -a | grep sysv.shm
kern.sysv.shmmax: 14680064
kern.sysv.shmmin: 1
kern.sysv.shmmni: 128
kern.sysv.shmseg: 32
kern.sysv.shmall: 17920

If your shmmax parameter is smaller than 14680064, I recommend that you follow 
the procedure that is explained in the ReadMe.txt file.

Regards,
Steve k9an

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

Re: [wsjt-devel] Wrong band info at times

[Bill Somerville]

On 20/12/2018 15:30, Rich Zwirko - K1HTV wrote:


Any idea as to why WSJT-X is responding this way?


Hi Rich,

WSJT-X in FT8 mode is a block message decoder, messages are accumulated 
throughout the whole Rx period and decoded afterwards, no attempt is 
made to attribute decodes to a previous band if the frequency is 
switched part way through a period.


Your solution is simple, time your band changes to be within the first 
half of a receive period. Near enough to the start of period to ensure 
no decodes of the old band are possible (in the first half will assure 
that) but long enough after the start to ensure that decoding and 
spotting is compete for the old band, that depends on your system speed. 
For FT8 I would try switching at start of period plus 5 seconds. Doing 
so earlier will get more decodes for the new band on the switch over 
period if your system is fast enough.


73
Bill
G4WJS.

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

Re: [wsjt-devel] File Open Error

[Dan Malcolm]

Bill,
That’s my guess too.  I have in the past excluded the WSJT-X directories from 
virus scans, but perhaps I missed one.  Thanks

__
Dan – K4SHQ

From: Bill Somerville [mailto:g4...@classdesign.com]
Sent: Thursday, December 20, 2018 7:11 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] File Open Error

On 20/12/2018 12:52, Dan Malcolm wrote:
affected file is ALL.TXT.  I will proceed with tracking down the offending 
application, but it would have been helpful if there was a timestamp on the 
error dialog.  That would narrow down the things to look at.  Thanks.

__
Dan – K4SHQ

Hi Dan,

I would guess at either a scheduled backup or a virus scan is locking the fie 
while you have decodes running.

73
Bill
G4WJS.
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Bug Report

[Bill Somerville]

On 20/12/2018 14:23, Gene H wrote:


A friend of mine also has same issue with his ICOM IC-7600 using Fake 
It. He went back to Split to get around the issue.


73 Gene K5PA


Hi Gene,

problems with Icom CAT control are often due to not disabling "CI-V 
Transceive Mode" on the rig.


73
Bill
G4WJS.

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

Re: [wsjt-devel] Bug Report

[Gene H]

A friend of mine also has same issue with his ICOM IC-7600 using Fake 
It. He went back to Split to get around the issue.


73 Gene K5PA

On 12/20/2018 8:15 AM, Steven Greer wrote:
Hey bill last time we touched base on this was right after release and 
you mentions you could send me a build with CAT trace enabled, if you 
could that would be great.  I did notice that another user was using 
ft-857d interface and had the same problem.  I have been able to 
connect directly to the interface with wsjt-x and also while using 
rigctl.  Both ways have the same outcome, jumps freqs when using fake 
split.  I tried to enable a mirror to see what was passing however 
wsjtx won't connect to the radio because it's not responding fast 
enough.  I'm using Debian 9 64bit


On 12/10/18 10:17 AM, Bill Somerville wrote:

On 10/12/2018 15:12, Steven Greer wrote:
It has whatever I put into serial debug, however I have to you a 
serial monitor to listen in between. I can tell it println vfo when 
PTT changes.  It's my own compilation, the ft857 Library is kinda 
separate, it is just a primer to getting started with the Library 
it's self.  I'm working on trying to get the native split working 
however I'm more of a novice coder so I spend a lot of trial and 
error testing making things work by using examples.


Hi Steven,

RR, if you can isolate the CAT sequence that causes the unexpected 
jump that would help. Otherwise I can send you a build of WSJT-X with 
CAT trace enabled which may help.


73
Bill
G4WJS.



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



--
Gene Hinkle
2026 Spyglass Hill, Leander, TX 78641
e-mail to Gene:  ghin...@gmail.com
cell phone or text messaging:  (512) 413-9251
--




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

Re: [wsjt-devel] Bug Report

[Bill Somerville]

On 20/12/2018 14:15, Steven Greer wrote:
I tried to enable a mirror to see what was passing however wsjtx won't 
connect to the radio because it's not responding fast enough.


Hi Steven,

some emulators use a device with a built in bootloader that is active 
for a second or two after a chip reset, these can cause Hamlib to reject 
an initial connection because retries are exhausted before the 
bootloader jumps to the emulation. We can help with this within reason 
by either adding more retries in Hamlib or possibly an extended delay on 
start up.


I will send you a direct e-mail with details of how to enable trace 
since you are building yourself on Debian 9.


73
Bill
G4WJS.



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

Re: [wsjt-devel] Bug Report

[Steven Greer]

Hey bill last time we touched base on this was right after release and 
you mentions you could send me a build with CAT trace enabled, if you 
could that would be great.  I did notice that another user was using 
ft-857d interface and had the same problem.  I have been able to connect 
directly to the interface with wsjt-x and also while using rigctl.  Both 
ways have the same outcome, jumps freqs when using fake split.  I tried 
to enable a mirror to see what was passing however wsjtx won't connect 
to the radio because it's not responding fast enough.  I'm using Debian 
9 64bit


On 12/10/18 10:17 AM, Bill Somerville wrote:

On 10/12/2018 15:12, Steven Greer wrote:
It has whatever I put into serial debug, however I have to you a 
serial monitor to listen in between.  I can tell it println vfo when 
PTT changes.  It's my own compilation, the ft857 Library is kinda 
separate, it is just a primer to getting started with the Library 
it's self.  I'm working on trying to get the native split working 
however I'm more of a novice coder so I spend a lot of trial and 
error testing making things work by using examples.


Hi Steven,

RR, if you can isolate the CAT sequence that causes the unexpected 
jump that would help. Otherwise I can send you a build of WSJT-X with 
CAT trace enabled which may help.


73
Bill
G4WJS.



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


--
Steven Greer
KM4OUS
OMISS #10630

NOTE: This e-mail was made with 100% recycled electrons.  No electrons were 
harmed, No trees were destroyed, No animals were killed, and No political 
correctness was observed in making or sending this message.



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

Re: [wsjt-devel] File Open Error

[Sam W2JDB via wsjt-devel]

Hi Dan, Try renaming the file. i.e. ALL.TXT to ALL.XTX. If WSJT-X starts up 
without an error, you will get a brand new ALL.TXT. If that works, try to copy 
ALL.XTX to ALL.TXT. (be careful on the copy). Hope this helps. 73, Sam W2JDB
  -Original Message-
From: Bill Somerville 
To: wsjt-devel 
Sent: Thu, Dec 20, 2018 8:13 am
Subject: Re: [wsjt-devel] File Open Error

 On 20/12/2018 12:52, Dan Malcolm wrote:
  
 affected file is ALL.TXT.  I will proceed with tracking down the offending 
application, but it would have been helpful if there was a timestamp on the 
error dialog.  That would narrow down the things to look at.  Thanks.   
__ Dan – K4SHQ 
 Hi Dan, I would guess at either a scheduled backup or a virus scan is locking 
the fie while you have decodes running. 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] File Open Error

[Bill Somerville]

On 20/12/2018 12:52, Dan Malcolm wrote:


affected file is ALL.TXT.  I will proceed with tracking down the 
offending application, but it would have been helpful if there was a 
timestamp on the error dialog.  That would narrow down the things to 
look at. Thanks.


__

Dan – K4SHQ


Hi Dan,

I would guess at either a scheduled backup or a virus scan is locking 
the fie while you have decodes running.


73
Bill
G4WJS.

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

[wsjt-devel] File Open Error

[Dan Malcolm]

I have been getting a File Open Error from v2.0.  It occurs every night, and 
I’ll have multiple notifications.  The affected file is ALL.TXT.  I will 
proceed with tracking down the offending application, but it would have been 
helpful if there was a timestamp on the error dialog.  That would narrow down 
the things to look at.  Thanks.

__
Dan – K4SHQ

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