WriteLog
[Top] [All Lists]

Re: [WriteLog] PTT to CW delay apply to FSK?

To: writelog@contesting.com
Subject: Re: [WriteLog] PTT to CW delay apply to FSK?
From: Ron Lodewyck <RLodewyck@csustan.edu>
Reply-to: RLodewyck@csustan.edu
Date: Sat, 21 Jan 2012 15:08:11 -0800
List-post: <writelog@contesting.com">mailto:writelog@contesting.com>
Mike, et al,

What I am asking for is a change in the software - Writelog in 
particular - so that Writelog first asserts the PTT line and tells the 
transmitter to turn on.  This will, as you say, generate a continuous 
carrier (Mark signal).  Then, after a specified time interval of xx 
milliseconds, Writelog would then start sending the characters and the 
frequency shift keying would then begin.

The idea is to allow time for the transceiver and/or amplifier, to be 
fully stable BEFORE starting the character sequence.  The point is to 
ensure that the receiving station is able to synchronize from the very 
first START bit.

Joe,
As for the MicroHam USB II interface, we were using this interface at 
PJ2N in the RTTY RU when this synchronization issue surfaced.  We were 
keying a Ten Tec Titan II amp at about 600 watts when we started 
receiving reports that the first few characters of every message were 
garbled.  We tried the Writelog CW Delay parameter, but it had no 
discernible effect - we still received reports of garble on the first 
few characters.  But I am unaware of how the MicroHam keys the amp 
independently from the transceiver.  How would I do this?

After a fair amount of experimenting, I have come to the conclusion that 
the front end garble is a synchronization issue.  But I now see that 
there are two ends to the issue:

--- on the transmit end, it is essential that the text (i.e. the 
character bit patterns) not be sent to the transceiver until the 
transceiver and amp, if used, is fully transitioned and sending stable 
RF.   MMTTY does have a command which can be inserted into a Macro 
message which can "Send a Mark Signal".  This can effectively add the 
necessary delay and my experiments show that it does the trick.  But 
there is no similar way to insert such a command in a Writelog message 
(that I am aware of).  Also on the transmit side, it is possible to 
improve synchronization by adding diddles - but in a contest exchange, 
the first character of the message is sent immediately and no diddle 
(LTRS usually) characters precede the message.  So the diddles only help 
(I think) if there is an idle period (no text in the buffer).

---on the receive end, the signal has to be clear enough for the 
decoding algorithm to be able to sense the START bit correctly.  Things 
that can mess this up are weak signal, QRN, QRM, mis-tuning, and too 
high of a squelch setting (to name a few).  BTW, I found the SQL setting 
as well as the sound card input level to be fairly critical.  It took a 
bit of experimenting with these two controls until I was able to 
eliminate the vast majority of front end synching problems and tail end 
random characters appearing on the screen.

What exactly was going on with our PJ2N RTTY signal before the contest 
started is still a bit of a mystery, but adding two spaces, a CR/LF, and 
another space before the exchange text seemed to solve the 
synchronization problem and cleared up the garble.  But it also slowed 
us down and should have been unnecessary.  I'd like to see a way to 
reduce the likelihood of synchronization problems by adding a RTTY DELAY 
parameter to Writelog, MMTTY, N1MM, and any other RTTY program, so that 
those who feel they would like it could use it.  The delay period 
doesn't have to be long and the continuous Mark signal would help ensure 
synching up with the first character START bit.

73,
Ron N6EE

On 1/21/2012 2:25 PM, Mike McCarthy, W1NR wrote:
> The delay would have to be in the rig. When my Icom ProIII and similar
> rigs are in FSK mode, as soon as PTT is applied, the carrier comes on
> soon after. Unlike CW, which is on/off keying, the only keying that gets
> done is the "shift" for the mark/space elements. There is no way to
> apply external delay as the carrier is on all the time.
>
> On 01/20/2012 10:51 PM, Don Hill AA5AU wrote:
>> I'm wonder if the PTT to CW delay also applies to FSK?  Does anyone know 
>> this?  It would seem that it would since perhaps both may
>> be keyed from a serial port when using PC generates.  Seems like it's the 
>> same thing only one uses DTR (CW) and the other TxD (FSK).
>>
> _______________________________________________
> WriteLog mailing list
> WriteLog@contesting.com
> http://lists.contesting.com/mailman/listinfo/writelog
> WriteLog on the web:  http://www.writelog.com/
_______________________________________________
WriteLog mailing list
WriteLog@contesting.com
http://lists.contesting.com/mailman/listinfo/writelog
WriteLog on the web:  http://www.writelog.com/

<Prev in Thread] Current Thread [Next in Thread>