Date   

locked Re: #bugreport ALL.TXT #IssueReport

Bill Lederer
 

Well, my issue was in the RC3 release.  I'm now running with RC4, and will see if it iis still there.

w8lvn

On Mon, Apr 19, 2021 at 6:41 AM Sam Birnbaum via groups.io <w2jdb=aol.com@groups.io> wrote:
Hi Bill,

I ran into this problem when I tested some function in my Alltext.exe program that I sued for the same function.
I found that when I used WSJT-X  2.3 rc1 (or rc2).  The Date and time was only included in the TX record that
was written to the All.txt file.

I believe the problem was fixed when 2.3 rc3 was released.

73,  

Sam W2JDB



-----Original Message-----
From: Bill Lederer <w8lvn.9@...>
To: WSJTX@groups.io
Sent: Sun, Apr 18, 2021 9:54 pm
Subject: [WSJTX] #bugreport ALL.TXT

Team:

I am noticing that under some conditions, the date field is omitted from ALL.TXT for monitored calls, but not for transmissions I make.

What is a little more odd, this did happen when switching from 160 meter FT8 to 6 meter MSK144.

Is this a known issue?

I have just downloaded and installed the rc4 version in case the issue is resolved.

(I use the ALL.TXT file to recreate QSOs that don't get properly logged due to an xquartz crash. Usually I run WSJTX on Intel NUCs running Ubuntu after doing "ssh -Y <linux-host>" and xterm. Works most of the time, but xquartz on mac has proven to be unexpectedly crash-worthy.)

--w8lvn--

--
--w8lvn--








--
--w8lvn--


locked Re: Q65 in less favourable condx? #Q65

Joe
 

Hi Jim and all,
Scatter signals are so highly variable that the only way to make
statistically reliable quantitative comparisons of different sumodes is
to transmit and receive them simultaneously.
Very interesting. Given the highly variable nature of propagation and
the different modes of which we try to take advantage, it would be
interesting to see this sort of work repeated on multiple days and at
different times of day.
Probably it will not surprise you that we've done some of this, especially with respect to time of day.  It's very easy to show that ionoscatter conditions are best around mid-day and worst around 7 or 8 PM local time. 

But we decided not to spend time on more extensive tests with respect to time of year, but rather to spend some time in a good research library.  Steve and I have access to excellent ones at the University of Illinois and Princeton University, respectively.

D-Region ionospheric scattering at VHF was studied exhaustively in the late 1950s.  An excellent summary of such studies carried out by the Central Radio Propagation Laboratory of the US National Bureau of Standards was published in 1961, and I've posted a copy here:
https://physics.princeton.edu/pulsar/k1jt/NBS_D-region_scatter.pdf

For a summary of diurnal, seasonal, and frequency dependence of signal strengths see their Figure 6.

  -- 73, Joe, K1JT


locked #FST4 Coding On a PIC #FST4

Andy Talbot
 

A brief update on progress.
PIC code for the later generation enhanced device, the 16F1827, now exists that will
turn 13 characters of Plain text, or  17.75 Hex characters  into a set of symbols ready to go for transmission.
So the encoding stage is complete.  I have no interest in compressing any other types of message, just plain text and Telemetry (raw data).  At the moment the Plain Text is retrieved from the EEProm memory space. or Telemetry format data entered as a hex string into the assembly file.

The whole encoding routine takes up a bit less than 2K words of  programme memory.  Of that 1112  (14 bit) words are for the parity matrix, and 768 words of executable code

Now that is done and tested, I want to take a break for a bit before combining it with the beacon source - not least as there are still things to learn about the 16F1827 PIC device.  I used this FST4 encoding exercise as a way to break into using that more advanced chip.

The code won't be made public just yet, but if anyone does want a copy of what is written so far, please contact me off-Group.
 
Note that this is for FST4, not FST4W.   The latter wouldn't need too many changes; source encoding, parity matrix and various pointer and constant values. 


locked Re: WSJT-X DEFAULTS TO LSB ON TX #FT8 #transmit

Phil Moore
 

Hi Mark
I also have a 6400 and have had similar - mine changes to LSB on 40m downwards - I think due to the turf file on the 6400 assuming that those bands are normally LSB. All other bands work fine. I get around it by using FR Stacks most recently used memories to change to the affected bands which remembers that I want USB. It also has some other natty features such as when I select 60m, it changes the profile being used, changes to ANT2 and alters the TX upper filter appropriately.
Hope that helps. It's a useful add on for Flex users.
73
Phil M0TZZ


locked Re: WSJT-X DEFAULTS TO LSB ON TX #FT8 #transmit

Bill Somerville
 

On 19/04/2021 02:22, Mark Gottlieb wrote:
Good Evening All,

I have been operating WSJT-x for years and have not had this problem before.   My FLEX 6400 just started defaulting to LSB on TX on all bands.  I am not having the same problem with FLDIGI.  I have been using FLEX equipment for the last 5 years.  Can't figure out the cause.  Any suggestions?

73

Mark
KK2L
Hi Mark,

this is due to a regression in the TS-200 driver in hamlib, which I assume you are using. It is fixed for the next release, you can either change to "Settings->Radio->None" in WSJT-X and set the mode manually, or use the Flex 6xxx network driver in WSJT-X to communicate directly with SmartSDR, which does not have this fault.

73
Bill
G4WJS.


locked Re: #bugreport ALL.TXT #IssueReport

Sam Birnbaum
 

Hi Bill,

I ran into this problem when I tested some function in my Alltext.exe program that I sued for the same function.
I found that when I used WSJT-X  2.3 rc1 (or rc2).  The Date and time was only included in the TX record that
was written to the All.txt file.

I believe the problem was fixed when 2.3 rc3 was released.

73,  

Sam W2JDB



-----Original Message-----
From: Bill Lederer <w8lvn.9@...>
To: WSJTX@groups.io
Sent: Sun, Apr 18, 2021 9:54 pm
Subject: [WSJTX] #bugreport ALL.TXT

Team:

I am noticing that under some conditions, the date field is omitted from ALL.TXT for monitored calls, but not for transmissions I make.

What is a little more odd, this did happen when switching from 160 meter FT8 to 6 meter MSK144.

Is this a known issue?

I have just downloaded and installed the rc4 version in case the issue is resolved.

(I use the ALL.TXT file to recreate QSOs that don't get properly logged due to an xquartz crash. Usually I run WSJTX on Intel NUCs running Ubuntu after doing "ssh -Y <linux-host>" and xterm. Works most of the time, but xquartz on mac has proven to be unexpectedly crash-worthy.)

--w8lvn--

--
--w8lvn--




locked Re: WSJT-X DEFAULTS TO LSB ON TX #FT8 #transmit

Dave Garber
 

on the radio settings tab, see if mode is set to data/pkt,  your radio may be trying to use bandplan as its setting, this should override it, i think

Dave Garber
VE3WEJ / VE3IE


On Sun, Apr 18, 2021 at 10:03 PM Mark Gottlieb <kk2l@...> wrote:
Good Evening All,

I have been operating WSJT-x for years and have not had this problem before.   My FLEX 6400 just started defaulting to LSB on TX on all bands.  I am not having the same problem with FLDIGI.  I have been using FLEX equipment for the last 5 years.  Can't figure out the cause.  Any suggestions?

73

Mark
KK2L



locked #bugreport ALL.TXT #IssueReport

Bill Lederer
 

Team:

I am noticing that under some conditions, the date field is omitted from ALL.TXT for monitored calls, but not for transmissions I make.

What is a little more odd, this did happen when switching from 160 meter FT8 to 6 meter MSK144.

Is this a known issue?

I have just downloaded and installed the rc4 version in case the issue is resolved.

(I use the ALL.TXT file to recreate QSOs that don't get properly logged due to an xquartz crash. Usually I run WSJTX on Intel NUCs running Ubuntu after doing "ssh -Y <linux-host>" and xterm. Works most of the time, but xquartz on mac has proven to be unexpectedly crash-worthy.)

--w8lvn--

--
--w8lvn--


locked WSJT-X DEFAULTS TO LSB ON TX #FT8 #transmit

Mark Gottlieb
 

Good Evening All,

I have been operating WSJT-x for years and have not had this problem before.   My FLEX 6400 just started defaulting to LSB on TX on all bands.  I am not having the same problem with FLDIGI.  I have been using FLEX equipment for the last 5 years.  Can't figure out the cause.  Any suggestions?

73

Mark
KK2L


locked Re: Q65 in less favourable condx? #Q65

Joe Dz
 

Thank you Joe for the data and Jim also makes a very good comment. When I
was looking at how weather storm systems affect transatlantic 6m
communications, and also during the winter months when we have the second Es
season, Es formed over storm systems and fast moving jet stream fronts.
However, a geomagnetic storm (G1 or K5 or better) would negate the effect.
It would be very interesting to see as people collect data, that they also
record what the geomagnetic field was doing at the time. The question
being: does an unsettled or stormy geomagnetic field also negate the
ionosphere scatter like it negates the weather effects that would normally
cause Es over storm systems or fronts?

If folks also record the K value as well on multiple day tests, that data
would be very interesting.

Joe, K1YOW

-----Original Message-----
From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of Jim
Brown
Sent: Sunday, April 18, 2021 3:24 PM
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] Q65 in less favourable condx? #Q65

On 4/18/2021 9:08 AM, Joe wrote:
Scatter signals are so highly variable that the only way to make
statistically reliable quantitative comparisons of different sumodes is
to transmit and receive them simultaneously.
Very interesting. Given the highly variable nature of propagation and
the different modes of which we try to take advantage, it would be
interesting to see this sort of work repeated on multiple days and at
different times of day.

73, Jim K9YC


locked Re: Q65 in less favourable condx? #Q65

Jim Brown
 

On 4/18/2021 9:08 AM, Joe wrote:
Scatter signals are so highly variable that the only way to make statistically reliable quantitative comparisons of different sumodes is to transmit and receive them simultaneously.
Very interesting. Given the highly variable nature of propagation and the different modes of which we try to take advantage, it would be interesting to see this sort of work repeated on multiple days and at different times of day.

73, Jim K9YC


locked Re: Q65 in less favourable condx? #Q65

Joe
 

In November of last year, as part of our earliest tests of the new mode Q65, K9AN (Steve Franke) and I made extensive tests of submodes Q65-15A, Q65-30A and B, and Q65-60A and B.  These tests led us to recommend Q65-30A for making scatter QSOs on 6 meters.  

Recently several have raised questions on which Q65 submodes are most effective for scatter on 50 MHz.  For general interest, then, I offer the following explanation and summary of our early test results.

Scatter signals are so highly variable that the only way to make statistically reliable quantitative comparisons of different sumodes is to transmit and receive them simultaneously. 

Of course, you can't do this with standard WSJT-X.  So I wrote a special version that transmitted an audio waveform equal to the sum of those for the A submode at TxFreq=1000 Hz and the B submode at 1500 Hz.  The summed waveforms do not have a constant envelope, so we made sure to keep the audio drive levels low enough that our amplifiers maintained good linearity.

The path from K1JT to K9AN is 1148 km, essentially East-West.  We did a 4-hour test on November 12, 2020, as follows.  Local noon at mid-path is around 1730 UTC.

   UTC     Submodes
--------------------
1600-1700   30A+30B
1700-1800   60A+60B
1800-1900   30A+30B
1900-2000   60A+60B

Both stations use a single Yagi (5 el at K9AN, 7 el at K1JT), and we ran at 400 W average power output (800 W PEP).  This means equivalent 200 W signals in the A submode and 200 W in the B submode.  We ran with "Save all" enabled, so after the fact we could decode the two modes separately and count their successful decodes.  When decoding we could intentionally degrade the recordings by specified numbers of dB, to see how similar stations using less Tx power would have fared in the same conditions.   

We ran the decoding tests with Enable averaging and Auto Clear Avg after decode enabled.  Here are the test results as summary tables showing the Number of decodes per hour for each submode and each sequence length.  The column labeled "Pwr" shows the equivalent transmitted power levels after the specified SNR degradation is applied.

     K9AN Received at K1JT
-------------------------------
 dB  Pwr   30A  30B    60A  60B
-------------------------------
  0  200   57   58     28   29
 -5   63   41   48     19   23
-10   20   22   24     12   15
-15    6   12   12      5    6
-20    2    5    7      1    1
-------------------------------
 
     K1JT Received at K9AN
-------------------------------
 dB  Pwr  30A  30B    60A  60B
-------------------------------
  0  200   57   59     29   30
 -5   63   43   51     19   26
-10   20   25   33     12   19
-15    6   14   16      6    9
-20    2    4    5      2    2
-------------------------------
 
W
e draw the following summary conclusions:

1. Even at the lowest usable SNRs, 30-second submodes produce twice as many decodes per hour as 60-second submodes,

2. Q65-30B (bandwidth B=433 Hz) produces 12% more decodes per hour than 30A (B=217 Hz).   

3. Considering bandwidth requirements and the advantage of permitting many non-overlapping signals in a 3 kHz spectral slice, we conclude that Q65-30A should be the preferred submode for general use in a channel designated as the 50 MHz scatter meeting-place.

4. Other tests have shown us that longer and wider submodes such as Q65-60C or even Q65-120E are also usable for 6m scatter work, and can possibly be attractive alternatives for completion of QSOs in QRP or compromise-antenna situations.  However, the large bandwidths and long times to complete a QSO in these submodes will probably limit their use to scheduled or specially-arranged QSOs.
  
  -- 73, Joe, K1JT


locked Re: Q65 in less favourable condx? #Q65

Lance Collister, W7GJ
 

On 6m EME, almost everyone uses a low noise external preamplfier in the shack and low loss feedline to the antenna. As long as the feedline loss is under 1 dB, it seems to make no difference where you have the preamp on 6m. And at 50 MHz, it is not that difficult to find good coax so that the feedline loss is under 1 dB. Many of us use use Heliax up the tower with an LMR600 Ultra Flex jumper around the rotor. Most of the activity on 6m EME now is on the new Q65 mode in WSJT-X 2.4.0.

GL and VY 73, Lance

On 4/18/2021 00:38:02, Arthur Bernstein via groups.io wrote:
The best of all would be a SHORT run of low loss coax and a mast mounted preamp. But that costs $$$ and we are hams! At VHF and UHF a low noise figure preamp is the way to go. At HF, more of a waste of time due to ambient noise.
Art, N2KA..
On Apr 17, 2021, at 3:01 PM, Alan G4ZFQ <alan4alan@...> wrote:


the benefit of the low loss for QRP is then transferred to low loss for received signals
Peter

This depends on the band and sensitivity of the receiver.
With transmit antennas on HF many receivers are more sensitive than required and an attenuator may be used. As others have said for VHF a preamp gives best results.
With QRP TX it depends whether you want to transmit a particular low power or whether you want to transmit the maximum a TX will provide.
The best low loss is an ideal, practically several runs of cheaper coax may be more versatile.

73 Alan G4ZFQ


--
Lance Collister, W7GJ(ex WA3GPL, WA1JXN, WA1JXN/C6A, ZF2OC/ZF8, E51SIX, 3D2LR, 5W0GJ, E6M, TX5K, KH8/W7GJ, V6M, T8GJ, VK9CGJ, VK9XGJ, C21GJ, CP1GJ, S79GJ, TX7MB)
P.O. Box 73
Frenchtown, MT 59834-0073
USA
TEL: (406) 626-5728
QTH: DN27ub
URL: http://www.bigskyspaces.com/w7gj
Skype: lanceW7GJ
2m DXCC #11 - 6m DXCC #815 - FFMA #7

Interested in 6m EME? Ask me about subscribing to the new Magic Band EME
email group, or just fill in the request box at the bottom of my web
page (above)!


locked Re: Q65 in less favourable condx? #Q65

Arthur Bernstein
 

The best of all would be a SHORT run of low loss coax and a mast mounted preamp. But that costs $$$ and we are hams! At VHF and UHF a low noise figure preamp is the way to go. At HF, more of a waste of time due to ambient noise.
Art, N2KA..

On Apr 17, 2021, at 3:01 PM, Alan G4ZFQ <alan4alan@...> wrote:



the benefit of the low loss for QRP is then transferred to low loss for received signals
Peter

This depends on the band and sensitivity of the receiver.
With transmit antennas on HF many receivers are more sensitive than required and an attenuator may be used. As others have said for VHF a preamp gives best results.
With QRP TX it depends whether you want to transmit a particular low power or whether you want to transmit the maximum a TX will provide.
The best low loss is an ideal, practically several runs of cheaper coax may be more versatile.

73 Alan G4ZFQ



locked Re: Well I have to say at first look I do not like the new JTAlertX #FT8

K0GU
 

I went back to 2.16.17 but eventually read the "JTAlert 2.50 features" Help file included with 2.50 (shown above). Adjusting some setting I am now pretty happy with what I have on the screen as I have pretty much total control of the JTAlert window size and text size. But maybe that is just me. I would guess a classic version has about as much chance of success as Classic Coke. :o)   
--
73,  Jay  K0GU  DN70mq


locked Re: Q65 in less favourable condx? #Q65

Alan G4ZFQ
 

the benefit of the low loss for QRP is then transferred to low loss for received signals
Peter

This depends on the band and sensitivity of the receiver.
With transmit antennas on HF many receivers are more sensitive than required and an attenuator may be used. As others have said for VHF a preamp gives best results.
With QRP TX it depends whether you want to transmit a particular low power or whether you want to transmit the maximum a TX will provide.
The best low loss is an ideal, practically several runs of cheaper coax may be more versatile.

73 Alan G4ZFQ


locked Re: Q65 in less favourable condx? #Q65

Jim Brown
 

On 4/17/2021 7:23 AM, Buddy Morgan via groups.io wrote:
All these guys that want to install a mast mounted preamp. I ask them, "Is there a reason you can't run larger cable?" Most of the time the answer is no. Then I ask,"Have you considered the cost of larger cable vs a preamp?"
Certainly big coax (or hard line) is a great ideal. But at VHF/UHF, the loss even in that big coax can be a dB or two in a long feedline. THAT'S why serious weak-signal ops use mast-mounted preamps.

73, Jim K9YC


locked Re: New JTAlert screen format #WSJTX_config

Pat N6PAT
 

As Laurie pointed out, click on the gear box in the call sign window. Then on the menu select Call Signs and the options will be displayed. The Display width option allows you to select from a lot of different fixed widths or Auto. When that option is set to Auto then the boxes are variable length. 

I set mine to 80 and all the boxes are fixed width and lined up. It only took me a few minutes to get used to the new layout and now I really like it.  It's a really great app.


locked Re: New JTAlert screen format #WSJTX_config

Joe Subich, W4TV
 

Select (activate) the Callsigns window -> click the gear icon or
press F2 -> Select Callsigns -> Set "Display width" to any value
you like other than "Auto" (90 works for me).

73,

... Joe, W4TV

On 2021-04-17 9:32 AM, Bruce Jungwirth via groups.io wrote:
Pat, let us know what the hamapps group has to say about this.
Bruce, K0SON
On Apr 16, 2021, at 11:11 PM, Pat N6PAT via groups.io <n6pat@...> wrote:

Thanks. I'll post it in the hamapps group

73 Pat N6PAT

On Friday, April 16, 2021, 11:38:45 PM EDT, Robert Lorenzini <bob@...> wrote:


Or the OCD group.

On 4/16/2021 8:19 PM, Dave Garber wrote:
should probably ask this in hamapps group


Dave Garber
VE3WEJ / VE3IE


On Fri, Apr 16, 2021 at 11:09 PM Pat N6PAT via groups.io <n6pat@...> wrote:
I just installed JTAlert 2.50.0. It seems to be working so far but the new call sign screen needs a change.

The call sign boxes sizes appear to be variable based on the length of the call signs. This causes a staggered and messy appearance of the boxes as the screen print below shows.

Is there any way to keep the boxes lined up? If not then I think (just my two cents) that this should be changed to have fixed length call sign boxes for a more orderly look like how the grid style was. .

<dummyfile.0.part>









<dummyfile.0.part>



locked Re: Q65 in less favourable condx? #Q65

Buddy Morgan
 

All these guys that want to install a mast mounted preamp. I ask them, "Is there a reason you can't run larger cable?" Most of the time the answer is no. Then I ask,"Have you considered the cost of larger cable vs a preamp?" The answer is always no. Mast mounted preamps are more troublesome than Heliax. With Heliax, you gain, on receive and transmit. I have been a ham, for over 50 years and have not used a mast mounted preamp, yet.

Buddy WB4OMG


-----Original Message-----
From: M0PWX <M0PWX@...>
To: main@WSJTX.groups.io <main@WSJTX.groups.io>
Sent: Sat, Apr 17, 2021 10:00 am
Subject: Re: [WSJTX] Q65 in less favourable condx? #Q65

 
 

My answer is losses in coax work both ways, TX  AND  RX,

15661 - 15680 of 39844