Welcome to the new FlexRadio Community! Please review the new Community Rules and other important new Community information on the Message Board.
If you are having a problem, please refer to the product documentation or check the Help Center for known solutions.
Need technical support from FlexRadio? It's as simple as Creating a HelpDesk ticket.

V1.0 next week - why the rush?

Al_NN4ZZ
Al_NN4ZZ Member ✭✭✭
edited June 2020 in SmartSDR for Windows
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.
«1

Answers

  • Kirk, K6KAR
    Kirk, K6KAR Member ✭✭
    edited May 2014
    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.
  • Gerald-K5SDR
    Gerald-K5SDR FlexRadio Employee ✭✭
    edited April 2019
    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."
  • Eric-KE5DTO
    Eric-KE5DTO Administrator, FlexRadio Employee admin
    edited June 2019
    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.
  • Al_NN4ZZ
    Al_NN4ZZ Member ✭✭✭
    edited March 2017
    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
  • Gerald-K5SDR
    Gerald-K5SDR FlexRadio Employee ✭✭
    edited April 2019
    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.
  • W5XZ - dan
    W5XZ - dan Member ✭✭
    edited June 2019
    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
  • k0eoo
    k0eoo Member ✭✭
    edited March 2017
    Very interesting thread.... Thanks Gerald and Eric for the detail, I feel better already...
  • Gerald-K5SDR
    Gerald-K5SDR FlexRadio Employee ✭✭
    edited December 2016
    We truly appreciate everyone's participation in the Preview release process. It has been extremely helpful in many ways. 73, Gerald
  • K1UO Larry
    K1UO Larry Member ✭✭✭
    edited December 2016
    Are the manuals ready to go with the Ver 1 release?
  • W5XZ - dan
    W5XZ - dan Member ✭✭
    edited December 2016
    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
  • Gerald-K5SDR
    Gerald-K5SDR FlexRadio Employee ✭✭
    edited December 2016
    Yes. We are finalizing now and working on formatting.
  • K4EAR
    K4EAR Member ✭✭
    edited April 2014
    Addendums should be timely also as 1.0 evolves.
  • Dale KB5VE
    Dale KB5VE Member ✭✭
    edited April 2014
    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.
  • George KF2T
    George KF2T Member ✭✭✭
    edited December 2016
    Congratulations on the 1.0 milestone! Looking forward to raising a glass towards Austin on Monday evening.
  • Paul RN3A
    Paul RN3A Member
    edited September 2017
    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!
  • Al_NN4ZZ
    Al_NN4ZZ Member ✭✭✭
    edited December 2016
    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/flexradio/topics/v0_16_4_extra_space_on_cw 50 WPM QSK is nice also but many us will use 15-30 WPM and the internal keyer more often. Regards, Al / NN4ZZ
  • Paul RN3A
    Paul RN3A Member
    edited September 2013
    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, ****... 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/Telegraph_key
  • Al_NN4ZZ
    Al_NN4ZZ Member ✭✭✭
    edited December 2016
    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
  • Ed, K0KC
    Ed, K0KC Member ✭✭
    edited September 2017
    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.
  • EMIL-DL8JJ
    EMIL-DL8JJ Member ✭✭
    edited February 2017
    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
  • Steve-N5AC
    Steve-N5AC Community Manager admin
    edited December 2016
    We *are* working for you ;-)
  • Steve-N5AC
    Steve-N5AC Community Manager admin
    edited December 2016
    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.
  • Steve-N5AC
    Steve-N5AC Community Manager admin
    edited December 2016
    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.
  • Paul RN3A
    Paul RN3A Member
    edited September 2013
    Concur with Emil...
  • Ed, K0KC
    Ed, K0KC Member ✭✭
    edited May 2014
    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.
  • Al_NN4ZZ
    Al_NN4ZZ Member ✭✭✭
    edited March 2017
    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
  • Steve-N5AC
    Steve-N5AC Community Manager admin
    edited December 2016
    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.
  • mike_w1bfn
    mike_w1bfn Member
    edited September 2013
    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
  • W5UN_Dave
    W5UN_Dave Member ✭✭
    edited February 2019
    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
  • Al_NN4ZZ
    Al_NN4ZZ Member ✭✭✭
    edited December 2016
    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
This discussion has been closed.