V1.0 next week - why the rush?

Mickey N4MB

For those of us not using an external keyer, there are definitely issues running 22+ WPM reliably on 0.16.4. All you need to do to reproduce this is to find someone who can send at 25 wpm with an iambic and to have them send a paragraph of text. It drops the occasional bit. I know that sounds trivial, but to need to buy a $100 keyer after dropping $4k on a state of the art radio is maddening. Having to insist that there is, indeed, a problem and having it labeled "not serious" gives me concern. I have a KX3 and an Icom IC-7100 here on my desk and they follow the key perfectly at 25 wpm. My Flex 6500 does not.

Gerald-K5SDR

Ed determined this afternoon that the "Auto Character Space" feature was turned on in the code by default. This is a mode the enforces spacing between characters. The Auto Character Space feature was doing exactly what it is designed to do. PowerSDR has a checkbox for Auto Character Space that is defaulted to OFF. There is no checkbox in SmartSDR and it was inadvertently defaulted ON in the code. We will be testing with it OFF this evening.

Al_NN4ZZ

That would be great if that is the fix. If you need some additional testers I'm sure a few of us would be glad to help. Regards, Al / NN4ZZ

Al_NN4ZZ

That could also account for the sluggishness I feel between characters at times. The "autospace" feature over-rides the keyers spacing. I don't know anyone that uses it for that reason but a lot of keyers offer it so some folks must like it. (keeping fingers crossed). Regards, Al / NN4ZZ

Paul RN3A

This is an interesting point! Honestly, I have never paid attention to "Auto Character Space" setting in PSDR. I will try playing with this later today with my Flex-3000 radio and post a brief report. 73! de Paul RN3A

Ken - NM9P

I have noticed something else odd. When I boot up SmartSDR, neither the A-mode or B-mode selection in Settings/CW/Iambic is highlighted. I could never use A-mode, it gets me very messed up and I like dot memory. But it is not in A mode. After I click B-mode it seems to send a little differently. It seems like it goes a bit smoother with fewer broken characters. Not a major difference... something very subtle. Am I imagining this? Or has anyone else noticed it? It seems like it boots up not as A-mode, but not quit fully functioning as B-mode Iambic. I am somewhat rusty on my code, but it seems like there is a difference here. If I select A it functions in A and B functions in B. But the initial non-declared mode seems to be like a slightly temperamental B mode. Can some of you expert brass pounders tell me if I am going stir crazy on this one?

Paul RN3A

Gerald et all, As promised, here is a brief report on PSDR CW keyer settings vs. SSDR. By DEFAULT PSDR has the following set of options available and Enabled / Disabled: Iambic - On (Box checked) Sidetone - ON Reverse Paddles - Off 2 wire Cable - off Mode B - On Mode B strict - Off Auto Mode Switch - Off Strict Character Space - Off With these settings keying in PSDR did not create any problems at any speed. After I checked "Mode B Strict" - there were some problems with keying, most likely because of my technique. I started to notice this after 40 WPM. When enabling Strict Character Space - the picture was very similar to what we have seen in 6000 - extra spaces, lost chars, etc. However, it still allowed me to do "recover', i.e. send a series of Dots any time I would like to do it after the symbol I consider to be erroneous. I think we are somewhere close to the root cause... SSDR currently has only A/B mode switch.. And this is just about it.. Steve has mentioned that Keyer part of the code is something imported from PSDR with almost no change. Why then not to add all options like in PSDR? Or is there a big reason not to do it at this point? IMHO - this needs to be added now, before v1 release and let ALPHA / Preview testers try it, the more people can do it - the better. CW keying MUST be impeccable, whatever it takes to make it such! Even at the cost of additional delays for v1 official release. Apologies for this, I am just your customer who cares, and, of course, I want to have the best Radio on the market. ASAP, as usual! )))))) 73! de Paul RN3A

Sergey R5AU

Paul, i am with you, i guess one are very simplified feature must be implemented with internal keyed - memory for one element: in case you transmitting dash and shortly press dot with paddle, key should send complete dash - complete pause - complete dot, and viсe versa with dot at beginning

Steve-N5AC

OK an update -- our best brass pounder tested the fix made to turn off the "Auto Character Space" by default and he reports that this has fixed the issue. He said previously that sending paragraphs at ~23WPM that he had a few instances of the keyer apparently getting confused on dot-to-dash and that now he can send without issue at this speed. Thanks for the help identifying the problem and I'll let you guys judge if you agree that it is fixed. Paul, I'm going to shoot you a copy of the fixed software and see if you agree. email shortly.

Mickey N4MB

The auto character space is a logically reasonable explanation. I appreciate and respect the fact that Flex put this at the top of the queue and that Steve apparently worked through the night on this problem. No matter what features are missing, and what bugs we find going into a production release, there has never been any doubt in my mind about the dedication of the FlexRadio folks to make everything work, despite the apparent underestimate of the scope of development to get to this point. I await the CW fix in 1.0 next week.

Steve-N5AC

Jim on our staff (WD5IYT) and Paul, RN3A, both confirm that we have now fixed the CW issue. Thanks for everyone's help in identifying this!

Al_NN4ZZ

Steve, Great news, looking forward to getting this version! Appreciate the efforts by all, and sorry it was such a push at the end but I think its is really important to come out with a solid CW setup for the V1.0 debut. Regards, Al / NN4ZZ ************* from above ********************** Steve - N5AC (VP Engineering) 3 minutes ago Jim on our staff (WD5IYT) and Paul, RN3A, both confirm that we have now fixed the CW issue. Thanks for everyone's help in identifying this!