I just tried it with an external keyer. Same results.
On 29 Dec 2014 23:07, Joe Subich, W4TV wrote:
Have you tried using an external keyer? I can not reproduce the bug
here but I'm using an external keyer. Perhaps the internal keyer adds
enough stress to the processor to cause a delay that exceeds a "knee".
73,
... Joe, W4TV
On 2014-12-29 4:01 PM, Vic Rosenthal 4X6GP/K2VCO wrote:
Right, but I conclusively proved that this is not the (only?) cause by
reproducing the bug without any applications running on my computer that
access the K3.
On 29 Dec 2014 22:58, Joe Subich, W4TV wrote:
It only happens here when the logging program (N1MM+) is active,
which suggests it is related to traffic on the RS232 link - perhaps
some kind of data collision which is being resolved by timeouts.
N1MM Logger (both Classic and Plus) is extremely aggressive in its
polling - something like 7 or 9 "GET" items - including FA; FB; and IF;
all at once every 300 ms. Add a second polling source - e.g. the P3 -
and the chance of collision, timeout, and/or buffer overflow gets
fairly substantial rather quickly.
73,
... Joe, W4TV
On 2014-12-29 3:32 PM, Ian White wrote:
On Mon,12/29/2014 7:35 AM, Joe Subich, W4TV wrote:
I have never seen this but I don't have the SVGA.
Nor have I. Perhaps an RF issue?
73, Jim K9YC
I have the same problem and it does occur in TEST mode so it isn't RF.
It is also a problem of long standing, not related to any recent
firmware upgrade.
The displays (both P3 and SVGA) hang at very irregular intervals, on
average about once in maybe 10-20-30 returns to TX. Sometimes the
displays freeze for only about a second, but sometimes for as long
as 10
seconds or even more. I also have the impression that the problem
sometimes occurs in 'streaks' when the probability seems much higher.
Unfortunately the problem cannot be created on demand, only by repeated
TX-RX cycling, but it does not seem to happen at all with purely manual
keying.
It only happens here when the logging program (N1MM+) is active, which
suggests it is related to traffic on the RS232 link - perhaps some kind
of data collision which is being resolved by timeouts. I have the
impression that the displays become more likely to hang when the VFOB
knob is rotated while transmitting on VFO A, which will feed a backlog
of data into the RS232 link or its buffers. (FYI, my RS232 link uses
the hardware COM1 port on the PC motherboard and the PC-P3-K3 chaining
is exactly as specified in the manuals; the whole link functions
perfectly in every other respect.)
Although the problem seems to require that the logging program is
running, it does not seem to be directly related to the source of CW
and/or PTT. The problem occurs with manual keying and VOX, just as
often
as it does with keying from N1MM+ (DTR=CW, RTS=PTT).
The same problem also occurs on RTTY but I'm not sure about SSB.
73 from Ian GM3SEK
-----Original Message-----
From: Elecraft [mailto:elecraft-boun...@mailman.qth.net] On Behalf Of
Jim Brown
Sent: 29 December 2014 17:09
To: elecraft@mailman.qth.net
Subject: Re: [Elecraft] P3 bug
On Mon,12/29/2014 7:35 AM, Joe Subich, W4TV wrote:
I have never seen this but I don't have the SVGA.
Nor have I. Perhaps an RF issue?
73, Jim K9YC
______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:Elecraft@mailman.qth.net
This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to k2vco....@gmail.com
--
Vic
______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:Elecraft@mailman.qth.net
This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to arch...@mail-archive.com
