Re: SDR-console 3.0.26 & 3.0.27 : cracks in audio


On 20210610 06:01:05, Rich NE1EE wrote:
On 2021-06-10 12:43:+0100, you wrote:

Way back around 1971 I was part of the 3 month study team for specifying and costing the Ptarmigan System.
<snip> I didn't notice if the expert was wearing rose tinted spectacles...
Allan G3PIY
Important note! I closed my engineering company years ago. My comments here are not directed toward individuals, nor are they meant to pat my company's back. There is a legacy that does that just fine. I am hoping to put ideas on the table, and support them with professional experience.

In the late 1990s,  a CEO of an industrial systems company, familiar with our work, contacted us regarding a $10M project that had gone astray, and wondered if we'd be willing to take it on. I said I'd check out, and get back. I went personally, because of my perception of the delicacy needed, in light of their internal struggles. The VP of engineering whom I met, looked at me and said that it was clear I had been around the block (greying hair, y'see), and wondered what I brought to the table. So we chatted. I decided that I'd spend some time just getting to know folks and the situation, and eventually we took on the project. I said that in the beginning, they should not think of us as taking over, but rather as well-paid secretaries, taking notes about the project.

At one point, early in the game, by mathematically modelling a system, we found a major design flaw. Rather than say that, we said that we had apparently made a mistake in our calculations, and asked for help finding the error. The story is long and colorful, but the result was that they discovered their design flaw. It was a turning point for us, as they began to see the value of our engineering approach.

Somewhere along the line, one of their engineers brought me an engineering journal (I forget the name), with an article about the Cheyenne Mountain Upgrade Program, which was in serious trouble by 1994. (Please see "Status of the Cheyenne Mountain Upgrade Program (Letter
Report, 09/01/94, GAO/AIMD-94-175)").

In the article, the /new/ contractor, who was apparently ahead of schedule and below projected costs, was asked why they were doing so well. (I understand that the project was completed by 1999.) The reply, as I remember the article, was to the effect that they constantly were in communication internally, and constantly critically reviewed requirements, designs, and proposed development. The engineer who gave me the article mentioned that it was exactly what we were saying was responsible for our successes. We wound up deeply embedded in the $10M project, and delivered significant critical parts of the final system. They continued to be a great client for many years.

As you can imagine, I have a large store of such stories that I will do my best to refrain from sharing. ;-) I believe that significant contributions to my company's success were a) learning from others' mistakes, so that I didn't repeat them, and b) learning from others' successes, so that I didn't reinvent the wheel. That freed up a lot of time to really enjoy turning out some very rewarding projects.

It is nice when the requirements are not changing weekly due to marketing influences. The projects that had little of that always seemed to turn out far better than the opposite.

Ham (and lab) projects seem to show a lot of "hey, how about adding this feature" cruft hanging all over them. Some survive this better than others.


Join to automatically receive all group messages.