Проверка частотомера с помощью U-blox NEO M8N

Попробовал навигационный модуль u-blox neo m8n в качестве эталона частоты для проверки частотомеров осциллографа Rigol DS1054z и генератора сигналов Uni-T UTG932e.

Я приобрёл модуль у которого есть SMA и IPEX разъёмы для антенны и отдельный выход PPS для импульсов. На плате нет USB-UART преобразователя, поэтому для подключения его к компьютеру потребуется внешний.

С подключённой активной антенной модуль потребляет около 50 мА при питании от 3,3 В (на антенном разъёме есть питание для активной антенны).

По-умолчанию модуль выдаёт импульсы с частотой 1 Гц, но частоту импульсов можно изменять в довольно широких пределах от 0,25 Гц до 10 МГц. Опорный генератор модуля имеет частоту 48 МГц и если нужна высокая точность, то стоит выбирать частоты которые можно получить делением опорной частоты нацело. Например для импульсов частотой 10 МГц требует делитель 4,8 и сигнал будет иметь заметную погрешность, а частота 8 МГц требует делитель 6 и ошибка будет минимальной.

Защита аккумулятора от глубокого разряда

Пока контроллер магнитной рамочной антенны питается от литиевого аккумулятора 4S2P, который установлен на самой антенне. Это старый аккумулятор от пылесоса, который собран из ячеек Samsung ICR18650-22F на 2200 мАч каждая. В силу своего возраста они потеряли часть ёмкости и уже не могут работать по прямому назначению, но для питания самоделок вполне подходят. Заменил родной разъём аккумулятора на XT60 и сделал ответную часть с выходом на приборные разъёмы для заряда.

По документации производителя эти ячейки считаются "пустыми" при напряжении 3 В на ячейку, а при 2,75 В нужно прекращать разряд во избежании необратимых изменений. К сожалению плата защиты аккумулятора не отключает выход при достижении 11 В и даёт разряжать его дальше. Чтобы не мучить батарею добавил в код контроллера функцию отслеживания напряжения питания и отключения контроллера, если напряжение питания станет ниже 12 В.

Возня с Kyverno

Какое-то время пришлось возиться с Kyverno в GKE и решил сделать пометки для истории. Началось всё с обратной связи от разработчиков, которым Kyverno не давал создать сервис Knative.

Failed to create Ingress: admission webhook "validate.kyverno.svc-fail" denied the request: resource Ingress/NAMESPACE/SERVICE was blocked due to the following policies disallow-empty-ingress-host: disallow-empty-ingress-host: The Ingress host name must be defined, not empty.

Это результат работы политики disallow-empty-ingress-host, которая написана без учёта того что одинаковые kind Ingress может быть у разных apiVersion и скорее всего они будут несовместимы.

Добавил исключение в конфигурацию, но обновление чарта с политиками Kyverno завершилась с ошибками:

admission webhook "validate-policy.kyverno.svc" denied the request: no unique match for kind Service
admission webhook "validate-policy.kyverno.svc" denied the request: no unique match for kind Ingress

В общем отделаться по-быстрому исключением и закинуть улучшение в бэклог не вышло. Выпустил новый релиз чарта с подправленными политиками (/v1/Service вместо Service и networking.k8s.io/*/Ingress вместо Ingress) и раз полез в Kyverno, то заодно подтянул изменения с нижних окружений, которые касались Kyverno.

В числе этих изменений было и обновление версии самого Kyverno. Полистал коротенький upgrading kyverno, но там подсветили только риск при обновлении до 1.13, которая уже была позади. Список изменений в GitHub это просто компиляция сообщений из комитов, но на всякий случай полистал и его. Обновление версии Kyverno в GKE принесло проблему, которая не проявлялась в AKS - большое количество полиси отчётов стали содержать ошибки вида:

Управление антенной из SDR приложения

 Продолжение проекта магнитной рамочной антенны. В прошлый раз был добавлен актуатор для КПЕ в виде шагового мотора и сделана прошивка для микроконтроллера. В этот раз я полностью собрал антенну и сделал автоматическое управление из SDR приложения.

Для автоматического управления антенной взял Raspberry PI 3 Model B у которого на борту есть WiFi и Ethernet. Поскольку антенна будет стоять на балконе (на котором не предусмотрена розетка Ethernet), то пока единственным вариантом соединения с raspberry будет WiFi.

Продолжение истории с Cilium в GKE

Какое-то время назад я писал про отваливающиеся пробы у подов в GKE кластере после установки Cilium. Тогда пришлось сделать шаг назад и удалить Cilium из кластера чтобы не блокировать команды разработки.

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

Из свежего - несколько часов разбирался почему некоторые поды определённых демонсетов становятся "not ready" спустя несколько часов после создания. Интриги добавляло что это происходило ночью и один из них смог сам починиться и продолжить работу. Эта проблема отличалась от той, с которой я разбирался в отдельном кластере, т.к. там поды не проходили проверки сразу после создания. В итоге причина снова была в Cilium.

Дистанционная настройка рамочной антенны

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

Для вращения вала КПЕ буду использовать шаговый электродвигатель 17HS4023 формата NEMA17. Я раньше не имел дела с такими моторами и взял размер NEMA17 т.к. они используются в 3D принтерах и найти их в местных магазинах не составляет проблемы. На барахолках можно поискать б/у шаговики от принтеров или сканеров. Шаговые моторы от оптических (CD/DVD) или флоппи приводов выглядят слишком мелкими и скорее всего смогут вращать вал КПЕ только через редуктор.

Ошибка "metadata.resourceVersion: Invalid value: 0: must be specified for an update" в Terraform после редактирования ресурса

После редактирования ресурса knativeserving в Kubernetis кластере через kubectl edit Terraform не может применить к нему изменения через gavinbunney/kubectl провайдер:

│ Resource: "operator.knative.dev/v1beta1, Resource=knativeservings", GroupVersionKind: "operator.knative.dev/v1beta1, Kind=KnativeServing"
│ Name: "knative-serving", Namespace: "knative-serving"
│ for: "/tmp/1389615405kubectl_manifest.yaml": error when patching "/tmp/1389615405kubectl_manifest.yaml": knativeservings.operator.knative.dev "knative-serving" is invalid: metadata.resourceVersion: Invalid value: 0: must be specified for an update
│ 
│   with kubectl_manifest.knative_serving,
│   on knative.tf line 163, in resource "kubectl_manifest" "knative_serving":
│  163: resource "kubectl_manifest" "knative_serving" {

Я пробовал использовать параметр force_conflicts = true, но это не даёт эффекта.

Исправляется ошибка удалением аннотации kubectl.kubernetes.io/last-applied-configuration с нужного ресурса.

kubectl -n knative-serving annotate knativeserving knative-serving kubectl.kubernetes.io/last-applied-configuration-