Re: [Gpredict-discussion] GPredict and SatNOGS rotor

[Lloyd B. <som...@gm...>]

I'm not sure I can address the first question at all, but I can give a
little info about the second one, the one about the rotation stops.

I'm only vaguely familiar with the SATNOGS project rotator, though I'd like
to build one some time.  So, let me as a couple of questions;

- What is the total amount of azimuth rotation in the SATNOGS rotator?
Traditionally az rotors were either 360 or 450 degrees.
- Does the azimuth rotor have rotation stops? If so, where are they
positioned?  North (0 deg) and South (+/- 180 deg) are the most common, but
really anything would work.
- Does the rotator expect to be fed only positive azimuth values (eg
0->360), or positive and negative values (eg. -180->0->180)?  Or does it
work well with either one?

Basically, I suspect you've got a problem with the defined azimuth stops in
gpredict.  For example, if your rotator has stops in the South, but
gpredict thinks they're in the North, or visa-versa.  If they don't agree,
then you have the swing-around problem, even when you wouldn't think it
would.


(LONG-WINDED EXPLANATION ALERT)

Let me explain in more detail.

For example, if your *actual* stops are in the North (0 deg), but gpredict
*thinks* they're in the South (+/- 180 deg), then you have these two
scenarios:
- When a pass crosses the North azimuth, gpredict assumes that it can just
go directly, and doesn't do anything weird. But, for example, when the
rotator is currently just west of north, and gpredict feeds it an azimuth
that's just east of north (assuming that it's only a few degrees to
change), the rotator will end up swinging all the way around to get there
from the other side.
- When a pass crosses the South azimuth, gpredict thinks it needs to do
avoid the rotation stops in the south, and so it does a flipped pass.  This
means that instead of tracking across the South azimuth, at some elevation
E, gpredict flips the antenna over and tracks across the North azimuth, at
an elevation of (180 degrees - E).  And so again, when gpredict feeds your
rotator something that crosses the North azimuth, it has to swing all the
way around again.

If you choose a 0->180->360 rotator in gpredict, it will assume the
rotation stops are in the North (0/360 deg), though that can be changed.
Similarly, if you choose a -180->0->180 rotator in gpredict, it will assume
the rotation stops are in the South (+/- 180 deg), but again, that can be
adjusted.

So, in the end, the simple answer is to make sure that gpredict correctly
knows where your azimuth rotation stops are, and it will work much better.

Lloyd



On Fri, May 11, 2018 at 8:28 AM, Sims, William Herb (MSFC-ES63) <
her...@na...> wrote:

> Guys and Gals,
>
> Two questions for the group.
>
> First, is there a way within GPredict to determine if TWO ground stations
> can see the same satellite at the same time?  Along a work related question
> we (Marshall Space Flight Center, MSFC) are doing some experiments on the
> International Space Station (ISS) RF test-bed and due to licensing issues
> on the station we cannot downlink data while NOT over pre-determined ground
> stations (in our we are NOT one of those ground stations but Glenn Research
> Center, GRC, is).  What we want to do is determine when both MSFC and GRC
> can see ISS at the same time.  Is it possible with GPRedict?  I realize we
> can use something Like Satellite Tool Kit but that requires funding other
> NASA people so I am trying to save our project some money (since I’m
> already on it).
>
> Second, I am using a SatNOGS rotor (AZ/EL) and was simulating tracking a
> satellite yesterday and noticed something that concerns me.  The satellite
> started on the horizon at say 10 degrees azimuth and during the pass went
> from 10 – 360 – 350 – 340 to finally close to 190 degrees.  The question I
> have is that once the projected azimuth hit 360 the SatnOGS rotor spun all
> the way around (went clockwise from 0.1 degrees to 180 to 359 degrees)
> instead of continuing in a counter-clockwise direction (this is, I believe,
> because I had the rotor controller set to 0-180-360).  I believe had I set
> the controller to -180-0-180 that it would have worked as expected.  The
> problem is, if I get a scenario of another satellite track that goes from
> 170 – 180 - -170 - -160, etc. and I was set up for the -180-0-180 it would
> do the same thing (i.e. go 170, 179.9 then swing all the way around
> counter-clockwise to -179 etc.).  Is that something that one “just has to
> live with” or should the rotor be capable of doing a full 720 degrees (2 *
> 360) too keep this from happening?  I realize that it would then wrap the
> coax around the system, but I just want to make sure that I am not missing
> something here.
>
> Thanks,
>
> Herb
>
>
> Dr. Herb Sims
> EV41
> Bldg. 4600 / Room 4113
> Control Systems Design & Analysis Branch
> MSFC, AL 35812
> 256-961-3214
> ------------------------------------------------------------
> ------------------------------------------------------------
> -------------------
> I want to tell the whole world that I love my wife and kids - what better
> way than one email at a time
>
> Ich will der ganzen Welt sagen, dass ich meine Frau und Kinder liebe – wie
> ist das besser zu machen als Mail für Mail,
> eine nach der anderen.
> ------------------------------------------------------------
> ------------------------------------------------------------
> -------------------
>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Gpredict-discussion mailing list
> Gpr...@li...
> https://lists.sourceforge.net/lists/listinfo/gpredict-discussion
>