Date, bugs, and features

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Date, bugs, and features

Ed K1EP
I don't want to add to all the noise about deliveries and delays, but
I do want to make a suggestion.  First, as some of you know, I was
lucky to receive my K3 early on.  While I was able to enjoy it sooner
than most, my K3 had more problems and "features" to deal with than
the K3s that are being delivered now.  I accepted that in return for
what turned out to be a great radio.   The radio does perform as a
radio, it's just that it is not 100% of what was promised on the
datasheet.  Virtually all of us bought the radio sight unseen based
on this documentation.   However altruistic you think Elecraft is, it
is still a for profit business.  Part of the cult, mystique, mojo, or
whatever you want to call it about Elecraft is that eventually,
everything will be right and work itself out.   But we are a customer
and we are purchasing a product from them.   The angst seems to be
about the definition of "eventually" and whether that "eventuality"
is two weeks, two months, two years or even at all.  Some of us can
put up with two years by not ordering a K3 now and some feel that the
wait since last May has been long enough.  But as K3s are shipped
from Elecraft, we all would like to know what we are getting when we
get our K3 or what we get when we upgrade our firmware.  Datasheets
and flyers list all the great features and outstanding performance
specs of the K3.  We all know that some of what is listed does not
exist as of today.  The firmware update site lists *some* of the new
features and bug fixes, but not all of them.  Most of us, if not all,
believe that "eventually" they will be delivered and existing bugs
will be fixed.

The point of all this is, I would like to see a list.  An enumerated
list of specific features that are working as described (e.g. QSK),
features that are implemented but are still in process (e.g. DSP NR),
features that are not available (e.g. KDVR3), new features that are
coming but not being worked on (e.g. CW sidetone on Line Out), and
bugs that are known, waiting to be fixed (e.g. having a different
band on VFO B).  A realistic delivery date should go with all of
features yet to be implemented and a status and/or completion date
for all the bugs.  I believe that Don is maintaining some ad hoc list
of bugs on zerobeat.net (only two active bugs are listed right now),
but I think that this list should come direct from Elecraft itself,
contain all the reported and known bugs, and updated whenever any
status changes.   Some may say that this might impact development
work as it takes time to maintain this list.  I know of no
development group that doesn't already maintain a list of bugs and
ongoing projects.  When I discovered the VFO problem earlier this
week, I don't think that it had been documented in any public
forum.  And if it was on this mail list, I probably missed it due to
all low signal to noise ratio.   One thing I don't like to see is
someone replying to an bug inquiry with the phrase, "Oh, it's a known
bug, they are working on it."  If it is known to someone, it should
be known to all owners or to everyone.

Yes, the K3 was probably released sooner than it should have been,
but Elecraft made the decision, it has been released and we can't go
back in time.  As an engineering manager or company owner, you would
like to have your product on time, within budget, and performing to
spec.  But if you talk to the engineer developing the product, he or
she will tell you that you can have only two out of the three.  You
pick which two.   It seems we are debating the on time vs. spec part
of the K3.  Some of the items have come out on time but not fully
implemented to spec and some have been delayed in order to meet the
specs.  But in all cases, the price point has been met.   I, as
probably many, would like to see which items are considered delivered
to spec and which items are still in development or need to be
fixed.  Sort of a dynamic datasheet.

This doesn't directly address the question of when will I get my
K3.  And since I stated above, I already have my K3, why should I
care?  Well, I don't have my second receiver and I do have another K3
(with deposit) on order.  Yes, I too am disappointed, but I believe
it will be delivered, the exact date at this point is beyond my
control and not worth the anxiety.  I have way too many other things
in life to worry about :)



_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: Date, bugs, and features

Brett Howard
What is really needed is a Sourceforge page.  Where users can search for
bugs and submit bugs and the developers can assign resources to them and
put notes on them and put schedules on them but the main thing is that
everything is held in one easy to manage place.  The real issue though
is from the consensus in here things would be posted TONS of times, few
would search before reposing it.  I also think the time frames that some
of our features is going to take would upset most users and there would
be an uprising about that as well.  Dealing with a mess like this WOULD
hinder development.  

On Sat, 2008-01-19 at 09:02 -0500, Ed K1EP wrote:
> his doesn't directly address the question of when will I get my
> K3.  And since I stated above, I already have my K3, why should I
> care?  Well, I don't have my second receiver and I do have another K3
> (with deposit) on order.  Yes, I too am disappointed, but I believe
> it will be delivered, the exact date at this point is beyond my
> control and not worth the anxiety.  I have way too many other things
> in life to worry about :)

_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: Date, bugs, and features

M0XDF
I think SourceForge would be a little over the top, not to mention that the
K3 code is not in the public domain.

I agree a single place to see what requests have been made and what the
status is. There is a page at
<http://www.zerobeat.net/mediawiki/index.php/Firmware_Enhancements_on_Elecra
ft%27s_list_to_be_added.>
(yes that really is a period on the end :(

But I don't thing the layout lends itself to easy reading, I'll contact
zerobeat admins to see if the are ok with a page redesign (and maybe get rid
of the .) In fact they have probably read this now!


On 19/1/08 21:50, "Brett Howard" <[hidden email]> sent:

> What is really needed is a Sourceforge page.  Where users can search for
> bugs and submit bugs and the developers can assign resources to them and
> put notes on them and put schedules on them but the main thing is that
> everything is held in one easy to manage place.  The real issue though
> is from the consensus in here things would be posted TONS of times, few
> would search before reposing it.  I also think the time frames that some
> of our features is going to take would upset most users and there would
> be an uprising about that as well.  Dealing with a mess like this WOULD
> hinder development.
>
> On Sat, 2008-01-19 at 09:02 -0500, Ed K1EP wrote:
>> his doesn't directly address the question of when will I get my
>> K3.  And since I stated above, I already have my K3, why should I
>> care?  Well, I don't have my second receiver and I do have another K3
>> (with deposit) on order.  Yes, I too am disappointed, but I believe
>> it will be delivered, the exact date at this point is beyond my
>> control and not worth the anxiety.  I have way too many other things
>> in life to worry about :)
--
I need someone to protect me from all the measures they take in order to
protect me. -Banksy, street artist (b. 1974)


_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

[K3] Another Bug? WAS: Re: Date, bugs, and features

Ed K1EP
At 1/20/2008 05:27 AM, David Ferrington, M0XDF wrote:

>I think SourceForge would be a little over the top, not to mention that the
>K3 code is not in the public domain.
>
>I agree a single place to see what requests have been made and what the
>status is. There is a page at
><http://www.zerobeat.net/mediawiki/index.php/Firmware_Enhancements_on_Elecra
>ft%27s_list_to_be_added.>
>(yes that really is a period on the end :(
>
>But I don't thing the layout lends itself to easy reading, I'll contact
>zerobeat admins to see if the are ok with a page redesign (and maybe get rid
>of the .) In fact they have probably read this now!

Yes, the page on zerobeat is too verbose.  The details could be
linked to other places, but a summary listing would be better, I think.

As another example, I found what I thought was another bug last
night.  I sent it to k3support, but again, maybe others have seen
it.  Maybe it isn't a bug but pilot error or maybe there is a work around.

I found that when I was in SSB and turned the Filter LO CUT down
below 0.15, it suddenly jumped up to 1.65.  I didn't hear a
corresponding change in noise (and didn't see one in a spectrogram),
so I assume it was a display type bug.  I searched in the mail list
archives and didn't see any reference to this.

_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: Date, bugs, and features

David Woolley (E.L)
In reply to this post by Brett Howard
Brett Howard wrote:
> What is really needed is a Sourceforge page.  Where users can search for

Sourceforge isn't a possibility, as they only accept open source
software.  However, Elecraft could run their own Bugzilla server.

> is from the consensus in here things would be posted TONS of times, few
> would search before reposing it.  I also think the time frames that some

Bug reporting systems don't solve the problem of duplicate reports,
except in as much as the the system maintainer can link duplicates together.

--
David Woolley
"The Elecraft list is a forum for the discussion of topics related to
Elecraft products and more general topics related ham radio"
List Guidelines <http://www.elecraft.com/elecraft_list_guidelines.htm>
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: Date, bugs, and features

Thom LaCosta
In reply to this post by M0XDF
On Sun, 20 Jan 2008, David Ferrington, M0XDF wrote:

> I think SourceForge would be a little over the top, not to mention that the
> K3 code is not in the public domain.
>
> I agree a single place to see what requests have been made and what the
> status is. There is a page at
> <http://www.zerobeat.net/mediawiki/index.php/Firmware_Enhancements_on_Elecra
> ft%27s_list_to_be_added.>
> (yes that really is a period on the end :(

There is a page of the same name without the period....Why not use that one?


Thom,EIEIO
Email, Internet, Electronic Information Officer

www.baltimorehon.com/                    Home of the Baltimore Lexicon
www.tlchost.net/hosting/                 Web Hosting as low as 3.49/month
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: Date, bugs, and features

Dick Green WC1M
In reply to this post by Ed K1EP
Like W4ZV, I was a beta tester for that other SDR. Bear in mind my post of a
few weeks ago in which I cautioned about avoiding "groupie-ism" and holding
manufacturers to high standards. Here's my 2-cents on the subject:

 

1. I agree with W4TV that Elecraft should update the approximate delivery
dates for all backordered K3s. I'm as anxious to get mine as anyone, but I
was aware that I wouldn't be getting instant gratification when I placed the
order and was prepared to wait. The main reason I need this information is
not to relieve anxiety. I need it for planning purposes. As a busy guy with
lots of work and family demands, I have to schedule time to build my K3.
Also, my SO2R contest station is pretty complex, so I need to know whether
the K3 will be available for certain contests. It makes a difference in
terms of configuration changes I'm planning. I don't see any reason why
Elecraft can't publish a real shipping status table indicating week of order
and approximate delivery date (early <month>, mid <month> or late <month>),
with plenty of disclaimers. However, if they perceive something proprietary
about this information, Joe's suggestion for privately notifying those with
outstanding orders makes sense. Many companies inform customers with
backordered products when the expected ship date changes. It's a common
courtesy and an excellent business practice. Building it into Elecraft's
order process now would be a good investment for the future. The worst way
to deal with it is silence or, "It's going to be later than the date we told
you -- figure it out from small bits of data gleaned from others on the
reflector."

 

2. On the Sub-RX, I'm mighty impressed with how Elecraft has informed us of
the status, including details on the issues they're addressing. I've not
seen another manufacturer of ham gear disclose so much about hardware
development (at least, not in the era of solid-state transceivers.) I
encourage Elecraft to keep doing this, despite the backlash from
disappointed customers who expected the Sub-RX sooner. Disclosure was my
main beef with the other SDR manufacturer. For example, they wouldn't tell
us when they discovered and fixed hardware problems. We never knew when a
hardware update was released, except when a repair workorder included the
mysterious "updated such-and-such board". In the case of critical flaws, I
expect the manufacturer to replace/update  boards free of charge (i.e.,
issue a recall.) For performance or reliability enhancements, boards should
be replaced/updated free of charge if the unit is under warranty. If the
unit is out of warranty, the customer should be offered the opportunity to
have the board replaced/updated at a reasonable price. I would gladly have
paid for replacement boards to keep my radio up to date. But the most
important aspect is disclosure: tell us what's going on. I don't see this as
significant proprietary information that can benefit a competitor. I can
understand withholding the information until an approximate delivery date is
known, but total silence isn't acceptable. Like I said, Elecraft has done a
nice job on the Sub-RX issue and I encourage them to continue the open
discussion. It helps them far more than it hurts them.

 

3. I think it has been well-known that the K3 is a brand-new product that
will initially lack certain features listed in the spec sheet. Those who
ordered the radio last May should have understood this. I, for one, was
planning on waiting for at least one to two years before buying a K3 so the
bugs would be shaken out. I ordered a K3 sooner than planned because I've
given up on any further improvements to that other SDR I keep referring to,
and I'm willing to put up with some inconvenience to get a K3 sooner rather
than later. What pushed me over the edge was observing how Elecraft has been
handling hardware and firmware issues for the K3. I have to tell you folks
that it's *way* better than that other manufacturer.

 

4. Posting the bug/enhancement list is a tricky issue. I've been in the
software business for about 30 years, and have dealt with this as a
technician, manager, CEO and board member. There can be a lot of proprietary
information in such lists, especially planned enhancements. Further, it's
risky to set expectations of when certain bugs will be fixed or enhancements
implemented. Murphy rules the world of software development like no other
engineering domain. It's business-as-usual for unforeseen problems to be
encountered over which you have limited control, such as bugs in a compiler
from another manufacturer. Sometimes, despite the most careful design and
implementation, a bug may be so engrained in the software architecture that
it will take a major rewrite to fix it. It's not unusual for this to be
discovered only after significant time has been spent investigating the
cause, and an initially optimistic forecast for a fix has to be thrown out
the window. So, what to do? My feeling is that, at a minimum, reported bugs
must be acknowledged, along with a statement as to whether it will be fixed
or not, along with a priority number. There's nothing more frustrating to a
customer than reporting a bug and being stonewalled by the vendor. I think a
priority assignment is important because the manufacturer may not have a
realistic understanding of how a bug affects users, so if a low priority is
assigned the customer will have an opportunity to plead his/her case for a
higher priority. Often engineers don't know what customers actually do with
their products, so this is very valuable feedback. Beyond that, I would be
reluctant to publish the target release or release date. The risk of setting
expectations too high is great when you do that. However, once the developer
has had a chance to review requirements for fixing the problem, and perhaps
has already mapped out what to do, then I think there's somewhat less risk
in publishing an expected release and/or release date.

 

73, Dick WC1M

 

_______________________________________________
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