[amsat-dc] Re: wanted: to borrow or buy a Yaesu G-5500 AZ-EL controller and rotor

David Bern David.Bern at engineer.com
Mon Jun 3 10:20:11 PDT 2013


What we are doing is quite simple.  We are building a device that 
understands the EasyComm protocol


and controls antenna rotors that use Digital Satellite Equipment Control 
(DiSEqC^(TM)) protocol


The DiSEqC rotors we are interested in are the Aspen Eagle/Pro Brand 
International rotor for azimuth


and the Sadoun PowerTech DG380 rotor for elevation


David, W2LNX

On 06/02/2013 01:43 PM, Samudra Haque wrote:
> 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 at engineer.com 
> <mailto:David.Bern at 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
>         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.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
>             Bern<David.Bern at engineer.com
>             <mailto:David.Bern at 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 at amsat.org <mailto:W2LNX at amsat.org>
>                 Thank you,
>                 David, W2LNX
>                 _______________________________________________
>                 Via the AMSAT-DC mailing list courtesy of AMSAT-NA
>                 AMSAT-DC at amsat.org <mailto:AMSAT-DC at amsat.org>
>                 http://amsat.org/mailman/listinfo/amsat-dc
>     _______________________________________________
>     Via the AMSAT-DC mailing list courtesy of AMSAT-NA
>     AMSAT-DC at amsat.org <mailto:AMSAT-DC at amsat.org>
>     http://amsat.org/mailman/listinfo/amsat-dc

More information about the AMSAT-DC mailing list