Re: Winkey PTT momentary dropout


Ken G0ORH
 



Ken.. G0ORH



On 11 Nov 2015, at 02:00, 'Joe Subich, W4TV' lists@... [N1MMLoggerplus] <N1MMLoggerplus@...> wrote:

 


> I am running W10, the latest version of N1MM+, K3s, and the Microham
> MK2R+.

Yes, I can duplicate the behavior with MK2R+ running Winkey2 v.22. The
MK2R+ shipped with WK2 v.21, v.22 or v.23 depending on which chip was
current at the time of manufacture. I'm fairly sure the issue is due
to Winkey PTT handling in host mode in v.21 and v.22 exacerbated by the
buffer handling (longer than normal word space at buffer update) in the
application.

The issue should not be present in the older "single radio" Winkey V.10
chips or WK2 v.23. WK V.10 applies a minimum wordspace delay before
releasing PTT (regardless of the PTT hang setting) and v.23 "holds" PTT
while sending a "space" (20h). WK2 (v.21 and .22) did not apply any
minimum delay for host data which results in a PTT dropping when PTT
hang is set very short and a space is encountered in the host data.
v.23 "holds" PTT during the space (20h) which generally provides enough
time for the application to load additional characters into the buffer.

For all microHAM interfaces containing Winkey, the Winkey chip is in a
socket and can be updated by installing a new chip. Single radio
interfaces use WK v.10, MK2R+ and micro2R can be upgraded to WK2 v.23.
WK2 v.30 is not supported in microHAM devices (and is not directly
interchangeable with V.21, 22, or 23, AFAIK).

73,

... Joe, W4TV

On 11/10/2015 6:42 PM, Richard King k5na@... [N1MMLoggerplus] wrote:
> I had the same problem this weekend.
>
> I may be confused, but I don't think it has anything to do with PTT delay.
> My problem I would call a PTT glitch, not a drop out. I think the problem
> was the length of the message.
>
> My exchange was "nnnn U K5NA 58 STX".
>
> The glitch (in run mode) always happened right at sending the "S" in STX.
>
> I tested by changing the length of the message. I first started taking the
> spaces out of the message one at a time. I would move the glitch out one
> character for every character removed. After removing 3 or 4 spaces in the
> message, there were no more glitches.
>
> The I started adding spaces to the message. For every space I added, I
> moved the glitch closer to the front of the message. It is very much
> dependent on the length of the message.
>
> I am running W10, the latest version of N1MM+, K3s, and the Microham MK2R+.
>
> I hope this information is useful.
>
> 73, Richard - K5NA
>
> On Tue, Nov 10, 2015 at 10:08 PM, 'Joe Subich, W4TV' lists@...
> [N1MMLoggerplus] <N1MMLoggerplus@...> wrote:
>
>>
>>
>>
>>
>> On 11/10/2015 4:44 PM, gbyahoo@... [N1MMLoggerplus] wrote:
>>> Joe,
>>>
>>> My point is that the 70 msec fixed tail length is substantially less
>> than the 1.0 wordspace timeout it is replacing. A wordspace is 7 dits long,
>> which at 30 wpm is about 280 msec.
>>
>> It depends entirely on which version of Winkey is in use. Some
>> versions have a fixed one word space timeout *plus* the fixed tail,
>> some have no timeout plus the fixed tail, some behave one way for
>> paddle sent CW and differently for machine (host interface) generated
>> CW.
>>
>> Again, one can not tell unless he is looking at a time stamped capture
>> of the data interaction between the host application and the Winkey
>> chip. That said, I can not duplicate the issue using a Winkey v.10
>> chip with PTT Tail set to a constant 10 ms, and a 100 character
>> message.
>>
>> 73,
>>
>> ... Joe, W4TV
>>
>>>
>>>
>>>>> Gerald, VE1DT
>>>
>>>
>>>
>>> ---In N1MMLoggerplus@..., wrote :
>>>
>>> On 11/10/2015 3:22 PM, gbyahoo@... mailto:gbyahoo@... [N1MMLoggerplus]
>> wrote:
>>>>
>>>> If that were the case, then why does a 70 msec timeout work?
>>>
>>> It just might be that 70 ms is enough extra fixed tail delay to prevent
>>> PTT from dropping before the next "chunk" of data arrives. One would
>>> only know by analyzing the interaction (data) between the application
>>> and Winkey.
>>>
>>> 73,
>>>
>>> ... Joe, W4TV
>>>
>>>
>>> On 11/10/2015 3:22 PM, gbyahoo@... mailto:gbyahoo@... [N1MMLoggerplus]
>> wrote:
>>>> Joe,
>>>>
>>>> If that were the case, then why does a 70 msec timeout work? I think
>> you might be confusing yourself by leaving out part of Dave's post results.
>>>>
>>>>
>>>> Logger Classicbehaves the same way.
>>>>> Using the same macro, and tail time set to 7 (.07 sec), there are
>>>>> no dropouts. I don’t know exactly what’s going on, but I’ll just
>>>>> stick with .07 sec vox delay. That’s quick enough.
>>>>
>>>>
>>>>
>>>>>> Gerald, VE1DT
>>>>
>>>> ---In N1MMLoggerplus@... mailto:
>> N1MMLoggerplus@..., wrote :
>>
>>>>
>>>>> With a 90 character macro, and tail time set to zero, Winkey PTT
>>>>> drops after about characters 30, 46, 62, and 80 from the start.
>>>>> Logger Classic behaves the same way.
>>>>
>>>> That sounds like a buffer management issue in the N1MM Logger code.
>>>>
>>>> The original Winkey chip had a 32 character buffer - IIRC N1MM sends
>>>> 30 characters followed by groups of 16. I'd bet it is waiting too
>>>> long between "chunks" at higher speeds rather than processing the
>>>> characters as sent/echoed by the Winkey chip to keep track of what
>>>> has been sent.
>>>>
>>>> 73,
>>>>
>>>> ... Joe, W4TV
>>>>
>>>>
>>>> On 11/10/2015 1:22 PM, 'Dave Hachadorian' k6ll.dave@... mailto:
>> k6ll.dave@...
>>>> [N1MMLoggerplus] wrote:
>>>>> I’ve been experimenting some more this morning.
>>>>> With a 90 character macro, and tail time set to zero, Winkey PTT
>>>>> drops after about characters 30, 46, 62, and 80 from the start.
>>>>> Logger Classicbehaves the same way.
>>>>> Using the same macro, and tail time set to 7 (.07 sec), there are
>>>>> no dropouts. I don’t know exactly what’s going on, but I’ll just
>>>>> stick with .07 sec vox delay. That’s quick enough.
>>>>> PTT via radio command also is working fine this morning. There was
>>>>> a reason why I switched away from that, but I can’t remember
>>>>> exactly what it was. I think maybe it was dropping out completely
>>>>> at random times. Maybe I’ll try it again in the next contest.
>>>>>
>>>>> Dave Hachadorian, K6LL
>>>>> Yuma, AZ
>>>>>
>>>>>
>>>>
>>>
>>
>>
>>
>

Join N1MMLoggerPlus@groups.io to automatically receive all group messages.