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
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.
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:
"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.
"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."
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.
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
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.
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!
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
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
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.
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.
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.
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?
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
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.
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.
This conversation is no longer open for comments or replies.