Don: I agree, and thanks.
I think the CAN-Do! manual also needs to be updated, because the next team to integrate a widget will be just as unfamiliar. Thanks & 73, Jim wb4gcs@amsat.org
Don Ferguson wrote:
Jim,
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 project.
Don
-----Original Message----- From: eagle-bounces@amsat.org [mailto:eagle-bounces@amsat.org] On Behalf Of Chuck Green Sent: Sunday, September 16, 2007 5:53 PM To: Jim Sanford Cc: Robert McGwier; eagle@amsat.org Subject: [eagle] Re: YAHOO!!!! IT WORKS!!!!
Hi Jim,
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.
Chuck
Jim Sanford wrote:
Guys: 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, Jim wb4gcs@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 simple.
I guess when the term "bus" is used, an address as probably key to getting to your destination. ;-)
Dave
On 9/16/07, Juan Rivera juan-rivera@sbcglobal.net wrote:
All,
We need to take up a collection to buy Stephen a large hero badge. He
fixed
the problem and the receiver is now sitting on my bench happily
receiving a
signal. The new CAN-Do module that he sent me had a different address
than
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,
Juan
Via the Eagle mailing list courtesy of AMSAT-NA Eagle@amsat.org http://amsat.org/mailman/listinfo/eagle
Via the Eagle mailing list courtesy of AMSAT-NA Eagle@amsat.org http://amsat.org/mailman/listinfo/eagle
Via the Eagle mailing list courtesy of AMSAT-NA Eagle@amsat.org http://amsat.org/mailman/listinfo/eagle