I have a Dell XPS9100 Circa 2012 which I've upgraded over the years with
SSD, new graphics card, additional HDD, PCI Serial Ports, USB3.0. It lacks
AVX instructions, which I found out when I tried to GPU-accelerate
TensorFlow. It is a lot slower than my work laptop.
73,
Chris VE3NRT
Joe K1YOW I was given that tip before but at times I wanted to see the
previous set of decodes so I found it very frustrating, but the suggestion
has clued me into something - possibly.
I saw the problem several times tonight running on 80M FT8. While I don't
like the "start new period decodes on
I see this almost every time I operate - last time was 30 minutes ago. Not
specific to 20m. It happens when TX and RX frequencies are different. A
double click on the left pane calls the last station heard on the right pane
whether it was calling CQ or not. A second double click fixes it but it
74c-2739-06f280887...@classdesign.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 23/06/2020 02:11, Chris Sullivan wrote:
> Windows-10 V2.2.0
>
> I had been idly listening to 6m FT8 and saw that a strong station is
> not being displayed in the band activity win
Windows-10 V2.2.0
I had been idly listening to 6m FT8 and saw that a strong station is not
being displayed in the band activity window even though JT-Alert is
displaying the call.
So the 'blank line' between periods displays but no decodes appear
in-between, which I've never seen before. The
6m was wide open yesterday with 10 to 20 decodes per cycle on FT8. On my 8
year-old desktop system I had to change from deep to normal to finish
decoding before my transmission ended (which makes me wonder how hard it
would be to implement multi-threading as I have 6x2 cores but WSJT-X only
seems
I've seen this a couple of times before on RC1, Windows 10-64.
I responded to a CQ from VE3VN (Hold TX set, also auto seq & call 1st). Just
after my transmission began I halted tx because I noticed he had called CQ
WC, which I guess isn't me. Then I saw, in red in the band activity window,
VE3VN
Maybe just add an option to display RRR 73 whenever the RRR message is
received, and to show RRR as RRR 73 on the transmit side, without actually
changing the protocol. I’m not up on the structure of the JT65 messages but I
suspect that RRR is just a single bit set somewhere in the message, or
I think the answer to this is simple. All it requires is that all JT mode
programs print RRR 73 when (sending and) receiving the standard RRR
message. It's just a sequence of bits after all, and not the actual text
RRR. Then the calling station could feel happy that they've sent 73 to the
