[Elecraft] P3 bug

[Joe Subich, W4TV]

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-bounces at mailman.qth.net] On Behalf Of
>>>> Jim Brown
>>>> Sent: 29 December 2014 17:09
>>>> To: elecraft at 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