[eagle] Re: We need to step back and reorganize

Bill Ress bill at hsmicrowave.com
Mon May 28 09:21:01 PDT 2007


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
>>>
>>>
>>>
>>>   
>>
>>
>
>



More information about the Eagle mailing list