[TenTec] Ten-Tec Transceiver Survey

[Rick Denney]

Martin Ewing AA6E writes...

> SDR is different because many if not most of the capabilities of the rig
> are determined by software, and users' requirements (interests) change
> over time.  New features and modes pop up all the time.  They're limited
> mainly by your imagination and your programming budget.

There is nothing about a properly constructed systems engineering
process that prevents iteration. But also recognize that those who
want a true SDR in the sense of a computer that happens to do radio
are probably sending their money to Flex, while the Orion is
configured more as a standalone radio (yes, even though one of the
FlexRadio 5000's has the PC built into it).

But the iterations will be focused on breakthroughs in RF processing
(i.e., new requirements), rather than on fixing bugs (unmet old
requirements). I think that's a very big difference.

(By the way, the process I am describing is how systems engineers
finally learned to manage software development efforts FAR more
complex than an amateur radio. In fact, this process is an IEEE
standard.)

> All that to one side, I'm not sure there ever was an Orion
> Specification, at least not a public one.

That's what I meant when I hinted that the Ten Tec programmers might
also be so wrapped up in design that they forget to model the
activities of the users in non-design terms first. That's why I don't
even want to use the word "specification" until have worn out "needs"
and "requirements".

>  Where does it say what the
> NR, Notch, NB buttons are specified to do?

Exactly my point. These are associated with what operators do with
radios, not with the design of the radio. I want the offending carrier
tone to disappear without causing any harm to the signal I want to
hear instead. I don't care how it's done. How to do it is the design
problem, not what it means.

>   (A technical specification,
> not just "reduce noise".)  What is the spec on SSB audio response, 
> distortion, etc.?  These features were probably engineered just to the
> point of being "good enough" for the market.  (And they are mostly good
> enough for me!)

Giving them even more credit, I would suspect they are engineered to
be the best they can possibly be on a radio like an Orion, and the
best they can be at a price point for lesser radios. And in some cases
they may well attain those goals. Even that sort of a goal can be a
requirement. But we can also be specific--and even the most ardent
computer hater probably has a good understanding of what they want in
terms of dynamic range, selectivity, notch-band suppression, and so
on.

> If you have doubts about Open Source programming, you can compare 
> Firefox, Apache, and Linux to Internet Explorer, IIS, and Windows 
> (Vista?).  Politics aside, which products show the best design methodology?

All of them cost much more to develop than they needed to, and
iterated too many times before reaching a stable product (of course,
Vista is going backwards in that department, but that's another
debate). That's true even if many of the developers donated (their
employer's) time. They measure progress in terms of "long-term-stable
version" rather than in terms of "fulfill all requirements in
Requirements Document v.2.04". As I said in a message you haven't seen
yet, the open development is a method for designing code, while I'm
advocating an open process for developing needs and requirements to
serve as the basis for that design. I like open software, but open or
closed, it will hit the target more accurately and with fewer bugs if
we get the requirements nailed down first.

Okay, I get preachy on this topic because my own industry is replete
with massive failed software development projects that screwed up this
aspect of development. I'm rather evangelical on the topic and that
has led me to be a little persistent. But I think I've repeated my
points the required dozen or so times to scratch the persistence itch,
and I'll back away now unless there's something specific. Thanks for
your indulgence.

Rick, KR9D