Date   

locked Re: New JTAlert screen format #WSJTX_config

Pat N6PAT
 

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=yahoo.com@groups.io> 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. .







    




locked Re: New JTAlert screen format #WSJTX_config

JTAlert Support (VK3AMA)
 

On 17/04/2021 1:38 pm, Robert Lorenzini wrote:
Or the OCD group.

Or RTFM!

de Laurie VK3AMA


locked Re: New JTAlertX #FT8 I Also Don't like The New Layout #FT8

JTAlert Support (VK3AMA)
 

On 17/04/2021 1:01 pm, Pat N6PAT via groups.io wrote:
Is there any way to have the call sign boxes fixed length so they all line up neatly like they did with the grid?

Right now the display is not very attractive with the boxes not lined up.

Yes. Look under the Options for that window (hint, click the gear icon).

Doesn't anyone bother reading release notes or help files anymore.

de Laurie VK3AMA


locked Re: New JTAlert screen format #WSJTX_config

Robert Lorenzini
 

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=yahoo.com@groups.io> 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. .









locked Re: New JTAlertX #FT8 I Also Don't like The New Layout #FT8

N2OG Scott
 

Hello,

I have installed 2.50.0

I have it working in only one user in my computer.  I have a contest user side of my Win 10 computer.  2.50.0 does not work there.

Tried all I can think of.  Maybe have the guys take a look at that issue if they get a chance.

N2OG  Scott  N3PKJ Todd


locked Re: New JTAlert screen format #WSJTX_config

Dave Garber
 

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=yahoo.com@groups.io> 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. .





locked New JTAlert screen format #WSJTX_config

Pat N6PAT
 

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. .


locked Re: New JTAlertX #FT8 I Also Don't like The New Layout #FT8

Pat N6PAT
 

Is there any way to have the call sign boxes fixed length so they all line up neatly like they did with the grid?

Right now the display is not very attractive with the boxes not lined up.


locked Re: Decoding nonstandard callsigns with jt9 utility #FT8

Rock WW1X
 

On Fri, Apr 16, 2021 at 03:01 PM, William Smith wrote:

it's meaningless without the recent history.

I understand the intention of the hashing. I am curious if the recent history can be passed, standalone, into the jt9 utility instead of relying on the WSJT-X GUI application.


locked Re: New JTAlertX #FT8 I Also Don't like The New Layout #FT8

Chuck Adams
 

Hello David AD4TJ,
 
As I mentioned I am previous post,, the new JTAlert 2.50.0 provides you with a MUCH wider and deeper range of Callsign decode display and filtering 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.
 
CFA KV4VT

Sent from my T-Mobile 5G Device


From: main@WSJTX.groups.io <main@WSJTX.groups.io> on behalf of David AD4TJ via groups.io <ad4tj@...>
Sent: Friday, April 16, 2021 6:46:22 PM
To: main@WSJTX.groups.io <main@WSJTX.groups.io>
Subject: [WSJTX] New JTAlertX #FT8 I Also Don't like The New Layout
 
I upgraded to the new JTAlertX. I could not get any activity to be displayed, nor was I able to find the Windows Filter Options box. What did I miss? I backed down to the December version for now.

David AD4TJ


locked Re: Q65 in less favourable condx? #Q65

Bill Somerville
 

Hi Hasan and John,

another factor is that here in the UK we a a couple of grid fields higher in latiitude, that may have a significant impact on ionospheric modes like iono-scatter. Long term tests need to be done. There is anecdotal evidence that iono-scatter on 2m is considerably better in the Summer months, that may be due to longer periods per day of exposure to direct Solar effects and possibly lower effective latitude with respect to the Sun.

73
Bill
G4WJS.

On 16/04/2021 23:57, Hasan Schiers N0AN wrote:

John,
I can't speak for Europe, but after running well over 150  hours of testing on 6 meters, this it what we have concluded:

1. Q65 30B is better than 30A, by a significant margin.
Our tests show 100w to 5 EL Yagis on each end will yield > 700 miles reliably. These would be called 'well equipped stations'

2. Low power 6m : use 120E, it is amazing. I am able to consistently work 670 miles with the distant station running less than 10w output, and I am running about 25w out because of his high noise. I also work two different stations who are running 75w at distances of 800+ miles quite easily. 

3. Q65 30A is not as effective, but 100w to 5 EL yagis will work with some effort at 600 to 800 miles. 

Anything other than Q65-30A  on the standard (whatever it might be) European 6m frequency, is likely to require a schedule. 

Also, we have found the best time of the day to be pre-dawn thru about 9 a.m. local time.

Q65 is very effective for ANY mode of propagation. It makes use of and takes advantage of:

1. Ionoscatter
2. Meteor Scatter
3. Sporadic E
4. Ground Wave
5. Troposcatter
6. Tropo ducting.
7. Airplane Scatter

This is why (our theory) Q65 30A, 30B and 120E work so well in the early morning hours...it takes advantage of 1,2, 4, 5 and 6 modes listed above, all at the same time, if they are available. 

While ionoscatter peaks at noon, mid-path, we have found that due to the eclectic rx capabilities of Q65,  in the face of various propagation conditions, that the early morning hours have a significant advantage.

KB7IJ, NM3G, K5GZR and WB4HIE and I have been testing on 6 meters for several months using Q65 30A/30B/120E for at least two hours every morning. 

The method of evaluation is to establish contact , then begin reducing power until decodes are missed and averaging begins. IA rough estimate:

Power listed is their transmit power
KB7IJ  7 EL @ 50' Hardline, 666 miles, 
   Mode 30B: 15 watts, Mode 120E 5 watts or less 
   Both cases I get > 80% decodes, mostly in the 90% range

K5GZR  5 EL @ 50', 863 miles
   Mode 30B 100w, Mode 120E 25w

WB4HIE 5 El ..., 800 miles
    Mode 30B, 100w, difficult at times, 30% decodes
     Mode 120E, 100w, > 90% decodes. (Mountain obstructions)

This should give a feel for what to expect from Q65 on 6 meters. If you do not see these kinds of results:

1. You have high local noise, or your partner does.
2. Your rx system is inadequate, or your partner's is.

As Joe has stated 'well equipped stations', should have no problem consistently working nearly 1000 miles. 100w to 3 EL yagis with low loss coax should permit 600 miles easily and 1000 with some patience on 6 meters.

73, N0AN
Hasan
 



On Fri, Apr 16, 2021 at 9:42 AM 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: New JTAlertX #FT8 I Also Don't like The New Layout #FT8

Hasan Schiers N0AN
 

Dave. read the release notes and the help file. The new windows are very powerful and replace the old display methods.

The little gear/wheel in many windows contain many settings.

It is very well done, but quite a change from the older versions.

73, N0AN
Hasan


On Fri, Apr 16, 2021 at 5:48 PM David AD4TJ via groups.io <ad4tj=yahoo.com@groups.io> wrote:
I upgraded to the new JTAlertX. I could not get any activity to be displayed, nor was I able to find the Windows Filter Options box. What did I miss? I backed down to the December version for now.

David AD4TJ



locked Re: Q65 in less favourable condx? #Q65

Hasan Schiers N0AN
 

John,
I can't speak for Europe, but after running well over 150  hours of testing on 6 meters, this it what we have concluded:

1. Q65 30B is better than 30A, by a significant margin.
Our tests show 100w to 5 EL Yagis on each end will yield > 700 miles reliably. These would be called 'well equipped stations'

2. Low power 6m : use 120E, it is amazing. I am able to consistently work 670 miles with the distant station running less than 10w output, and I am running about 25w out because of his high noise. I also work two different stations who are running 75w at distances of 800+ miles quite easily. 

3. Q65 30A is not as effective, but 100w to 5 EL yagis will work with some effort at 600 to 800 miles. 

Anything other than Q65-30A  on the standard (whatever it might be) European 6m frequency, is likely to require a schedule. 

Also, we have found the best time of the day to be pre-dawn thru about 9 a.m. local time.

Q65 is very effective for ANY mode of propagation. It makes use of and takes advantage of:

1. Ionoscatter
2. Meteor Scatter
3. Sporadic E
4. Ground Wave
5. Troposcatter
6. Tropo ducting.
7. Airplane Scatter

This is why (our theory) Q65 30A, 30B and 120E work so well in the early morning hours...it takes advantage of 1,2, 4, 5 and 6 modes listed above, all at the same time, if they are available. 

While ionoscatter peaks at noon, mid-path, we have found that due to the eclectic rx capabilities of Q65,  in the face of various propagation conditions, that the early morning hours have a significant advantage.

KB7IJ, NM3G, K5GZR and WB4HIE and I have been testing on 6 meters for several months using Q65 30A/30B/120E for at least two hours every morning. 

The method of evaluation is to establish contact , then begin reducing power until decodes are missed and averaging begins. IA rough estimate:

Power listed is their transmit power
KB7IJ  7 EL @ 50' Hardline, 666 miles, 
   Mode 30B: 15 watts, Mode 120E 5 watts or less 
   Both cases I get > 80% decodes, mostly in the 90% range

K5GZR  5 EL @ 50', 863 miles
   Mode 30B 100w, Mode 120E 25w

WB4HIE 5 El ..., 800 miles
    Mode 30B, 100w, difficult at times, 30% decodes
     Mode 120E, 100w, > 90% decodes. (Mountain obstructions)

This should give a feel for what to expect from Q65 on 6 meters. If you do not see these kinds of results:

1. You have high local noise, or your partner does.
2. Your rx system is inadequate, or your partner's is.

As Joe has stated 'well equipped stations', should have no problem consistently working nearly 1000 miles. 100w to 3 EL yagis with low loss coax should permit 600 miles easily and 1000 with some patience on 6 meters.

73, N0AN
Hasan
 



On Fri, Apr 16, 2021 at 9:42 AM 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 New JTAlertX #FT8 I Also Don't like The New Layout #FT8

David AD4TJ
 

I upgraded to the new JTAlertX. I could not get any activity to be displayed, nor was I able to find the Windows Filter Options box. What did I miss? I backed down to the December version for now.

David AD4TJ


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.

15641 - 15660 of 39792