Sorry, an error occurred while loading the content.
Browse Groups

• ## Re: part of first cw character is truncated

(4)
• NextPrevious
• Hi Fred, Here is a bit of an insight into how cw signals are polled for key presses. International Morse code is composed of five elements: 1. short mark,
Message 1 of 4 , May 27
View Source
Hi Fred,

Here is a bit of an insight into how cw signals are polled for key presses.

International Morse code is composed of five elements:

1. short mark, dot or 'dit' (·)  'dot duration' is one unit long
2. longer mark, dash or 'dah' ()  three units long
3. inter-element gap  one dot duration or one unit long
4. short gap (between letters)  three units long
5. medium gap (between words)  seven units long

Based upon a 50 dot duration standard word such as PARIS, the time for one dot duration or one unit can be computed by the formula:

T = 1200 / W

or

T = 6000 / C

Hence at 30 WPM

T = 1200 / 30 = 40 mSec duration for one dot

and at 50 WPM

T = 1200 / 50 = 24 mSec duration for one dot

If the key is polled every 5 mSec it is possible to lose the first 5 mSec of the first element and variable amounts of the subsequent elements as follows. If the poll completed immedediately before the press of the key and we had to wait 5 mSec for the next poll. At 50 wpm if the character was a dot it would make it ...

24 - 5 = 19 mSec long.

A sucessful poll to detect key up would occur 20 mSec later (4 x 5 mSec polls) i.e. 1 mSec after the key is opened. These timings would give the effect of slightly clipping the dot i.e. 24 mSec down to 20 mSec. The inter element space would then be affected and would give a duration of 20 mSec as well. The culmulative errors of the two shortened elements would would give rise to a dot time of 30 mSec if the next element was a dot and the rest of the subsequent characters would continue in this fashion..

This may be unacceptable at 50 wpm and a case for a 2 mSec poll time could be made but at 30 wpm the effects of variable element times as a percentage of the element length can be ignored. However 5 mSec polls are possibly a fair burden on the software and longer poll times may be in place. If so the first dot clipping may make the cw element so short that it is lost all together. In addition to avoid key clicks the algorithm almost certainly includes a gradual rising and falling edge probably of around 5 mSec and could be an exponential curve which will exacerbate the problem. I have not written the routine so am guessing on the poll times but am pretty sure that is what is happening to your cw.

You may have to drop back to 20 wpm and suffer the jibes from your cw friends.

73 Graeme ZL2APV

--- In powersdr-iq@yahoogroups.com, "FRED" <flsaas@...> wrote:
>
> I apologize if this has been answered before-
>
> My problem is that when I send my call, WA8PGE, the person on the other end hears MA8PGE because the first dit of the W becomes truncated.
>
> I am not having a latency problem, just the beginning of the character is shortened.
>
> Here is my setup-
> Dual core cpu, @2ghz with 2gig memory
> running XP Professional
> soundcard is Delta 44
> Powersdr-iq is vers 2.4.4
> CW is Keyed thru the com port
> I am using an external keyer and have unchecked "iambic", usually speed is around 28 - 30 wpm.
>
> Any ideas? Buffer settings?
>
> Thanks
> Fred
> WA8PGE (not MA8PGE 8-) )
>
• Thanks Graeme for the detailed explanation of the CW problem. (and sorry for the late reply) I think that you have probably answered the problem that I have
Message 1 of 4 , Jun 7
View Source
Thanks Graeme for the detailed explanation of the CW problem. (and sorry for the late reply)

I think that you have probably answered the problem that I have been having forever with Rocky.
When I hook up an external keyer to Rocky the CW character elements are unevenly created and transmitted, the higher the speed, the worse it sounds.  (If I use the internal iambic CW on Rocky I do not have this problem for some reason.) This is a really a problem for me for Rocky because I would like to set the CW input to Straight Key and plug in a keyboard, but that is where the problem with the uneven element spacing happens...  This is the main reason I want to get PowerSDR-IQ working.

On PowerSDR-IQ CW, with the  keying via the com port, iambic unchecked, I ONLY get the first part of the CW character "chopped off".  This is when PTT comes up, something to do with the timing of PTT being up before TXing.
I think there is a setting for this on the CWX setting but I cannot find the setting that might be for using a keyer.
Some sort of  "time after PTT is up before TX" setting is what I am missing.

BTW, if anyone has the timing settings that work for them for CWX, I would appreciate it if they could share their settings

Thanks
Fred
WA8PGE

--- In powersdr-iq@yahoogroups.com, "Graeme" wrote:
>
> Hi Fred,
>
> Here is a bit of an insight into how cw signals are polled for key presses.
>
> International Morse code is composed of five elements:
>
> 1. short mark, dot or 'dit' (·)  'dot duration' is one unit long
> 2. longer mark, dash or 'dah' ()  three units long
> 3. inter-element gap  one dot duration or one unit long
> 4. short gap (between letters)  three units long
> 5. medium gap (between words)  seven units long
>
>
> Based upon a 50 dot duration standard word such as PARIS, the time for one dot duration or one unit can be computed by the formula:
>
> T = 1200 / W
>
> or
>
> T = 6000 / C
>
> Hence at 30 WPM
>
> T = 1200 / 30 = 40 mSec duration for one dot
>
> and at 50 WPM
>
> T = 1200 / 50 = 24 mSec duration for one dot
>
> If the key is polled every 5 mSec it is possible to lose the first 5 mSec of the first element and variable amounts of the subsequent elements as follows. If the poll completed immedediately before the press of the key and we had to wait 5 mSec for the next poll. At 50 wpm if the character was a dot it would make it ...
>
> 24 - 5 = 19 mSec long.
>
> A sucessful poll to detect key up would occur 20 mSec later (4 x 5 mSec polls) i.e. 1 mSec after the key is opened. These timings would give the effect of slightly clipping the dot i.e. 24 mSec down to 20 mSec. The inter element space would then be affected and would give a duration of 20 mSec as well. The culmulative errors of the two shortened elements would would give rise to a dot time of 30 mSec if the next element was a dot and the rest of the subsequent characters would continue in this fashion..
>
> This may be unacceptable at 50 wpm and a case for a 2 mSec poll time could be made but at 30 wpm the effects of variable element times as a percentage of the element length can be ignored. However 5 mSec polls are possibly a fair burden on the software and longer poll times may be in place. If so the first dot clipping may make the cw element so short that it is lost all together. In addition to avoid key clicks the algorithm almost certainly includes a gradual rising and falling edge probably of around 5 mSec and could be an exponential curve which will exacerbate the problem. I have not written the routine so am guessing on the poll times but am pretty sure that is what is happening to your cw.
>
> You may have to drop back to 20 wpm and suffer the jibes from your cw friends.
>
> 73 Graeme ZL2APV
>
>
> --- In powersdr-iq@yahoogroups.com, "FRED" flsaas@ wrote:
> >
> > I apologize if this has been answered before-
> >
> > My problem is that when I send my call, WA8PGE, the person on the other end hears MA8PGE because the first dit of the W becomes truncated.
> >
> > I am not having a latency problem, just the beginning of the character is shortened.
> >
> > Here is my setup-
> > Dual core cpu, @2ghz with 2gig memory
> > running XP Professional
> > soundcard is Delta 44
> > Powersdr-iq is vers 2.4.4
> > CW is Keyed thru the com port
> > I am using an external keyer and have unchecked "iambic", usually speed is around 28 - 30 wpm.
> >
> > Any ideas? Buffer settings?
> >
> > Thanks
> > Fred
> > WA8PGE (not MA8PGE 8-) )
> >
>
• Hi Fred, There may be more to it than the timings associated with PSDR port polling as some years ago when Christos set it up I was involved with testing for
Message 1 of 4 , Jun 9
View Source
Hi Fred,

There may be more to it than the timings associated with PSDR port polling as some years ago when Christos set it up I was involved with testing for him. I could send at 18 wpm using the monitor function in PSDR but when going faster I had to use the tone osc on my keyer. Rocky also went in a similar fashion.

I am now thinking that you have some sort of bias delay on your final so that the relays can operate first before RF is applied to avoid the brief transmission into an open circuit as the relay contacts transition. Maybe this delay is too long. For an SSB rig 50 mSec would hardly clip the first syllable but would lose the first dot or turn a dash into a dot on CW. I would be looking at a 10 mSec delay if your relays are good quality high speed ones.

BTW I did have people comment on my first dot sometimes being very short with PSDR and with the cumulative effect of a delayed switch on for your final could be the reason. I am sorry I can not test any further as some years ago I moved to Linux and am now very out of touch with PSDR progress but knowing Christos it will be better.

73 Graeme ZL2APV

--- In powersdr-iq@yahoogroups.com, "FRED" <flsaas@...> wrote:
>
> Thanks Graeme for the detailed explanation of the CW problem. (and sorry
> for the late reply)
> I think that you have probably answered the problem that I have been
> having forever with Rocky.When I hook up an external keyer to Rocky the
> CW character elements are unevenly created and transmitted, the higher
> the speed, the worse it sounds. (If I use the internal iambic CW on
> Rocky I do not have this problem for some reason.) This is a really a
> problem for me for Rocky because I would like to set the CW input to
> Straight Key and plug in a keyboard, but that is where the problem with
> the uneven element spacing happens... This is the main reason I want to
> get PowerSDR-IQ working.
> On PowerSDR-IQ CW, with the keying via the com port, iambic unchecked,
> I ONLY get the first part of the CW character "chopped off". This is
> when PTT comes up, something to do with the timing of PTT being up
> before TXing.I think there is a setting for this on the CWX setting but
> I cannot find the setting that might be for using a keyer.Some sort of
> "time after PTT is up before TX" setting is what I am missing.
> BTW, if anyone has the timing settings that work for them for CWX, I
> would appreciate it if they could share their settings
> ThanksFredWA8PGE
> --- In powersdr-iq@yahoogroups.com, "Graeme" wrote:
> >
> > Hi Fred,
> >
> > Here is a bit of an insight into how cw signals are polled for key
> presses.
> >
> > International Morse code is composed of five elements:
> >
> > 1. short mark, dot or 'dit' (·)  'dot duration' is one unit
> long
> > 2. longer mark, dash or 'dah' ()  three units long
> > 3. inter-element gap  one dot duration or one unit long
> > 4. short gap (between letters)  three units long
> > 5. medium gap (between words)  seven units long
> >
> >
> > Based upon a 50 dot duration standard word such as PARIS, the time for
> one dot duration or one unit can be computed by the formula:
> >
> > T = 1200 / W
> >
> > or
> >
> > T = 6000 / C
> >
> > Hence at 30 WPM
> >
> > T = 1200 / 30 = 40 mSec duration for one dot
> >
> > and at 50 WPM
> >
> > T = 1200 / 50 = 24 mSec duration for one dot
> >
> > If the key is polled every 5 mSec it is possible to lose the first 5
> mSec of the first element and variable amounts of the subsequent
> elements as follows. If the poll completed immedediately before the
> press of the key and we had to wait 5 mSec for the next poll. At 50 wpm
> if the character was a dot it would make it ...
> >
> > 24 - 5 = 19 mSec long.
> >
> > A sucessful poll to detect key up would occur 20 mSec later (4 x 5
> mSec polls) i.e. 1 mSec after the key is opened. These timings would
> give the effect of slightly clipping the dot i.e. 24 mSec down to 20
> mSec. The inter element space would then be affected and would give a
> duration of 20 mSec as well. The culmulative errors of the two shortened
> elements would would give rise to a dot time of 30 mSec if the next
> element was a dot and the rest of the subsequent characters would
> continue in this fashion..
> >
> > This may be unacceptable at 50 wpm and a case for a 2 mSec poll time
> could be made but at 30 wpm the effects of variable element times as a
> percentage of the element length can be ignored. However 5 mSec polls
> are possibly a fair burden on the software and longer poll times may be
> in place. If so the first dot clipping may make the cw element so short
> that it is lost all together. In addition to avoid key clicks the
> algorithm almost certainly includes a gradual rising and falling edge
> probably of around 5 mSec and could be an exponential curve which will
> exacerbate the problem. I have not written the routine so am guessing on
> the poll times but am pretty sure that is what is happening to your cw.
> >
> > You may have to drop back to 20 wpm and suffer the jibes from your cw
> friends.
> >
> > 73 Graeme ZL2APV
> >
> >
> > --- In powersdr-iq@yahoogroups.com, "FRED" flsaas@ wrote:
> > >
> > > I apologize if this has been answered before-
> > >
> > > My problem is that when I send my call, WA8PGE, the person on the
> other end hears MA8PGE because the first dit of the W becomes truncated.
> > >
> > > I am not having a latency problem, just the beginning of the
> character is shortened.
> > >
> > > Here is my setup-
> > > Dual core cpu, @2ghz with 2gig memory
> > > running XP Professional
> > > soundcard is Delta 44
> > > Powersdr-iq is vers 2.4.4
> > > CW is Keyed thru the com port
> > > I am using an external keyer and have unchecked "iambic", usually
> speed is around 28 - 30 wpm.
> > >
> > > Any ideas? Buffer settings?
> > >
> > > Thanks
> > > Fred
> > > WA8PGE (not MA8PGE 8-) )
> > >
> >
>
Your message has been successfully submitted and would be delivered to recipients shortly.
• Changes have not been saved
Press OK to abandon changes or Cancel to continue editing
• Your browser is not supported
Kindly note that Groups does not support 7.0 or earlier versions of Internet Explorer. We recommend upgrading to the latest Internet Explorer, Google Chrome, or Firefox. If you are using IE 9 or later, make sure you turn off Compatibility View.