V1.0 next week - why the rush?

  • 2
  • Question
  • Updated 6 years ago
  • Answered
Archived and Closed

This conversation is no longer open for comments or replies and is no longer visible to community members. The community moderator provided the following reason for archiving: 1.0 has been released

V1.0 next week - why the rush?

V0.16.4 is the last version the preview team will see before V1.0 comes out next week. (see note below).

Why not keep posting 0.x.x releases to the preview team until all the bugs are fixed? Doesn't it make sense to stop adding new features but fix all of the existing bugs before declaring the code ready for the V1.0 production release?

Every preview release so far has flushed up new issues or failed to correct previously identified ones. It seems like the QA process (alpha, QA team, black and grey box, etc) does not catch many of the issues that the large "preview team" identifies. (e.g. the internal keyer has been buggy since day 1 although I've heard it is fixed in the next version 0.17.4 that we can't test)

Just my $0.02 but if the production release has as many bugs (crashes, etc) as we see currently it's not ready for prime time. What is the rush other than meeting a goal or "red line"? Wouldn't it be better to delay a few more weeks and debut the production release with a solid version?

Regards, Al / NN4ZZ

p.s. Please don't take this question as bashing FRS. I'm supporting the effort and want this to be as successful as everyone else does.

Gerald - K5SDR (Official Rep) (from a VOX post on 26-Sep-2013)
I would quit trying until you get v1.0 next week. VOX was fixed in v0.17.4 but you won't get to play with it since it is an interim release. v0.16.4 is the last one the Preview group will see before v1.0.
Photo of Al / NN4ZZ

Al / NN4ZZ

  • 1852 Posts
  • 672 Reply Likes

Posted 6 years ago

  • 2
Photo of Kirk, K6KAR

Kirk, K6KAR

  • 39 Posts
  • 6 Reply Likes
I absolutely agree! Putting out another release of buggy software, makes no sense. Obviously, your gray/black box concept of alpha testing isn't working very well for you and it doesn't (not that you're following this), come close to following the SEI (Software Engineering Institute) concept for SW release. Suggest you pull back and provide what you said you were going to provide when you initially advertised. As it is, the 6000 series is a poor excuse for a flagship product.
Photo of Gerald - K5SDR

Gerald - K5SDR, Employee

  • 830 Posts
  • 1514 Reply Likes
Al,

Your comments are appreciated. However, this group has not found any bugs that were not reported by the alpha group during their test cycle. In fact, the bugs reported here were fixed in v0.17.4 BEFORE we released v0.16.4 to Preview. The v0.16.4 iteration is approaching 2 weeks old now.

Our theory, maybe incorrect, was that we should release v0.16.4 here to see if the preview group would find any significant bugs that had not already been reported by the alpha team. I am personally monitoring bug reports here and from the alpha group. I also just left a bug review meeting and there are no reported and unresolved issues that would stop the v1.0 release as of this morning. We are feature frozen for v1.0 and doing final testing/bug fixes.

Here are a couple of comments received this morning related to CW performance on v0.17.4:

From RN3A:
"I am getting addicted here, so I will keep testing it with different QRQs :) So far it works for me on CW speeds up to 30 - 35 WPM (150 - 175 CPM). This is already close to my ceiling for hand manipulation, so I can't wait when internal CW control will be available! (Or do I need to buy me a $1,000 Begali Sculpture paddles?) :)"

GY note: QRQ QSK requires separate receive antenna for speeds above ~35WPM. With this configuration you can hear between dits at QRQ speeds.

From W2RF:
"QSK is good up to about 35wpm. I can hear enough of a signal between dits to know it’s a BK. (The K3 tops out in the low 20s so I’ve heard.) However it is not all that important to hear between dits between 30 and 40wpm because the chars are short. What is important is to hear the band cleanly between chars, and on this the radio is superb. I would venture to say unmatched. Maybe historic. It is a pleasure to operate. Almost addicting."
Photo of Eric - KE5DTO

Eric - KE5DTO, Official Rep

  • 878 Posts
  • 323 Reply Likes
Another thing to keep in mind: What we have heard from the community is that you would like to have more frequent software updates -- even if it has some caveats. This gives us the ability to list the known issues and get feedback on the pieces where we have made improvements while continuing development.

The alternative to this approach is to only release software when it has passed all the gates. This necessarily means less frequent updates. I don't think this is what the community wants.

I wish we were superhuman coders that never made mistakes, but I'm pretty sure everyone who signed up for the Preview understood that the preview releases would likely contain bugs. As Gerald points out, there has been a monumental shift forward in terms of functionality in the SmartSDR software in the last couple of weeks and I look forward to continuing on that path.
Photo of W5XZ - dan

W5XZ - dan

  • 571 Posts
  • 86 Reply Likes
Most of us already know that you guys really ARE 'superhuman coders' !! I really feel like you guys are working for me, and am pleased to help fund the payroll to help advance the state of the art...73
Photo of Steve - N5AC

Steve - N5AC, VP Engineering / CTO

  • 1055 Posts
  • 1080 Reply Likes
We *are* working for you ;-)
Photo of Al / NN4ZZ

Al / NN4ZZ

  • 1852 Posts
  • 672 Reply Likes
Eric,
I've been there too. In my development experience typically about 85% of the existing bugs were caught at each stage of testing. (i.e. fewer bugs get to each stage and each stage finds about 85% of those).

So I'm actually in favor of more testing (from all of the groups including the preview group) before declaring the software solid and ready to debut as V1.0.

So please don't take my comments and questions as a negative. I know you are all trying 110% to get it done. I was just asking why not wait a few more weeks and make it even better. No one will remember if you took a few more weeks, many will not forget it the debut version has issues like the keyer SPACE bug. And others may have specific issue they will be looking at as well.

I was glad to hear that news about the keyer QSK testing but it didn't specifically mention the "extra space" in the middle of the characters issue. That one has been there since the beginning and one I really hope is fixed.

Regards, Al / NN4ZZ
Photo of Gerald - K5SDR

Gerald - K5SDR, Employee

  • 830 Posts
  • 1514 Reply Likes
Al,

We have fixed all of the known bugs of any significance and we have moved to time boxed releases.

We have hundreds of customers waiting for v.1.0 and it would not be fair to make them wait any longer. Read the quotes from RN3A and W2RF regarding their experience with CW on v0.17.4. RN3A is a QRQ operator.

Unless we find a significant issue before Monday, we will be shipping v1.0 at that time.
Photo of Dale KB5VE

Dale KB5VE

  • 415 Posts
  • 56 Reply Likes
Great news Gerald! One question I never asked, will the preview group cease to get releases between the 1.0 releases or will we continue to be involved. We have come a long way from our talk Friday morning at Dayton, agree. Keep up the good work.
Photo of George Molnar, KF2T

George Molnar, KF2T, Elmer

  • 1664 Posts
  • 612 Reply Likes
Congratulations on the 1.0 milestone! Looking forward to raising a glass towards Austin on Monday evening.
Photo of W5XZ - dan

W5XZ - dan

  • 571 Posts
  • 86 Reply Likes
Wow, a landmark; the Preview is over on Monday. Hope the forklifts don't break down! great job, Gerald & team...very pleased to participate...73
Photo of Gerald - K5SDR

Gerald - K5SDR, Employee

  • 830 Posts
  • 1514 Reply Likes
We truly appreciate everyone's participation in the Preview release process. It has been extremely helpful in many ways. 73, Gerald
Photo of K1UO - Larry

K1UO - Larry

  • 865 Posts
  • 135 Reply Likes
Are the manuals ready to go with the Ver 1 release?
Photo of Gerald - K5SDR

Gerald - K5SDR, Employee

  • 830 Posts
  • 1514 Reply Likes
Yes. We are finalizing now and working on formatting.
Photo of K4EAR

K4EAR

  • 138 Posts
  • 17 Reply Likes
Addendums should be timely also as 1.0 evolves.
Photo of k0eoo

k0eoo

  • 623 Posts
  • 87 Reply Likes
Very interesting thread.... Thanks Gerald and Eric for the detail, I feel better already...
Photo of Paul RN3A

Paul RN3A

  • 56 Posts
  • 6 Reply Likes
Just want to share some last night's experience. I've spent about 2 hours CW ragchewing with some German and East European QRQ stations. Radio setup was - separate antennas for TX and RX, no PA, full QSK. We were playing with CW speeds up to 250 CPM (50 WPM). I confess - I was using the aid of K1EL based external CW keyer and keyboard, and CWGet to receive all this. (Not sure what the guys on the other end were using...) The main purpose was to see how the radio is going to work with CW speeds like this. I started to receive complaints on readability of CW in full QSK after exceeding 45-50 WPM. Yet again, I am not convinced that this is Flex-6700 issue, since a separate receiver has decoded my own transmission with no problem.
Quite an interesting experience - after playing with CW self-control settings and RX audio levels, I could very well hear about 75% of what is happening between dots and dashes of my own TX on the same frequency. After splitting TX and second slice RX, there was no problem what so ever to listen to the second frequency.
The radio was set up in the following way - First SCU with one slice for TX only,
second SCU with 2 RX slices. First slice to match TX frequency, the second one to monitor other frequencies on the same band.
The experience was quite amazing - it worked really well. One thing which I consider to be not very convenient (yet), is that there are too many movements you have to do with the mouse to fine set different controls... (I know, I know... I am not complaining. I am simply too spoiled...).
I am looking forward to the times when all basic things will be completely out of the way and this radio will most likely become the best for Contesting - which other radio allows you to have inband SO2R, and SO3R, SO4R... and counts... in one box? :)
Great stuff, Flex Radio!
Photo of Al / NN4ZZ

Al / NN4ZZ

  • 1852 Posts
  • 672 Reply Likes
Paul,
Since you have the new version (0.17.4) can you spend some time using the internal keyer to confirm that the "SPACE" issue is fixed. You have to use the internal keyer to see the issue.

http://community.flexradio.com/flexra...

50 WPM QSK is nice also but many us will use 15-30 WPM and the internal keyer more often.

Regards, Al / NN4ZZ
Photo of Paul RN3A

Paul RN3A

  • 56 Posts
  • 6 Reply Likes
Al et all,

I see your point. I was not using internal CQ keyer much. Probably, because of the old habit I've got... I've tried it today at different speeds in both Iambic A and B modes, as well as single paddle mode. (On a personal side, I am iambic B operator, so iambic A represents a certain challenge to me). Here are some observations.

1. Do people REALLY use iambic A or B keying technique? Or is it rather a single paddle mode? This is an important question. I've tried iambic B up to 30 WPM and and it worked ALMOST well. Iambic A didn't work for me at all - it is almost like learning CW keying from the scratch...

"Single paddle" technique delivered some interesting results. First of all - YES, there are extra spaces which occur every once in a while. However, I am not sure WHY they occur... Let me explain myself. I've tried at very low speed first (15 WPM) and keying went seamless ... until I was strictly following Dot - Dash lengths by my fingers. Once I was not doing it precisely - there you go - you've got an extra space. Attempt to quickly "recover" erroneous symbol (like sending 6 dots or similar) resulted in a failure to do so. But if you stop and release paddles for a second, everything appeared to recover, and you can continue. This effect was not present as such when I used strict iambic B technique..
Then I started to gradually increase the speed. When I've got to 25 WPM (my most comfortable and relaxing speed), the "single paddle" effect was still there... Extra spaces occurred quite often. :( Back to iambic B technique - all is mighty good!
What I did next - I've dug out my old time home-made electronic keyer, which has separate relays for Dots and Dashes, constructed a cable that would emulate hand keying when connected to both Old Timer's keyer and 1/4" Keyer input in Flex. I have pre-recorded a 30 - 40 chars text and tried sending it. Synchronization was a big issue, of course! And once I've synchronized these correctly - all went fine!
What I believe is happening, Flex radio keyer lacks internal logic which will allow it to be more "forgiving" for minor glitches in keying technique.... If it get's "confused" by a paddle pressed at a "wrong time", it simply stops...
Iambic technique assumes both paddles depressed simultaneously when sending certain chars. ANd the technique itself is simpler and more forgiving for the operator. But if I was loosing strict following of the technique for a moment, bang... there we go... an extra space appears..
After I went up to 30 - 35 WPM - it became even worse. At 40 WPM - almost unusable.
I am not a World-Class CW high-speed operator, not at all. On top of that, once you get used to some keying techniques, it is difficult, almost impossible, to change "bad habits". Most of us are this way. What needs to be done, I believe, is to somehow make Flex internal keying more "forgiving" to a non-perfect operator.
And the last thing. For those of you, who are not familiar with iambic keying technique, here is the link to follow.
http://en.wikipedia.org/wiki/Telegrap...
Photo of Al / NN4ZZ

Al / NN4ZZ

  • 1852 Posts
  • 672 Reply Likes
Paul,
Thanks for the feedback. That confirms what many of us are seeing. I don't see this on any of my other radios with internal keyers or on any of the external keyers I use. I can't say what the exact cause but the internal keyer is not acceptable as it is.

Regards, Al / NN4ZZ
Photo of Steve - N5AC

Steve - N5AC, VP Engineering / CTO

  • 1055 Posts
  • 1080 Reply Likes
I agree with Paul's observations and have experienced this unforgiving nature in the keyer as well and this is likely in the keyer. I wasn't sure if I should chalk it up to my sloppy technique or the keyer, itself. Eric and I rewrote the keyer from scratch about two years ago for the FLEX-5000 and FLEX-3000 and we are using the same code (I think this is the only surviving code from PowerSDR we used). I would be interested to know if anyone who has both radios (a FLEX-6000 and one of the others) observes the same behavior. From what I know at this point, my suspicion is the keyer. Because the radio works excellent when keyed externally, it tends to impeach the keyer. Knowing if it is in the keyer or other control logic would be a help in diagnosis.
Photo of Ed, K0KC

Ed, K0KC

  • 287 Posts
  • 20 Reply Likes
Steve,

I own both a Flex-3000 and a Flex-5000. If I remember correctly, I received my 3000 about four years ago and upgraded to the 5000 about six months after that. Prior to going about 95% digital operation about two years ago, I used my Flex rigs almost every day on CW. I cannot recall an issue with the internal keyer.

I thought at first that I was "rusty" since I had not been on CW a lot the past couple of years, but I do not think that is the case. I also suspected that it was a keyer problem, but since you said that the code is essentially unchanged from PowerSDR, I wonder if that is really the case?

I also suspected that it might be an interrupt problem, but I do not have the knowledge of the rig architecture and software/firmware to verify if this is the case.

Good luck in your troubleshooting! We all know that you guys are expending maximum effort on this and other issues and as loyal customers we appreciate it.
Photo of Ed, K0KC

Ed, K0KC

  • 287 Posts
  • 20 Reply Likes
Please, please make this internal keyer work correctly for the 99% of us who do not use iambic (squeeze) keying, operate at QRQ speeds, and/or use QSK. I have never had a problem with any internal or external keyer in the past. If this problem still exists in v. 1.0 and shows-up in published reviews, Flex's reputation and sales will suffer.
Photo of EMIL-DL8JJ

EMIL-DL8JJ

  • 48 Posts
  • 11 Reply Likes
Hello guys,

I use the technique as a single lever with dash and dot memory. Many of the EU used this in single or squeeze.
My new Flex-6700 is on the way and I'll get it next week. Then I can tested and give a asap feedback here.
I run every day QRQ chat’s at about 60 WPM (300CPM) with local people in Germany. Dose chats take up to 1.5 hours.
My training speeds are is the time at 80 WPM (400 CPM) on single lever. This is the speed settings, but I reach on PARIS up to 70 WPM (350 CPM)
I'm testing the new developments of Begali and Scheunemann and electronic pressure paddle of 9A5N.

CW on Flex-6000 is very important. I have personally talked to Steve on the HAM Radio fair in Friedrichshafen how important CW are and should be included in the official release 1.x.
1. Internal key must have 60 WPM with dash and dot memory (ON/OFF opportunity).
2. Mode A / B as well.
3. Internal key must be work perfect on all speeds and should work not worse than K1EL or DF4KV key for DOS. Take a look and try it.
4. Full QSK is important - on all speeds. I can hear between the dots and dash and of course this must be the same on all speeds.
5. Side tone should be fine on all speeds.

Take your time one or two weeks more and make it perfect.
It will be appreciated.

Thanks and cu.
Emil, de DL8JJ
Photo of Steve - N5AC

Steve - N5AC, VP Engineering / CTO

  • 1055 Posts
  • 1080 Reply Likes
Thanks, Emil, I look forward to your feedback and it was good meeting you in F'hafen. We want to make the keyer perfect we'll do what it takes to get it there.
Photo of Paul RN3A

Paul RN3A

  • 56 Posts
  • 6 Reply Likes
Concur with Emil...
Photo of Al / NN4ZZ

Al / NN4ZZ

  • 1852 Posts
  • 672 Reply Likes
Steve,
There may be another clue to consider on the keyer SPACE issue. When it happens, frequently attempts to recover (i.e. resend the character, or even a series of DOTs) are often impacted. It almost feels like the keyer code is ignoring input, in a fixed timing loop, or otherwise trying to resynch. The event may be triggered by an interrupt or just by the very tight transition time required between the DOT and DASH paddle. But the recovery delay seems to indicate something else may be going on as well.

********** Paul mentioned it as well *********************************************************

Attempt to quickly "recover" erroneous symbol (like sending 6 dots or similar) resulted in a failure to do so. But if you stop and release paddles for a second, everything appeared to recover, and you can continue.

******************************************************************************************************

Does your development environment have code profiling tools to identify what the code is doing when it happens? It seems to happen about once per 200 characters at 20-25 WPM. And the trigger seems to be the transition from the DOT to to DASH paddle. Still a lot to look at but may be worth the effort.

Regards, Al / NN4ZZ
Photo of Steve - N5AC

Steve - N5AC, VP Engineering / CTO

  • 1055 Posts
  • 1080 Reply Likes
Yes we have some of the best profiling tools in the business, but we've not brought them to bear on this problem yet. From the additional feedback, sounds like time to do this.
Photo of Mickey N4MB

Mickey N4MB

  • 49 Posts
  • 10 Reply Likes
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.
Photo of mike_w1bfn

mike_w1bfn

  • 9 Posts
  • 1 Reply Like
A couple of days ago, Gerald advised me that in fact the hiccup problem had been solved, or made me believe that it had been., and that it was in 17.x

This discussion makes me think that 1.0 will show up with the problem intact.

I will recommend AGAINST purchasing this product until it has been fixed , to anyone who intends to use it for CW.

Sorry guys.. had to put this out.

Mike
Photo of W5UN_Dave

W5UN_Dave

  • 316 Posts
  • 30 Reply Likes
I usually use Winkey to key my 6700. Today I connected the paddle directly to the radio. It hiccuped several times as I was sending at 22 wpm. I am using 0.16. I hope this problem has been solved in subsequent coding.

Back in my younger day, I coded cw for my CWkey programs. The coding requires special ingenuity, so I know the difficulty Flex is facing. One almost has to program at the machine level to get it right, as I remember.

Dave, W5UN
Photo of Al / NN4ZZ

Al / NN4ZZ

  • 1852 Posts
  • 672 Reply Likes
Dave, I agree on the complexity. I did some assembly language programming years ago to implement a keyboard interface. It was also a lot more complicated than I anticipated (key de-bounce logic, key repeat timing, multi-key combinations, type ahead buffer, etc). At the time it had to be done in assembly language to perform.

Keyer logic is not trivial but I'm sure they will get it, it's just a matter time now.

Regards, Al / NN4ZZ
Photo of Gerald - K5SDR

Gerald - K5SDR, Employee

  • 830 Posts
  • 1514 Reply Likes
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.
Photo of Al / NN4ZZ

Al / NN4ZZ

  • 1852 Posts
  • 672 Reply Likes
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
Photo of Al / NN4ZZ

Al / NN4ZZ

  • 1852 Posts
  • 672 Reply Likes
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
Photo of Paul RN3A

Paul RN3A

  • 56 Posts
  • 6 Reply Likes
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
Photo of Ken - NM9P

Ken - NM9P, Elmer

  • 4236 Posts
  • 1351 Reply Likes
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?
Photo of Paul RN3A

Paul RN3A

  • 56 Posts
  • 6 Reply Likes
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
Photo of Sergey, R5AU

Sergey, R5AU

  • 860 Posts
  • 117 Reply Likes
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
Photo of Steve - N5AC

Steve - N5AC, VP Engineering / CTO

  • 1055 Posts
  • 1080 Reply Likes
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.
Photo of Steve - N5AC

Steve - N5AC, VP Engineering / CTO

  • 1055 Posts
  • 1080 Reply Likes
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!
Photo of Mickey N4MB

Mickey N4MB

  • 49 Posts
  • 10 Reply Likes
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.
Photo of Al / NN4ZZ

Al / NN4ZZ

  • 1852 Posts
  • 672 Reply Likes
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!

This conversation is no longer open for comments or replies.