SSDR CW Timing Error

  • 1
  • Problem
  • Updated 4 years ago
  • Acknowledged
  • (Edited)

Was working QRQ CW this evening on 40m and noticed a slight timing error with my Flex 6700 running SSDR V1.6.21.77.  An external keyer is used. 

Using a dual trace scope to check CW timing, I noticed that the start of the CW RF waveform jitters between 6 msec. and 11 msec.  Running a string of dits, the RF start point can actually be seen wandering at different points between those two extremes.  Prior SSDR versions did not show this behavior.  I confirmed that the key line pulse used to trigger the alternate scope trace is steady.

To be clear, this is not so-called "dit shortening," meaning the duration of the RF envelope isn't changing.  The start of the RF envelope is simply bouncing around between 6 msec. and 11 msec.  To the ear, it becomes much more noticeable as CW speed increases.  Knowing that the SSDR CW Speed control did have an effect on key shape, even with external keying, I changed settings but the result remained the same.

To validate that an error didn't creep into my test configuration, I confirmed that two other transceivers display steady CW start times using the same external keyer.

Hopefully Flex Engineering can have a look at this and localize the root cause in the latest SSDR version when run with the Flex 6700. 

Paul, W9AC


Photo of Paul Christensen, W9AC

Paul Christensen, W9AC, Elmer

  • 323 Posts
  • 138 Reply Likes

Posted 4 years ago

  • 1
Photo of DL2CC

DL2CC

  • 20 Posts
  • 1 Reply Like
Hi Paul,

I always wondered why nobody else discovered the CW issues in SSDR 1.6.21.

I actually opened a support ticket for this issue.
They were not very helpful with the issue, apparently they don't do CW much.

In addition to missing dits when using CWX (which were confirmed by Flex support) I found out that there is a jitter in the CW signal using an external keyer with the 1.6 SSDR Version when shortening the ring contact on the KEY input.

Check if you use a mono plug with your keyer ouput. I found out that since version 1.6x you actually have to make sure you ONLY connect the center pin and it has to be stereo plug.

The manual is actually correct on this.
I am sure many others use a mono plug 3.5mm and a 3.5mm to 6.5mm stereo adapter like I did.

With the newest SSDR version, apparently the keyer part of the software has been changed and even when switching IAMBIC mode off, it is still causing a problem when connecting the grounding the ring pin.

73

Frank DL2CC
Photo of Al / NN4ZZ

Al / NN4ZZ

  • 1853 Posts
  • 672 Reply Likes
Frank,
Interesting info.   Is it correct that the jitters problem doesn't exist when using the ACC connector with an external keyer?

I haven't noticed the CWX issue (missing dits).  Does it occur when using the Fkeys or live keying or both?  Is there a previous post with more details on this issue?



Paul,
Do you connect your external keyer to the ACC connector (pin 4) or use the KEY jack in front?

Does the waveform jitters problem also happen when using the internal keyer or only with an external keyer?   (which could align with Frank's comment about the wiring if you are using the KEY jack)


Regards, Al / NN4ZZ  
al (at) nn4zz (dot) com
6700 - HW.................... V 1.6.21.77
SSDR / DAX / CAT...... V 1.6.21.159
Win10
Photo of Paul Christensen, W9AC

Paul Christensen, W9AC, Elmer

  • 323 Posts
  • 138 Reply Likes

Frank & Al,

Very interesting.  Yes, a Tip-Sleeve (TS) plug is used on the front key jack. Since owning the 6700, it's not been a problem using a T/S plug since SSDR senses this type of plug whether at start up or at any time after startup when removing the plug and re-inserting it into the key jack.

Laster today, I will change the plug to Tip-Ring-Sleeve (TRS) type and leave the ring unconnected.  If that corrects the issue, then SSDR should be updated to either: (1) go back to the way it was in previous releases; or (2) sense that a TS plug is being used and then leave the key line closed, thus alerting the operator to use a TRS plug.  This should occur regardless of what's stated in the owner's manual.

I'll report back later today or this evening.

Paul, W9AC




Photo of Al / NN4ZZ

Al / NN4ZZ

  • 1853 Posts
  • 672 Reply Likes
Paul,
I'm just thinking out loud here (I know that's usually not a good idea).   I wonder if there is a set of CW specific test cases that get run for every SSDR release.   ( i.e. a regression test).    Thorough regression testing for all aspects of a product is a big commitment so maybe that's not being done formally.  For a product like SSDR it would require hundreds of detailed test cases to be defined and executed and would take a dedicated QA team. 

Alpha team -- CW Specialist

It would be nice to augment their testing with someone on the Alpha team with the knowledge and equipment and time to do that just for one aspect (thinking CW for example).  While it's too much to ask any one volunteer to regression test every aspect, maybe focusing on one aspect is feasible.  
I've read there are about 50 alpha testers so maybe that is already happening.  If not I would definitely nominate you for that role and feel better knowing it was being done before the software was out in general release.    You have been instrumental in finding and documenting other CW issues. I'm sure there are others that are also  qualified. 

I can understand FRS not wanting to publish the alpha team members and all of the details of their testing process but it would be nice to know a little more about it.  Maybe Gerald and Steve can share some of the details. 

After Maestro is released and then WAN remote, I can see where just this one aspect (CW performance) could require even more testing.  

Regards, Al / NN4ZZ  
al (at) nn4zz (dot) com
6700 - HW.................... V 1.6.21.77
SSDR / DAX / CAT...... V 1.6.21.159
Win10
Photo of Paul Christensen, W9AC

Paul Christensen, W9AC, Elmer

  • 323 Posts
  • 138 Reply Likes

Al,

Thanks for the feedback.  Time is my #1 enemy.  I would hate to make a commitment as an Alpha Team tester and then fall short due to an unpredictable work schedule. 

As it is, Flex has been pretty good about issuing maintenance releases shortly after a major SSDR update.  I'll try and get to testing a bit earlier.

Paul, W9AC



Photo of DL2CC

DL2CC

  • 20 Posts
  • 1 Reply Like
Hi Al and Paul,

indeed, I switched over to the ACC connector and the issue vanished.
I was very unhappy with the way Flex support treated the issue.

I had to open two support tickets to just get the same answer that it was passed over to the development team and the issues were entered into the bug tracker and thus closed as a support ticket - end of communication with the customer.
Nobody tried to replicate the issue, at least they didn't communicate it to me.

I then experimented myself and found the choppy CW issue to be resolved by using the center PIN only.

Another interesting thing I've noticed was that I couldn't hear Receiver Audio in Full Duplex on the second Panadapter slice when using the shorted ring contact.
This has also vanished when switching over to the center contact / ACC pin only.


Anyway, the missing dits - this is the test scenario I've used:

Listen to the HF signal in Full Duplex mode on the second panadapter slice only.
I then used CWX and went for keyboard live mode.
Then hit a character with a leading dit (like L) every two seconds or so, about every so and so many characters the leading dit is missing from the signal.

73
Frank DL2CC
Photo of Mal G3PDH

Mal G3PDH

  • 49 Posts
  • 2 Reply Likes
I was not happy with keying using an external keyer into the front jack and changed over to the back accessory skt pin 4 which was much better. It would also be nice to have some menu control of waveform rise and fall times.
Photo of Walt - KZ1F

Walt - KZ1F

  • 3040 Posts
  • 645 Reply Likes
Hasn't there always been a cw issue? Isn't that why when Barry goes cw, he goes Elecraft? Hopefully I am accurately paraphrasing his rationale. I understood that to be an artifact of SDR.
Photo of Paul Christensen, W9AC

Paul Christensen, W9AC, Elmer

  • 323 Posts
  • 138 Reply Likes

All,

I have completed measurements using a 1/4-inch TRS plug on the front panel of my 6700.  CW timing results explained below:

1) Using a TRS plug and connecting the external keyer between Tip and Sleeve (open Ring) yields no improvement; 

2) Out of curiosity, I tried a connection between Ring and Sleeve (open Tip) and there's still no change (i.e., the jitter remains).  I also tried other CW parameters in the SSDR setup menu and no change;

3) As Frank and Mal have pointed out, the problem is finally cured when using the HD-15 rear panel ACCESSORY connector with the external keyer connected between pin 4 and GND.  The start of the CW rise occurs exactly at 5 msec. and is consistent with no jitter; and

4) Changes to SSDR's CW SPEED control no longer affect the slope of the CW rise/decay envelope.  Probably a strict Gaussian (raised cosine) curve is now used but should be confirmed by Flex.  The resulting RF envelope rise/fall time is now fixed at ~ 5 msec.  I see no issue with this but the evolution of how it ended here is interesting (first three slope change levels, then two, now one). 

I am late in making this report as I'm mostly using a K3 with a RemoteRig to our Internet site located about an hour north of my home in Jacksonville (details on my QRZ.com page).  The site is located on the SW edge of the Okefenokee Swap and DSL service is all that's presently available.  I'm looking into a high-speed point-to-point spread spectrum system and linking to a Comcast subscriber about ten miles to the south.  Until then, the K3/RemoteRig combo will be used.  When a better high speed ISP link arrives and SSDR 2.0 becomes available, the Flex 6700 will go out to the site.

Conclusion: hopefully Flex will correct the front panel key jack issue in a future release.

Paul, W9AC

P.S. I made no attempt to try the internal keyer.  Accurate timing results require an external PTT key line for correct scope triggering.

 


 


(Edited)
Photo of Al / NN4ZZ

Al / NN4ZZ

  • 1853 Posts
  • 672 Reply Likes
Paul,
Good information -- Since the problem is completely eliminated when using an external keyer via the ACC connector, do you think the issue is strictly software?  Or is there potentially some hardware difference between the two connectors?  (i.e. buffers or debounce circuitry on the JACK lines).  Generally these days debounce is done in software but without schematics it's hard to say for sure.  In other words are all of the keying lines just logic inputs with no other circuitry involved?

I only use the JACK with my paddle and the internal keyer.  At my moderate speed setting I have not noticed any problems.  It would be interesting to hear if anyone  has noticed the jitter issue with internal keyer.  Without putting a scope on it, it may be hard to tell.    

Do you think using a straight key connected to the JACK would also be subject to the issue?  I have my straight key connected to the ACC connector so no worries there. 

Do you think Maestro with the internal hardware Winkeyer  could also affect the local radio CW logic?  I guess that is a way to ask if we should be on alert when V 1.7 comes out.

Regards, Al / NN4ZZ  
al (at) nn4zz (dot) com
6700 - HW.................... V 1.6.21.77
SSDR / DAX / CAT...... V 1.6.21.159
Win10
Photo of Paul Christensen, W9AC

Paul Christensen, W9AC, Elmer

  • 323 Posts
  • 138 Reply Likes

Al,

Since prior SSDR versions have been fine when using an external keyer with the front panel KEY jack, the timing/jitter problem is almost certainly with 1.6.21.

Lots of moving parts here, made no easier with Maestro and preparation for WAN in V2.0.  Possibly these reasons now account for the fixed CW keyed waveform rise/decay setting in 1.6.21.  I can see where making CW rise/fall adjustable could wreak havoc when the 6000 series must work across so many different operating environments. 

We'll just have to watch and see if problems develop as the 6000 product matures. I

Paul, W9AC

 


(Edited)
Photo of Tim - W4TME

Tim - W4TME, Customer Experience Manager

  • 9198 Posts
  • 3558 Reply Likes
Official Response
I have entered this detailed problem report into our bug tracker (defect #3422) for additional investigation. Thank you for the defect report.