[eagle] Re: YAHOO!!!! IT WORKS!!!!
kd6ire at sbcglobal.net
Sun Sep 16 19:54:39 PDT 2007
You are correct that some documentation is necessary. The reason we did not
relate to this concern earlier was that when we received the Widget for the
UHF Receiver I first communicated with it using CDNC and in doing a Query
the module returned its presence and created log records with the correct
address in them.
I then used these original Log records to create the data stream to include
the initialization data for the U-Rx. The fact that these records already
contained the correct address, via CDNC Query, made the concept of Widget
Address a non issue.
Our lack of understanding was not obvious until we attempted to use our
initialization stream on a different widget and the receiver failed to
function. There was no noticeable indication from the CDNC program that the
widget addressed was not available.
It is now apparent that we will need to document this area and I will add
some documentation to the CAN-DO part of the U-RX ATP. Others will want to
use this experience to guide them in documenting their part of the Eagle
From: eagle-bounces at amsat.org [mailto:eagle-bounces at amsat.org] On Behalf Of
Sent: Sunday, September 16, 2007 5:53 PM
To: Jim Sanford
Cc: Robert McGwier; eagle at amsat.org
Subject: [eagle] Re: YAHOO!!!! IT WORKS!!!!
The mode and address must be soldered onto the widget (jumper pads
provided on the widget for this purpose). It is assumed that the module
builder would do this. It's that assumption that should be documented.
I say this to bring up the follow-on issue.
The module builder chooses the mode.
The address should be specified by the system administrator since the
addresses must be unique for each module and the priority is a function
of the address. Module builders should give input to the system
administrator as to what they feel their priority should be, but
presumably only the system administrator is in a position to know the
priority requirements of *all* modules and is therefor in a position to
make these priority (address) decisions.
Jim Sanford wrote:
> There's a lesson here: DOCUMENTATION
> Juan expected/assumed one thing, the CAN-Do! widget was something
> else. Other teams will go through exactly the same issue. SO, it
> appears we need to add some documentation to each WIDGET in terms of
> serial number, address, and probably a handful of other things I don't
> know about.
> Let's learn from this experience.
> Juan, thanks to you and your team for perservering.
> Stephen, thanks for your prompt support on a short fuse.
> This kind of response and mutual support is exemplary, and what it
> will take to get Eagle on orbit.
> Thanks & very 73,
> wb4gcs at amsat.org
> Dave hartzell wrote:
>> Wow, this is a relief. I'm glad it was something simple....after all
>> the hunting and pecking we did yesterday, I'm glad it was something so
>> I guess when the term "bus" is used, an address as probably key to
>> getting to your destination. ;-)
>> On 9/16/07, Juan Rivera <juan-rivera at sbcglobal.net> wrote:
>>> We need to take up a collection to buy Stephen a large hero badge. He
>>> the problem and the receiver is now sitting on my bench happily
>>> signal. The new CAN-Do module that he sent me had a different address
>>> the old one and the old files were addressing the initialization
>>> instructions to a non-existent device. All we have to do is change the
>>> address field in the initialization files and everything is fine.
>>> Whew! The train of life in back on the tracks!
>>> 73 to all,
>>> Via the Eagle mailing list courtesy of AMSAT-NA
>>> Eagle at amsat.org
> Via the Eagle mailing list courtesy of AMSAT-NA
> Eagle at amsat.org
Via the Eagle mailing list courtesy of AMSAT-NA
Eagle at amsat.org
More information about the Eagle