Расчет того, какие спутниковые проходы видны

Используя библиотеку Python pyephem, я рассчитываю проходы для ISS на основе данных TLE и моей широты/долготы, но как я могу определить, какие из множества проходов, которые он возвращает в день, видны?

Я понимаю, что спутники видны только во время восхода или заката, но есть ли какой-либо систематический способ вычислить, находится ли проход в диапазоне времени, когда он может быть виден?

Не забывайте о видимости во время ярких фаз Луны. ;)
Мне нравится этот вопрос. Код для этого был бы отличным дополнением к pyephem.

Ответы (2)

Проведя некоторое исследование, я нашел ответ на свою проблему на Celestrak. У них есть отличная статья именно об этом, которую я кратко изложу здесь, хотя, если вы заинтересованы в этом, вы должны прочитать ее здесь .

Есть 3 основных требования, чтобы спутник был виден:

• The satellite must be above the observer's horizon.
• The sun must be below the observer's horizon enough to darken the sky.
• The satellite must be illuminated by the sun.

Первый пункт мы можем игнорировать, потому что по определению проход, рассчитанный любой библиотекой или веб-сайтом, должен быть за горизонтом, чтобы он был проходом над указанным местом.

Этот второй момент имеет решающее значение для того, что меня интересует. Солнце должно находиться как минимум на -6˚ ниже горизонта, чтобы было достаточно темно, чтобы свет от солнца, отраженный от спутника, был достаточно ярким по сравнению с небом, чтобы выделяться. , это называется морскими сумерками. Таким образом, солнце должно было зайти, но оно также не должно быть ниже -18˚, иначе на спутник не попадет достаточно солнечного света, чтобы его можно было увидеть. Вот почему вы можете видеть спутники только в течение нескольких часов на рассвете или в сумерках.

Третий момент заключается в том, что объект не должен затмеваться Землей. Если вы не используете pyehem или другую библиотеку, которая вычисляет это, я настоятельно рекомендую вам прочитать их статью, в которой подробно описано, как это вычислить. Поскольку pyephem действительно вычисляет, затмевается ли объект, я не буду здесь вдаваться в математику и просто скажу, что это можно найти, например, с помощью iss.eclipsed.

Чтобы связать все это вместе, используя pyephem, можно найти следующий проход и увидеть его так:

def seconds_between(d1, d2):
    return abs((d2 - d1).seconds)

def datetime_from_time(tr):
    year, month, day, hour, minute, second = tr.tuple()
    dt = datetime.datetime(year, month, day, hour, minute, int(second))
    return dt

 def get_next_pass(lon, lat, alt, tle):

    sat = ephem.readtle(str(tle[0]), str(tle[1]), str(tle[2]))

    observer = ephem.Observer()
    observer.lat = str(lat)
    observer.long = str(lon)
    observer.elevation = alt
    observer.pressure = 0
    observer.horizon = '-0:34'

    now = datetime.datetime.utcnow()
    observer.date = now

    tr, azr, tt, altt, ts, azs = observer.next_pass(sat)

    duration = int((ts - tr) *60*60*24)
    rise_time = datetime_from_time(tr)
    max_time = datetime_from_time(tt)
    set_time = datetime_from_time(ts)

    observer.date = max_time

    sun = ephem.Sun()
    sun.compute(observer)
    sat.compute(observer)

    sun_alt = degrees(sun.alt)

    visible = False
    if sat.eclipsed is False and -18 < degrees(sun_alt) < -6 :
        visible = True

    return {
             "rise_time": timegm(rise_time.timetuple()),
             "rise_azimuth": degrees(azr),
             "max_time": timegm(max_time.timetuple()),
             "max_alt": degrees(altt),
             "set_time": timegm(set_time.timetuple()),
             "set_azimuth": degrees(azs),
             "elevation": sat.elevation,
             "sun_alt": sun_alt,
             "duration": duration,
             "visible": visible
           }
Хорошая работа, интересно, есть ли способ использовать некоторые из этих библиотек углов для прогнозирования таких вещей, как вспышки Иридия . Небеса-выше делают это , но я всегда полагал, что там происходит какая-то нетривиальная математика.

Мое предложенное улучшение кода harryissac предлагается для устранения любого исключения, вызванного значением None ( которое «иногда» будет возникать без этого исправления ). Это только фрагмент, который устранит возможность исключения из любых значений кортежа None. Комментарий мне показался слишком длинным, поэтому я предлагаю его здесь.

Все это должно иметь отступ на один уровень, чтобы соответствовать коду Гарри. Извиняюсь за то, что еще не знаком с форматированием здесь. После этой части кода от harryissac:

now = datetime.datetime.utcnow()   
observer.date = now   

tr, azr, tt, altt, ts, azs = observer.next_pass(sat)    

вставьте этот код с комментариями или без них. Комментарии помогают объяснить:

# --- improvement to eliminate any None values -- START ------------  

while (tr == None or  
       tt == None or  
       ts == None or  
       ts < tr  
      ):  

    # Sometimes PyEphem needs a nudge to a later time in order for  
    # next_pass() to be fully populated with valid data. Therefore  
    # as long as there remains any None value returned, continue to  
    # re-compute in 15 minute jumps until any None is replaced with  
    # valid data.  15 minute jumps should produce a fully populated   
    # tuple before yet another pass begins.  A valid time should   
    # ensure a valid azimuth as well.  This fix catches all the   
    # Exceptions I 'have' encountered in similar earth satellite   
    # code, such as for ISS, when using PyEphem.  

    observer.date = now + datetime.timedelta(minutes=15)  
    sat.compute(observer)  
    tr, azr, tt, altt, ts, azs = observer.next_pass(sat)  

# --- improvement to eliminate any None values -- END --------------  

Если у кого-то есть более короткая версия или исправление, продолжайте и комментируйте.

Если требуется более полное объяснение того, почему это исправление необходимо, оставьте комментарий, и я отредактирую более подробное объяснение. Документация PyEphem предупреждает о возможных значениях None при использовании next_pass для спутников Земли.

Brandon Rhodes предоставил нам многофункциональный пакет PyEphem, поместив оболочку python вокруг кода Xephem Элвуда Дауни. Есть определенное полезное преимущество в том, чтобы знать, когда он может вернуть None вместо какого-либо другого ожидаемого значения.

@uhoh Мне нравится заявленная точность Skyfield и его скорость с использованием numpy. В настоящее время я работаю с PyEphem на Raspberry Pi 3B+ и учусь терпению. Около 16 секунд, чтобы получить следующие ~120 проходов от SVPOST TLE, без ошибок исключений из значений None. Ему нужно время от времени менять дату поиска, подобно тому, что я только что опубликовал, чтобы потерять None(s). И TLE, даже с выбранной наиболее подходящей датой эпохи TLE, если я правильно понимаю, все еще может отличаться на километр или два. Достаточно точно для моих текущих целей. Я планирую поближе взглянуть на Скайфилд.
Да. Среди первых комментариев в моих проектах PyEphem: «Думайте о UTC и избегайте постоянно меняющихся мелких деталей политики местного часового пояса, баз данных и кода». Большинство моих проектов на python совершенно наивны, как и код harryissac здесь, поэтому они могут быть полностью переносимыми в полевых условиях (для их запуска не требуется подключение к Интернету, за исключением обновления моей библиотеки TLE перед выходом в поле).
Да, еще одна причина, по которой мне нравится пиепхем. Простота. Но я могу оценить работу Брэндона по разработке и поддержке очень и очень точного пакета, для которого могут потребоваться частые онлайн-обновления того или иного рода.
Уточнение... после рефакторинга rpi 3B+ с pyephem выполняет ~120 проходов за ~4,5 секунды, и это тоже, вероятно, можно улучшить. Он читает и просматривает библиотеку TLE с тысячами записей, и это, без сомнения, хороший процент времени обработки, чтения, обработки и выбора наиболее подходящего TLE для каждой даты поиска прохода. Я не хотел оставлять возможности rpi с pyephem с таким медленным отчетом необъяснимыми.