[Elecraft] K3: data modes - bizarre behavior

Sun Jan 1 16:25:08 EST 2012

Thanks, Joe.  I've been with MARS for a few years now and understand
the "channel center" frequency matrix.

This is a case where the string setting the K3's carrier freq is
setting the correct value.  There is something odd at work here.

matt

On Sun, 01 Jan 2012 15:47:51 -0500, you wrote:

>
>Matt,
>
> > I verified that the software is setting the correct carrier freq,
> > based on the center freq cited by the MARS frequency matrix.  I was
> > thinking along the same lines as your suggestion below.
>
>Standard practice in government operation - including MARS in recent
>years - is to specify the "center of channel" and *not* the USB dial
>frequency.  The two frequencies will differ by 1400 to 1500 Hz based
>on the particular assumptions used for the transmitter with 1500 Hz
>being slightly more common.
>
>I suspect you will find your MARS matrix specifies "center of channel"
>for all digital and any remaining CW networks while still giving USB
>suppressed carrier frequency for voice networks.
>
>73,
>
>    ... Joe, W4TV
>
>
>On 1/1/2012 2:25 PM, Matt Zilmer wrote:
>> Thanks for your reply, Bill.
>>
>> I verified that the software is setting the correct carrier freq,
>> based on the center freq cited by the MARS frequency matrix.  I was
>> thinking along the same lines as your suggestion below.
>>
>> If I use program control to set the freq, then I get TX + 1.5 KHz =
>> RX.  This is with split disabled and RIT / XIT turned off.
>>
>> Temporarily, I'm manually setting the carrier freq to 1.5 KHz below
>> center instead of relying on the control program to do this.  That
>> solved the problem, but doesn't explain why the radio has carrier freq
>> centered on the freq only under program control.
>>
>> Mysteries....
>>
>> 73,
>> matt W6NIA / NNN0UET
>>
>>
>>
>> On Sun, 01 Jan 2012 13:21:51 -0500, you wrote:
>>
>>> Well, this is normal for digital mode DATA A.  I'm not familiar with your
>>> particular software, but for PSK31 and similar modes, the K3 VFO A is set to
>>> a frequency for the carrier.  The audio is on the upper sideband, and is
>>> centered in the 3 KHz passband which is 1.5kHz up from the carrier.  Thus
>>> the offset.  Some digital software has an allowance for an offset, but I'm
>>> not sure about yours.  You might check on this.
>>>
>>> Typically if operating on 20 meters with radio set to 14.070MHz, the
>>> waterfall will be full of traces at audio frequencies spread across the
>>> passband of your radio.  So you actual transmission freq is the sum of VFO
>>> plus the audio.
>>>
>>> ...bill  nr4c
>>>
>>> -----Original Message-----
>>> From: Matt Zilmer [mailto:mzilmer at verizon.net]
>>> Sent: Sunday, January 01, 2012 11:31 AM
>>> To: elecraft at mailman.qth.net
>>> Subject: [Elecraft] K3: data modes - bizarre behavior
>>>
>>> In all this time with K3 #24, I've never been stymied by any issue
>>> such as described below.
>>>
>>> I'm a Navy-Marine Corps MARS member.  We use RMS Express in the WL2K
>>> system on HF, running WL2K Winmor mode  The software I have is version
>>> 1.1.3.0.
>>>
>>> I also use LP Bridge to create two COM ports: one used for DTR (PTT)
>>> and the other for control, COM19 and COM20 respectively.  The sound
>>> card is an EMU 0202.
>>>
>>> The problem is this:  When RMS Express takes control of the K3,
>>> calling an RMS node on HF *always* results in the receive frequency
>>> being 1.5 KHz too high.  I've had to rotate the RIT between call-up
>>> transmissions to get the RX on frequency before the initial 5 attempts
>>> time out.  The TX frequency seems dead-on, because the RMS always
>>> answers - but RX is 1.5 KHz high.  And yes, I've tested with multiple
>>> RMS nodes, including my own NMCM RMS here at the shack.  Same problem
>>> occurs with each, so it's a setup issue with software or the K3 here.
>>>
>>> RMS Express sends the following commands after it's set the COM20 comm
>>> parameters:
>>>
>>> 	FR0;	# cancel split
>>> 	RT0;	# RIT OFF
>>> 	XT0;	# XIT OFF
>>> 	MD6;	# TX DATA mode
>>> 	DT0;	# DATA A sub-mode of TX DATA
>>>
>>> The sequence above is sent once at the beginning of an RMS Express
>>> call-up of the remote node.  Only COM19's DTR is used to assert PTT
>>> for transmissions.
>>>
>>> Just for grins, I checked the various meta-modes the K3 is in.  I
>>> discovered that even though AI is set to ZERO, I'm still getting IF
>>> annunciations back from the K3.  Odd, that.
>>>
>>> 	K31;	# K3 extended commands enabled
>>> 	K22;	# K2 extended " "
>>> 	AI0;	# AUTOINF OFF
>>>
>>> Since split and the incremental controls are off and ZEROed, I'm
>>> totally blind to what's going on.  VFO A is on the correct frequency
>>> in each case (for each RMS Node), which means to me that RX and TX
>>> actual frequencies should be the same.
>>>
>>> Any ideas what's causing this?
>>>
>>> 73 and HNY,
>>> matt W6NIA, NNN0UET
>>>
>>>
>>> ______________________________________________________________
>>> Elecraft mailing list
>>> Home: http://mailman.qth.net/mailman/listinfo/elecraft
>>> Help: http://mailman.qth.net/mmfaq.htm
>>> Post: mailto:Elecraft at mailman.qth.net
>>>
>>> This list hosted by: http://www.qsl.net
>>> Please help support this email list: http://www.qsl.net/donate.html
>> ______________________________________________________________
>> Elecraft mailing list
>> Home: http://mailman.qth.net/mailman/listinfo/elecraft
>> Help: http://mailman.qth.net/mmfaq.htm
>> Post: mailto:Elecraft at mailman.qth.net
>>
>> This list hosted by: http://www.qsl.net
>> Please help support this email list: http://www.qsl.net/donate.html
>>