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.

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

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

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

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

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

Karl

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

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

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.

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



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.

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.

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

Joe:

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.