AIR TRANSPONDER – Simple aviation transponder system. Простая система передачи и приёма параметров полёта

Идея проекта AIR TRANSPONDER возникла, как говорится, не на пустом месте. Так уж вышло, что планеризмом, стал заниматься с 2001 года. По началу подлётывал на разных аэродромах, пока в 2007-ом году, по иронии судьбы прям под боком, в той местности где я теперь проживаю, обнаружил самый известный в нашей стране планерный аэроклуб «2-ой МАК». С тех пор там же и подлётываю.

Авиационный парк нашего аэроклуба простой, всё как у всех.  Остатки былой славы Советского прошлого: Вильги, Бланики, Яки, Янтари которые бережём, своими руками восстанавливаем, и при надобности ремонтируем. Благо коллектив собрался очень дружный и толковый.

Учимся летать, а точнее парить на планёрах. Тут тоже как в любом другом АУЦ, программа обучения – прежде всего буксировка и полёты по кругам до «тошнотиков», несложные пилотажные зоны включая штопорные, и самое главное ради чего всё это – парение. Это когда у тебя перья прорастают, а инструктор тебя научил восходящие потоки пятой точкой чувствовать при этом самостоятельно лететь уже можешь, но увы, летать далеко не отпускают. И это понятно, так как парение — это целая наука! Не рассчитал – не долетел. Сел в поле, хорошо если не на лес. Если что напомню, планер – это всё же как самолёт, но только без мотора. L13 Бланик весит 295 кг без пилота. Лететь может не только вниз, но и вверх. Эта металлическая птица может набирать высоту благодаря восходящим потокам, совершать большие длительные переходы по небу, от облака к облаку… Разложить планёр об кочки при посадке очень не хочется. Потому то руководитель полётов(РП) внимание уделяет немалое тому, где мы парим, как парим, на какой высоте, в каком потоке, на каком удалении, в каком месте – за стартом или впереди старта… Однако, не всегда есть возможность визуального контроля за бортами. Это бывает по различным причинам. Зона-парение, площадка, у кого маршрут и планёр скрывается с глаз. Есть конечно радиосвязь. Регламент обмена, доклад, и всё такое… Хорошо, но всё же, необходимо больше. Иногда, казалось бы уже «всезнающие» планеристы, всё же увлёкшись потоком забываются, и уходят далеко за старт, да и другие причины так же бывают - азарт во чтобы то ни стало, найти тот самый термик...  Как раз из-за подобных ситуаций, родилась идея того, чтобы можно было как-то следить за бортами всех пилотов, особенно курсантов, не обладающих необходимым опытом. Что бы РП мог всегда увидеть, подсказать, дать команду на выполнение. В общем дополнительно обезопасить весь процесс обучения. Так и появилась идея, установить на борт что-то, что может передавать параметры на землю.

Конечно же первое что пришло в голову – это система ADSB и прочие xDSB. Всё это круто, но нереально дорого для нас, да и места нет для такой сложно аппаратуры, ко всему прочему имеющей вес. Другие коммерческие решения, так же оказывались дорогостоящими, либо не соответствующими нашей специфике, да и попросту не удобными.

Ну чтож. Пришлось, применить скромные радиолюбительские навыки.

Первое что было сделано – определено техническое задание от которого и оттолкнулся.

Техническое задание

1.       Первое и самое важное – никаких сторонних операторов связи, никакого интернет, GSM, 5G и каких-либо других сетей, включая радиолюбительскую APRS. Только своя базовая станция(БС) на земле и транспондер в воздухе, за исключением GPS/ГЛОНАС приёмника – тут уж никак.

2.       Определено количество транспондеров в системе. Так как авиапарк не большой, то и количество было определено по количеству бортов – 10 транспондеров в системе (хотя можно и больше).

3.       Определён максимальный радиус действия системы. Основываясь на опыте полётов наших старожилов, и учитывая требования безопасности полётов, за основу было взят круг радиусом 35 км (думаю можно больше в раза два). Это расстояние, в которое попадают всё значимые населённые пункты на карте, дальше которых на парение мы не улетаем. Ну и примерно 100 километровый треугольный маршрут для зачёта. Если учесть, что речь идёт о обучении то новички редко за 8 км от старта уходят, то более чем достаточно.

4.       Транспондер летательного аппарата должен в автоматическом режиме передавать:

• Место

• Высоту

• Курс

• Скорость курсовую

• Скорость в потоке

• Скороподъёмность

• Номер борта

5.       Транспондер должен передавать данные не реже 1 раза в 4 секунды.

6.       Мощность транспондера в пределах 1 Ватта. Питание автономное.

7.       Базовая станция (БС) должна принимать данные со всех транспондеров одновременно.

8.       Данные полученные БС должны быть записаны в базу данных.

9.       Данные полученные с транспондеров должны отображаться на карте в режиме реального времени.

10.   Отображать данные можно на компьютере планшете смартфоне в WEB браузере. Повторюсь, НИКАКОГО ИНТЕРНЕТА!!! Всё оффлайн.

11.   Базовая станция автономна: батарея, плюс антенна на СКП. Подключение компьютера к БС с помощью Ethernet или WIFI.

12.   Решение должно быть максимально бюджетным, при этом габариты транспондеров должны быть такими чтоб ничему и никому не мешали.

Первый пункт многое перечеркнул. Если бы не этот пункт то, готовых решений, на просторах интернета, сходу найти можно с дюжину. Всяческих GPS трекеров любительских. Про коммерческие и вовсе молчу. Но всё работает в сетях операторов связи, либо офлайн... Это минус. (Хотя на будущее включить использование GSM канала в качестве неосновного аварийного всё же стоит).

Так же не стал привлекательным вариант с использованием APRS системы, а именно с развёртыванием своей сети не включенной в общую сеть. Слишком громоздко. Да и требования пунктов 2 и 4 исключили возможность использования этого протокола. Представьте 10 бортов должны циклично, каждые 4 секунды, передавать данные в которых кодировано 7 параметров. При этом они не должны мешать друг другу.

Изучено было много материала. Камнем преткновения стал протокол передачи данных. Конечно, я много смотрел в сторону AX25. Но как по нормальному совместить передачу данных через радиоэфир на малой мощности, от постоянно движущегося объекта, на условно большое расстояние, да так чтоб гарантированно, при этом объектов сразу 10. И чтоб данные отображались действительные - актуальность 4 секунды?

Пришло понимание того что передаваемый пакет должен быть коротким. Исходя из п. 10 и 5 получается:

4сек / 10бортов = 400мсек 1борт

Пункт 12 так же определил выбор используемых частот - 433 или 144 МГц.

Предварительно прикинул какое при этом количество знаков необходимо передавать:

1. МЕСТО с определённой точностью - это данные GPS широта и долгота. Полный передаваемый параметр системой GPS — это два 9-тизначных числа с плавающей запятой!!

2. ВЫСОТА с определённой точностью. Полный параметр, передаваемый системой GPS 6 знаков.

3. Скорость. курсовая Закладываю 3 знака.

4. Скорость в потоке. Закладываю 3 знака.

5. Скороподъёмность. 3 знака.

6. Номер борта. 2 знака.

7. Незабываем что необходимо хоть какое-то избыточное кодирование, плюс преамбулы начала передачи пакета, контрольные суммы в конце передачи. Назовём это «Транспорт» + 50% ресурса – это примерно 15 знаков сверху.

В итоге что имеем: Необходимо кодировать и передавать в эфир ~ 50 байт, на частоте (433) 144МГц малой мощностью, со скоростью 400 мсек (примерная скорость 120 байт в секунду).

На помощь пришёл его величество случай. Как-то в один из зимних вечеров, пришёл ко мне товарищ и принёс мне простенькую самодельную метеостанцию, сделанную на ESP8266. Платка ESP и датчик BME280 всё без корпуса. Просто незатейливо, но всё работало. Идея со сбором метеоданных с того момента начала развиваться. Хотелось сделать больше, собирать больше различных данных. Явно не хватало анемометра и уровня осадков. Стал копать в этом направлении что есть. Перебрав опять же кучу материала, набрёл на статью об использовании датчиков OREGON SCIENTIFIC WRT810 и PCR800. И надо же, эти датчики есть в достаточном количестве в продаже, и даже не дорого! Заказал сразу два комплекта, себе и товарищу. Но проблема была в том, что к ним нет базы. Они беспроводные, работают по радиоканалу 433 MHz. Нужно было строить. В итоге был построен радио-модуль для приёма данных с этих датчиков, но самое главное то, что для этих датчиков не было поддержки в коде. На просторах интернет наткнулся на пост автора Invandy, в котором он описывает работу различных коммерческих датчиков, а также какие-то свои собственные разработки датчиков. На мой взгляд, это лучшая статья, и лучшая любительская работа. Ему спасибо! Начал изучать, и как водится допиливать этот проект под свои задачи. Всё получилось. Датчики были встроены успешно в проект и по сей день работают. Увидеть результат можно на narodmon.ru. Ссылка на проект git-lira.net. Результат впечатлил. Меня тут осенило. Стало понятно то, что идея применима к тому, что я искал столько времени. Просто, дёшево и сердито. Главное повторяемо!

Итак, за основу был взят код из проекта метеостанции Invandy https://github.com/invandy/Oregon_NR. Код существенно доработанный под мои задачи, но за идею ему ещё раз спасибо! Общая концепция проекта приобрела вот такой вид:

Как вы понимаете, исходя из схемы, транспондер только передаёт, а БС только слушает. Между собой они не договариваются. Это минус, но зато время передачи пакета существенно сокращается, да и потом, становится ниже вероятность того, что кто-то кого-то перестал слышать и в итоге пакет либо не дошёл, либо был отвергнут из-за квитанции… Остаётся только обрабатывать возможные ошибки на стороне БС и проверять контрольные суммы приходящих пакетов. На стороне БС ресурс производительности условно можно и не жалеть.

Прошу принять во внимание тот факт, что речь далее пойдёт о передаче данных на разрешённых радиолюбительских частотах диапазона 2 метра, с мощностью не превышаемой разрешённую. То есть, в соответствии с радиолюбительским регламентом! Следовательно, для использования этого диапазона вы должны иметь радиолюбительский позывной(лицензию).  Альтернатива - 433 MHz гражданский диапазон. Так же хочу отметить что согласно того же регламента, запрещено шифрование данных передаваемых радиолюбителями в эфир. Поэтому не стоит путать термины КОДИРОВАНИЕ и ШИФРОВАНИЕ. В данной статье речь идёт только о кодировании.

Формирование пакета.

Ну что же всё есть. Вооружившись начальными данными, и небольшим опытом вкратце обрисуем схему формирования пакетов.

Теперь, что нам необходимо передавать, какие параметры. Основываясь на ТЗ и на параметрах полёта планёра Бланик L13 имеем следующие предельные значения:

Длинна параметра. Полная.

Итого получается, что размер полезных данных (data) 26 ниблов! И это без транспорта. Слишком длинная посылка для радиоканала получается.  С этим надо что-то делать. Не остаётся ничего кроме, как оптимизировать этот data блок.

Самое прожорливое значение lan и lon получаемые приёмником GPS. Для нашей специфики полётов такая высокая точность избыточна. Поэтому принято решения сократить кодируемые координаты до 3-х знаков после запятой, да и саму запятую необходимо бы убрать избавившись тем самым от неудобного числа с плавающей запятой. Сократили lat lon до 12 символов, помимо символов «+» и « – » их кодировать достаточно одним битом 1/0 .

В самом начале за основу была взята версия пакета для WGR800, поэтому общая длинна пакета не изменялась, и в него входили только те параметры которые есть в схеме.  После первых оптимизаций получилась вот такая расчётная схема кодирования разрядов:

Можно сэкономить байт если использовать пустую часть нибла в переменной lat. В этом начальном нибле можно хранить флаги значений (+,-) для параметров lat, lon, vario. Использовать можно только последних три MSB.

Оптимизации касаются и других переменных значений. Пришёл к выводу, что курс можно не передавать, а рассчитывать его математически на стороне БС, то же самое и сделать с курсовой скоростью. Более сложной оказалась задача с ПВД – прибором воздушного давления. Пришлось пока отказаться, ибо скорость в потоке всё равно взять просто нечем (у меня нет датчика, но это задача на будущее).

Так же ограничил длину остальных параметров транспондера:

Длинна параметра.

Если кодировать знаки +/- в конец переменных lat, lon – а именно: использовать по одному биту значения 0, 1 как флаги знаков +/-. Пространство alt должно быть FF, так как не хватает места для указания параметра alt.  Можно взять ещё один свободный бит из переменной lon.

Тесты и отладки показали то, что можно экономить байтовое пространство, и задействовать все свободные биты которые не использовались бы при заполнении. В таблице, параметры lat, lon, представлены адресным пространством начиная с 0F Так как при максимальном числе, например, lat = 179 я могу использовать всего три разряда этого нибла. Нулевой бит этого нибла(2x80) остаётся незадействованным. Поэтому я могу использовать его как флаг: 1 это «-». 0 останется «+». Напомню, что в системе GPS, в зависимости от полушария, значения могут быть и минусовыми.

Так же поступил и с ещё одним параметром var (vario) указание скороподъемности так же требует разных знаков. В данном случае параметр lon ещё более короткий чем lat. И в старшем байте остаются целых два свободных бита (4x08, 4x04), чем я и воспользовался. В итоге родился пакет версии 6.

На заметку: Для передачи координат lat/lon, необходимо было избавиться от запятой, так как тип float занимает большое пространство, что увеличивает размер пакета, тем самым снижая его надёжность, а также снижается общая производительность системы. Поэтому я кодировал значение целого числа отдельно от дроби(мантиссы).

Ужимал пространство пакета, как только мог. Как можно увидеть из этой схемы, параметры curs и vario так же разделили между собой бит. Параметры alt кодируется значением от 0 до 255. На стороне БС этот параметр умножается на 10. Точность измерения в этом случае +/- 10 метров. Не очень то, но пришлось сэкономить. Параметр vario так же ограничен значением +/- 15 метров секунду. Для планеристов такие показатели во время полёта бывают крайне редко, как правило критические. Например, попал в грозовое облако, а вариометр с пределом всего 10 метров в секунду. Напомню, что полёты в облаках запрещены :).

Идентификаторы пакета

ID – идентификатор пакета. Содержит версию протокола. Так же ID содержит номер канала (timeslot) адрес 1x0F.

Небольшое пояснение по принципу формирования каналов транспондеров. Использован timeslot – то есть каждому транспондеру задаётся интервал и своё время передачи, в общем цикле равном 4 секундам. Например, первый транспондер начинает передачу на нулевой секунде, продолжительность 0,4 сек. Второй на 0,5-ой секунде, продолжительность 0,4 сек. Третий на 1-ой секунде и т.д…

Идентификация начинается с адресного пространства AAA + номер канала(ch). Тогда получаем:

1. AAA1    –             протокол X       AIR1 (канал1)

2. AAA2    –             протокол X       AIR2 (канал2)

3. AAA3    –             протокол X       AIR3 (канал3)  

4. AAA4    –             протокол X       AIR4 (канал4)

И т.д..   (Префикс AIR для удобства. Ставится в соответствие с идентификатором на стороне БС и может быть любым)

Стендовые испытания

Считаю нужным сказать пару слов об стендовых испытаниях, так как ошибки допущенные на этапе разработки, больше помогут понять то, как устроен пакет. В стендовых испытаниях уже участвовал декодер. Для этих целей поначалу я использовал БС от проекта метеостанции, доработал протоколы, допилил что нужно и, пакеты различных версий я уже мог отлаживать.  И так дело дошло до очередных стендовых испытаний. Выявлены следующие проблемы:

Неверно был расшифрован пакет

• Неверно была определена длинна пакета

• Неверно была определена CRC checksum

В итоге оказалось, что длинна пакета составляла 17 ниблов, а это 8 байт и 1 полубайт. Перепутал количество ниблов с длинной – нумерация начинается с нуля. То есть первый нибл под номером НОЛЬ. Кроме этого сократилось пространство для полезной информации из-за неправильно подсчитанной мной длинны checksum. Длинна checksum составляла 5 ниблов, то есть 2,5 байта.  Это особенность работы протокола OREGON V3.  И Так как я в своей изначальной работе с метеодатчиками имел дело с допиливанием, как мне казалось, хорошо изученного протокола для PCR810, то результатом такой ошибки стало то, что в пакет не вошло 4 параметра:

• Speed  FF

• ALT FF

• VARIO  F0

• CURS    0F

Всего три байта.

Частично решено

1.       Сократил checksum (избавился от CRC) до одного байта, занявшего пространство FF тем самым высвободил один байт.

2.       Увеличил длину пакета на 1 нибл (пол байта). И сдвинул checksum вправо (окончание пакета).

Высвободившееся пространство использовал для параметра alt – 0xFF. Ещё осталось пол байта vario. (При необходимости можно будет сдвинуть checksum ещё на пол байта вправо для параметра curs).

Пакет версии 7.

Результатом отладки стал пакет версии 7. Всего 19 ниблов. Если считать от 0-го, то последним будет 18-ый нибл.

Вид пакета v7. Пример:             AAA10D5C909206170F5

Сравнение типов пакетов

Для большего понимания, для сравнения приведу два типа пакетов.

Первый это пакет протокола OREGON V2.1 на основе которого был разработан пакет транспондера.

Первое отличие в том, что поле СИНХРОНИЗАЦИЯ, ТИП, КАНАЛ, были слиты в единый короткий идентификатор, более экономный, но не потерявший своей информативности.

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

Третье отличие отсутствие CRC8. Контрольной суммы достаточно…

Привожу ссылку на пост INVANDY в которой он описывает содержание различных пакетов OREGON - https://habr.com/ru/post/525446/ - Весьма наглядно!

Полевые испытания

Наконец наступил долгожданный лётный сезон. Можно приступать к полевым испытаниям. Сразу оговорюсь, что зимой-весной, било подготовлено и отлажено всё необходимое железо и ПО, но об этом потом…

Развёрнута базовая станция Старенький Macbook в качестве сервера. Приёмник - их было два, тестировались по очереди: Rado Shack и YAESU FT-11r В качестве преобразователя уровней двухканальный ОУ от оптического привода.  Декодер – их тоже было два: ESP8266 для беспроводного соединения с сервером, и Arduino UNO с ETHERNET шильдом для проводного соединения с сервером. Вариант на ESP8266 мне понравился больше, так как от него не было цифрового шума, и как ни странно обработка пакетов на ESP8266 была быстрее! Для беспроводного соединения рабочих станций с сервером, использовался WIFI роутер TP-LINK. Ну и в качестве рабочей станции – ноутбук, или смартфон, да что под рукой было…:) Да и самое главное – антенна. Внешняя двух диапазонная антенна OMNI 144/433 MHz, с круговой диаграммой, и с коэффициентом усиления, по паспорту, 3,5/4 db.

Транспондер был установлен на один из планёров. Кодер на Arduino Nano. В качестве трансмиттера YAESU FT-11r. Антенна была штатная резинка. На фотографии справа можно увидеть батарею, FT-11r, и беленькая коробочка. Вот оно в таком виде отлетало.  Обзору и пилотированию не мешало, приём был хорошим :).

В результате полевых испытаний была обнаружена ошибка передачи параметра alt. При достижении высоты 255 метров, счётчик (указатель высоты), обнулялся. После чего отсчёт вновь продолжался с нуля. И так каждый раз до 255 и вновь сброс счётчика…

Ошибка была на стороне приёмника (в библиотеке get_altitude) были установлены неверные типы данных – byte. Для корректного приёма этого было достаточно, но для дальнейшей передачи параметров больше 255, нужно было увеличить полученное число на один разряд путём перемножения полученного значения на 10. В результате разрядность числа увеличивалась, превышая размеры указанного типа данных – byte (всего 8 бит), не вмещающиеся в 8 бит старшие разряды отсекались. Так счётчик обнулялся через каждые 255 метров.

Решение было таким: Изменён тип данных всей библиотеки get_altitude до 16 бит – тип данных word.

Итоги полевых испытаний

Итоги первых полевых испытаний порадовали. При излучаемой мощности 0.1 Ватт (не опечатка, да всего 100 милливатт) уверенны приём был в радиусе 8 км от точки. Жаль в те дни не было парящих маршрутов. Ходили вокруг да около старта те самые 8 км. От экрана я не отрывался. Следил за всеми перемещениями метки.

В интерфейсе, если обратили внимание, я сделал так же метеосводку. Эти данные берутся с тех самых датчиков OREGON и BME280 которые устанавливались так же на аэродроме. На этой фотографии данные отсутствуют, но все датчики я так же оттестировал в полевых испытаниях. Тут проблем не было.

Тестирование проводилось на частоте 144.810 MHz мощностью 100 милливатт. Активные тесты начинаются с конца мая.  Несмотря на небольшую мощность, высОты на которых работают транспондеры, позволяют излучать на приличные расстояния. Так что коллеги радиолюбители, на частоте 144.810 MHz с субботы по воскресенье каждую неделю до октября, могут послушать сигналы транспондеров и при желании, декодировать.

Надо пояснить почему всё-таки 100 милливатт. Минимальная мощность излучения FT-11r составляет 300 милливатт, максимальная 5 Ватт. Но батареи моих Yaesu давно вышли из строя. Разобрав корпуса батарей я установил в них li-ion батареи на 3,7 вольт. При таком напряжении эти радиостанции не выдают более 100 милливатт.  В планах использование других источников питания и тестирование на 500 милливатт и на 1 Ватт.

По итогам полевых, боевых, лётных (как угодно...) испытаний были сделаны доработки:

15.07.20 Дополнен код приёмника. Теперь приёмник одновременно может принимать несколько транспондеров. Префиксы транспондеров AAA0 – AAA9

22.07.20 Исправлен код транспондера. Транспондер может передавать, соответственно кодировать пакеты AAA0 – AAA9

Замечание: Указатель префикса(заголовок) можно только в файле transponder_air.h Необходимо вынести define transponder в пользовательский *.ino файл – скетч.

Каналы транспондеров или time_slot function

Поскольку отладка происходила на одном транспондере, то дальнейшей задачей стала отладка двух и более транспондеров в системе. Для этого необходимо описать функцию time_slot которая будет определять время начала передачи пакета, каждого транспондера, в зависимости от времени (префикс транспондера содержит номер канала – номер таймслот).

Исходя из условий ТЗ, имеем:

qTX = 10              -              кол-во транспондеров AIRx (AAAx) – Начальное условие

iTX  = 4 сек         -              интервал передачи – расчётное условие, смещение времени не более 4 сек.

dTX = 0,4 сек     -              длительность передачи 1-го транспондера. Рассчитано и оптимизировано.

 Тогда очевидно:

iTX / qTX = dTX;

dTX =  0,4 сек

Таким образом необходимо добиться что бы каждый транспондер начинал передачу в своё заданное время с циклом dTX – 4 секунды. Для этого необходимо синхронизировать таймеры транспондеров с GPS time с точностью не ниже 0,1 сек. После чего отсчитывается 0-я секунда каждой минуты реального времени, от которой начинается отсчёт таймера. Например,

Формирование каналов (Time slot).

Порядок инструкций:

1. Синхронизация с GPS

2. Получение GPS_time_seconds

3. Определение нулевой секунды любой минуты.

4. Начало отсчёта от нулевой секунды

5. Начало передачи пакета, по достижению счётчика.

Да. Скорее всего, при такой реализации, мы получим пару проблем:

1-я проблема. Из-за особенности работы Arduino возникнет разность нулевой отметки времени. Отсчёт millis у всех ардуин хоть немного, но отличаются друг от друга. Из-за этого, сразу после включения, различные сигналы транспондеров будут накладываться друг на друга в начальном минутном интервале даже после синхронизации с GPS_time.

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

1: Инструкция 50% ресурса

2: Инструкция 50% ресурса

3: Инструкция offset_time = doit_now – возвратит FAIL

Потому что из таймера в память не пришло то значение счётчика секунд, которое было нужно, из-за того, что система была занята в этот момент другой процедурой. И попросту пропустила это время (например: при передаче в консоль, во время отладки).

Решение по второй проблеме, оказалось простым. Можно было использовать допуски +/- 0,2 сек. Но и этого не понадобилось. Опасения не подтвердились. Тесты показали, что заданные отметки времени своевременно отрабатывались инструкциями без пропусков (не в режиме отладки, вывод данных в консоль не производится!!!).

А вот по первой проблеме решение было таким:

1. Получить время с точностью до 0,001 секунды

2. Представить время в разрядной десятичной форме

3. Определить разряды, отвечающие за минуты, секунды.

4. Старшие разряды обнулить и не использовать. Таким образом, полученное переменное значение, повторяющееся в цикле, будет синхронно с GPS_time.

5. Привязать millis counter к полученному значению.

6. Задать смещение от нулевой секунды (offset_time)

Внимание, тут нас поджидает небольшая проблема! :) Дело в том, что значение time (параметр, отдаваемый библиотекой TYNY GPS и вообще приёмником GPS NEO M6), представляется в таком виде: hh min sec 0.00. То есть, миллисекунды всегда равны 00!!! В библиотеке они есть, но GPS приёмник их не может отдать из-за своей ограниченной функциональности.

Применил, как мне кажется, весьма элегантное решение. Для наглядности кусок из скетча:

Так как преобразование из DEC в HEX с сохранением вида числа (например, 59 DEC -> 0x59 HEX) затратное по количеству процедур и бла-бла-бла (сорри). По этому было решено использовать оператор - % (процент). Напомню, этот оператор заносит только остаток деления в переменную. Поэтому решение получилось очень простым. Взять параметр second, передаваемый gps.crack_datetime, и поделить его на 5 с сохранением остатка в ту же переменную second.

Так мы получаем цикличность параметра second, получаемого от GPS time, не от 0 до 60, а от 0 до 5-ой секунды с шагом 0,2 сек. То есть 0, 2, 4, 6, 8, 0 - каждые 5(пять) секунд! И так по кругу.

Таким образом получим прохождение через .0-ю секунду каждые 5 секунд. А так же, синхронизация пакетов происходит относительно быстро, за один цикл передачи транспондера - 5 секунд.

Замечу, что на период отладки, для удобства, я увеличил интервал отправки данных до 5 секунд. Но ничего не мешает вновь установить значение % 4 или даже % 3;

Еще одно важное замечание по поводу работы GPS NEO M6 и синхронизации времени gps. Синхронизация наступает только в том случае если есть приём данных GPS со спутников.

1. У меня эти модули начинают принимать данные (лампочка начинает моргать), только на подоконнике, внутри комнаты. И то не всегда. Если облачная погода, то приходится к стеклу прислонять.

2. Если приёмник впервые включается в вашей геолокации, то первоначальный расчёт данных, самим GPS приёмником при первом включении в ваших координатах, может занять до 20 минут при плохом приёме спутников!!!

3. Во время отладки транспондера, подключённого через USB, при выводе данных в терминал система будет запаздывать, не попадать в свои тайминги. Что так же будет вводить в заблуждение. Проверять синхронизацию в таком случае можно на стороне Базовой станции.

Эти факторы необходимо учитывать при отладке и настройке системы. Но напомню про специфику – полёты под открытым небом. Тут проблем с приёмом как правило нет.

По состоянию на момент написания статьи 21.01.2021, стендовые испытания проводятся с сентября по текущее время. Используются два транспондера непрерывно работающих на различных каналах (соседние ch0, ch1). За время тестирования, каналы формировались правильно, за исключением тех случаев когда пропадал приём GPS.

Из недостатков. При пропадании приёма GPS (стенд внутри помещения), происходит рассинхронизация каналов, по этому транспондеры начинают «плыть». На синхронизацию (вхождение транспондера в свой таймслот) уходит не менее 5 секунд - цикл установленный на время отладки.

Статья в процессе написания.

Весь материал, включая библиотеки и схемотехнику по данному проекту, доступен на github.com