|
I am consummately pleased with my K3. I am astounded with the raw performance and dazzled with the features. I look forward to remaining stunned with the product as more features are implemented. Considering the breadth of uses the K3 is applied towards by the large diversity of users with widely varying technical expertise and focus, Elecraft succeeds surpassing expectations masterfully. The fact they have incorporated in their development strategy a transparent and responsive forum easily accessible to the unqualified and very well qualified is revolutionary but sometimes reading this reflector is a little like getting my news at the pub.
Expectedly, just as in the pub, there is a wide diversity here of informed, misinformed, and those wishing to be informed but there is often too much conflicting misinformation containing personal views of second hand "facts" obscuring the successes with unfounded doubts which raise spurious issues. One recurring theme concerns the perception of software failures and as yet unimplemented features. Frequently, operational flexibility or designer prerogative is misconstrued as a failure or a bug and unimplemented features thus far have a history of being implemented. Earlier technology adopters have little problem sorting through these issues. They are usually the folks in the pub smiling and enjoying a pint before returning to the shack and playing radio. Latter technology adopters tend to be the animated somewhat noisy nervous crew spilling their ale and prone to moan at every retelling of the latest "disasterous" development. When walking by the pub many folks, usually the last adopters, write off the whole pub as too unstable to consider viable. All of us could benefit from the simple facts from the source. An Official List both of features to be enabled and recognized bugs might go a long way towards reducing the spurious responses and allaying the fear of features yet to be enabled. Such a list likely already exists among the developers. Or did I miss finding it? I love a good pint and a smile but sometimes I am the last to know. Jim Benson NS5U/1 My K3 Mojo is working My two cents and worth just what you paid for it. |
Jim, I don't think you'll ever stop hams from airing their opinions, informed or otherwise. :) While I have sometimes thought that something like an online bug tracker, as used by a lot of open source software projects (an example: http://bugs.freepascal.org/) would be a nice thing to have, a way for people to report issues they have found or make suggestions for enhancements and then track the progress being made, I suspect that implementing this and then maintaining it would be a lot of work for what is after all a very small development team, time that might be better spent writing and testing code. We're getting there, most people are happy now, but the nature of ham radio is that users have widely different priorities, and some will always find something to grumble about.
Julian, G4ILO. K2 #392 K3 #222 KX3 #110
* G4ILO's Shack - http://www.g4ilo.com * KComm - http://www.g4ilo.com/kcomm.html * KTune - http://www.g4ilo.com/ktune.html |
|
In reply to this post by NS5U/1 Jim Benson
> I am consummately pleased with my K3. I am astounded
> with the raw > performance and dazzled with the features. So am I. The K3 is the first radio I have ever bought without some silly engineering shortfall. The only things I see people complaining about are specialized personal use or application issues. It's impossible without years of field refinement to get on the very top of the curve, but they are already close and respond fast. > surpassing expectations masterfully. The fact they have > incorporated in > their development strategy a transparent and responsive > forum easily > accessible to the unqualified and very well qualified is > revolutionary I've been involved with other groups and it is often to get them to even consider major issues. It's so frustrating I vowed to never again work with a radio manufacturer. For example one manufacturer had an amplifier keying issue. The radio spit out RF before it told the amplifier to turn on. I knew it was happening because my homebrew amp has a "hot-switch" sensor that prevents keying (relay transfer) while RF is present, and I looked at it on a scope and could see the issue. It took almost a week of actual work to get them to look at the problem. The engineer responsible kept saying he checked it and it was fine, but it turned out he never did check. When they finally checked they fixed it, but historically everything they did worked that way. It worked that way with ALC issues that caused keyclicks, and it worked that way with a dozen other bugs some of which never were resolved. All three major Japanese manufacturers are out of touch the same way. It actually takes decades to address some very simple problems. Thankfully Elecraft has chosen a different approach. > and as yet unimplemented features. Frequently, > operational flexibility or > designer prerogative is misconstrued as a failure or a bug > and unimplemented > features thus far have a history of being implemented. That's the problem I see. While there are shortfalls in specialized areas, it is always an application specific and design critical area like a noise blanker or IF port use. What works well in one case might hurt other uses so they have to find a compromise, and that takes time. They have to learn all the different field applications, it can't really be planned because planning would take so much time the first radio would never leave the assembly line. 73 Tom . _______________________________________________ Elecraft mailing list Post to: [hidden email] You must be a subscriber to post to the list. Subscriber Info (Addr. Change, sub, unsub etc.): http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/subscribers.htm Elecraft web page: http://www.elecraft.com |
| Free forum by Nabble | Edit this page |
