Date   

locked Re: What should Radio TX Power Setting really be? #wsjt-x #WSJTX_config

Paul Turner
 

Oh man! What have you done? Another round of arguments about low power vs weak signal, ALC settings and blown finals. I can only speak for myself: I run an IC-9700 on 2 metres and have had nearly 1000 QSOs on FT8 mode, all at about 90 watts , which is virtually full power. The Icom rig has good cooling and is happy running the 43% duty cycle of FT8 mode for several minutes at a time. I also have an IC-7300 and have used it at 100 watts on 6 metres in the past although I now have a small amp so only need to run it at about 10 watts. I’m guessing that the IC-7610 has similar cooling and temperature monitoring to my two rigs, so you can probably run close to full “key down” power if that’s what it takes to complete a QSO. Keep the ALC in the “green” (it doesn’t have to be zero) and all will be well.

 

73, Paul G4IJE.

 

 

From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of Ramon S via groups.io
Sent: 20 July 2021 21:44
To: main@WSJTX.groups.io
Subject: [WSJTX] What should Radio TX Power Setting really be? #wsjt-x #WSJTX_config #wsjt-x #radio

 

I have been using the WSJT modes since the JT65/JT9 days, until now on FT8, JS8 and I don't think I am doing too bad, given my compromise antenna. Since then, until now, I have not used the WSJT-X panel "Pwr" vertical slider, set at maximum and untouched, and only use my radio's RF power out control, to set my TX power, eg, 5W for WSPR, 20~30W for FT8, JS8.

I recently got a new IC-7610 and I though it might be a good opportunity to review my radio setup and read the latest the online WSJT documentation. These docs do not mention explicitly about the required radio TX power setting, but from what I see in the related io forums, I think they recommend, that the transceiver be set at maximum, 100W in my case, and only use the WSJT-X "Pwr" power slider to go down to your required lower TX output, 5W, 20W.

Does everybody really set their radio to their maximum rated RF power, eg, 100W? Would this not cause undue stress to a radio's finals, if you do a lot of WSJT QSOs?

TIA and 73,
Ramon


Virus-free. www.avast.com


locked Re: What should Radio TX Power Setting really be? #wsjt-x #WSJTX_config

Bill Somerville
 

On 20/07/2021 21:44, Ramon S via groups.io wrote:
I have been using the WSJT modes since the JT65/JT9 days, until now on FT8, JS8 and I don't think I am doing too bad, given my compromise antenna. Since then, until now, I have not used the WSJT-X panel "Pwr" vertical slider, set at maximum and untouched, and only use my radio's RF power out control, to set my TX power, eg, 5W for WSPR, 20~30W for FT8, JS8.

I recently got a new IC-7610 and I though it might be a good opportunity to review my radio setup and read the latest the online WSJT documentation. These docs do not mention explicitly about the required radio TX power setting, but from what I see in the related io forums, I think they recommend, that the transceiver be set at maximum, 100W in my case, and only use the WSJT-X "Pwr" power slider to go down to your required lower TX output, 5W, 20W.

Does everybody really set their radio to their maximum rated RF power, eg, 100W? Would this not cause undue stress to a radio's finals, if you do a lot of WSJT QSOs?

TIA and 73,
Ramon
Hi Ramon,

in SSB modes the stress on the PA and PSU is related to the output power, not to the carrier power set on the rig. Personally I would set the Pwr slider to the top (0db attenuation) and use the rig's POWER control as a control of output. I reserve the Pwr slider for if I want to reduce power to less than the POWER control on my rig allows. TBH it is not critical and some setups may work better using the Pwr slider. You could do some tests with a local to see if you can detect any difference.

Here is a post containing a recipe for setting Tx power correctly:

https://wsjtx.groups.io/g/main/message/13890

73
Bill
G4WJS.


locked What should Radio TX Power Setting really be? #wsjt-x #WSJTX_config

Ramon S
 

I have been using the WSJT modes since the JT65/JT9 days, until now on FT8, JS8 and I don't think I am doing too bad, given my compromise antenna. Since then, until now, I have not used the WSJT-X panel "Pwr" vertical slider, set at maximum and untouched, and only use my radio's RF power out control, to set my TX power, eg, 5W for WSPR, 20~30W for FT8, JS8.

I recently got a new IC-7610 and I though it might be a good opportunity to review my radio setup and read the latest the online WSJT documentation. These docs do not mention explicitly about the required radio TX power setting, but from what I see in the related io forums, I think they recommend, that the transceiver be set at maximum, 100W in my case, and only use the WSJT-X "Pwr" power slider to go down to your required lower TX output, 5W, 20W.

Does everybody really set their radio to their maximum rated RF power, eg, 100W? Would this not cause undue stress to a radio's finals, if you do a lot of WSJT QSOs?

TIA and 73,
Ramon


locked Re: Clock Sync #Timesync

Jim Pennino
 

I am well aware that ntp needs 3 or more sources of time. In the experiments with multiple GPS sources, there were also several network time sources defined so ntp always had at least 4 sources to choose from. Those sources were a mix of other GPS ntp servers on my 1G network and my ISP's ntp servers which are only a few hops away.

I think I said you only need one GPS and if you have two, put one on another machine. It was an experiment to see what happens.

As the post was about using cheap GPS receivers, there are no cheap GPS receivers with good hold over performance.

You will be hard pressed to find any hardware with USB 1 that is still running and I have already posted data about the jitter and accuracy that can be expected using USB 2.

The current USB GPS receivers are already very close to the limit of jitter that can be had using only NMEA sentences and going to USB 3 can not improve that in any significant way. The advantage of a USB 3 GPS receiver would be that it could have a PPS signal which WOULD significantly reduce jitter, but there are currently none available. Maybe next year or so.

As I have said several times now, I have a Raspberry Pi with an Ultimate HAT GPS that keeps time in the microseconds. If one wishes to home brew, the simplest thing to do is get such a HAT or an evaluation board, build a simple logic level to RS-232 converter and connect it to a serial port. Using USB for serial data and something else for PPS would require hacking the OS.

Using the $15 VK-162 G-Mouse USB GPS I recommended at the start of this thread provides a long term (several days) timing accuracy of  about 5 milliseconds to a 95% confidence level and will settle to well within 100 milliseconds a few minutes after power on. There are lots of others that will produce worse results, but ironically some are more expensive.

Jim WB6DKH


locked Re: Operating portable #WSJTX_config #FT8

Bill Somerville
 

On 20/07/2021 12:38, Reino Talarmo wrote:

>I would much prefer to follow recommendations than risk misunderstanding.  Also WSJT-X  treat /P, /A etc as ’standard’ callsigns so no issue there.  

Hi Tom,

Have you tested how /P, /M, /MM, /A, /1 - /9 behave in CQ messages with a standard call sign?
If you test, then you should note that only /P supports locator in the CQ message. In all other cases only call sign is sent and that is the issue.

73, Reino OH3mA

Hi Tom and Reino,

the way the newer 77-bit payload protocols work with /P and /R callsign suffixes is not quite the same as standard callsigns, but has less restrictions that other nonstandard callsigns. The reason /P and /R are different is that they are both used in certain contest exchanges, and since nonstandard calls are not supported in contest modes, special source encoding rules are used for /P and /R suffixes.

See the WSJT-X User Guide Contest Messages section for some examples:

https://physics.princeton.edu/pulsar/k1jt/wsjtx-doc/wsjtx-main-2.4.0.html#CONTEST_MSGS

73
Bill
G4WJS.


locked Re: Operating portable #WSJTX_config #FT8

Reino Talarmo
 

>I would much prefer to follow recommendations than risk misunderstanding.  Also WSJT-X  treat /P, /A etc as ’standard’ callsigns so no issue there.  

Hi Tom,

Have you tested how /P, /M, /MM, /A, /1 - /9 behave in CQ messages with a standard call sign?
If you test, then you should note that only /P supports locator in the CQ message. In all other cases only call sign is sent and that is the issue.

73, Reino OH3mA

 


locked Clock Sync #Timesync

Robert Lorenzini
 

On 7/19/2021 5:01 PM, Tim wrote:


Anything more is running down the hole which is time nuttery :)

Tim are you one of us?
https://groups.io/g/time-nuts

Make that https://groups.io/g/fmt-nuts


Bob - wd6dod


locked Re: Contest mode? #ContestMode

Dave Garber
 

read up on fox and hound mode....  usually dx stations, though


Dave Garber
VE3WEJ / VE3IE


On Mon, Jul 19, 2021 at 11:54 AM George J Molnar, KF2T <george@...> wrote:

One enhancement that might help in this situation is to build a call queue that allows multiple callers to be stacked and worked either sequentially or from a pick list by the operator. The progress of each contact could be maintained so that in QSB or scatter situations, contacts could “interleave” a little bit to improve rate.  Rare grid rovers, expeditions, and other popular stations could benefit. 


Having a blast on the radio. Thanks to all!

George/KF2T





locked Re: Clock Sync #Timesync

Robert Lorenzini
 

On 7/19/2021 5:01 PM, Tim wrote:



Anything more is running down the hole which is time nuttery :)

Tim are you one of us?
https://groups.io/g/time-nuts

Bob - wd6dod


locked Re: Operating portable #WSJTX_config #FT8

Tom Melvin
 

Karl

Please remember Amateur Radio is world wide - so FCC rules may not apply and people should be advised to check their own licence wording.

In the UK while it is not mandatory to send /P,  /A etc it is RECOMMENDED.


(d) When operating at locations other than the Main Station Address, it is recommended that the following suffixes be used:

I. If the Licensee operates the Radio Equipment at an Alternative Address, the Licensee may use the suffix “/A” with the Callsign;

II. If the Licensee operates the Radio Equipment at a Temporary Location, the Licensee may use the suffix “/P” with the Callsign;

III. If the Licensee operates the Radio Equipment from a Mobile location, the Licensee may use the suffix “/M” with theCallsign;

IV. If the Licensee operates the Radio Equipment from a Maritime Mobile location, the Licensee may use the suffix “/MM” with the Callsign.


I would much prefer to follow recommendations than risk misunderstanding.  Also WSJT-X  treat /P, /A etc as ’standard’ callsigns so no issue there.   In some contests it is mandatory to sign /P if portable.  By all means jump on stations governed by FCC rules but that is not everyone.

Regards

Tom
GM8MJV


On 19 Jul 2021, at 22:05, Karl Beckman <wa8nvw@...> wrote:

This has been well covered recently in this forum, almost to the point of becoming annoying.  Please take note and pass the word to your ham friends. 
1)  FCC RULES PART 97 DOES NOT REQUIRE OR EVEN MENTION THE IDEA OF MODIFYING YOUR ISSUED OPERATOR CALL SIGN WITH A /P, /M, OR /R SUFFIX.  It has been over 45 years since that ID method and the single licensed station location concept was abandoned by the FCC,
2)  Well meaning amateur "Elmers", PLEASE STOP teaching new hams those archaic cancelled ID rules which do not exist in Part 97. They are incompatible with the advanced digital QSO technologies available to us.  The ITU defines a reversed format for amateur DX operation outside the licensee's country which uses the host country's assigned prefix. 
3)  When operating WSJTx modes you enter your issued callsign (maximum 6 characters) and your grid square. Nothing else will fit into the highly compressed data protocols of these weak signal modes and be readable by your QSO partner at the other end.  Meanwhile, ARRL and others offering virtual QSL services have added multiple location capability into their packages, specifically to accomodate amateur operators with more than one station equipment location. 
- -

Karl  WA8NVW  OH
WA8NVW@...
in WSJTX@groups.io




locked Re: Clock Sync #Timesync

Tim
 

Hi Jim,

The fundamental error here is using 2 clocks as reference, it doesn't matter that they are both GPS.

NTP specifically requires 3 or more to arrive at correct time. But 3 is still a "single point of failure" mode since the failure of any one clock will result in there being only 2 and then NTP doesn't know who is correct. In some circumstances NTP will mark them both "insane" and use the host computer's internal clock as the reference.

Given each GPS receiver is supplying time resulting from the aggregate of 64+ clocks ( assuming I'm seeing 16 or more satellites and I'm locked to them ), you really don't need more than one GPS receiver attached to a computer.

If your view of the sky is compromised then use a GPS receiver with good hold over performance, to provide the reference time.

If you want network redundancy then build 4 or more PIs with GPS/PPS and NTP, your client devices will then have multiple sources for the time.

NTP was originally derived to take WWV, WWVB, or GOES satellite time and redistribute the time over a network for synchronising a routing protocol.

PPS abilities appeared in NTP around 1999.

Using USB 1 or 2 as the timing source introduces significant jitter into a time stamp given its polling nature.

Proper implementations over USB 3 might change that given it can use interrupts instead of polling.

Best time keeping is by using PPS over a serial port's DCD pin, or PPS to a GPIO pin on a CPU, to drive NTP and use the NMEA statements via serial or USB to let NTP time stamp the PPS it just heard. i.e. at 1PPS, a time stamp via USB can arrive within the next 59ms to let NTP know what time the PPS it heard actually was.


All that being said... a single USB/GPS receiver, and associated software, attached to your computer is generally more than enough for WSJT-X's timing requirements of +/- 1 second.


Anything more is running down the hole which is time nuttery :)


cheers

Tim

-- 
VK2XAX : QF56if : ITU59 : CQ30 : BMARC : WIA


locked Re: Operating portable #WSJTX_config #FT8

Jim Brown
 

On 7/19/2021 2:44 PM, Bill Somerville wrote:
I would not say it is a bad idea, it is a user choice. Complaining that that you can't add a gridsquare to your CQ calls if you are using a nonstandard callsign is a bad idea, as it demonstrates a poor understanding of how weak signal digimodes work.
Yes, that too. But as I observed in my response to Dana, a grid square provides far more information to others considering whether to work you and where to point their antenna than does any of those suffixes. Consider, for example, a station in California seeing a station signing /7. The US 7th area extends from Washington to Arizona, so depending on where you are in California, the beam heading varies by as much as 90-130 degrees.

And if you're contesting or calling a DX pileup on CW, SSB, or RTTY, you're both wasting time AND making it more difficult for the other station to get your call right. Ditto for those who seek preferential treatment by signing /QRP. I work a lot of QRP (170 countries confirmed), I've never done that, and I won't work stations who do.

73, Jim K9YC


locked Re: Operating portable #WSJTX_config #FT8

Bill Somerville
 

On 19/07/2021 22:41, Jim Brown wrote:
On 7/19/2021 2:33 PM, Marion D. Kitchens wrote:
Do the rules part 97 PROHIBIT using suffix?

No. But for the reasons Bill cited, doing so is a bad idea.

73, Jim K9YC

Jim,

I would not say it is a bad idea, it is a user choice. Complaining that that you can't add a gridsquare to your CQ calls if you are using a nonstandard callsign is a bad idea, as it demonstrates a poor understanding of how weak signal digimodes work.

73
Bill
G4WJS.


locked Re: Operating portable #WSJTX_config #FT8

Jim Brown
 

On 7/19/2021 2:33 PM, Marion D. Kitchens wrote:
Do the rules part 97 PROHIBIT using suffix?
No. But for the reasons Bill cited, doing so is a bad idea.

73, Jim K9YC


locked Re: Operating portable #WSJTX_config #FT8

Marion D. Kitchens
 


Do the rules part 97 PROHIBIT using suffix?  I kinda like seeing those suffizs because it offers addition information.
 
Just my 2 cents worth....
 
Marion,    K4GOK
 
On Mon, 19 Jul 2021 14:05:09 -0700 "Karl Beckman" <wa8nvw@...> writes:

This has been well covered recently in this forum, almost to the point of becoming annoying.  Please take note and pass the word to your ham friends. 
1)  FCC RULES PART 97 DOES NOT REQUIRE OR EVEN MENTION THE IDEA OF MODIFYING YOUR ISSUED OPERATOR CALL SIGN WITH A /P, /M, OR /R SUFFIX.  It has been over 45 years since that ID method and the single licensed station location concept was abandoned by the FCC,
2)  Well meaning amateur "Elmers", PLEASE STOP teaching new hams those archaic cancelled ID rules which do not exist in Part 97. They are incompatible with the advanced digital QSO technologies available to us.  The ITU defines a reversed format for amateur DX operation outside the licensee's country which uses the host country's assigned prefix. 
3)  When operating WSJTx modes you enter your issued callsign (maximum 6 characters) and your grid square. Nothing else will fit into the highly compressed data protocols of these weak signal modes and be readable by your QSO partner at the other end.  Meanwhile, ARRL and others offering virtual QSL services have added multiple location capability into their packages, specifically to accomodate amateur operators with more than one station equipment location. 
- -

Karl  WA8NVW  OH
WA8NVW@...
in WSJTX@groups.io
 


locked Re: WSJT-x signal processing versus RTTY decoding in Fldigi? #decode

Bill Somerville
 

On 19/07/2021 19:26, Bruce KX4AZ wrote:
I have always been in awe over the signal processing and error correction techniques used in the assorted WSJT-x modes....and my curiosity compels me to ask...

I wonder if any of these techniques could be applied with other modes like RTTY in programs like Fldigi.  Of course, RTTY has no error correction by design, but what about the other "tricks" used by WSJT-x for weak signal decoding?  Or do programs like Fldigi already have the latest and greatest decoding algorithms built in for weaker RTTY signals?

If this query doesn't belong in this forum, would appreciate a "re-direct" sent my way.
Hi Bruce,

simple answer, if you want weak signal efficiency then don't start with something like BAUDOT using FSK at 45.5 baud.

Of course authors of soundcard RTTY decoders have explored and implemented all sorts of smart filtering and other DSP techniques to get the best decoding performance they could. There is probably very little leeway for much better performance without changing the protocol in some way.

73
Bill
G4WJS.


locked Re: Operating portable #WSJTX_config #FT8

Bill Somerville
 

On 19/07/2021 22:05, Karl Beckman wrote:
This has been well covered recently in this forum, almost to the point of becoming annoying.  Please take note and pass the word to your ham friends. 
1)  FCC RULES PART 97 DOES NOT REQUIRE OR EVEN MENTION THE IDEA OF MODIFYING YOUR ISSUED OPERATOR CALL SIGN WITH A /P, /M, OR /R SUFFIX.  It has been over 45 years since that ID method and the single licensed station location concept was abandoned by the FCC,
2)  Well meaning amateur "Elmers", PLEASE STOP teaching new hams those archaic cancelled ID rules which do not exist in Part 97. They are incompatible with the advanced digital QSO technologies available to us.  The ITU defines a reversed format for amateur DX operation outside the licensee's country which uses the host country's assigned prefix. 
3)  When operating WSJTx modes you enter your issued callsign (maximum 6 characters) and your grid square. Nothing else will fit into the highly compressed data protocols of these weak signal modes and be readable by your QSO partner at the other end.  Meanwhile, ARRL and others offering virtual QSL services have added multiple location capability into their packages, specifically to accomodate amateur operators with more than one station equipment location. 
- -

Karl  WA8NVW  OH
WA8NVW@...
in WSJTX@groups.io

Karl,

modes like FT8, FT4, MSK144, Q65, and FST4, which all share the same basic source encoding rules, have a great deal of flexibility for nonstandard callsigns (by non-standard I mean in terms of these modes definition of a standard callsign which is more complex than "maximum of 6 characters"). If a nonstandard callsign is used with these modes then there are restrictions on what other information can be passed in standard format messages. The main restriction is that gridsquares cannot be conveyed in CQ or QRZ messages, another secondary but important restriction is that two stations with such nonstandard callsigns cannot easily work each other, yet another is that the special contest modes do not support nonstandard callsigns.

73
Bill
G4WJS.


locked Re: Operating portable #WSJTX_config #FT8

Karl Beckman WA8NVW - NNV5BH
 

This has been well covered recently in this forum, almost to the point of becoming annoying.  Please take note and pass the word to your ham friends. 
1)  FCC RULES PART 97 DOES NOT REQUIRE OR EVEN MENTION THE IDEA OF MODIFYING YOUR ISSUED OPERATOR CALL SIGN WITH A /P, /M, OR /R SUFFIX.  It has been over 45 years since that ID method and the single licensed station location concept was abandoned by the FCC,
2)  Well meaning amateur "Elmers", PLEASE STOP teaching new hams those archaic cancelled ID rules which do not exist in Part 97. They are incompatible with the advanced digital QSO technologies available to us.  The ITU defines a reversed format for amateur DX operation outside the licensee's country which uses the host country's assigned prefix. 
3)  When operating WSJTx modes you enter your issued callsign (maximum 6 characters) and your grid square. Nothing else will fit into the highly compressed data protocols of these weak signal modes and be readable by your QSO partner at the other end.  Meanwhile, ARRL and others offering virtual QSL services have added multiple location capability into their packages, specifically to accomodate amateur operators with more than one station equipment location. 
- -

Karl  WA8NVW  OH
WA8NVW@...
in WSJTX@groups.io


locked Re: Clock Sync #Timesync

Alan <n5pa@...>
 

Joe:

I am completely agree with you!  And in my unscientific means, it works well enough to keep your time for WSJT-X working. It may not be as accurate as a yottasecond (Ys or 10 to the 24th), but it is accurate enough to work with WSJT-X, and as that is all that matters!

73,
Alan Clark, N5PA
Ellisville, MS
Email:  n5pa@...
URL:  http://www.n5pa.com

On Jul 19, 2021, at 11:55 AM, Joe <joe@...> wrote:

Hi Jim,

"If one assumes the velocity factor of a USB cable is about 80%, that means about 250 microseconds of propagation delay per meter."

Let's see...  the speed of light is 3 x 10^8 m/s, so the delay in a 1 meter cable is 1.0/(0.8x3x10^8) = 4.2 x 10^-9.  I make it around 4 nanoseconds, not 250 microseconds.  But you're certainly right, the cable delay is well under a millisecond.  :-)

  -- 73, Joe, K1JT



locked WSJT-x signal processing versus RTTY decoding in Fldigi? #decode

Bruce KX4AZ
 

I have always been in awe over the signal processing and error correction techniques used in the assorted WSJT-x modes....and my curiosity compels me to ask...

I wonder if any of these techniques could be applied with other modes like RTTY in programs like Fldigi.  Of course, RTTY has no error correction by design, but what about the other "tricks" used by WSJT-x for weak signal decoding?  Or do programs like Fldigi already have the latest and greatest decoding algorithms built in for weaker RTTY signals?

If this query doesn't belong in this forum, would appreciate a "re-direct" sent my way.

10021 - 10040 of 36728