roboforum.ru

Добрый день.
Собираю данные с датчиков на карту памяти для ведения статистики. Для общей оси времени включил GPS модуль GY-NEO6MV2 Ublox и библиотеку Adafruit Ultimate GPS на Arduino UNO. Проблема в том, что время и дата приходят по Гринвичу, а в библиотеке не нашел переменной для корректировки часового пояса. Подскажите пожалуйста, кто сталкивался с подобным, как это исправить? Пробовал сложением-вычитанием привести время к UTC-формату, но на дату это естественно не влияет. Есть ли какие-то специальные средства или библиотеки для этого? Или это решать только математическими операциями?

Может его через u-center нужно настроить?

Ухты, спасибо, не слышал про эту программу. Выглядит здорово. Но все таки было бы лучше настроить часовой пояс из основной прошивки (например обозначить +2, +4, +8, -5, и т.д.), а она сама дату и время переведет.

Проблемы с переводом времени от диапазона не решить, нужен массив координат/зон для авто перевода. Если использовать только в одном месте, то можно не напрягаться так и пользоваться обычными: вычитанием/прибавлением.
Можно конечно эту проблему решить как-то через онлайн подключение к какому либо сервису/серверу, но это уже другой уровень системы.

Диапазон тут не нужен. Я предполагаю что будет простое обозначение текущего часового пояса, например int a=3; или int a=-8; А дальше последовательно идет сложение hours += a; но тут сложность что надо идти от часов выше по уровню вплоть до уровня годов. В месяцах будет затык именно из-за разницы количества дней разных месяцев и високосных годов. Что бы этого избежать потребуется слишком сильное и ненужное усложнение алгоритма. Вот и думаю как-бы от этого избавиться попроще и поэффективней...

Кстати дата всё равно цепляется, т.к. как вы заметили, при вычитании/сложении времени с спутника, может понадобится временное изменение даты с учетом всех законов...
Следовательно тут путей несколько:

- как вы предложили пересчитывать время "от креста христова" (бешеное число);
- либо нужна готовая функция календаря.

Вообще где-то в инете я видел решение подобной проблемы, но там всё в итоге сделали по "фэншую".
Я вообще так мучится не стал (когда делал GPS часы), ведь весь переход на 1-3 часа не критичен и находится ночью (все спят ), просто вычитал часы, а на дату забил (всё равно она подтянется через это время.

Добавлено спустя 38 минут 11 секунд:
Кстати для вычитания алгоритм может быть весьма простым...делаем просто "кешь" для даты предыдущей, которую используем, если флаг переполенния времени срабатывает при вычитании.
Вот вперёд/сложение, тут либо можно сгенерить заранее массив данных дат на несколько лет и по ним скакать...но это не вечный календарь...

в данных которые выдаёт модуль должна быть также и цифра часового пояса в котором он сейчас находится $GPZDA
я не помню точно но по моему через u-center можно обновить таблицу часовых поясов в модуле, чтоб он выдавал. если модуль старый там может не быть последних движух с летним/зимним временем.
если лень писать конвертер времени, для ардуины есть библиотечки перевода времени в локальное, типа вот https://github.com/JChristensen/Timezone

Нашел на сайте Adafruit:

Remember, the GPS does not know what time zone you are in (even though it knows your location, there is no easy way to determine time zone without a massive lookup table) so all date/time data is in UTC (aka. Greenwich Mean Time) - You will have to write the code that converts that to your local time zone and account for Daylight Savings if required! Since that's pretty complicated, most people just stick to keeping everything in UTC

(https://learn.adafruit.com/adafruit-ult ... ery-backup)
Нда уж.. обнадеживает.
Зато у них же нашел пример часов реального времени с учетом часового пояса (правда изначально заданного в коде) - https://learn.adafruit.com/arduino-clock/software.
Добирусь до своей железки - попробую использовать эту библиотеку.

2Мур
Спасибо! Попробую и с u-centr поковыряться, может быть что-то путное получится.

Remember, the GPS does not know what time zone you are in

озвученный модуль дофига умный, он знает
там кстати можно настроить строку данных которую он выдаёт, например отключить всю лишнюю фигню в строке выходной да и вобще лишние строки убрать.
можно чтоб он выдавал только координату и время, или вобще только время, если он нужен тока для часиков

не совсем. информация о временной зоне штука с подвохами. модулю её нужно как-то из вне получать и самый простой вариант это когда есть установка через регистры, но 5й и 6й регистр zda доступен не для всех модулей. попытки придумать систему сбора по всему миру даных о временных зонах и потом это как-то со спутника вещать, ничем хорошим не закончится, т.к. будут конфликты мнений, где какое смещение времени в данный момент. ситуации конечно разные могут быть, но в общем более удобно брать utc и самому со смещением возится. а записывать, корректируя каждую запись о времени или записывая сообщение "текущая временная зона сменилась на такую-то" или ещё как, то уже от другой момент.
очень удобный вариант хранить время не как год/месяц/день/день недели/час/минута/секунда/..., а одним большим числом, указывающим сколько "квантов" времени (может быть секунда или миллисекунда или ещё что для нужной точности) прошло с определённого момента. в одной из версий ардуиновской библиотеки, которую можете найти на офсайте, время храниться одной unsigned long переменной (количество секунд, прошедших с 01.01.1970), всё остальное это вычисляемые вещи. что бы в таких библиотеках сделать поправку на смешение часов и минут, нужно просто добавить или отнять нужное количество "квантов" времени, допустим секунд. а когда в библиотеке хранят сразу год/месяц/день/..., так поправку на часы с минутами можно сделать сначала пересчитав это в "кванты", сделать поправку и пересчитать обратно.
как логгировать тоже нужно думать - иногда тактики вычислялки и битики для хранения не безграничны. в бинарном или текстовом виде. одним большим числом о "квантах" или до записи преобразовывать в год/месяц/день/... у "квантов" недостаточное разрешение, переписывается библиотека или добавляется поле(я) для хранения с нужной точностью - миллисекунд, наносекунд,... можно не постоянно 4х байтное число записывать, а допустим 2х байтное (~65тыс сек) и в самом начале логгирования или эпизодически записывать или полное время или сколько времени прошло с базовой даты (01.01.1970 или какое оно у вас).
Myp, убрать лишнее из вывода что бы не перегружать или глюки не ловить, иногда полезно, бывает у людей и наоборот шутки. берут готовый контроллер, гэпэсэ модуль, подключаааают ииииииии... а не работает вообще или какая-то часть. вот нет в выводе нужных данных и чавой-то оно не работает?

Хранить в секундах с какой-то даты - спорное решение на сегодняшний момент. Периодически добавляют leap second. То бомбу взорвут, то землетрясение и тогда добавляют секунду. Объявляют об этом заранее, дополнительную секунду присылают в GPS, в этот момент в минуте 61 секунда - с 0 по 60, а не 0-59. Если хранить только секунды, то расчеты даты-времени в прошлое немножко поплывут, если не иметь таблицу добавленных секунд.

доминирующий вариант это как раз хранение с более-менее НУЖНОЙ ТОЧНОСТЬЮ в "попугаях" "квантах" - секундах, миллисекундах, наносекундах, тиках генератора, колебаниях какого вещества,... "координационная секунда" это очередные попытки приделать кривой костыль к кривому костылю (в упрощённую модель с кучей в принципе плохо решаемых проблем). костыли с секундами настолько корявые, что годами думают, а не отказаться ли вообще от этой затеи. а нужны такие точности, которые гсп могут выдать, не нужны, учитывать эти координационные секунды или от них больше проблем будет, достаточно будет гпс или под задачу ещё придётся добавить какой источник информации о времени и хорошенько пофеншуить софт/железо, то уже отдельная тема.

осталось только ещё учесть переход на: зимнее/летнее время и наличие этого или нет