> > 3. I have been seeing a lot of bragging about 1 new rig where
> > you can get 30 cycles next to another station and not be bothered
> > by them. But, you do bother us.
>
> I think I know which rig you are talking about since it is
> one of the transceivers that I own.
>
> If it is this particular model, the situation that you have
> witnessed is compounded by the problem that this rig is known
> to [[ currently ]] put out an abnormally wide spectrum of RTTY
> keyclicks, created by glitches in the FSK envelope. I have
> measured it myself under controlled conditions. It will improve
> over time, but you have to live with it for now.
The issue is with AFSK not FSK. The first fix was released in
the pubic beta software (MCU 2.82/DSP 2.00) dated 9 Feb 2009
and includes a transmit BPF (CONFIG:AFSK TX).
Additional improvements to the DSP modulation are present in
the current limited beta that have fixed the interaction with
DUAL PB that was causing the DSP glitch.
Of course none if this makes any difference if your old
receiver folds when another station moves in 100 Hz away.
73,
... Joe, W4TV
> -----Original Message-----
> From: rtty-bounces@contesting.com
> [mailto:rtty-bounces@contesting.com] On Behalf Of Kok Chen
> Sent: Sunday, March 01, 2009 1:45 PM
> To: RTTY Reflector
> Cc: Tom Osborne
> Subject: Re: [RTTY] Fun, but
>
>
> On Mar 1, 2009, at 9:07 AM, Tom Osborne wrote:
>
> > 1. Please put a 'CQ' or 'NA' or whatever on the end of your CQ.
> > People
> > tune across your signal and hear 'W1ABC K'. We don't know
> if you are
> > calling someone, ending a CQ, or just finishing up working
> someone.
> > A 'CQ'
> > on the end takes care of that.
>
> This has always been a problem, but one that can be fixed in the
> software modems without the need for "behavioral
> modification" of the
> newbie contest ops.
>
> You just need to get your favorite software author to include
> a "tape
> loop" and a "replay" function (that replays at a high speed,
> to catch
> up with real time) to their program.
>
> It won't work of course if you are constantly moving the VFO knob
> instead of allowing the DSP to do that work for you. The software
> also needs to be frequency agile.
>
> An "RTTY Skimmer" will solve the problem completely, of
> course (until
> some RTTY contest manager puts a stop to it :-).
>
> > 2. I know some people don't like to do it, but put the callsign of
> > the
> > station you are working at the end of the macro. LOTS of times
> > someone came
> > back to me when they were CQ'ing, but were covered up at the start
> > by people
> > still calling them, and I had no idea who they were coming
> back to.
> > All I
> > get is $%!()^&)Joe CO k. Then they had to wait and send the
> > exchange again
> > so I could see who they were working.
>
> That is very good recommendation. In addition to QRM, there is a
> second place where this is useful -- when you are receiving with
> slowish AGC. I don't know how many people have observed this, but
> quite often I have seen the first few characters from a
> strong station
> get garbled due to mis-detection of the first start bit. After a
> couple of garbled characters, the rest of the exchange will print
> perfectly.
>
> > 3. I have been seeing a lot of bragging about 1 new rig where you
> > can get
> > 30 cycles next to another station and not be bothered by them.
> > But, you do
> > bother us.
>
> I think I know which rig you are talking about since it is
> one of the
> transceivers that I own.
>
> If it is this particular model, the situation that you have
> witnessed
> is compounded by the problem that this rig is known to [[
> currently ]]
> put out an abnormally wide spectrum of RTTY keyclicks, created by
> glitches in the FSK envelope. I have measured it myself under
> controlled conditions. It will improve over time, but you have to
> live with it for now.
>
> In the meantime, I have myself avoided transmitting through this rig
> (so has another long time RTTY contester) -- you just need to
> persuade
> the others to refrain from using this rig on RTTY until the
> problem is
> fixed. There was an earlier firmware release by the
> manufacturer that
> only patched the symptom, but not the cause -- so it didn't fix all
> cases.
>
> 73
> Chen, W7AY
>
_______________________________________________
RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty
|