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
Great news guys!
73's and thanks Stephen. I hope you feel better soon. Thanks for coming out of the sick bed to avoid crisis!
Bob
Juan Rivera 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
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 [email protected] 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 [email protected] http://amsat.org/mailman/listinfo/eagle
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 [email protected]
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 [email protected] 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 [email protected] http://amsat.org/mailman/listinfo/eagle
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 [email protected]
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 [email protected] 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 [email protected] http://amsat.org/mailman/listinfo/eagle
Via the Eagle mailing list courtesy of AMSAT-NA [email protected] http://amsat.org/mailman/listinfo/eagle
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: [email protected] [mailto:[email protected]] On Behalf Of Chuck Green Sent: Sunday, September 16, 2007 5:53 PM To: Jim Sanford Cc: Robert McGwier; [email protected] 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 [email protected]
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 [email protected] 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 [email protected] http://amsat.org/mailman/listinfo/eagle
Via the Eagle mailing list courtesy of AMSAT-NA [email protected] http://amsat.org/mailman/listinfo/eagle
_______________________________________________ Via the Eagle mailing list courtesy of AMSAT-NA [email protected] http://amsat.org/mailman/listinfo/eagle
Dave,
This is a classic example of why a peer review is so important. You need to get folks that are not directly involved in your project to look it over with fresh eyes. We were too narrowly focused and missed the obvious. If multiple nodes all exist on the same twisted pair cable they much have different addresses. Duh...
73, Juan - WA6HTP
-----Original Message----- From: Dave hartzell [mailto:[email protected]] Sent: Sunday, September 16, 2007 5:06 PM To: [email protected] Cc: [email protected]; Robert McGwier Subject: Re: [eagle] YAHOO!!!! IT WORKS!!!!
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 [email protected] 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 [email protected] http://amsat.org/mailman/listinfo/eagle
Jim,
In this case it wouldn't have helped since I wouldn't have gotten to the point of reading the documentation for a long time since we already had everything running. As I mentioned in another email, it does point out the benefit of the peer review. Although this is not a classic example, Stephen was able to look at our problem with a fresh perspective, unbiased by our prior experience with the receiver and spot the problem that we should all have thought of but didn't. I've seen this exact thing happen over and over. The fact that Stephen was not involved in the receiver project that was his strength. Knowing the CAN-Do network inside and out was of course a huge plus too!
73,
Juan
_____
From: Jim Sanford [mailto:[email protected]] Sent: Sunday, September 16, 2007 5:28 PM To: Dave hartzell Cc: [email protected]; [email protected]; Robert McGwier Subject: Re: [eagle] Re: YAHOO!!!! IT WORKS!!!!
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 [email protected]
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 mailto:[email protected] [email protected] 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 [email protected] http://amsat.org/mailman/listinfo/eagle
Chuck,
Good point and another argument for top-level system engineering. There should be network documentation showing address and priority assignments for each payload. This should be a top-level function along with allocating the amount of power each payload can consume. None of these global issues should be left to the individual subsystem teams to determine.
Juan - WA6HTP
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Chuck Green Sent: Sunday, September 16, 2007 5:53 PM To: Jim Sanford Cc: Robert McGwier; [email protected] 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 [email protected]
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 [email protected] 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 [email protected] http://amsat.org/mailman/listinfo/eagle
Via the Eagle mailing list courtesy of AMSAT-NA [email protected] http://amsat.org/mailman/listinfo/eagle
_______________________________________________ Via the Eagle mailing list courtesy of AMSAT-NA [email protected] http://amsat.org/mailman/listinfo/eagle
On Sun, 2007-09-16 at 20:27 -0400, Jim Sanford wrote:
Guys: There's a lesson here: DOCUMENTATION
The only additional documentation I can think of that might help in this sort of case would be something like a CAN bus troubleshooting flowchart. Having something like that wouldn't help avoid this kind of problem, but it might reduce the time to resolution.
It does sound like the software Juan is using could use better error reporting in the case where there's apparently no module responding at the address selected.
Pretty typical in projects like this for us to get a lot of mileage out of software and process documentation that's just barely adequate to the task and lacking in "frills" like good user interfaces and/or error reporting. That doesn't make it right, but I don't think there are any magic fixes, either.
Bdale
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 [email protected]
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: [email protected] [mailto:[email protected]] On Behalf Of Chuck Green Sent: Sunday, September 16, 2007 5:53 PM To: Jim Sanford Cc: Robert McGwier; [email protected] 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 [email protected]
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 [email protected] 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 [email protected] http://amsat.org/mailman/listinfo/eagle
Via the Eagle mailing list courtesy of AMSAT-NA [email protected] http://amsat.org/mailman/listinfo/eagle
Via the Eagle mailing list courtesy of AMSAT-NA [email protected] http://amsat.org/mailman/listinfo/eagle
Bdale: I don't disagree with anything you say.
I had in mind something along the lines of installation and/or configuration instructions. Based on Chuck's note, it appears that the user needs to specify address and mode before delivery.
Thanks & 73, Jim [email protected]
Bdale Garbee wrote:
On Sun, 2007-09-16 at 20:27 -0400, Jim Sanford wrote:
Guys: There's a lesson here: DOCUMENTATION
The only additional documentation I can think of that might help in this sort of case would be something like a CAN bus troubleshooting flowchart. Having something like that wouldn't help avoid this kind of problem, but it might reduce the time to resolution.
It does sound like the software Juan is using could use better error reporting in the case where there's apparently no module responding at the address selected.
Pretty typical in projects like this for us to get a lot of mileage out of software and process documentation that's just barely adequate to the task and lacking in "frills" like good user interfaces and/or error reporting. That doesn't make it right, but I don't think there are any magic fixes, either.
Bdale
All,
In our case we were confused because the log showed packets coming and going, at least I think it did. If the application can tell that nothing is getting acknowledged perhaps it could pop an alert box up. That would have done it for us in this particular instance.
Juan
_____
From: [email protected] [mailto:[email protected]] On Behalf Of Jim Sanford Sent: Monday, September 17, 2007 3:24 PM To: Bdale Garbee Cc: Robert McGwier; [email protected] Subject: [eagle] Re: YAHOO!!!! IT WORKS!!!!
Bdale: I don't disagree with anything you say.
I had in mind something along the lines of installation and/or configuration instructions. Based on Chuck's note, it appears that the user needs to specify address and mode before delivery.
Thanks & 73, Jim [email protected]
Bdale Garbee wrote:
On Sun, 2007-09-16 at 20:27 -0400, Jim Sanford wrote:
Guys: There's a lesson here: DOCUMENTATION
The only additional documentation I can think of that might help in this sort of case would be something like a CAN bus troubleshooting flowchart. Having something like that wouldn't help avoid this kind of problem, but it might reduce the time to resolution.
It does sound like the software Juan is using could use better error reporting in the case where there's apparently no module responding at the address selected.
Pretty typical in projects like this for us to get a lot of mileage out of software and process documentation that's just barely adequate to the task and lacking in "frills" like good user interfaces and/or error reporting. That doesn't make it right, but I don't think there are any magic fixes, either.
Bdale
Hi Jim,
Chuck's note stated that the user determines mode. It can be set before delivery but the user can also do it themselves as long as they know it needs to be done. The address needs to be specified by the *system administrator*. Again, it can be set before delivery but can also be done by the user if they know it needs to be done.
Chuck
Jim Sanford wrote:
Bdale: I don't disagree with anything you say.
I had in mind something along the lines of installation and/or configuration instructions. Based on Chuck's note, it appears that the user needs to specify address and mode before delivery.
Thanks & 73, Jim [email protected]
Bdale Garbee wrote:
On Sun, 2007-09-16 at 20:27 -0400, Jim Sanford wrote:
Guys: There's a lesson here: DOCUMENTATION
The only additional documentation I can think of that might help in this sort of case would be something like a CAN bus troubleshooting flowchart. Having something like that wouldn't help avoid this kind of problem, but it might reduce the time to resolution.
It does sound like the software Juan is using could use better error reporting in the case where there's apparently no module responding at the address selected.
Pretty typical in projects like this for us to get a lot of mileage out of software and process documentation that's just barely adequate to the task and lacking in "frills" like good user interfaces and/or error reporting. That doesn't make it right, but I don't think there are any magic fixes, either.
Bdale
Via the Eagle mailing list courtesy of AMSAT-NA [email protected] http://amsat.org/mailman/listinfo/eagle
participants (7)
-
Bdale Garbee -
Chuck Green -
Dave hartzell -
Don Ferguson -
Jim Sanford -
Juan Rivera -
Robert McGwier