I’m fairly new but have been running WSJT-X on my IC-735 via a MFJ-1204 interface for FT8. Everything seems to work fine and as expected on 10m-80m with the exception of when I try 20M. When I tune or

#FT8 #BugReport

Today I came across an issue I haven't had with past releases. I use the "Tune" function, when changing bands, to tune the LDG antenna tuner with my TS-590s. Today when I hit the tune, the radio keyed

#BugReport

Saw more than a few false decodes (AKA as "Ghosts") yesterday -- not balloons. I've seen WSPR-2 "Ghosts" from time-to-time on other releases, but there were about 20 seen yesterday. 73 Bob K4RCG

#BugReport

Problem has been resolved in RC 3

#BugReport

Stopping dead does not sound like the same problem that I am seeing. Do you mean that everything halts completely or that you see alternating rx sequences that are being cut short like I see. Ken KC6P

#BugReport

Tnx Bill....it sure would be nice if it would TUNE (for the RF-sensed auto ATU) on every band hop UNLESS "RX ONLY" was ticked. When using multiband antenna with auto ATU, the TUNE burst would be great

#BugReport

Hi Bob, WSJT-X only transmits on bands scheduled for transmit. It does that on the assumption that you may not be licensed to transmit on bands not set to Tx in the schedule. 73 Bill G4WJS.

#BugReport

When "hopping" in WSPR-2, TUNE (in hopping "Schedule") does not always TX upon band change. Sometimes it does, and sometimes it does not. Desired state would be to have the TUNE function always TX upo

#BugReport

Yep RC3 it stops dead after a long run, not seen this before on any previous version Peter M0PWX From: Kenneth Williams By going through the sequence of disabling 'Monitor' then re-enabling 'Monitor'

#BugReport

My machine: Windows 7, 64-bit WSJT-X Version 2.4.0-rc3 Current mode: FT8 By going through the sequence of disabling 'Monitor' then re-enabling 'Monitor' some time later, the waterfall display will hal

#BugReport

This appears to be resolved in RC3

#BugReport

This appears to be resolved with RC3

#BugReport

Normally, if you are working MS, it is understood that RR73 will not be used. It is the nature of MS that the other station will possibly, or even probably, not receive your RRR and you’ll need to rep

#raspberryPi #BugReport

Hi Larry, Generally, no one resends an RR73 unless they received a repeated SNR report or a fat finger situation. If you received a repeated SNR report it is an indication that they did not receive yo

#raspberryPi #BugReport

Hi Bill, Sorry if I oversimplified the situation, and I now realize when I responded that Carlos was discussing an MS Q. At least for normal FT8 Qs, I assume that hams only send RR73 when they do not

#raspberryPi #BugReport

Yes and No. When both sides of the QSO copy RRR or RR73, yes, the QSO is over. That's fine when both stations are loud and clear. But RR73 is not a great choice for MS, because it's common for such QS

#raspberryPi #BugReport

OK, well, Reino, I will do how the Software do and will be almost right. Good evening, 73, Karl Am 11.03.21, 18:53 schrieb Reino Talarmo <reino.talarmo@...>:

#raspberryPi #BugReport

Larry, that is a gross oversimplification. Sending an RR73 message is preferred only when repeats are unlikely to be needed, when making MS QSOs repeats are almost certainly required. Aside from that,

#raspberryPi #BugReport

Thanks a lot Larry ! 73, Karl Am 11.03.21, 18:43 schrieb "Larry Banks via groups.io" <larryb.w1dyj@...>:

#raspberryPi #BugReport

Hi Karl, You may study User Guide section 8.6. last paragraph shows typical minimum QSO message exchange sequence. In your case the other operator has used RR73 instead of RRR, which is ok. A you see

#raspberryPi #BugReport