Не уверен, но и пользователь не обязан покупать новые версии ПО при каждой коррекции времени. Значит с информацией об LEAP SECONDS для ПО что-то не так, как Вы объясняете. Давайте подождём иных мнений. Я, кстати, задал свой, вроде бы, наивный вопрос: потому что обрабатываю в «Pinnacle», которая давно не поддерживается, а значит не знает о всех новых коррекциях, начиная с 2007 года. Или знает, но через обрабатываемые файлы? Потому-то, повторные наблюдения устойчивых реперов в 2015 году имеют те же координаты с точностью 1-2мм, что и в 2007. А может эти секунды для относительного метода вообще по-барабану, будь их хоть мульён?
А никто не говорит о покупке новой версии ПО. Обновляются файлы данных аналогично тому, как обновляется информация о новых антеннах. Вы же не покупаете новую версию при появлении новой антенны!
А неподдерживаемые версии в один прекрасный момент перестают работать, как мы это уже наблюдали. Что касается Pinnacle, могу сделать следующее предположение (надо проверить). Т.к. Pinnacle требует наличия авторизованного файда (который делает сам), то в нём ОБЯЗАТЕЛЬНО должна присутствовать строка LEAP SECONDS.
Делает авторизованный под «Pinnacle» приёмник. Он же, получается, передаёт эти секунды в ПО? Значит строка с LEAP SECONDS для «Pinnacle» должна быть обязательной? Проверяем. В RINEX с авторизованных приёмниках её нет. Можете мне поверить, но один из умельцев научился авторизировать RINEX-файлы и с неавторизированных приёмников. Так вот, и в этих файлах нет этой строки. А «Pinnacle» считает. И считает с такой точностью, что могут позавидовать многие современные ПО.
Речь шла об файлах наблюдений. В файлах эфемерид это строка, если память не изменяет, обязательная. Код: 2.11 GLONASS NAV DATA RINEX VERSION / TYPE cnvtToRINEX 2.25.0 convertToRINEX OPR 15-Jan-15 06:59 UTC PGM / RUN BY / DATE ----------------------------------------------------------- COMMENT 2015 1 9 -0.321306288242D-07 CORR TO SYSTEM TIME 16 LEAP SECONDS END OF HEADER 17 15 01 09 00 45 0.0 0.144541263580D-03 0.909494701773D-12 0.282000000000D+04 0.102519125977D+05-0.280511760712D+01 0.279396772385D-08 0.000000000000D+00 0.677041992188D+04 0.122063922882D+01 0.000000000000D+00 0.400000000000D+01 0.223871655273D+05 0.913112640381D+00-0.931322574615D-09 0.000000000000D+00 16 15 01 09 00 45 0.0-0.263778492808D-04 0.909494701773D-12 0.282000000000D+04 Код: 2.11 NAVIGATION DATA GPS(GPS) RINEX VERSION / TYPE cnvtToRINEX 2.25.0 convertToRINEX OPR 15-Jan-15 06:59 UTC PGM / RUN BY / DATE ----------------------------------------------------------- COMMENT 0.1676D-07 -0.7451D-08 -0.5960D-07 0.1192D-06 ION ALPHA 0.1352D+06 -0.1802D+06 0.6554D+05 0.0000D+00 ION BETA 0.931322574615D-09 0.888178419700D-15 61440 35 DELTA-UTC: A0,A1,T,W 16 LEAP SECONDS END OF HEADER 10 15 01 09 01 59 44.0-0.157942064106D-03-0.170530256582D-11 0.000000000000D+00 0.900000000000D+01 0.430312500000D+02 0.520771692231D-08 0.877760723720D+00 0.229105353355D-05 0.145055744797D-01 0.698678195477D-05 0.515364805984D+04 0.439184000000D+06-0.189989805222D-06 0.162832060195D+01 0.894069671631D-07 0.941048713245D+00 0.236375000000D+03 0.914802182531D+00-0.855892794227D-08 0.240724312848D-09 0.100000000000D+01 0.182600000000D+04 0.000000000000D+00 0.240000000000D+01 0.000000000000D+00-0.325962901115D-08 0.900000000000D+01 0.434838000000D+06 0.400000000000D+01 0.000000000000D+00 0.000000000000D+00 --- Сообщения объединены, 14 мар 2015, Оригинальное время сообщения: 14 мар 2015 --- Умелец из Белоруссии?
Увы... Код: *|LEAP SECONDS | Number of leap seconds since 6-Jan-1980 | I6 |* Records marked with * are optional Погуглил ещё этот вопрос и наткнулся на ... обсуждение на форуме geodesist.ru . Ба! Знакомые всё лица! Почему это из Белоруссии?
Тогда дискуссия была немного об ином, но, в принципе, что-то я всё больше и больше склоняюсь к выводу, что если не для то ПО не обязательно должно знать о коррекции. Пока против этой версии аргументов не видно. Загадочный автор не из Беларуси? Белорусскому товарищу кто-то передал готовые наработки?
Если совместно обрабатываются данные GPS и ГЛОНАСС, должно знать. Аргументы приведены выше. Пока, я так понимаю, вопрос остался только с Pinnacle. Вы хорошо его знаете, попробуйте провести эксперимент: обработайте данные GPS+ГЛОНАСС, а затем удалите строку "LEAP SECONDS" из файлов наблюдений и навигационных файлов и повторите обработку. Результаты совпадут?
Нет проблем, но где здесь: Код: 2.10 GLONASS NAVMESS DATA RINEX VERSION / TYPE Pinnacle 1.00 14-MAR-15 14:02 PGM / RUN BY / DATE build April 19, 2002 COMMENT 2015 3 10 .000000000000D+00 CORR TO SYSTEM TIME END OF HEADER и здесь: Код: 2.10 N: GPS NAV DATA RINEX VERSION / TYPE Pinnacle 1.00 14-MAR-15 14:02 PGM / RUN BY / DATE build April 19, 2002 COMMENT END OF HEADER LEAP SECONDS?
Во! Вот это, похоже, и есть решением всех проблем! Программы, создающие RINEX берут из "сырых" всё что надо, в том числе и LEAP SECONDS, и делают всё что надо, а строку, могут писать, а могут не писать (как пожелал разработчик). Такое может быть?
А в авторизованном файле его тоже нет? Нет, не может. ПО должно знать LEAP SECONDS, либо из файла сырых данных, либо извне.
Может быть, но может и не быть. Если он есть, вот результат обработки: Код: Process Queue Solution [Session] - Processed Process: Static Engine, v.01.22.089 std, processed vectors: 2 , adj_rms=0.00000 (2 sec) Vector: 0601 --> 2-52 {-71.6994, -2.2573, 58.3301} Rms=0.0025 Len=92.4570 (fixed:47/95.63,float:4/0.27%) Vector: 0601 --> 2-12 {-160.6988, -86.0116, 169.4579} Rms=0.0013 Len=248.8736 (fixed:34/100) Vector Adjustment Residuals: rms=0.00000 Если удалить: Код: Process Queue Solution [Session] - Processed Process: Static Engine, v.01.22.089 std, processed vectors: 2 , adj_rms=0.00000 (1 sec) Vector: 0601 --> 2-52 {-71.7013, -2.2575, 58.3293} Rms=0.0023 Len=92.4580 (fixed:20/100,float:2/0.058%) Vector: 0601 --> 2-12 {-160.6978, -86.0124, 169.4600} Rms=0.0015 Len=248.8746 (fixed:18/100) Vector Adjustment Residuals: rms=0.00000 Вот разница в координатах: -0.001-0.0010.002-0.0010.001-0.002
Нет, это не обязательно. В приемнике во время измерений вычисляется ошибка собственных часов и вычисляется поправка часов приемника (clock offsets). В 1994 г. в Trimble утверждали, что clock offsets вычисляется с точностью ±2 наносекунды. Соответственно и файл "сырых" данных формируется уже с учетом поправки часов приемника, а шкала часов приемника корректируется, таким образом, со шкалой времени GPS.
Не обязательно. Приёмник может и не вычислять clock offset, а просто регистрировать измерения. Шкала времени корректируется не у всех приёмников - есть приёмники с коррекцией, есть без. Приёмник знает LEAP SECONDS всегда (он принимает его вместе с сигналом). При послесеансной обработке комбинированных измерений GPS и ГЛОНАСС, как в примере выше, LEAP SECONDS необходимо знать, иначе невозможно рассчитать время излучения сигнала ГЛОНАСС в шкале времени ГЛОНАСС, а это нужно для расчёта координат спутника.
Это надо было-бы только в том случае, если допустить, что UTC(SU) будет иметь отличие от UTC на эту поправочную секунду.
Тема важная, читаю с удовольствием. Время в навигации это всё. Мои 5 коп. Ещё в 2005, коллега сравнил время на дисплее DL-4 (novatel) со временем GPS, и оказалось, что приёмник выводит на экран время UTC, не GPS. Кажется это сродни времени навиг. сообщения. Обрабатываю наблюдения в GNGN. Ни в одном файле программы нет LEAP SECONDS, обрабатываются rinex со строкой об этом или без. GNGN не нуждается в знании этого офсета. Единственно, когда я вижу поле для ввода LEAP SECONDS - синтез позиции траектории с IMU. Время инерциальной системы, почему-то, синхронизировано с UTC. Может это особенность приёмников от Novatel, но интуитивно чувствую, что за время GPS можно говорить лишь в контексте послеобработки. Real time = UTC, GPS = PP. А так, полностью согласен с Vladimir VV, синхронизировали шкалу приёмника с системным и вперёд! --- Сообщения объединены, 15 мар 2015, Оригинальное время сообщения: 15 мар 2015 --- Оффтоп (Move your mouse to the spoiler area to reveal the content) Насколько помню А. Скурихин, на Кредо будучи работая, не?
Оффтоп (Move your mouse to the spoiler area to reveal the content) И ... ? Это известно, и то что время таким образом синхронизируется , этот миллиард пользователей и не заметит- оно им и не нужно знать . Наверное, я неточно выразил мысль- я о тех единицах из миллиарда , которым необходимо учитывать эту разницу и совмещать файлы данных неких событий с записанным временем TAi и записанным временем UTC (ну, например, в строках сообщений NMEA ) . В принципе, ответ на свой вопрос я получил, спасибо, коллеги за обсуждение
