#65 Handling of flip passes

Undecided
open
nobody
5
2013-02-04
2012-12-08
Anonymous
No

While flip passes most of the time work like a charm, there are some passes when most rotators will still loose the satellite. Unfortunately those passes tend to be sweetest ones when chasing cubesats with limited output power.

Such occasions take place under following circumstances:
1. pass is not crossing zenith-north line
2. maximum elevation of the pass is large - i.e. (very) close to zenith

At the moment (in the GPredict v. 1.3.* and probably also in pre 1.4) such passes are handled in non-flip way and while e.g
Yaesu GS-5500 does the best it can, 180 degrees of rotation in the azimuth takes about 30 seconds..

If it would be possible to add some kind of additional logic to the flip pass decision code, controlling e.g. maximum elevation (and giving extra \"vote\" for flip pass if elevation will be more than 60 degrees or something like this) - that would be just great.

Discussion

  • Comment has been marked as spam. 
    Undo

    You can see all pending comments posted by this user  here

    Anonymous - 2012-12-08

    Screenshot showing described situation with high passes

     
  • Alexandru Csete

    Alexandru Csete - 2012-12-13
    • milestone: Next_Release_(example) --> Undecided
     
  • Alexandru Csete

    Alexandru Csete - 2012-12-13
    • status: open --> open-accepted
     
  • Alexandru Csete

    Alexandru Csete - 2012-12-13

    Thanks for the info. I will take a look at it.

     
  • Charles Suprin

    Charles Suprin - 2012-12-16

    To anonymous, thank you for the feedback on the flip passes and the nice bug report.

    To Alex, if you look in gtk-rot-ctrl.c, you should see is_flipped_pass. This is the function that decides whether to treat a pass as flipped or not.

    It would be trivial to put in a threshhold on a passes maximum azimuth to treat it as flipped or not. This would need to be put into the rotor control configuration and require gui and configuration file hooks as well to make it user configurable.

    This may not be the correct solution as flipped passes rotate the azimuth 180 degrees away so there never will be an azimuth discontinuity across 0 or 180 degrees. Flipping it everytime the pass is high would introduct going through the stop on some chunk of the passes. Something smarter is required.

    My interpretation is that the user wants to move the angular discontinuity to elevation channel rather than the azimuth channel because the azimuth channel is slower.

    Ideally some logic in the code determines the pointing which is the "fastest" of all allowable pointings. Fastest also includes what happens when the azimuth rotator needs to swing around because of a stop. (This makes it related to a flip pass but not identical.)

    The "correct" solution is eluding me. Others must have solved this. Unfortunately none of the documentation I reviewed discussed this.

     
  • Alexandru Csete

    Alexandru Csete - 2013-02-04
    • Status: open-accepted --> open
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks