[wsjt-devel] Thanks for 6m DXCC

[Seb]

Yesterday I logged my 100th country on 6 meters.  So far in the last couple of 
days alone, I have worked half a dozen new countries on 6 meters.  I have been 
’stuck’ in the 90s for a few years now.  But with the advent of FT8, we are 
seeing propagation that was perhaps not noticeable or of short duration, or 
maybe there is just better propagation this year.

Regardless, my thanks to all involved with WSJT-X!

73 de Sebastian, W4AS
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Minor typo

[Seb]

On the Sourceforge site, where there is documentation on JTSDK, there is a 
minor typographical error:

https://sourceforge.net/projects/jtsdk/files/win32/2.0.0/

On this section: Set Environment Options (Important)
...
enabble-autorun

73 de Sebastian, W4AS


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Experimental changes in r8125

[Seb]

+1

73 de Sebastian, W4AS




> On Sep 29, 2017, at 4:30 PM, Richard Lamont  wrote:
> 
> On 29/09/17 20:10, Bill Somerville wrote:
> 
>> I am failing to see why most of the existing automatic behaviour when
>> double-clicking decodes has to be given up just for a number of
>> operators who think that by default one's Tx offset should not be moved

Snip

> What Bill said.
> 
> The default should be to respond to a CQing station on his offset, if
> only from the point of view of spectrum economy. If the default is
> 'half-duplex' rather than 'simplex' then the number of simultaneous QSOs
> that can fit into (say) 2500 Hz will fall by up to 50%.

Snip

> 73,
> Richard G4DYA


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Settings, popups

[Seb]

In (r8018) the Frequencies tab of Settings, the hover on Frequency Calibration, 
Slope, and Intercept, has the word documentation misspelled.

In the Advanced tab of Settings, the hover on Two-pass decoding mentions only 
JT65.  Two-pass also works with FT8 correct?

73 de Sebastian, W4AS




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X: How to handle using RR73 as a final

[Seb]

Or how about RR 73.  Would this not be saved as the grid in your logging 
program?

I realize there is nobody living in the grid RR73, but bad data is bad data.  
Bad data should never be accepted as a quick fix, IMHO.

On HF, grids (at this time) are pretty much meaningless, but having this 
ability in the program will be carried over to VHF (as many already do).

While I’m not against someone sending RR73 or something similar, my concern is 
with the logging.

73 de Sebastian, W4AS




> On Jul 20, 2017, at 12:27 PM, Bill Turner via wsjt-devel 
>  wrote:
> 
> How about R-73 to avoid confusion with grids RR-73?
> 
> Bill, W4WNT
> 
> Sent from Yahoo Mail on Android 
> 
> On Thu, Jul 20, 2017 at 11:16 AM, Rich - K1HTV
>  wrote:
> G4WJS.  
> 
> 
> Bill,
> Regarding the use of "RR73", I believe that it should be formalized as an 
> option to the present "73" TX5 message.
> 
> 
> 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJTX RC1

[Seb]

Ok I must have missed that.  Calling CQ automatically is nothing new.  This is 
done with keyers for both CW/SSB.  Of course on CW/SSB, the operator has to 
‘manually’ acknowledge a reply.  Thanks for the clarification.

73 de Sebastian, W4AS




> On Jul 11, 2017, at 11:21 AM, Steve Huston <hus...@srhuston.net> wrote:
> 
> On Tue, Jul 11, 2017 at 11:09 AM, Seb <w...@miamisky.com> wrote:
>> I am seeing the same problem (at least with FT8), Enable Tx goes out after
>> logging a QSO.  I do NOT have Disable Tx after sending 73 enabled.
> 
> I believe this was the intended behavior; from an email yesterday:
> 
> On Mon, Jul 10, 2017 at 9:52 AM, Joe Taylor <j...@princeton.edu> wrote:
>> 3. When your QSO finishes, another CQ transmission should be queued up, but
>> "Enable Tx" will be off.  To continue running a frequency you must click
>> "Enable Tx" again.
> 
> Otherwise your machine could theoretically just keep replying as long
> as someone responds to a CQ at least once every 6 minutes.  While that
> might be nice for WAS/DXCC...
> 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJTX RC1

[Seb]

I am seeing the same problem (at least with FT8), Enable Tx goes out after 
logging a QSO.  I do NOT have Disable Tx after sending 73 enabled.

v1.8.0-rc1 on Windows 10 64-bit.

73 de Sebastian, W4AS




> On Jul 11, 2017, at 6:13 AM, Gordon Higgins  wrote:
> 
> HI all using ft8 v1.8.0-rc1
>  when i call cq  with call 1st ticked workes fine call sequence as exppeted 
> but when i have logged call, enable tx goes out @ i have to re  enable to 
> call cq again, i do not have  disable tx after sending 73 ticked ??
> 
> 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] 7816 build hangs

[Seb]

I’ve tried twice compiling 7816 but it won’t go any further than this:
[ 92%] Building CXX object CMakeFiles/wsjt_fort.dir/wsjt_fort_automoc.cpp.obj

Windows 10 64-bit.

73 de Sebastian, W4AS





--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] CMake Eror

[Seb]

That was easy.  Thanks Mike!

73 de Sebastian, W4AS




> On Jul 4, 2017, at 11:36 AM, Black Michael via wsjt-devel 
> <wsjt-devel@lists.sourceforge.net> wrote:
> 
> Sounds like something is hosed on your system.
> 
> Try "enable-clean" and build again.
> 
> de Mike W9MDB
> 
> 
> From: Seb <w...@miamisky.com>
> To: Black Michael via wsjt-devel <wsjt-devel@lists.sourceforge.net> 
> Sent: Tuesday, July 4, 2017 10:31 AM
> Subject: [wsjt-devel] CMake Eror
> 
> After successfully building WSJT-X for several months, today I experienced 
> this issue:
> 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] CMake Eror

[Seb]

After successfully building WSJT-X for several months, today I experienced this 
issue:

-
CMake Error at CMake/Modules/LibFindMacros.cmake:87 (message):
  Required library hamlib NOT FOUND.

  Install the library (dev version) and try again.  If the library is already
  installed, use ccmake to set the missing variables manually.
Call Stack (most recent call first):
  CMake/Modules/Findhamlib.cmake:69 (libfind_process)
  CMakeLists.txt:805 (find_package)


-- Configuring incomplete, errors occurred!
See also 
"C:/JTSDK/wsjtx/devel/qt55/1.7.1/7782/Release/build/CMakeFiles/CMakeOutput.log".


 CMAKE BUILD ERROR


 There was a problem building ( wsjtx devel )

 Check the screen for error messages, correct, then try to
 re-build ( wsjtx  devel Release install )
-


Since hamlib was not found, I built it again.  Then attempted another compile 
of WSJT-X, and it appeared to be ok, but it got ‘stuck’ (didn’t go any further) 
than this:

-
 Linking CXX executable wsjtx.exe
[100%] Built target wsjtx
-

As I expected, the build did not complete.  This is on Windows 10, 64-bit.  I 
don’t really know how this happened, but I figured that before I reinstall 
everything, someone on here can come up with a faster solution, or, could there 
be additional problems where I might as well reinstall JTSDK again?

73 de Sebastian, W4AS




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X: Beware if building from development sources

[Seb]

Never mind.  I understand now.

73 de Sebastian, W4AS




> On Jun 9, 2017, at 11:23 AM, Seb <w...@miamisky.com> wrote:
> 
> Should that read: “there are some Tx modulation issues with revisions PRIOR 
> to r7703”?
> 
> 73 de Sebastian, W4AS
> 
> 
> 
> 
>> On Jun 9, 2017, at 8:45 AM, Bill Somerville <g4...@classdesign.com 
>> <mailto:g4...@classdesign.com>> wrote:
>> 
>> Hi All,
>> 
>> I have noticed that there are some Tx modulation issues with revisions later 
>> than r7703. Only use revisions later than r7703 on air if you are sure that 
>> they are working correctly.
>> 
>> 73
>> Bill
>> G4WJS.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X: Beware if building from development sources

[Seb]

Should that read: “there are some Tx modulation issues with revisions PRIOR to 
r7703”?

73 de Sebastian, W4AS




> On Jun 9, 2017, at 8:45 AM, Bill Somerville  wrote:
> 
> Hi All,
> 
> I have noticed that there are some Tx modulation issues with revisions later 
> than r7703. Only use revisions later than r7703 on air if you are sure that 
> they are working correctly.
> 
> 73
> Bill
> G4WJS.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Web site announcement

[Seb]

Charlie, thanks for the feedback about the official user guide, I now have it 
on the home page.

Bill, about the sensitivities for the Fast modes; I believe there are several 
places where those are mentioned.  I forwarded this to Roger, VE1SKY who wrote 
those parts, as my eyes have had enough for now!

The site is now live, and I hope to make mention of it on the WSJTGROUP, and 
VHF Contesting mailing lists.  If there are other lists where anyone believes 
it should be mentioned, please feel free to do.

The site is here: https://wsjtx.net/home.html <https://wsjtx.net/home.html>

73 de Sebastian, W4AS

Replying to:

It might be worth having a prominent link on the home page pointing to the
offical User Guide.

73

Charlie G3WDG

And, 

Hi Seb,

one important correction. The sensitivity figures you are quoting for JT9(Fast) 
modes are wrong, you are using the figures for the slow mode equivalents. I 
don't think the sensitivities for the JT9(Fast) modes have been published but 
figures nearer -18dB to -13dB seem more realistic for JT9E(Fast) through 
JT9G(Fast). My numbers here are no more than guesses.

73
Bill
G4WJS.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Web site announcement

[Seb]

Bill, many thanks for the detailed response.  I agree that the band plan 
proposal will be very difficult, if not impossible, to coordinate world-wide.  
Note that this proposal is only for North America.  I’m hoping that other 
amateurs in different regions will share whatever band plans are locally 
accepted for inclusion into the website.

It’s human nature to continue doing things a certain way, and be leery of 
change.  Here on this side of the pond, we were amazed how quickly FSK144 was 
replaced by MSK144 for meteor scatter, while many on the other side of the pond 
have been hesitant to move away from ISCAT for example.  Likewise the web site 
is not an attempt to setup any rules, my hope is that in large bands such as 6 
and 10 meters, where many of the WSJT-X modes can be used (in NA); we can list 
a frequency range where a mode is commonly used, or is legal to use.  Many new 
users have no idea where or why or when to use JT9H vs MSK144 vs JT65.

Mike W9MDB can you please contact me about documenting where the submodes can 
be used here in the USA due to their baud rate and/or bandwidth.

73 de Sebastian, W4AS




> On Jun 4, 2017, at 6:05 AM, Bill Somerville  wrote:
> 
>> 
>> Hi Sebastian,
> good luck with the band planning proposals! There certainly needs to be more 
> coordination for the VHF and up modes used for international terrestrial 
> communications but there are also some areas where this will be very tricky. 
> For example here are a few comments after a quick scan:-
> 
> For the international frequency suggestions where a calling frequency is 
> proposed there must also be some agreement on even or odd periods to minimize 
> local QRM. It can probably be easily resolved for most cases by something 
> like working to the east [0,180) uses odd and working to the west [180,360) 
> but getting everyone to agree will be hard. Even then there will be 
> contention when the prevailing propagation is N/S e.g. TEP modes.
> 
> There is a fairly tricky problem with the above when paths open in opposing 
> directions, it doesn't happen that much in my experience but it is quite 
> possible for EU to have a 6m opening to both Japan and the Americas at the 
> same time. In this case a pair, or more, of EU stations could end up running 
> high ERP levels right at each other on the same T/R period!
> The above is less suitable for MS where there is no prevailing propagation 
> direction. In this case population density probably impacts QRM most. Here in 
> the EU a used convention, on 2m at least, is that those in IO and JO grid 
> fields call on odd and everyone else on even.
> 
> Again with MS, here in EU. Because FSK441 has wide adoption for 2m operating, 
> it will be much slower for MSK144 to reach any "critical mass" and it may 
> never do so. This has implications for the T/R period chosen. FSK441 uses 30s 
> so any MSK144 proposal should probably do the same to limit local QRM. Note 
> this applies even with separate calling frequency proposals due to population 
> density in some areas.
> 
> The frequencies used on 2m for terrestrial non-automatic MGM tend to be 
> around 144.370 with 144.370 being widely accepted as the FSK441 random 
> calling frequency. 144.360 seems to be gaining adoption as an MSK144 random 
> calling frequency but activity levels are low.
> 
> IARU region 3 has some notable differences in their overall band plans that 
> may make international coordination impossible. JA stations in particular use 
> digital modes quite a lot and there seem to be coordination issues already 
> there.
> None of the above should be taken as any more than observations and example 
> proposals, I am not trying to set any agreements or rules up here, just 
> pointing out some of the problem areas as I see it here in the UK with the 
> bands I have access to.
> 
> 73
> Bill
> G4WJS.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Web site announcement

[Seb]

With the many new flavors of JT9, as well as MSK144 in WSJT-X, many users who 
don’t bother to read the docs, and even those who do, are often lost when it 
comes to installing and running the software.  But you guys already knew that.

I have acquired the wsjtx.net domain, and have started working on a web site 
that I believe would have value for the users.

Immediate plans are to present the proposed band plan for 6 meters which 
several hams have worked on, and screen shots of the various menus explaining 
how they work and offering suggestions based on the band/mode, etc.  You will 
see that I already had some screen shots, but apparently the resolution was 
poor, and the menu pointer shows, so I’ll be generating new ones.

My intent is to not reinvent the wheel, so much of the text will come from the 
existing docs to explain the screen shots of the various menus.  Please take a 
look at the “WSJT-X Team” page, and let me know if anything there needs to 
change (about 99% of that page comes from the existing docs).

Since the site is in the planning stage, I ask that this link not become 
public, as page and directory names will change (note this is not viewable from 
directly going to wsjtx.net):

https://wsjtx.net/preview/home.html 

Comments, ideas and insults are welcome.


73 de Sebastian, W4AS




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Prompt to log QSO when either RRR or 73 is sent

[Seb]

Mike if the intent was not to shorten the time for a QSO, then what was the 
purpose?

Once again, see my example if I’m sending Tx3 and waiting for Tx4.  The station 
I’m working sends Tx4 once, and logs the contact because typically when we see 
a popup, it generally means to do something.  I might not hear his single 
transmission of Tx4, whether it is on meteor scatter, EME or HF.

73 de Sebastian, W4AS




> On Jan 1, 2017, at 5:15 PM, Black Michael <mdblac...@yahoo.com> wrote:
> 
> It doesn't shorten the time for a QSO.  You must be referring to the idea 
> that RRR is the last message for the CQ side.  Seems the fast mode people 
> still send a 73 which isn't surprising.  But the EME people and HF want the 
> RRR to be last.
> 
> Can't argue with it being an option, can you?  Should make everybody happy.
> 
> de Mike W9MDB
> 
> 
> From: Jay Hainline <ka9...@mtcnow.net <mailto:ka9...@mtcnow.net>>
> To: 'Black Michael' <mdblac...@yahoo.com <mailto:mdblac...@yahoo.com>>; 'WSJT 
> software development' <wsjt-devel@lists.sourceforge.net 
> <mailto:wsjt-devel@lists.sourceforge.net>> 
> Sent: Sunday, January 1, 2017 4:08 PM
> Subject: RE: [wsjt-devel] Prompt to log QSO when either RRR or 73 is sent
> 
> I don’t know for certain why this was changed in the first place except the 
> JT65 HF crowd is always looking for a way to sidestep a sequence to shorten 
> the time for a QSO. This does not work in the meteor scatter VHF world where 
> you are relying on random data bits to fly in on a meteor for less than 1 
> second and you are trying to decode just what the guy on the other end has 
> received. If it aint broke, don’t fix it.
>  
> I hope I don’t get black balled for being negative like the Ham Radio Deluxe 
> people do to users of their software. Lol ;-)
>  
> 73 Jay KA9CFD
>  
> From: Black Michael [mailto:mdblac...@yahoo.com <mailto:mdblac...@yahoo.com>] 
> Sent: Sunday, January 1, 2017 3:39 PM
> To: WSJT software development <wsjt-devel@lists.sourceforge.net 
> <mailto:wsjt-devel@lists.sourceforge.net>>
> Subject: Re: [wsjt-devel] Prompt to log QSO when either RRR or 73 is sent
>  
> I think the consensus solution would be to make it a user option.
> Seems the meteor scatter people have the most problems with it since they 
> were quick to speak up.
>  
> I had proposed at one time to make the "Prompt me to log QSO" a tri-state box 
> so one could check 73, 73+RRR, or none.  But seems the binary choice is 
> clearer and there are no other tri-state checkboxes in WSJT-X.
>  
> So this patch makes it optional with an added option line below the current 
> prompt option.  All worlds should be happy with this.
>  
> https://www.dropbox.com/s/s5xwpc39bubmzxx/rrr_option.patch?dl=1 
> <https://www.dropbox.com/s/s5xwpc39bubmzxx/rrr_option.patch?dl=1>
> 
>  
>  
> de Mike W9MDB
>  
>  
> From: Seb <w...@miamisky.com <mailto:w...@miamisky.com>>
> To: WSJT software development <wsjt-devel@lists.sourceforge.net 
> <mailto:wsjt-devel@lists.sourceforge.net>> 
> Sent: Sunday, January 1, 2017 1:26 PM
> Subject: Re: [wsjt-devel] Prompt to log QSO when either RRR or 73 is sent
>  
> IMHO the introduction of the log QSO prompt when you are sending RRR does not 
> solve or help anything.  
>  
> It is useless when you are doing meteor scatter. If I’m sending Tx3 and the 
> other station hears that and sends Tx4 and then logs the contact, it is not a 
> valid QSO because I have no idea if the other station has heard my report.  I 
> will end up sending Tx3 several times until I just give up on the contact.
>  
> 73 de Sebastian, W4AS
> 
> 
>  
> On Jan 1, 2017, at 9:38 AM, Jay Hainline <ka9...@mtcnow.net 
> <mailto:ka9...@mtcnow.net>> wrote:
>  
> This was introduced in r7431. I think its bad form to get a prompt to log the 
> QSO when you are sending RRR. How do you know if your QSO partner has 
> received it if he does not send 73 back to you??
>  
> Jay Hainline KA9CFD
> Colchester, IL  EN40om

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Prompt to log QSO when either RRR or 73 is sent

[Seb]

IMHO the introduction of the log QSO prompt when you are sending RRR does not 
solve or help anything.  

It is useless when you are doing meteor scatter. If I’m sending Tx3 and the 
other station hears that and sends Tx4 and then logs the contact, it is not a 
valid QSO because I have no idea if the other station has heard my report.  I 
will end up sending Tx3 several times until I just give up on the contact.

73 de Sebastian, W4AS




> On Jan 1, 2017, at 9:38 AM, Jay Hainline  wrote:
> 
> This was introduced in r7431. I think its bad form to get a prompt to log the 
> QSO when you are sending RRR. How do you know if your QSO partner has 
> received it if he does not send 73 back to you??
>  
> Jay Hainline KA9CFD
> Colchester, IL  EN40om
>  

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Version 1.7 User Guide

[Seb]

I offer the following (sorry I am not familiar with the system used to make it 
easier to correct):


1.1 New in Version 1.7
“New Franke-Taylor decoder toreplace” (should be ‘to replace’)


4.2. Radio
"Set Poll Interval to the desired interval for WSJT-X to query your radio. For 
most radios a small number (say, 1 – 3 s) is suitable.”
FYI Omni-Rig displays the polling internal in milliseconds, not seconds.


4.8. Advanced
There needs to be a reference or explanation of the MSK144 Contest Mode box; I 
imagine that is in the works.


10.2. Button Row
There is nothing to ‘fix’ there, however now that I read it, the Tune function 
really needs a time-out-timer!  I speak from experience!!!


10.3. Left
“The program can maintain a database of callsigns and locators for future 
reference.”  Add -> the filename is call3.txt


10.7. Wide Graph
“Four sliders control reference levels and scaling for waterfall colors and the 
spectrum plot…”. Add -> ‘Hover the mouse over a control to display a tip 
reminding you of its function.’  (This same wording is found elsewhere in 
reference to tool tips but is missing here).

Please note there are problems displaying the on hover menu in the Wide Graph.  
I’m currently using r7219 (Windows) in the event someone has already corrected 
them.  Or perhaps it has to do with display resolution.  The top left displays: 
Waterfall Gai - looks like the n is truncated, and the lower right displays: 
Spectrum zer, looks like the o is truncated or missing.  In the Fast Graph, the 
left slider displays Waterfall Gai - looks like the n is truncated.


10.9. Echo Graph
“Smooth values greater than 0 apply running averages to the plotted spectra, 
therebu…”. Should be thereby.


18. Acknowledgments
Second sentence “…All all code”, has an extra ‘all’.  Second paragraph last 
sentence “…code, tetsting..” Should be ’testing’.


73 de Sebastian, W4AS




> On Oct 25, 2016, at 2:22 PM, Joe Taylor  wrote:
> 
> Hi all,
> 
> Slowly but surely, a respectable User Guide for WSJT-X v1.7 has been 
> taking shape.  Much material has been added over the past week or so -- 
> and quite a bit more, even today.
> 
> If you have not referred to the User Guide recently, please give it a 
> careful look.  A fresh copy is available here:
> http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-1.7.0-rc1.html
> 
> Please let me know of any errors, confusing parts, perceived omissions, 
> etc. -- or any other way in which it could be improved.
> 
> Your help will be much appreciated -- by me, by the well over 4000 
> WSJT-X users, world-wide, and by who-knows-how-many future users...
> 
>   -- 73, Joe, K1JT


--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel