I get random hiccups when using cw.

Al_NN4ZZ

Dan, I don't have an easy way to do that without breaking a bunch of stuff. Maybe someone else can do it more easily. Regards, Al

W5XZ - dan

i had assumed it was my cheap-o consumer grade network stuff..

Mickey N4MB

I don't see a way to use a straight key. Where can you tell it not to use the keyer?

Mickey N4MB

I have very nice gigabit stuff. Still drops a bit occasionally. Did do some nice looking at the spacing... it definitely just drops a bit and starts another at the same spacing. Al - Rise time on first bit is under 5ms from key closure to peak envelope, so that is promising. But it is maddening to drop bits on transmitted cw, and it happens often at 22-25wpm with a ker. It's almost like your words not working when you speak.

Al_NN4ZZ

Click the "Iambic" button OFF to use a straight key. Regards, Al / NN4ZZ

Al_NN4ZZ

Mickey, 5ms is very good. Is the 5ms latency with the internal keyer or an external keyer? Agree, also seeing the dropped dits is happening here also. It is disconcerting during a QSO. Regards, Al / NN4ZZ

Ed, K0KC

Well, I finally got around to making a few CW contacts today with 0.13.10 and I still think it is better that the previous release, but it still has some problems as outlined previously. Please keep "tweaking".

mike_w1bfn

mike_w1bfn First, roses to your support and service departments for the incredibly fast service. Back on the air in six days including the weekend. Thanks Dudley! SECOND, 0.13... has the same hiccup problem. And it shows up on the transmitted signal. Verified by listening with the Orion. To review, this problem is easily recreated. I use a single paddle keyer, and the program is looking for a squeeze type keyer. I can make it sound fine only if I make the transition from dot to dash at my "top speed." Any slower and I get the pause on the monitor and also on the transmitted signal. Only shows up in the "dot first" sequence. Strongly suggest this programming problem be cleared up before you offer QSK. I purely hate the idea of having to use an external keyer.

Tim - W4TME

We have re-added this issue to our bug tracker for additional investigation. Thanks to everyone for your reports.

Mickey N4MB

Here's more info. I got my keyer back off loan and can replicate the same behavior with "Iambic" clicked off (set for straight key) and sending a string of dits. Sometimes it happens 10s into dits, sometimes later. It drops dit on a 20WPM didahdidahdida, from a long iambic squeeze, again, bypassing the SmartSDR keyer, if that's possible. Hope that helps. I'll post a scope trace of dits with key down and envelope measurement if I can get this dang Rigol scope software to behave! It is as least as good as what Gerald posted a few months ago. Mickey N4MB

Mickey N4MB

More info - latency looks like 8-10ms on my Flex6500. Blue line is key closure (output of the keyer goes low) and yellow is the RF envelope in the same time domain.

Al_NN4ZZ

Mickey, That looks very good for both the amount of latency and wave form shape. Assume that was done with your external keyer, is that correct? If so, I wonder if you could try it with the internal keyer. (i.e. paddle press to RF). It seems like there is some sluggishness with the internal keyer, But it could be related to the dropped DITs or just anticipation of them. (I see a dropped DIT about every minute or so of keying at 20 WPM). It would be great to have a scope trace to see. Regards, Al / NN4ZZ

Al_NN4ZZ

Mickey, ARRL uses 60 WPM for their key latency traces What speed were you using and do you see a difference at different speeds? Regards, Al / NN4ZZ

Mickey N4MB

I seem to remember that WPM =1.2 / (Dit Length in Seconds). From the display, we can see that the frequency is 25.25Hz. Spacing being a dit, there would be 50.50 dits per second, so bit length is 1/50.50s or about 0.02s. 1.2/0.02 = 60WPM I see no latency difference at speed. That's a good thing. More importantly, there's no latency difference with a long string of bits, so whatevery hiccup we're seeing, the output isn't incrementally lagging the input... is isn't causing a problem because of latency,,, the latency seems consistent. I didn't spend hours looking at this - 20 minutes to get out the scope and set up the test and (at most - a half hour) of playing around with it. Mickey

Ned K1NJ

With my setup, using external keyer, I hear keying problems when delay is set < 45ms. If delay is set > 50ms. I don't hear it. I am usually set with delay > 300ms. At default delay setting cw is very poor even with external keyer.

Al_NN4ZZ

Mickey, Thanks for the trace. Assume that was done with your external keyer, is that correct? If so, I wonder if you could try it with the internal keyer. (i.e. paddle press to RF). I'm sure you would rather play on the radio but if you have some time it would sure be appreciated. It seems like there is some sluggishness with the internal keyer, But it could be related to the dropped DITs or just anticipation of them. (I see a dropped DIT about every minute or so of keying at 20 WPM). It would be great to have a scope trace to see. Regards, Al / NN4ZZ

Steve-N5AC

I believe we have found the source of the hiccups in the CW and fixed it as well as having made substantial changes to latency, keying speed and QSK. This fix will be in 0.15.x or later.

Mickey N4MB

Very cool, more progress toward making this transceiver usable in my shack. Thanks for the work and the update. DAX is high on my personal list, I see that it's for January, so I'll be using a non-Flex radio for the fall contests for the first time in a number of years. Mickey

Al_NN4ZZ

Thanks, Steve, Looking forward to 0.15.x. As a CW only OP this keyer fix is going to make a big difference for me. Regards, Al / NN4ZZ

Ken - NM9P

Wonderful news! I assume it is still in grey box testing this week? Is it possible that we will see it this weekend...I hope, I hope? Or is that in the pipeline for the release after the upcoming one?

Al_NN4ZZ

Ken, Good news is either way it is a 0.x.x release so we will get it before V1.0 is out. Latest Insider said they are still shooting for end of September for V1.0. Regards, Al / NN4ZZ

Eric-KE5DTO

To be clear, we released v0.15.4 for gray box testing last week and it didn't pass our quality tests. We are coming up on another release (likely v0.15.8) for gray box testing this week. If it passes our quality tests it will be released to the preview group. So at this point, it isn't a guarantee that this will be seen in a release prior to v1.0. There is a reasonably good shot at it though.

Eric-KE5DTO

I updated my note to be more specific. I wasn't saying that this fix would not make it into v1.0. Rather that v1.0 could possibly be the first time the fix is available to the public.

Al_NN4ZZ

Eric, Does that mean that after the preview groups sees the last 0.x.x release, V1.0 will (or could) come out with new fixes that we (the preview group) have not yet seen? I guess my impression was that the preview group would see all of the releases prior to the V1.0 production release. Regards, Al / NN4ZZ

Eric-KE5DTO

The process is as described previously: Once a release passes internal testing, it goes on to gray box testing with our alpha group. If the release passes our internal and alpha quality tests, it goes on to the Preview group. My point was that it is possible that the next one that makes that trip could be v1.0. It is also possible that there could be one or more before v1.0. Possible is the key word here.