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:[email protected]] >>> Sent: Sunday, January 01, 2012 11:31 AM >>> To: [email protected] >>> 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:[email protected] >>> >>> 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:[email protected] >> >> 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:[email protected] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html
