Hi Bob,

Good to hear you weighing in.

Just on the subject of posting to Eagle, we need to understand why it keeps "bouncing" posts made to Eagle. Both Tom and I have tried and received bounces saying there are to many recipients. So there is NO, again NO overt attempt to restrict posts, just an apparent posting glitch, which I'm trying to work around with this post by eliminating all recipients except you (and then including the Eagle address). We'll see how that works.

So NO need for scolding from on high. No one has lost the desire to be open. We just ran into what I guess is a "posting format" issue.

Looking forward to your revelation(s)......................

Regards...Bill - N6GHz

Robert McGwier wrote:

Jim and I are reviewing the remarks but my first pass at this is to review history before I review the current situation in detail. We have had MANY spacecraft go in and out of eclipse. We have done thermal design work for all of them, and that work has been first class, and we have never EVER flown electronics where we allowed the temperature to move outside of its usable range. The very suggestion that we would is almost insulting. What I suggest is that we take a deep breath and analyze the situation without resorting to the sky is falling syndrome.

The receiver will operate within specifications and thermal stresses will be mitigated. The points about mounting the circuit board and the bending torques thermal stresses will reviewed. Any modifications to the hardware will be okayed post haste.

I want everyone to hold together here because I am going to hint at a secret that I hope is about to be revealed. DO NOT SNATCH DEFEAT FROM THE JAWS OF VICTORY. I believe we have extremely exciting developments about to come upon us for a ride to orbit <as in a launch contract>. Do not lose heart now. All programs for space undergo changes as gotchas come up. This is no reason to be discouraged but in my mind has always been a thrill because we have worked hard and overcome them. The only place in my mind where our management situation failed completely was on AO-40. It has never been completely comfortable but it is simply the nature of activities like this where almost everyone, if not everyone, is a volunteer.

Last: WHY is this conversation not happening in the Eagle mailing list? I object most strenuously because it is not consistent with our promise to design in the public eye. We cannot start this by hiding our work from other eagle team members who might be wondering if any work is going on at all. I will listen to any good reasons before I issue an irreversible order. We will have a small insurrection on our hands when a few of the members who have not been privy to the conversations (and who are potentially very large donors) find out such as Phil Karn and Franklin Antonio. I have Franklin's assurance we can build the ACP in Qualcomm labs with their having equipped it. I will not have him angered by secrecy. This should not have been allowed to continue.

73's Bob N4HY

Bill Ress wrote:

...

Juan, (et al.,)

It will be interesting to see the responses you get to your VERY appropriate post. Obviously you are wrestling with several very important issues.

I hope your subject title "We need to step back and reorganize," is meant to apply not just to your 70CM Rx but to the whole Eagle program.

I was going to add more of my few cents but I'll wait to see if and how upper management replys to your points.

We should all ask ourselves: why have there been so many amateur satellite failures since AO-40? In the current batch of recently launched CubeSats, many are non or semi operational. I don't know why they failed once in orbit after working fine on the ground. Could it be that some of the issues Juan brings up caught those design teams in the butt?

Hang in there Juan - we really need your great efforts, knowledge and frank and honest criticisms. I know you're just trying to help build a "reliable" satellite worthy of the many thousands of donor dollars that will go into Eagle.

Regards...Bill - N6GHz

Juan Rivera wrote:

...

Jim,

I'm writing to you at 4:00 AM because I've been laying awake for the past three hours worrying about this receiver project. Let me go over a few of the surprises that we've encountered after the requirements were peer reviewed and approved, my team was brought on board, the receiver was designed, parts ordered, and construction started:

1. Power can be interrupted every three seconds and the receiver has to

store enough charge to survive those outages.

2. The receiver is not the telecommand uplink receiver. That

receiver isn't even on UHF. It's on L-Band.

3. The lower temperature extreme it must survive is not -20C. It's

-70C.

4. The chassis it will be mounted in flexes.

5. It may or may not have to operate while subjected to PAVE PAWS

interference which is either impulse radar or chirping across the entire satellite UHF segment.

6. The receiver cannot depend on a boot from the HCU. It must be

autonomous.

7. The Can-do module power switch will be bypassed to provide

continuous power to the receiver. No, wait! The receiver will be shut down during eclipse and cold soaked to -70. Well, it's one of those two anyway.

I'm sure I'm forgetting a few items, but you get the idea. Obviously the original requirements document was incomplete. In my opinion this was a result of the unstructured and informal approach that was used, and the fact that the RF designer, John, wrote it instead of a system engineer looking at the satellite as a whole.

The receiver ATP peer review is another example. I know there are problems with that document. After all, I wrote it. Unfortunately I have not received one single comment suggesting an improvement, even though it has been posted on Eaglepedia since last year.

Now is the perfect time to create a structure that will avoid these problems from now on. It should start with a completely new receiver requirements document, an ICD (Interface Control Document), and an actual review of the ATP.

The requirements document needs to have input from everyone that has anything to do with the project - thermal, power, mechanical, control, EMI, etc. There should be a formal checklist to insure that no functional group is omitted from the process.

There needs to be another checklist that spells out exactly what needs to be included in the specification. If the two lists are complete, and adhered to, then all future requirements should be complete as well.

The requirements need to start by defining the RF environment that the receiver is expected to operate in. I've seen email suggesting that PAVE PAWS is impulse radar. The addendum that is attached to the ATP suggests otherwise, but it could be wrong. The nature of the RF environment the receiver will operate in needs to be defined clearly. The ATP references that addendum and has a test or two designed to characterize receiver operation under the conditions that addendum and John's requirements document outline. Are those assumptions incorrect? Does it really matter since this receiver is no longer the command uplink receiver? The entire design rests on assumptions that may or may not be accurate. All of these issues need to be addressed before John is turned on to begin the revision process.

I also question the mechanical layout of the receiver. Having the Can-do module at right angles to the receiver makes no sense in terms of space utilization. Perhaps it should be a daughter board that sits parallel to the main PCB. The DB15 also doesn't make any sense to me. I'm sorry but why use such a large connector? At the very least a 15-pin connector could be used that occupies a DB9 shell. That connector dictates having the Can-do module vertical, which in turn forces the chassis to be much higher than it needs to be. The front panel space is also severely restricted by the Can-do PCB, leaving very little room for connectors associated with the main PCB.

The case itself is flexible and that flex will be transferred to the PCB and from there to the SMD devices, many of which are very susceptible to mechanical damage from board flex. Lastly, the entire rear third of the chassis is empty - another waste of space. I know I'm stepping on toes but I'd much prefer milled aluminum boxes to sheet metal. They wouldn't necessarily be much heavier and would be much more rigid, providing badly needed stability to the PCBs. I fully expect to be shot down on this but it should be open to discussion while a new requirements document is created. Working with surface mount devices is completely different than the through-hole PCBs of the past. These devices have special needs that can only be ignored at your peril.

I don't mean this email to be a complaint because we've learned a tremendous amount in the process so far. I'm actually very excited about the chance we now have to really tighten up the requirements definition process and take a fresh look at this receiver. The lessons learned on this project will make life much easier for the next group. I'm convinced.

73,

Juan WA6HTP