1. main@WSJTX.groups.io
  2. Messages
   Date   
locked Re: #Memory #macOS

Bill Somerville
 

On 16/04/2021 20:46, James Quick wrote:
Can’t get com.wsjtx.syctl.plist to load.
Hi Jim,

can you elaborate on what doesn't work please?

73
Bill
G4WJS.

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

Chuck Adams
 

Hello Al - N1API,

 

The new JTAlert 2.50.0 provides you with a MUCH wider and deeper range of Callsign decode display options.

 

The new Callsigns window replaces the old callsigns display grid embedded the main JTAlert window.

 

This new window is fully resizable with no limit  on the number of Callsigns displayed, except for available screen space  and the number of decodes produced at the end of a period.

 

Please take a few minutes to review the new Help file and then let me know if I can help further.

 

You can also reach out to  Support@HamApps.groups.io where there are many happy users of the latest version.

 

73,

 

Chuck

KV4VT

 

P.S.

 

I’m an beta system tester for HamApps/ JTAlert. 

 

Here are the latest release notes (see the red text highlights):

 

JTAlert Release Notes:

--------------------------------------------------------------------------------

2.50.0 (2021-Apr-12)

 

  *** The Microsoft .NET 5 desktop runtime is required to be installed for this

  *** version of JTAlert (and all future versions). The JTAlert installer will

  *** automatically run a runtime check utility which will offer to install the

  *** necessary runtime if it is not detected installed on your PC.

 

  *** Important note regarding Q65 mode: Q65 support is only partial.

  *** Accurate Q65 B4 checks and Q65 logging are fully supported.

  *** There is no Alerting for Q65 DXCCs, States, Grids, Prefixes, etc.

 

  *** Includes Callsign database file version 2021-04-05 (2021-Apr-05)

 

  New Features:

 

    *** Important: Please review the new "JTAlert 2.50 features" help file for

    *** a complete description (with loads of images) of the new Callsigns,

    *** Activity, Messaging & BandHeat windows and the location of their

    *** respective settings. See under the "Help" window of the main JTAlert

    *** window or the shortcut in the "HamApps JTAlert" Windows start-menu group.

 

    - Callsigns window: This replaces the old callsigns display grid embedded

       in the main JTAlert window. This window is fully resizable with no limit

       on the number of Callsigns displayed, except for available screen space

       and the number of decodes produced at the end of a period.

 

    - Messaging window: This replaces the old Text Messages window. It will

       show both sent and received messages and retain them for 7 days.

       Previously sent/received messages can be saved for reuse. The message

       limit is 2048 character (old window was 256 characters).

 

    - Activity window: This replaces the old Mode Activity window. It is resizable,

       supports the new FST4 and Q65 modes as well as the 560m, 8m, & 5m bands.

       Individual bands and modes can be turned off and not displayed.

 

    - Band Heat window: This replaces the old Activity Bands display that was

       embedded in the main JTAlert window. It is now an independent window,

       supports the 560m, 8m & 5m bands, and can be set to display vertically

       or horizontally (the default). Individual bands can be turned off and hidden.

 

  Changes:

 

    - Decodes window: Frequency column can be set to either KHz or MHz.

 

    - QSL flags: The Lotw and Eqsl flag positions on the Callsigns display

       and Decodes window are no longer changeable. They are fixed in location.

        Lotw -> bottom left of the Callsign.

        Eqsl -> bottom right of the Callsign.

 

    - Hotkeys: No longer user-changeable, they are now hard-coded.

        F1 -> Help window

        F2 -> Settings window

        F3 -> Callsigns window

        F4 -> Decodes window

        F5 -> Text Messages widow

        F6 -> Call History window

        F7 -> Alert Status window

        F8 -> Macros window

        F9 -> not used

        F10 -> not used

        F11 -> Activity window

        F12 -> BandHeat window

 

        Alt + H -> Open browser to HamSpots.net

        Alt + Q -> Open browser to QRZ.com

 

    - Callsign Display Grid: Has been removed and is now a separate,

       resizable window, simply called the "Callsigns" window.

 

    - Text Messages Window: Now called "Messaging" Window, is only launchable

       from the JTAlert first instance (#1).

 

    - WSJT-X: B4 & Ignored callsigns are now highlighted in WSJT-X when

       they are hidden in JTAlert due to filtering.

 

    - Menus: Several menus associated with the new Windows introduced with

       this release (Activity, Messaging & Callsigns) have been removed from

       the main JTAlert window. All necessary options/settings for these new

       windows can be set from the Options popup for each of these windows.

 

  Fixes:

 

    - Q65 mode: Callsigns not being displayed in the Callsign display and

       decodes not being displayed in the Decodes window.

 

    - DXKeeper: non-AG eQSL member QSLs marked as "received" incorrectly considered

       as confirmed when running the Alert database rebuild. That is QSOs marked as

       confirmed from non-AG callsigns will no longer be considered during the rebuild.

 

    - HRDLogbook V6+: Lat & Lon data missing from logging instruction sent to

       Log via its TCP interface

 

    - Text Messages: Online status randomly incorrectly shows offline when the

       Callsign is online and has been sending messages.

 

    - JTAlert debug data: Some session files not being truncated as part of

       the automated maintenance routines.

 

    - JTAlert Installer: The desktop shortcuts checkbox settings when the installer was

       last run are now remembered and restored.

 

From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of Al - N1API
Sent: 16 April, 2021 11:09 AM
To: main@WSJTX.groups.io
Subject: [WSJTX] Well I have to say at first look I do not like the new JTAlertX #FT8

 

I installed the latest JTAlertX version and I got to say at first look I don't like it.   I seem to have lost or can't find the settings menu.  Spots are limited to one line of spots about 8 or so.  Thinking of trying to go back to a version 24.xx and stay there.

Al

locked #Memory #macOS

James Quick
 

Went to bed last night and all was well with all of my system. I run macOS Big Sur, I-Mac computer, IC-7300 and IC-7100 radios. I have been working with 2.4.0rc4 and all was well until I started up today. Mac did a update that I thought I had turned off.. But I did not. Thanks for any help or advice. Can’t get com.wsjtx.syctl.plist to load.

73
Jim

Jim Quick / N4ule-Ex-KA4BEG
n4ule@...
locked Re: Decoding nonstandard callsigns with jt9 utility #FT8

William Smith
 

The whole point of the hash table is "when I say <hash> I mean that callsign we heard recently that computes to <hash>", so there's no fixed hash table, as it's meaningless without the recent history.

73, Willie N1JBJ

On Apr 16, 2021, at 1:13 PM, Rock WW1X <rockwell@...> wrote:

Okay, thanks for the clarification. That is really unfortunate to hear.

I have built a browser-based FT8 client which remotely calls jt9 and ft8code without using WSJT-X at all, but if I cannot find a way to decode nonstandard callsigns with these executables, that is a major show-stopper.
locked Re: #fst4 LDPC Coding order #FST4

William Smith
 

This is really cool, neat to see this on a PIC!

73, Willie N1JBJ

On Apr 16, 2021, at 3:30 AM, Andy TALBOT <andy.g4jnt@...> wrote:

During the study of FST4 coding and getting its generation onto a PIC device,   
it took a while to spot a little aspect of the signal that was blindingly obvious, and is almost certainly stated somewhere and is no-doubt quite intentional ...

The important bits are transmitted first; the 77 message bits followed by the CRC, then the parity bits.   So in a strong signal error-free situation, if the first 42% of the transmission is received without errors, and the CRC matches, no further work with the parity bits is needed.

Unlike other modes that have the message interleaved throughout and need a spread of bits from the entire duration to decode properly.

70% of the PIC coding is done.  So far I can turn 77 source bits into a CRC and 139 parity bits.  The next stage is grouping these into symbols and inserting sync and it's done.  The PIC device I'm using is a 16F1827.  This has enough program memory (4K) to comfortably hold the 1.2K needed for the parity matrix and leave plenty for coding and generation - and more than enough RAM.
The parity encoding stage wasted a couple of hours as I'd initially coded it as XOR + XOR  without thinking, rather than AND + XOR
locked Re: Decoding nonstandard callsigns with jt9 utility #FT8

Rock WW1X
 

Okay, thanks for the clarification. That is really unfortunate to hear.

I have built a browser-based FT8 client which remotely calls jt9 and ft8code without using WSJT-X at all, but if I cannot find a way to decode nonstandard callsigns with these executables, that is a major show-stopper.
locked Re: Decoding nonstandard callsigns with jt9 utility #FT8

steve_k9an
 

Hi Rock WW1X,

You have discovered the hashtable that is used for the WSPR decoder, wsprd. This table has no connection with the hashtables that are used for the 77-bit modes FT4, FST4, FT8, and Q65. The 10-, 12-, and 22-bit hashtables that are used for these modes are stored in memory and will be properly populated and maintained only when jt9 is called by WSJT-X. These tables are not stored on disk and they are repopulated from scratch each time WSJT-X is started.

73 Steve k9an

locked Re: Decoding nonstandard callsigns with jt9 utility #FT8

Rock WW1X
 
Edited

Update: so I found hashtable.txt in the WSJT-X data directory, which looks like exactly what I want. I'm hoping that jt9 will simply read this file if it exists. So I guess I just need to dig through the source to determine how these 16-bit unsigned hashes are generated, so I can generate this text file myself.

  129 DL1MMK
  390 K1YZY
  431 I4ZTO
 1032 G0UJA
...snip...
31186 G8PBH
31712 F5SN

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

Bob K4RCG
 

I've taken a look at GridTracker and found that I like it's capabilities.  I still use JTAlert...but GridTracker seems to be a great tool and I'm using it more-and-more it seems.

73 de Bob K4RCG

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

Larry Banks
 

Hi Al,
 
Have you read the release notes and help files?

73 -- Larry -- W1DYJ

 
From: Al - N1API
Sent: Friday, April 16, 2021 11:08
Subject: [WSJTX] Well I have to say at first look I do not like the new JTAlertX #FT8
 
I installed the latest JTAlertX version and I got to say at first look I don't like it.   I seem to have lost or can't find the settings menu.  Spots are limited to one line of spots about 8 or so.  Thinking of trying to go back to a version 24.xx and stay there.

Al




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

Jim - N4ST
 

Al (Call?)

 

Read the help file.

“Spots” have their own window and are almost unlimited in number.

There are multiple new windows.  Look for the little gear in the window and you can bring up a list of options.

 

 

___________

73,

Jim – N4ST

 

From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of Al - N1API
Sent: Friday, April 16, 2021 11:09
To: main@WSJTX.groups.io
Subject: [WSJTX] Well I have to say at first look I do not like the new JTAlertX #FT8

 

I installed the latest JTAlertX version and I got to say at first look I don't like it.   I seem to have lost or can't find the settings menu.  Spots are limited to one line of spots about 8 or so.  Thinking of trying to go back to a version 24.xx and stay there.

Al

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

Al - N1API
 

I installed the latest JTAlertX version and I got to say at first look I don't like it.   I seem to have lost or can't find the settings menu.  Spots are limited to one line of spots about 8 or so.  Thinking of trying to go back to a version 24.xx and stay there.

Al

locked Re: Q65 in less favourable condx? #Q65

johnsherry57 <Glecarron57@...>
 

Hi Derek six metres 50.305
Thanks

On Fri, 16 Apr 2021, 15:42 Derek Brown via groups.io, <g8eci=yahoo.co.uk@groups.io> wrote:
Hi John

What band are you TX ing on, I will beam north and take a look see.

Derek G8ECI JO03ai.

On Friday, 16 April 2021, 14:32:24 BST, johnsherry57 <glecarron57@...> wrote:


Hi folks 
Some advice please.  At present I am working 
Q65a 30 seconds from Scotland GM into mainland Europe. Running a home brew 2 ele and 80 watts.
Using the ON4KST chatroom I know guys are listening for me but not hearing me.

I understand conditions play a part but has anyone had success in marginal conditions by changing mode or time? I am perhaps trying to work stations about 600 of more miles away early mid afternoon.

Many thanks John GM0AZC  






locked Re: #fst4 LDPC Coding order #FST4

Julian
 

Are FST4W and wspr the same as FST4 wrt the position of error coding?

What is the position with all the other modes in wsjt -  which modes have an interleved ECC and which are separate?

Julian, G3YGF


On 16/04/2021 08:30, Andy TALBOT wrote:

During the study of FST4 coding and getting its generation onto a PIC device,   
it took a while to spot a little aspect of the signal that was blindingly obvious, and is almost certainly stated somewhere and is no-doubt quite intentional ...

The important bits are transmitted first; the 77 message bits followed by the CRC, then the parity bits.   So in a strong signal error-free situation, if the first 42% of the transmission is received without errors, and the CRC matches, no further work with the parity bits is needed.

Unlike other modes that have the message interleaved throughout and need a spread of bits from the entire duration to decode properly.

70% of the PIC coding is done.  So far I can turn 77 source bits into a CRC and 139 parity bits.  The next stage is grouping these into symbols and inserting sync and it's done.  The PIC device I'm using is a 16F1827.  This has enough program memory (4K) to comfortably hold the 1.2K needed for the parity matrix and leave plenty for coding and generation - and more than enough RAM.
The parity encoding stage wasted a couple of hours as I'd initially coded it as XOR + XOR  without thinking, rather than AND + XOR

locked Re: Q65 in less favourable condx? #Q65

Derek Brown
 

Hi John

What band are you TX ing on, I will beam north and take a look see.

Derek G8ECI JO03ai.

On Friday, 16 April 2021, 14:32:24 BST, johnsherry57 <glecarron57@...> wrote:


Hi folks 
Some advice please.  At present I am working 
Q65a 30 seconds from Scotland GM into mainland Europe. Running a home brew 2 ele and 80 watts.
Using the ON4KST chatroom I know guys are listening for me but not hearing me.

I understand conditions play a part but has anyone had success in marginal conditions by changing mode or time? I am perhaps trying to work stations about 600 of more miles away early mid afternoon.

Many thanks John GM0AZC  



locked Hamlib error - WSJTx v2.3.1 - RPi4 -FiFi SDR #IssueReport #raspberryPi #Cat_RigControl

Erwin - PE3ES - F4VTQ
 

First install on RPi4 B 2Go with PiSDR image

With same settings and same udev file for FiFi SDR JTDX rc155 works fine.

WSJTx throws error, see picture


--
PE3ES / F4VTQ
de Erwin

locked #fst4 LDPC Coding order #FST4

Andy Talbot
 

During the study of FST4 coding and getting its generation onto a PIC device,   
it took a while to spot a little aspect of the signal that was blindingly obvious, and is almost certainly stated somewhere and is no-doubt quite intentional ...

The important bits are transmitted first; the 77 message bits followed by the CRC, then the parity bits.   So in a strong signal error-free situation, if the first 42% of the transmission is received without errors, and the CRC matches, no further work with the parity bits is needed.

Unlike other modes that have the message interleaved throughout and need a spread of bits from the entire duration to decode properly.

70% of the PIC coding is done.  So far I can turn 77 source bits into a CRC and 139 parity bits.  The next stage is grouping these into symbols and inserting sync and it's done.  The PIC device I'm using is a 16F1827.  This has enough program memory (4K) to comfortably hold the 1.2K needed for the parity matrix and leave plenty for coding and generation - and more than enough RAM.
The parity encoding stage wasted a couple of hours as I'd initially coded it as XOR + XOR  without thinking, rather than AND + XOR
locked Q65 in less favourable condx? #Q65

johnsherry57 <Glecarron57@...>
 

Hi folks 
Some advice please.  At present I am working 
Q65a 30 seconds from Scotland GM into mainland Europe. Running a home brew 2 ele and 80 watts.
Using the ON4KST chatroom I know guys are listening for me but not hearing me.

I understand conditions play a part but has anyone had success in marginal conditions by changing mode or time? I am perhaps trying to work stations about 600 of more miles away early mid afternoon.

Many thanks John GM0AZC  

locked Decoding nonstandard callsigns with jt9 utility #FT8

Rock WW1X
 

Hi folks. I am decoding 15-second WAV files using the jt9 command-line utility with the --ft8 option. All is good… except when it comes to nonstandard callsigns. I'm referring to section 7.5 of the documentation here – basically any long callsigns, or callsigns with a slash.

From what I understand, because of the limited number of bits per message, long callsigns within brackets, e.g. <KP4/WW1X> actually go out over the air as hashes of the callsigns, and that WSJT-X needs to have seen that callsign recently in order for it to match up the received callsign hash and properly decode it. Please correct me if I'm wrong so far.

My issue is that I cannot find a way to pass in a list of "recent callsigns" into the jt9 utility, so that nonstandard callsigns can be decoded. For example, when I call CQ KP4/WW1X, I can see folks calling me back, but my callsign is decoded as <...> because jt9 has no a priori knowledge of which callsign hashes to expect.

Is there any way around this limitation?
locked Re: Hover over taskbar icon shows settings form although settings form has been closed #WSJTX_config #mainscreen

Rob PD0RZH
 

Sorry Bill,

I've updated to the latest drivers. Unfortunately it stays the same.. It's not a big issue though. Several people have adderessed this behavior in the past. 

Rob

17601 - 17620 of 41738