Yaesu G-5500 with expanded range

[UW5EJA]

Hello, developers and everyone else.

First, I want to say “Thank you for such a good program.” This is an easy to use and convenient program.

I have Yaesu G-5500 rotator. I expanded the azimuth rotation range to 540 degrees. I installed a multi-turn potentiometer and a gear with 12 teeth (printed on a 3D printer). Also, I modified the value of max. azimuth in Hamlib source code. Is it possible to add two functions in Flyby - the detection of satellite orbits crossing the direction of the North Pole, and then converting the values of azimuth angles from 1..180 to 361..540?

Best regards, Victor

UW5EJA 73!

[bjorgan]

Thanks for the issue! I'm not sure if I understand the situation correctly, however. Could you illustrate it with a figure or an example? Or maybe supply a TLE, a time and QTH coordinates where this situation would occur, and where it would help to extend the azimuth range.

It might be possible that it is not necessary to implement this in Flyby, but that it could be handled more elegantly by an intermediate layer between Flyby and rotctld, but I need to know more about the problem first. :-)

[UW5EJA]

Thank you for your reply!

Yes, you understood the situation correctly. When a passages crosses the north direction - add 360 to all values from 1° to 180° before tracking.

For example, after detected passages crosses the northern direction from East to West (CCW) send next values to rotctld: 500° (= 140° + 360) ... 450° (= 90° + 360) ... 415° (= 45° + 360) ...

OR

when rotation clockwise, send to rotctld: 355° ... 361° (= 1° + 360) ... 450° (= 90° + 360) ... 500° (= 140° + 360)

1. Is it possible?
2. Yes, maybe, more elegantly by an intermediate layer between Flyby and rotctld, but is it possible to detect these passages in Flyby?

Best regards, Victor

UW5EJA 73!

[bjorgan]

I'm assuming that the case here is that your rotor originally only could rotate between 0 and 360 degrees azimuth, and that passes that went from angle X to angle Y > 360 would lead, at angle 360, to the rotor turning all the way back to 0 before continuing (or the other way around), and that you are attempting to solve it by extending the range.

This got a bit more complicated than expected, so I'll split it in two cases in order to get a bit more overview over the problem for myself:

Case I: Pass enters at some angle less than 360 degrees (larger than 180), ends up at angle larger than 0 degrees (less than 180) (satellite goes from west to east in the north quadrants). The rotor rotates until 360 degrees azimuth according to the commands from flyby, and then flyby issues a command to go to 0 degrees azimuth. You want your rotor to rotate until 361 degrees azimuth, and not turn the other way around. Here, your rotor controller or a layer in-between should be aware of the real limits of your rotor (540 degrees azimuth) and choose the shortest path. If the rotor controller can't handle it, it should be able to easily solve this by something which receives the rotctld commands from flyby, checks the current azimuth command against the current angle and supplied rotor limits, and then passes the correct recalculated angle on to rotctld.

Case II: Pass enters at angle larger than 0 degrees, goes from east to west, enters angle 0 degrees, continues to 360 degrees and then on to some angle less than 360 degrees. This one is more tricky than case I, since the rotor should already have started within your extended limits, and will still have a problem if it starts at angle > 0, angle < 360 degrees. I now realize that this is not solvable by having a limit-aware layer between or letting the rotor controller take care of it. :-)

Alternative 1: Change soft limits of the rotor

Technically, some of it could have been a bit solvable by changing the soft limits of the rotor, so that it rotates between -270 and +270 real-life azimuth degrees instead of 0 and 540 real life azimuth degrees, but this still won't solve the problem fully:

Mapping:

• Angles between N and E: Converted to angles between +0 and +90 degrees
• Angles between E and S: Converted to angles between +90 and +270 degrees
• Angles between W and N: Converted to angles between -0 and -90 degrees
• Angles between W and S: Converted to angles between -90 and -270 degrees

It would solve the problem for the example you mentioned, but you get the same problem again for a satellite which passes from SW to WN (and some other situations), so I guess this is not a real option, but just pushes the problem elsewhere.

Alternative 2: Hacking it together for now based on information which already is available within Flyby

If you want to hack together a solution within Flyby yourself for your specific case (I guess you'll be able to do this since you've already patched your own hamlib), I've some instructions below:

The angles are sent to rotctld here: https://github.com/la1k/flyby/blob/master/src/singletrack.c#L891. If you create a variable for azimuth that is calculated from the actual azimuth, and pass it on to rotctld in place of obs.azimuth, you should be able to change the angles passed to rotctld with minimal interference with the rest of the application.

You can detect the situation from a couple of variables that are already available. They are filled here: https://github.com/la1k/flyby/blob/master/src/singletrack.c#L787. The variables "aos" and "los" contain information about the azimuth/elevation where the satellite enters (aos), and where the satellite exits (los), which you can access from where you recalculate azimuth before passing it to rotctld. The AOS azimuth is accessed as aos.azimuth, while LOS azimuth is accessed as los.azimuth, both in radians (needs to be converted to degrees).

If satellite enters at azimuth >= 180, azimuth <= 360 (obtained from aos.azimuth and converted to degrees) and exits at azimuth >= 0, azimuth <= 180 (obtained from los.azimuth and converted to degrees): You know that this is case I, and that the satellite should continue on the extended range, and can add 360 degrees to the angle that is passed to rotctld once it crosses 0 azimuth.

If satellite enters at azimuth >= 0, azimuth <= 180 and exits at azimuth <= 360, azimuth >= 180: You know that it is on case II, and should have started on the extended range 360 to 540 instead of 0 to 360. Add 360 to the angle passed to rotctld when it is between 0 and 180, and pass the angle suggested by flyby when it is between 360 and 180.

If the case is neither of these, just pass on the angle suggested by flyby (or add more edgecases).

Alternative 3: Adding new features in Flyby for smarter tracking.

I'll have to think about that one. :-P

I don't really want to include rotor limits or rotor-awareness in Flyby, since it might get a bit ugly fast. I'd rather just blindly push out coordinates and let the rotor controller (or layers between) find the shortest path in a limit-aware way, and assume that they are smart enough, but I see not all cases are solved by this. Still, if the rotor controller is too smart and rests at e.g. 20 degrees, and you need it to start at the extended range, issuing a command to turn to 380 degrees would make the rotor rest at its current angle... So flyby would also need information about whether the rotor controller tries to choose the shortest path, or flyby would need the rotor controller to turn off the shortest path feature and handle it itself. It quickly gets a bit undefined and messy. :-) But I hope you are for now satisfied with the instructions to patch it yourself, at least.

Alternative 4: Faux rotctld-application between Flyby and rotctld enabling smarter tracking

Might also be that a limit-aware layer inbetween Flyby and rotctld could solve it still if it infers the turning direction from a series of commands, and choose to go to the extended range according to the required turning direction. This would make the antenna first rotate within the 0-360 range, and then realize that it should have been at 360-540, and then turn there, which would waste satellite time, but could for example be done when satellite is below the horizon. Such a layer in the form of a Python script or similar could be as ugly as it wanted to be, and would be easier to hack by users wanting a specific behavior. Could also be usable for other satellite tracking applications. I'll think a bit about it and maybe throw together something and supply it as a Flyby utility if it turns out to solve the problem. Wouldn't solve all problems, since it wouldn't be aware of the exit angle and could make wrong decisions.

[UW5EJA]

Hello, Thank you so much for detailed reply!

I have ERC-M controller for Yaesu G-5500. It is possible to set any value of the maximum azimuth. Alternative 2 is more elegant solution for myself.

Case I: ERC-M can choose shortest path.

Case II:

Maybe, for detection satellite goes from East to West, would be easier to use the following rules: aos.azimuth−los.azimuth always < -180 OR los.azimuth−aos.azimuth always > 180

And it will be enough add 360 only to aos.azimuth and move antenna towards AOS position in the extended range before tracking. It makes sense?

Could you, please, write how to change correctly or what need add in the source code singletrack.c?

UW5EJA 73!

[bjorgan]

Yeah, something like that could have solved it, since you would have started at the extended range and the rotor controller would have taken care of the rest.

But, one problem: The way tracking currently is implemented, however, tracking angles are taken directly from the current satellite prediction and never involves aos.azimuth. It just starts to track current angles once elevation is above the horizon, and that's it. You can still kind of do it that way, so I'll outline a couple of alternatives (and included the modifications I mentioned in the last post):

Alternative I: Hack behavior of key 'A'

When key 'A' is pressed while in singletrack mode (before the pass starts), the rotor turns to aos.azimuth: https://github.com/la1k/flyby/blob/master/src/singletrack.c#L899.

If you add 360 to aos.azimuth once the conditions are appropriate here, the antenna will move to the extended range. This fix would work only when you press 'A' before each pass, however.

Modify

        //move antenna towards AOS position
        if ((input_key == 'A') && (obs.elevation*180.0/M_PI < rotctld->tracking_horizon) && rotctld->connected) {
            rotctld_fail_on_errors(rotctld_track(rotctld, aos.azimuth*180.0/M_PI, 0));
        }

to

        //move antenna towards AOS position
        if ((input_key == 'A') && (obs.elevation*180.0/M_PI < rotctld->tracking_horizon) && rotctld->connected) {
                        double track_aos = aos.azimuth*180.0/M_PI;
                        if (CONDITIONS INVOLVING aos.azimuth AND los.azimuth) {
                                track_aos += 360;
                        }
            rotctld_fail_on_errors(rotctld_track(rotctld, track_aos, 0));
        }

Alternative II: Change the first tracked angle

Make the first tracked angle always be aos.azimuth, but let the rest of the angles follow obs.azimuth. This one requires major rewrite, you'd need to check whether you are about to track the first angle, and also make the rest of the tracking wait for the rotor to be at the aos.azimuth position before continuing to receive angles. Probably more trouble than it's worth.

Alternative III: Change tracked angles throughout the full pass.

(Original suggested solution)

See https://github.com/la1k/flyby/blob/master/src/singletrack.c#L890:

Currently says:

                //send data to rotctld
        if ((obs.elevation*180.0/M_PI >= rotctld->tracking_horizon) && rotctld->connected) {
            rotctld_fail_on_errors(rotctld_track(rotctld, obs.azimuth*180.0/M_PI, obs.elevation*180.0/M_PI));
        }

Change to:

                //send data to rotctld
        if ((obs.elevation*180.0/M_PI >= rotctld->tracking_horizon) && rotctld->connected) {
                        double track_azimuth = obs.azimuth*180.0/M_PI;
                        if (CONDITIONS WHERE YOU WANT TO CHANGE THE AZIMUTH ANGLE) {
                               track_azimuth += 360;
                        }
            rotctld_fail_on_errors(rotctld_track(rotctld, track_azimuth, obs.elevation*180.0/M_PI));
        }

Suggestion for conditions in alternative I: (aos.azimuth >= 0) && (aos.azimuth <= M_PI) && (los.azimuth <= 2*M_PI) && (los.azimuth >= M_PI) (or something simpler based on differences)

Suggestion for conditions in alternative I: (Same as above) && ((track_azimuth >= 0) && (track_azimuth <= 180)

[UW5EJA]

Thank you!

I think Alternative I with Alternative III is excellent solution. I will change to

        //send data to rotctld
        if ((obs.elevation*180.0/M_PI >= rotctld->tracking_horizon) && rotctld->connected) {
                        double track_azimuth = obs.azimuth*180.0/M_PI;
                        if ((aos.azimuth >= 0) && (aos.azimuth <= M_PI) && (los.azimuth <= 2*M_PI) && (los.azimuth >= M_PI) && (track_azimuth >= 0) && (track_azimuth <= 180)) {
                             track_azimuth += 360;
                        }
            rotctld_fail_on_errors(rotctld_track(rotctld, track_azimuth, obs.elevation*180.0/M_PI));
        }

        singletrack_print_main_menu(main_menu_win);

        //handle keyboard input
        input_key=getch();

                //move antenna towards AOS position
        if ((input_key == 'A') && (obs.elevation*180.0/M_PI < rotctld->tracking_horizon) && rotctld->connected) {
                        double track_aos = aos.azimuth*180.0/M_PI;
                        if ((aos.azimuth >= 0) && (aos.azimuth <= M_PI) && (los.azimuth <= 2*M_PI) && (los.azimuth >= M_PI)) {
                                track_aos += 360;
                        }
            rotctld_fail_on_errors(rotctld_track(rotctld, track_aos, 0));
        }

(but, I don't know when I can check, need a few days.)

[UW5EJA]

Hello and thank you so much,

1. Alternative III works great. After press "A", the antennas move towards the AOS azimuth position (> 360° and <= 540°). Started autotracking in the extended range.
2. Alternative I works great too. I deleted quotation mark ( before (track_azimuth >= 0)

Suggestion for conditions in alternative I: (Same as above) && ((track_azimuth >= 0) && (track_azimuth <= 180)

UW5EJA 73!

[UW5EJA]

Hello Asgeir,

I hope next information may be useful to you:

• First For remote access to Flyby via web-browser I use application TTYD

Share your terminal over the web. https://github.com/tsl0922/ttyd

• Second ONLY when elevation rotation range >= 180 deg. Good solution for track LEO satellite - enable "Elevation reverse mode" OR "Flip Mode" for auto-tracking when the satellite crosses the azimuth rotor's end point. With this mode enabled, the program steers the azimuth rotor to the opposite direction of the satellite's azimuth position and the elevation rotor to an elevation of 180 degrees minus true elevation.

I read this in manual for satcom application by Neoklis Kyriazis 5B4AZ and manual for SatPC32. ...sets a North crossing flag which then instructs the rotor control function to do a "reverse track"...

For example, convert and send values to controller

Elevation = 45 ° ≡ 135° ≡ (180° - El°) Azimuth = 0° ≡ 180° (to the opposite direction of the satellite's azimuth position) =(180° + Az°) (when Az° = 0..179) OR = (Az° - 180°) (when Az°=180..360)

[bjorgan]

Sorry for not replying to your message 20 days ago, but glad to hear that you found an error and were able to make it work in the end. :-) xsatcom's solution sounds interesting, thanks for linking to it! I'll take a closer look at it.