The "classical" programming paradigm is to develop a solution FOR a fixed set of requirements. In the case of an AZ-EL rotor, this would conceivably result in the development of the modern version of "the same thing" in use for many years, and no new discovery, essentially some sort of computing device, calculating and putting out a control signal that would be translated to an actuator that would turn the attached boom in two axes, and therefore the antenna. Several problems will plague such a design, and will be difficult to scale up or modify to other systems - the torque required, the braking forces, the sensors (closed loop, open loop), and the different modes of operation required for low-angle passes, overhead and flip-passes. It's difficult to get a computer program to solve such diverse issues. And of course, the inertia of the system is almost always never taken into account at the level of ham radio homebrew development efforts.
If you agree with me upto this point ... (and with apologies to my robotics and dynamics instructors at GWU) would the community support a formal dynamics/mechatronics inter-disciplinary project to define an actuator mechanism (6DOF) and develop a antenna positioner robot to provide ad-hoc slewing of antennas? This type of project would require advanced concepts in dynamics such as an equation of motion/inertia/acceleration/, state vector/RK45 predictor estimation and trajectory planning. Also some of the mechatronics control systems would have to be modeled and the various forward and reverse kinematics equations solved for different required pass trajectories. And, the system would obviously have a command and control loop with absolute position sensors, so our beams could be that much tighter in specification.
Warning: the math is not for the faint of heart - but the challenge as I have described will an excellent framework to get high school/college/AMSAT STEM syllabii in line for an graduate engineering degree program.
73 de N3RDX
On Sun, Jun 2, 2013 at 6:51 AM, David Bern David.Bern@engineer.com wrote:
Correction: I told them that hardware comes and goes but software is forever.
On 06/02/2013 06:03 AM, David Bern wrote:
Louie:
All good ideas. The Raspberry Pi or BeagleBone Black little Linux computers gives us the possibility of running a tracking program such as predict
http://www.qsl.net/kd2bd/**predict.html<http://www.qsl.net/kd2bd/predict.html>or gpredict
http://gpredict.oz9aec.net/in addition to a protocol converter. I especially like the idea of controlling a telescope drive. This project could be useful to astronomy buffs.
I am teaching my students a software engineering principle that it is valuable to be as generic as possible; that is, to be platform agnostic and protocol agnostic. It is a more work in the short-term but the benefits are huge in the long-run. I told them that hard comes and goes buy software is forever. On Thursday, I told them, for example, that the initial version of a protocol converter would take a protocol in and then produce the same protocol out: to really understand a protocol, you need to be able to read and write the protocol. We dubbed this a "null" protocol converter and it should do nothing correctly, i. e. bits in and the same bits out. The plan is to implement a "null" protocol converter for the DiSEqC and the EasyComm protocols that we are learning. Once we have these two null protocol converters working then we have the pieces to easily configure a DiSEqC to EasyComm protocol converter.
David, WL2NX
On 06/01/2013 10:04 AM, Louis Mamakos wrote:
Perhaps this might be of help:http://gatorradio.org/** Manuals/Yaesu_GS-232B_Manual.**pdfhttp://gatorradio.org/Manuals/Yaesu_GS-232B_Manual.pdf
It might be cool to build the controller around an inexpensive Raspberry-Pi or BeagleBone Linux controller that has an ethernet interface available. You could export a simple REST-based HTTP API, as well as emulating the Yaesu serial protocol over a TCP connection. A simple HTTP API might make testing easier, perhaps. You could easily return status and debugging information if you used an extensible encoding format like JSON.
For bonus points, you could also implement the Meade or Celestron serial protocol to be able to drive the rotor like it was a telescope mount from various astronomy-oriented programs that might be useful for locating the moon, Jupiter or tracking satellites. It would be a shame to build something new a modern and saddle it with only an ancient serial protocol that might not be the best choice for today.
Just a thought.
louie wa3ymh
On May 31, 2013, at 10:50 AM, David BernDavid.Bern@engineer.com wrote:
Friends:
I am working on a summer project with students at Montgomery College, Rockville. The project is to design and build a device that controls a pair of inexpensive satellite TV rotors. And the device would emulate a popular AZ-EL rotor such as a Yaesu G-5500 AZ-EL controller so it can be used by a satellite tracking program such as SatPC32. Tom, K3IO suggested this project at the last AMSAT-DC workshop and is guiding us with this project.
I would like to borrow a Yaesu G-5500 AZ-EL controller and rotor for about three months or buy a used one so we can study and understand its command protocol.
I will pick up or pay for shipping. Please contact David, W2LNX directly at
W2LNX@amsat.org
Thank you, David, W2LNX ______________________________**_________________ Via the AMSAT-DC mailing list courtesy of AMSAT-NA AMSAT-DC@amsat.org http://amsat.org/mailman/**listinfo/amsat-dchttp://amsat.org/mailman/listinfo/amsat-dc
______________________________**_________________ Via the AMSAT-DC mailing list courtesy of AMSAT-NA AMSAT-DC@amsat.org http://amsat.org/mailman/**listinfo/amsat-dchttp://amsat.org/mailman/listinfo/amsat-dc