Date   

locked Re: Rig Failure #Cat_RigControl

wmmilton <WMMILTON@...>
 

Also Mode set to Data/Pkt and Split Operation to Fake It.

On Sun, May 23, 2021 at 7:26 PM wmmilton <wmmilton@...> wrote:
Try Setting data bits to 8
Stop bits to 1 
Handshake to None and
Both DTS and RTS to High
Make sure you have the correct COM port.

On Sun, May 23, 2021 at 7:18 PM Walter Egenmaier <wegenmaier@...> wrote:
I am trying WSJTX 2.3.1 for the first time with latest N3FJP  (ACL ver 7.01), WIN 10, 64 bit laptop, and FT-991A (with internal modem).
I have never used WSJTX software before, but do use N3FJP and since it is compatible, I though I would try to set this up on my rig for FT8.
As you can see by the attachment, I have several rig failures. Any suggestions on how to fix. I am set up on COM7 using VSPE (Virtual Serial Port Emulator software) which does work with my ACL from N3FJP. The ACL software has rig control and it reads the freq on my rig perfectly. So not sure what my next step should be. 
I did get band activity that wasn't there before, so not sure how that happened. I'm on USB 7.074 MHz.
Appreciate any help to get me started. 
Walt / WB4ZUT
73s



locked Re: Rig Failure #Cat_RigControl

wmmilton <WMMILTON@...>
 

Try Setting data bits to 8
Stop bits to 1 
Handshake to None and
Both DTS and RTS to High
Make sure you have the correct COM port.

On Sun, May 23, 2021 at 7:18 PM Walter Egenmaier <wegenmaier@...> wrote:
I am trying WSJTX 2.3.1 for the first time with latest N3FJP  (ACL ver 7.01), WIN 10, 64 bit laptop, and FT-991A (with internal modem).
I have never used WSJTX software before, but do use N3FJP and since it is compatible, I though I would try to set this up on my rig for FT8.
As you can see by the attachment, I have several rig failures. Any suggestions on how to fix. I am set up on COM7 using VSPE (Virtual Serial Port Emulator software) which does work with my ACL from N3FJP. The ACL software has rig control and it reads the freq on my rig perfectly. So not sure what my next step should be. 
I did get band activity that wasn't there before, so not sure how that happened. I'm on USB 7.074 MHz.
Appreciate any help to get me started. 
Walt / WB4ZUT
73s



locked WSJT-X 2.4.0 GA Release #general

Joe
 

We are pleased to announce the General Availability (GA) release of WSJT-X version 2.4.0, which includes the new digital mode Q65.

Q65 is designed for two-way QSOs over especially difficult propagation paths including ionospheric scatter, troposcatter, rain scatter, TEP, EME, and other types of fast-fading signals. Details and recommendations concerning the Q65 submodes are provided in the "Quick-Start Guide to Q65", available here:
https://physics.princeton.edu/pulsar/k1jt/Q65_Quick_Start.pdf

The WSJT-X User Guide includes further details about Q65 and is available here: https://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-2.4.0.html

Links to WSJT-X 2.4.0 installation packages for Windows, Linux, and Macintosh are available here:
http://physics.princeton.edu/pulsar/k1jt/wsjtx.html

You can also download the packages from our SourceForge site:
https://sourceforge.net/projects/wsjt/files/
It may take a short time for the SourceForge site to be updated.

WSJT-X for Windows now ships with Hamlib version 4.2 as a dynamic link library (DLL). This change will allow Hamlib bug fixes to be resolved by replacing the DLL with an updated version.

WSJT-X is licensed under the terms of Version 3 of the GNU General Public License (GPL). Development of this software is a cooperative project to which many amateur radio operators have contributed. If you use our code, please have the courtesy to let us know about it. If you find bugs or make improvements to the code, please report them to us in a timely fashion.

The authors and Copyright holders of WSJT-X request that derivative works should not publish programs based on features in WSJT-X before those features are made available in a General Availability (GA) release of WSJT-X. We will cease making public Release Candidate (RC) pre-releases for testing and user early access purposes if this request is ignored.

Bugs should be reported by following instructions found here in the User Guide:

https://www.physics.princeton.edu//pulsar/K1JT/wsjtx-doc/wsjtx-main-2.4.0.html#_bug_reports

We hope you will enjoy using WSJT-X 2.4.0.

-- 73 from Joe, K1JT; Bill, G4WJS; Steve, K9AN; and Nico, IV3NWV


locked Rig Failure #Cat_RigControl

Walter Egenmaier <wegenmaier@...>
 

I am trying WSJTX 2.3.1 for the first time with latest N3FJP  (ACL ver 7.01), WIN 10, 64 bit laptop, and FT-991A (with internal modem).
I have never used WSJTX software before, but do use N3FJP and since it is compatible, I though I would try to set this up on my rig for FT8.
As you can see by the attachment, I have several rig failures. Any suggestions on how to fix. I am set up on COM7 using VSPE (Virtual Serial Port Emulator software) which does work with my ACL from N3FJP. The ACL software has rig control and it reads the freq on my rig perfectly. So not sure what my next step should be. 
I did get band activity that wasn't there before, so not sure how that happened. I'm on USB 7.074 MHz.
Appreciate any help to get me started. 
Walt / WB4ZUT
73s


locked #GeneralGroupInfo SLOW TO DECODE. #GeneralGroupInfo

 

As I stated earlier wsjt-x is slow to decode. Like double decoding.
Appreciate the help
--
Thanks 73's de NU4N/Dave


locked VS: [WSJTX] Problem with SCU 17 CAT control on FT450D #Cat_RigControl

Reino Talarmo
 

And I have Data/Pkt as-well-as Fake-It for the split.

Hi Bob,
You should not have those jumps as you are using Fake-it as it uses a single
VFO only. Have you tried Rig for the split?
I am using FTdx3000 and it also rattles with Rig for the split.
73 Reino, OH3mA


locked VS: [WSJTX] #GeneralGroupInfo Problem Decoding. #GeneralGroupInfo

Reino Talarmo
 

I am running the latest version. I have been using Dimension as may time syn for years.Today I am getting Double decoding ?? I am making contacts. My computer has enuf horsepower to decode quickly. Any thoughts ??

Hi Dave,
What you mean by double decoding. Do you mean exactly the same message, but on two different frequencies? If so are those two messages with a frequency difference 120 Hz or a multiple of 120 Hz? Is there a large difference at S/N of those decodes? Do you have a waterfall or .wav file on those instances to share?
In earlier versions of wsjt-x that was quite ‘normal’, at least v2.3.1 is difficult encourage to decode clear 120 Hz (or 100 Hz in Europe) next to the main transmit frequency, it prefers strongly the correct one.
73, Reino OH3mA


locked Re: Problem with SCU 17 CAT control on FT450D #Cat_RigControl

NR4U Bob AFMARS
 

Hello Austin,
Saturday, May 22, 2021, 1:39:38 PM, you wrote:
----------------------------------------------------
My settings are as follows:
Rig: Yaesu FT450
Serial Port: /dev/tty.SLAB_USBtoUART
Baud: 38400
Data Bits: 8
Stop Bits: 1
Handshake: Default
PTT: CAT
Mode: Data/Pkt
Split: None
----------------------------------------------------
Hi Austin.
I also have an active FT450 working with wsjtx

though I am using FLRig as "Radio" in the WSJTx settings ....

My settings are RTS not CAT, as the FT450 seems to like RTS

And I have Data/Pkt as-well-as Fake-It for the split.

Am also using the SCU-17 happily with the FT-450.

I just tested a few QRG changes inside the WSJTx pull-down and didn't see any jump from A->B->A

--
Best regards,
Bob KD7YZ



--
--
Bob KD7YZ in NE Kentucky


locked #GeneralGroupInfo Problem Decoding. #GeneralGroupInfo

 

I am running the latest version. I have been using Dimension as may time syn for years.Today I am getting Double decoding ?? I am making contacts. My computer has enuf horsepower to decode quickly. Any thoughts ??
--
Thanks 73's de NU4N/Dave


locked Re: Receive only decoder #general

Tom V. Segalstad
 

Hi Mike

 

There is an app for PC, and for mobile phone (at least for Android type phones), which is able to decipher a number of digital modes. It is called «SignalID» for «Automatic Radio Signal Identification».

 

SignalID can at this time recognize the following digital modes:

RTTY (85 Hz, 170 Hz, 450 Hz, 850 Hz, and amateur 170 Hz).

STANAG 4285 (GEN, SYS3000 FEC, 8PSK, TFC, IDLE, SYS3000).

FT4

FT8

 

The authors of this app are working to include more kinds of digital modes.

And there may be other apps doing this digital deciphering also?

 

The SignalID app can be downloaded from «Google Play» or from the following web sites:

https://github.com/Neosama/SignalID

or

https://apkpure.com/signalid-automatic-radio-signal-identification/com.tortillum.signalid

 

When you start the app, you will see a button labeled «0 – 30 MHz», hence it is set for HF and frequencies below.

If you press that button, the SignalID app will work for modes used from 30 MHz and upwards in frequency.

You get more info by pressing the «+» button in the upper left corner of the screen.

See the copy of the screen in the picture below.

 

73 and good luck from Tom, LA4LN

 

SignalID for Android - APK Download

 

 

Fra: Mike
Sendt: søndag 23. mai 2021 kl. 12.17
Til: main@WSJTX.groups.io
Emne: [WSJTX] Receive only decoder #general

 

This may be a stupid question - But in scouring the bands I hear so many data signals and I look for a possible decode based on what I think they sound like. As Im predominately a 2M up and we've already removed modes from WSJT-X (JT6M FSK441 for example but not in MSHV) and there are limited modes I struggle to identify them and as some are meteor pings its hard to go back over the recording if one was made and replay and decode it.

So my question is - is it possible to have a receive only system that will run through all the modes and give a predicted match. I understand that all the protocols and code is probably available but today my programming skills are diminishing (too old) so lets see if anyone out there can provide a solution Id like to help in any way I can.

Mike
GD6ICR

 


--
Tom (LA4LN)


locked Re: #JT4 and now #Q65 Decoding of very high S/N #JT4 #Q65

Andy Talbot
 

And now, having just modded the PIC code to generate Q65
Pure tones, no noise - NO DECODING whatsoever, ever, never,  to the extent I was pointlessly chasing up errors in the code and wasted over an hour of my life :-(

Add in some noise and straight decodes,
So the Q65 decoder, unlike the JT4 one,  needs background noise.



On Sat, 22 May 2021 at 17:09, Andy Talbot <andy.g4jnt@...> wrote:
Update
If I add noise the frequency measurement works properly.
But the S/N doesn't

Is S/N reporting supposed to be implemented in JT4 wider modes?
I do very vaguely seem to recall a comment once that it was not done at all.



On Sat, 22 May 2021 at 16:41, Andy Talbot <andy.g4jnt@...> wrote:
I've been testing a new JT4G beacon source , a single PIC chip generating quadrature audio tones for directly feeding a quad-upconverter.  Testing by feeding the tone output directly into the soundcard, running Ver 2.4.0 RC4

In the past, with earlier versions of WSJT-X,  the JT4 decoder hasn't always been very happy with pure tones and very high S/N. and would often miss decodes.  The situation resolved itself when the S/N was degraded by deliberately adding in noise from an audio noise generator

Now, though, with the latest decoder behaviour with a pure tone input is different.    Decoding is always successful - there are no missed decodes - but the frequency estimation and  the S/N reported are way-out.   I use exactly 1000Hz for tone 0 , but the decoder reports a spread from 914 to 1050 at least, and S/N is reported as -15 or so, when it is really a very high positive value.

Getting the S/N wrong I can understand why it may be happening, with the S/N estimation going off scale with no noise to measure, but the random value of frequency reporting is a new one.   Why is this ?

See the  attached screen shots


locked Receive only decoder #general

Mike <gd6icr@...>
 

This may be a stupid question - But in scouring the bands I hear so many data signals and I look for a possible decode based on what I think they sound like. As Im predominately a 2M up and we've already removed modes from WSJT-X (JT6M FSK441 for example but not in MSHV) and there are limited modes I struggle to identify them and as some are meteor pings its hard to go back over the recording if one was made and replay and decode it.

So my question is - is it possible to have a receive only system that will run through all the modes and give a predicted match. I understand that all the protocols and code is probably available but today my programming skills are diminishing (too old) so lets see if anyone out there can provide a solution Id like to help in any way I can.

Mike
GD6ICR


locked Cannot use /P in callsign when using JT65 and JT9 modes #JT65 #JT9 #IssueReport

Haris SV1GRB
 

Hello to all, I would like to mention a strange behavior regarding the use of a specific type 1 suffix in the callsign.

The list of type 1 suffixes indicates that /P is a valid type 1 suffix:
image.png
When /P is used in callsign on JT65 and JT9 modes, the /P suffix is present in all generated messages so there is no room for the third word (reports,  RRR and 73) to be transmitted.
image.png
The Tx1 is transmitted normally as G1ABC SV1GRB/P
The Tx2 instead of G1ABC SV1GRB -15 is transmitted as G1ABC SV1GRB/P
The Tx3 instead of G1ABC SV1GRB R -15 is transmitted as G1ABC SV1GRB/P
The Tx4 instead of G1ABC SV1GRB RRR is transmitted as G1ABC SV1GRB/P
The Tx5 instead of G1ABC SV1GRB 73 is transmitted as G1ABC SV1GRB/P
The Tx6 is transmitted normally as CQ SV1GRB/P

When using another type 1 suffix such as /3, the suffix is correctly present only in TX1 and TX6 and everything is transmitted FB.
image.png

Currently using version is 2.3.1.

73
Haris
SV1GRB


locked Cannot use /P in callsign when using JT65 and JT9 modes #JT65 #JT9 #IssueReport

Haris SV1GRB
 

Hello to all, I would like to mention a strange behavior regarding the use of a specific type 1 suffix in the callsign.

The list of type 1 suffixes indicates that /P is a valid type 1 suffix:
image.png
When /P is used in callsign on JT65 and JT9 modes, the /P suffix is present in all generated messages so there is no room for the third word (reports,  RRR and 73) to be transmitted.
image.png
The Tx1 is transmitted normally as G1ABC SV1GRB/P
The Tx2 instead of G1ABC SV1GRB -15 is transmitted as G1ABC SV1GRB/P
The Tx3 instead of G1ABC SV1GRB R -15 is transmitted as G1ABC SV1GRB/P
The Tx4 instead of G1ABC SV1GRB RRR is transmitted as G1ABC SV1GRB/P
The Tx5 instead of G1ABC SV1GRB 73 is transmitted as G1ABC SV1GRB/P
The Tx6 is transmitted normally as CQ SV1GRB/P

When using another type 1 suffix such as /3, the suffix is correctly present only in TX1 and TX6 and everything is transmitted FB.
image.png

Currently using version is 2.3.1.

73
Haris
SV1GRB


locked Re: Intl. WSPR Beacon Project #Beacons

Bob K4RCG
 

RR Martin.  It is an interesting project.

73 de Bob
K4RCG

On Sun, May 23, 2021 at 1:44 AM Roland <roland@...> wrote:
Thanks Bob, currently reaching out to HAM Radio Clubs around the world to draw some interest and to promote the new Project. I already made a post on the Wsprnet.org forum.
Much appreciated if you could spread the message to anyone who is interested. The Project website can be found here https://github.com/HB9VQQ/WSPRBeacon just as a reminder.

73 fer now
Roland



locked Re: Calling with TX2 #FT8

Jim Shorney
 

OK, time for this discussion to END.

73

-Jim
NU0C

On Sun, 23 May 2021 02:48:42 +0000 (UTC)
"K8BL BOB LIDDY" <k8bl@...> wrote:

it's selfish andinconsiderate


locked Re: Calling with TX2 #FT8

K8BL BOB LIDDY <k8bl@...>
 

Bill,

Thanks for pointing those things out. Yes, there are many helpful
and often necessary things provided when an answering Station is
gracious enough to provide their Grid. That's why it's selfish and
inconsiderate to answer merely with TX2 to save themselves a few
seconds of turnaround.

73,   Bob  K8BL


On Saturday, May 22, 2021, 10:17:28 PM EDT, Bill, WB6JJJ <bill@...> wrote:


The grid allows WSJT-X to show their beam heading so I can turn the antenna.  Also, JTAlert will quickly / automatically provide their name and grid.  But the grid displayed in JTAlert (from QRZ.com) isn’t always their correct grid…

Bill
WB6JJJ 



On May 22, 2021, at 6:41 PM, K8BL BOB LIDDY <k8bl@...> wrote:


IMHO...  I consider it rude and inconsiderate to purposely avoid using the proper
 protocol that was specifically designed to provide the Grid to the station you are
 calling just to save a few seconds of turnaround between timeslots. The software
 was designed such that CQ'ing Stations call using TX6 and answering Stations
 respond with TX1, including their Grid. If you answer someone's CQ by using
 improper protocol, you are purposely refusing to provide them with info that they
 may be seeking by being on the radio in the first place. You are refusing to tell
 them your Grid, which they may be collecting for various Awards, and you are
 refusing to give them an indication of your location, which would tell them where
 their signal is reaching. You might as well give them a crude gesture at the same
 time. In many instances, that forces the CQ Station to look up your info on-line
 before they'll log it in WSJT and/or their Station Log. That effort takes more time
 than the 15 seconds saved by NOT  providing your Grid when rudely calling by
 using TX2! After reading all the comments here about using TX2 to call Stations
 and all the lame/weak excuses for doing so, I'm seriously considering NOT logging
 QSOs that call using TX2. I'll work them, but I think I won't Log them. That would
 be just as rude and inconsiderate.

GL/73,   Bob  K8BL               (Let the flaming begin. 3...2...1)



On Saturday, May 22, 2021, 04:54:00 PM EDT, Reino Talarmo <reino.talarmo@...> wrote:









locked Re: Calling with TX2 #FT8

Bill, WB6JJJ
 

The grid allows WSJT-X to show their beam heading so I can turn the antenna.  Also, JTAlert will quickly / automatically provide their name and grid.  But the grid displayed in JTAlert (from QRZ.com) isn’t always their correct grid…

Bill
WB6JJJ 



On May 22, 2021, at 6:41 PM, K8BL BOB LIDDY <k8bl@...> wrote:


IMHO...  I consider it rude and inconsiderate to purposely avoid using the proper
 protocol that was specifically designed to provide the Grid to the station you are
 calling just to save a few seconds of turnaround between timeslots. The software
 was designed such that CQ'ing Stations call using TX6 and answering Stations
 respond with TX1, including their Grid. If you answer someone's CQ by using
 improper protocol, you are purposely refusing to provide them with info that they
 may be seeking by being on the radio in the first place. You are refusing to tell
 them your Grid, which they may be collecting for various Awards, and you are
 refusing to give them an indication of your location, which would tell them where
 their signal is reaching. You might as well give them a crude gesture at the same
 time. In many instances, that forces the CQ Station to look up your info on-line
 before they'll log it in WSJT and/or their Station Log. That effort takes more time
 than the 15 seconds saved by NOT  providing your Grid when rudely calling by
 using TX2! After reading all the comments here about using TX2 to call Stations
 and all the lame/weak excuses for doing so, I'm seriously considering NOT logging
 QSOs that call using TX2. I'll work them, but I think I won't Log them. That would
 be just as rude and inconsiderate.

GL/73,   Bob  K8BL               (Let the flaming begin. 3...2...1)



On Saturday, May 22, 2021, 04:54:00 PM EDT, Reino Talarmo <reino.talarmo@...> wrote:






locked Re: Intl. WSPR Beacon Project #Beacons

Roland
 

Thanks Bob, currently reaching out to HAM Radio Clubs around the world to draw some interest and to promote the new Project. I already made a post on the Wsprnet.org forum.
Much appreciated if you could spread the message to anyone who is interested. The Project website can be found here https://github.com/HB9VQQ/WSPRBeacon just as a reminder.

73 fer now
Roland


locked Re: Calling with TX2 #FT8

K8BL BOB LIDDY <k8bl@...>
 

IMHO...  I consider it rude and inconsiderate to purposely avoid using the proper
 protocol that was specifically designed to provide the Grid to the station you are
 calling just to save a few seconds of turnaround between timeslots. The software
 was designed such that CQ'ing Stations call using TX6 and answering Stations
 respond with TX1, including their Grid. If you answer someone's CQ by using
 improper protocol, you are purposely refusing to provide them with info that they
 may be seeking by being on the radio in the first place. You are refusing to tell
 them your Grid, which they may be collecting for various Awards, and you are
 refusing to give them an indication of your location, which would tell them where
 their signal is reaching. You might as well give them a crude gesture at the same
 time. In many instances, that forces the CQ Station to look up your info on-line
 before they'll log it in WSJT and/or their Station Log. That effort takes more time
 than the 15 seconds saved by NOT  providing your Grid when rudely calling by
 using TX2! After reading all the comments here about using TX2 to call Stations
 and all the lame/weak excuses for doing so, I'm seriously considering NOT logging
 QSOs that call using TX2. I'll work them, but I think I won't Log them. That would
 be just as rude and inconsiderate.

GL/73,   Bob  K8BL               (Let the flaming begin. 3...2...1)



On Saturday, May 22, 2021, 04:54:00 PM EDT, Reino Talarmo <reino.talarmo@...> wrote:


13001 - 13020 of 37956