Просьба подсказать по коррекции времени от GPS приемника.
Как вообще мы работаем. У нас два устройства: первое - микроконтроллер с АЦП с жесткой привязкой с сигналам 1 PPS от GPS приемника (алгоритм использует пакеты TSIP и прерывание по 1PPS) - устройство работает отлично! (Т.е. ранесенный в пространстве приборы работают одинаково). Второе устройство - микроЭВМ с ОС Windows XP Embedded которое по порту COM1 принимает значений от микроконтроллера (1 пакет в секунды содержащий ровно 150 значений) и по порту COM2 принимает TSIP пакеты от GPS приемника для точной установки системного времени (используем пакеты 46 (для контроля количества спутников) и 41 (берем время если спутников не менее 4) - сигнал 1 PPS не используем - не имеем возможности).

Контроль осуществляем по часовым файлам (файл с данными: в одном файле ровно 180000 значений - или 1 час) и вот здесь возникает ошибка:
допустим первый файл (от запуска) 09.24.12, то следующий файл 10.24.12, следующий 11.24.12 и так далее - если работаем без корректировки времени (системное время от внутренних кварцев) - то все верно: и время и количество значений в 1 файле.

Если работаем с корректировкой времени (т.е. время постоянно корректируем в течении часа): то каждый последующий файл отличается от самого первого примерно +- 1 с, примерно так: 09.24.12, 10.24.11, 10.24.13, 11.24.12...( количество значений в файле ровно 180000).
Алгоритм вычисления времени:

if(GMT[0]==0x41) // если пришел 41 пакет - содержащий время (после проверки 46 пакета - о количестве спутников)
{
GetLocalTime(&st);
dt = 0;
dt|=GMT[7]; dt<<=8;
dt|=GMT[8]; dt<<=8;
dt|=GMT[9]; dt<<=8;
dt|=GMT[10];
if(dt!=0)
{
T = *(float*)&dt;
tcorr = T; // GSP поправка - для перевода в UTS
dbg1->Lines->Add("Time correction = "+IntToStr(tcorr)+" sec.");
}
dt = 0;
dt|=GMT[1]; dt<<=8;
dt|=GMT[2]; dt<<=8;
dt|=GMT[3]; dt<<=8;
dt|=GMT[4];
if(dt!=0)
{
T = *(float*)&dt;
dt = T;
dt%=86400;
int dth=dt;
dth/=3600; st.wHour = dth;
dt%=3600;
int dtm=dt;
dtm/=60; st.wMinute = dtm;
dt%=60; st.wSecond = dt-tcorr;
if(st.wSecond>65000)
{
st.wSecond+=60;
st.wMinute-=1;
if(st.wMinute>65000)
{
st.wMinute=59;
st.wHour-=1;
if(st.wHour>65000) st.wHour=23;
}
}
}
sTime = IntToStr(st.wHour)+" : "+IntToStr(st.wMinute)+" : "+IntToStr(st.wSecond);
SetLocalTime(&st); // установка нового времени
}

Где может быть ошибка и как правильно округлять значения времени: мы получаем (по RS232) в 41 посылки по протоколу TSIP от Lassen LP GSP время в виде 4 байт, после преобразования которых получаем число плавающего типа float и видим что всегда есть числа после запятой - как с ними поступать: округлять до минимального целого, до максимального целого или по закону математики (т.е. до 0,4 к 0; 0,5 и больше к 1)?
Сейчас мы определяем время на микроЭВМ только из посылок TSIP (не используем сигнал PPS, т.к. он у нас занять на синхронизацию микроконтроллеров и АЦП) - на какую точность можно рассчитывать при установке времени только по посылкам?

Просьба подсказать по нашей проблеме (немного разобрался, но требуются комментарии со знанием GPS приемников и протокола TSIP и WINAPI).
1. Как я понимаю установку точного времени: получив пакет 41 (протокол TSIP) и обработав время мы получаем следующие точные значения времени: часы, минуты и секунды, и после прихода сигнала PPS устанавливаем это время как системное (для Windows используем WINAPI - функцию SetLocalTime()) - правильно? (Иметься ввиду что пакет 41 передает время чуть раньше, чем реально это время наступит в действительности и наступает оно с приходом сигнала PPS).
2. В функции SetLocalTime() есть установка микросекунд (999 максимум), но ввиду того что мы получаем в пакете 41 - целое число секунд (хвост после запятой отбрасываем - так следует из описания и примеров на "С" от Trimble) - то мы устанавливаем всегда 0. Это так?
3. Если в системе не используется сигнала PPS, но при этом мы можем программно учесть задержку между полученным пакетом и сигналом PPS (вычислим) - то введя задержку на установку времени, мы получим более менее приемлемую точность установки по отношению к мировому времени? И самое главное - если нечего не будить меняться - то этот сдвиг (хоть и минимальный) со временем не будет изменяться - т.е. все последующие кооректировки времени также будут идти с одинаковой ошибкой?

ИМХО основная проблема в том что у вас потоки данных и времени передаются по двум независимым асинхронным каналам.
С момента принятия микроконтроллером сигнала PPS и обнаружения данных программой в WinXP проходит некоторое время, состоящее из времени реакции МК, времени передачи данных по RS-232, времени реакции драйвера COM порта в WinXP и времени передачи управления вашей программе. Аналогичная ситуация и с потоком времени.
Если время передачи по RS-232 можно считать стабильным, то задержки в ОС WinXP (и возможно в ПО GPS приёмника и МК) можно считать случайными. Поэтому можно долго плясать с бубном, выясняя почему в одном случае работает а в другом нет.

Правильным решением будет объединение потока данных и времени в один: подмешивать время в пакет с данными от МК и передавать их по одному COM-порту.

Ключевое слово: Win XP

Предлагаемое Вами решение еще усложнит задачу.
Хотя решение уже получено:
1. Основная ошибка : не установка числа микросекунд в структуре (оставляли как есть) - поэтому и результат плохой, поставили =0 - все резко улучшилось.
2. ОС которую применяюEmbedded - основное отличие - убрано все что нам не нужно ( еще производителем), плюс сам убрал еще часть, в результате в памяти мин. процессов и выполняемых задача ( точнее задача 1 - моя программа и все), больше нечего не делаеться (все запрещенно). Поэтому задержку можно примерно подсчитать (у меня получилось где-то 30 мс) и ее учесть.
Самое главное: уже проверил - все работает, точность выставления интервалов времени ( т.е. часовых файлов) - один в один.
3. В вашем решение есть ошибка (возможно не знаете порядок прихода байтов от GPS) - сначала идет время, потом число спутников (точнее можно или нельзя применять данные) - их разрезать нельзя, а подругому не получиться: скорость данных 115200 бит/с, данные с GPS - 9600 бит/с.