Возможно ли убрать задержку при синхронизации времени
- Войдите на сайт для отправки комментариев
Чт, 31/05/2018 - 12:06
Возможно ли убрать задержку при синхронизации времени? Она влияет на передачу/прием данных по uart..
WiFi.hostByName(ntpServerName, timeServerIP); sendNTPpacket(timeServerIP); // Отсылаем время-серверу NTP-пакет // Ждем, чтобы увидеть, доступен ли ответ: delay(1000); int cb = udp.parsePacket();
Типа того?
А нафига ставили-то?
...) Дык, просто скопипастил, там была...)
Без задержки, очень редко срабатывает... У меня поставленна синхронизация раз в 2 минуты с 4 попытками. Поэтому, я не представляю, как вышеуказанный код будет у меня работать, поскольку заходит туда раз в 2 минуты...
У меня поставленна синхронизация раз в 2 минуты с 4 попытками.
А можно полюбопытствовать, что это за суперустройство такое, которому раз в две минуты нужно время устанавливать? Не слишком часто?
По канону, Ардуина считает время (сама ли, с RTC ли - зависит от потребностей) и раз, например, в сутки синхронизирует время.
ТС, вам такое подойдёт?
Да, собсвенно, особой точности и не нужно. Но все дело в том, что при старте за эти 4 попытки, время может и не синхронизироваться. И если при этом сделать синхронизацию реже, то и реальное время появится соответственно позже, а если опять не синхронизируется, то вы понимаете, может и вообще не появиться...)) Хотя, можно поставить флаг об успешной синхронизации - и после этого уже делать ее намного реже... Какое время посоветуйте поставить?
При старте отдельно синхронизируйте до тех пор, пока нормального времени не получите, потом раз в сутки...В чём проблема?)
При старте отдельно синхронизируйте до тех пор, пока нормального времени не получите, потом раз в сутки...В чём проблема?)
Да, спасибо, я выше уже предположил этот вариант. При старте долбить без перестанно, раз в две секунды?
Не знаком с методами, но долбить, пока не получите вменяемого времени. Потом выставить флаг и с барабаном на шее пойти выполнять основной цикл)
..) Я думаю, что основной цикл пусть выполняется, а то хто его знает, может интернет вообще отключили, а я буду ждать времени... Оно ведь мне, второстепенно - больше для красоты. Пока его нет, буду смотреть нарисованное, с помощью millis()...)
В общем сделал так, сначала долбит раз в две секунды(паузу между sendNTPpacket(timeServerIP); и int cb = udp.parsePacket();
предусмотрел), пока не получит время, далее ждет сутки(ну сутки конечно еще не прошли..))... Вроде все норм, работает..)
Примерно какое будет расхождение по времени через сутки? Для счета, я использую millis().
Примерно какое будет расхождение по времени через сутки? Для счета, я использую millis().
а зависит от того как считаете, я делал с корректировками в самом алгоритме счета (константы) на хорошей плате с нормальным кварцем секунда в неделю
Зависит от кварца. Если он суперпрецезионный и выдаёт ровно 16000000 Гц :), то почти никакое (но всё равно будет), а если, например, 15995000 - то это выходит 5000 мкс в секунду, то бишь 5 мс, или 0.005 сек * 86400 = 432 секунды = примерно на 7 минут в сутки.
Считаю так:
корректировок на нестабильность в коде нет, считать будет с большой ошибкой
Можете показать, как корректировать?
---
Запустил синхронизацию в вемосе 1,5 часа назад. На данный момент отставание составляет около 3-4 секунд. Получается: 16(24/1,5часа)*4сек =64секунды - это более менее...)
Или просто каждые пол часа добавлять по 1 секунде и так сойдет?..)
Можете показать, как корректировать?
здесь тёрли, но я ни разу не программист, просто идея
Прошло 15 часов безпрерывной работы - отставание так же около 3-4 секунд..) (я думаю отставания изначально не было, я просто скорее не правильно посмотрел из начально) Какая точность у китайских плат...)
Прошло 15 часов безпрерывной работы - отставание так же около 3-4 секунд..) (я думаю отставания изначально не было, я просто скорее не правильно посмотрел из начально) Какая точность у китайских плат...)
если поставить приличный кварц с малым ppt то точность будет еще лучше