Hi Team,
Change Request: Do not reset an in-progress QSO from TX3 to TX1 when your
called station responds to another station on the same RX frequency with RRR or
RR73. Stations often interleave multiple QSOs resulting in a situation where
you are sending TX3, but the partner is sending TX4 (
.cbr freq data shd be..
50
144
432
Not..
50314
144175
432500
Nor even..
50.314
144.175
432.500
BCNU DE N2LO~>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Hi George, Hasan, and all,
On 1/21/2019 17:09, Hasan al-Basri wrote:
I agree, George, CM worked wonderfully. Processing my log for ARRL was a
complete pain. The cab file has full freq in it, and ARRL won't accept
it in the upload. So I had to edit the file. The file had full freq and
ARRL woul
On 21/01/2019 22:09, Hasan al-Basri wrote:
I like your suggestion about just real time export to N1MM. I may ask
you about how to do that in more detail in the future.
I will say this, based on this contest (which I thoroughly enjoyed!),
if I have to go through what I did to submit a log in th
I agree, George, CM worked wonderfully. Processing my log for ARRL was a
complete pain. The cab file has full freq in it, and ARRL won't accept it
in the upload. So I had to edit the file. The file had full freq and ARRL
would only accept 50 (for 6m)
I like your suggestion about just real time e
> On Jan 21, 2019, at 13:19, Paul Kube wrote:
>
> yes; but letting auto seq run works just fine most of the time. Toggling
> Enable off only to toggle it on at the beginning of the next cycle is very
> often superfluous.
Don’t forget - it is fine to start several seconds late in the sequenc
On 1/18/2019 5:22 AM, Jari A wrote:
Did I experience another hash error?
Looking at the screen grab shows that the station is signing /QRP. I
work a lot of QRP, but I never sign /QRP, and I won't work a station
signing /QRP. I see it as the station asking for special treatment.
Far more imp
> Try turning it on its head, Paul. Pre-decide NOT to transmit on the
*next* cycle by deselecting
> Enable Tx during the *current* cycle … unless you spot something in the
decodes that
> makes you change your mind, in which case you reselect Enable Tx.
Hi Gary, yes; but letting auto seq run wo
I just had a funny hash collision. Was calling , got - for what
reasons ever - a reply " DG2YCB", clicked on that and then started
a QSO with myself (which I of course stopped):
190121_194115 Transmitting 1.84 MHz FT8: DG2YCB
190121_194145 Transmitting 1.84 MHz FT8: DG2YCB
194145 -24
Jari, This seems to be a known issue. See
https://sourceforge.net/p/wsjt/mailman/message/36518222/.
73, Paul K6PO
On Fri, Jan 18, 2019 at 5:26 AM Jari A wrote:
> Did I experience another hash error?
>
> Had one previously, but thought it was a glitch, now I had this again:
> Just to let you kno
Yes. The likely cause is failure to implement proper chassis-to-chassis
bonding between all station equipment, including the computer and
computer audio interface. It is also important that all station
equipment get power from the same outlet or outlet box, or, if from
different outlets, the fr
What a great pleasure to work contest mode this time — kudos to the dev team
for a HUGE improvement.
Tricky thing is that the “Contest Log” shows only contacts for that particular
profile. So with one or more -rig setup, a unique log is generated.
Understandable, but inconvenient. Probably best
On 21/01/2019 01:34, Bill Somerville wrote:
Hi Barry,
we can't automatically account for device names changing due to an o/s
upgrade. If there are more than one i/p and o/p audio device then
changing to another and back to whatever the rig audio devices are in
the WSJT-X settings should sort
Hello,
Although, there were multiple contacts in today’s, and yesterday’s event, to be
the primary mode – as it appears to be with no SSB posts – it needs a duplicate
noting feature. I attempted a contact with K1JT with no success, but that’s
understandable. I like the mode, and it brought me
Hi WSJT team
We (DL3GA, F1ULQ) are just on the last miles on the way home from 9LY1JM.
While in Sierra Leone, we uploaded the FT8 to ClubLog and instantly received reports about missing QSOs.
It turned out that roughly 10 percent of the QSOs were in the FoxQSO.TXT but not in the original A
Perhaps the development team could consider an option for VHF and above to
only report the strongest signal in the case of multiple decodes of the
same station. The option would be user selectable. Just a suggestion.
On Mon, Jan 21, 2019, 11:11 AM Philip Gladstone <
pjsg-w...@nospam.gladstonefamil
Thanks for all the comments -- I think that these particular cases are due
to power line issues. [And I had forgot about the non-standard callsign
issue.]
Philip
On Mon, Jan 21, 2019 at 10:59 AM Joe Taylor wrote:
> On 1/21/2019 10:49 AM, DG2YCB, Uwe wrote:
> > Interesting is the following: Same
On 1/21/2019 10:49 AM, DG2YCB, Uwe wrote:
Interesting is the following: Same station, same equipment, same
settings, same signal level, just a couple of minutes later. Maybe DD7…
has his antenna in a more direct direction?
The aircraft reflection that had caused the Doppler-shifted signal in
Hi Philip,
Our policy is to report all decodes that include a grid square, as we
receive them. Multiple decodes of the same transmission by the same
receiving station are most frequently caused by:
1. Low-level sidebands offset in frequency by multiples of the
power-line frequency. Usually
On 21/01/2019 03:33, Philip Gladstone wrote:
WE6Z reported seeing KG7VOR twice at Jan 21, 2019 03:03:29. The only
differences were:
One entry had Frequency 1841279 with snr -15
Another had Frequency 1841400 with snr of 13
In fact there were 9 spots of KG7VOR in the same packet (at five
differ
The fact that the two signals are almost exactly 120Hz apart indicates that
60Hz power noise is mixing with the audio somewhere on the signal path.
Since it sounds like multiple people are hearing ghosts from that one station,
my bet would be that the problem is with the transmitted audio.
On J
21 matches
Mail list logo
