Ron,
> 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?
I specifically referenced microKEYER II and DigiKeyer II as having the
ability to key an amplifier and/or LNA (receive antenna switching
devices) before the transceiver. That feature us not available in the
entry level devices (USB Interface II and USB Interface III).
In any case, most software appears to have sufficient PTT to data delay
to accommodate reasonably designed transceivers and amplifiers even
with 10 to 20 milliseconds of lead between amplifier and transceiver
PTT. If you disable diddles in MMTTY, you will find that MMTTY (the
plug-in in WriteLog) will delay data (or initial diddles) by about
800 ms after PTT (I did not get out a scope and measure it - just a
stopwatch and ears)! Remember, when properly implemented one RTTY
character is 165 ms long (6.5 bits at 22 ms each) so if macros are done
properly ... with a leading CR/LF ... there should be plenty of time
for *any* transceiver to stabilize before any text is sent as the
combination of PTT lead on MMTTY and CR/LF more than a full second.
The more likely cause of "garble in the first few characters" is either
a lack of diddle or a problem with ALC induced power instability. This
is particularly likely if a transceiver with a *known* leading edge
power spike is used (at reduced output) to drive an amplifier sensitive
to such spikes and amplifier ALC is connected to the rig. Such a
configuration is a system with terribly unstable feedback and is likely
to create power overshoots and dips (bit length drop outs) for as much
as two seconds depending on the specific ALC time constants and the
amount of excess gain in the transceiver (size of the overshoot).
> 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).
This should be unnecessary. As above, MMTTY already takes about 800
ms. before it begins sending important data.
73,
... Joe, W4TV
On 1/21/2012 6:08 PM, Ron Lodewyck wrote:
> 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/
>
_______________________________________________
WriteLog mailing list
WriteLog@contesting.com
http://lists.contesting.com/mailman/listinfo/writelog
WriteLog on the web: http://www.writelog.com/
|