Великобритания потратила £6 млн на data scientist’ов

В мае 2018 года коллектив британских ученых провел тематическое исследование и выяснил, что траты на data scientist’ов (или экспертов по аналитическим данным) в Великобритании значительно увеличились. Мы решили разобраться в ситуации и дать краткий обзор.

/ фото Nic McPhee CC BY-SA

В чем дело

Цель исследования — определить роль, которую играют «учёные по данным» в государственном секторе, и выделить сферы деятельности, где наблюдается повышенный спрос на таких специалистов. Для реализации задумки были опрошены представители пяти министерств: труда, транспорта, здравоохранения, строительства и Министерства по выходу Великобритании из Европейского союза.

Например, в Министерстве труда штат «учёных по данным» увеличился на 400% за 3 последних года: с 6 до 30 сотрудников; а в Министерстве строительства уже работают 69 специалистов, получая в сумме в £3,725 тыс. в год. Интересно, что в Министерстве по выходу Великобритании из ЕС «учёных по данным» вообще не оказалось.

В целом по оценкам ученых, к 2020 году data scientist’ы добавят £241 млрд к британскому ВВП и создадут 157 тыс. новых рабочих мест в этой и смежных сферах. Отметим, что в коммерческом секторе потребность в найме «учёных по данным» пока не так высока: всего 18% британских компаний работают с Big Data.

Что другие

Другие исследования подтверждают, что интерес к «учёных по данным» растет. В IBM прогнозируют, что к 2020 году спрос на экспертов по аналитическим данным вырастет на 28%. Это — 700 тыс. вакансий ежегодно. При этом 19% из них будут в сфере финансов и страхования.

Если говорить про skillset, то IBM выделают умение работать с MapReduce, Apache Pig, Apache Hive и Apache Hadoop. Например, в США специалист по MapReduce в среднем зарабатывает $116 тыс. в год. В Европе зарплата таких специалистов варьируется от €30 до €99 тыс. в год (для Junior и Senior соответственно).

Как пишут в Rusbase, российским компаниям нужны не только data scientist’ы, но и data engineer’ы. Однако заработок таких специалистов в России меньше, чем в Европе или Америке: если смотреть HeadHunter, ежемесячный оклад data scientist’ов в Москве варьируется от 50 до 200 тыс. рублей.

Не так быстро

В 2018 году компания Kyvos Insights опросила 300 американских предприятий и выяснила, что профессиональных кадров в отрасли не хватает: 52% респондентов заявили, что столкнулись с нехваткой специалистов для проектов, подразумевающих работу с Big Data. При этом только 29% опрошенных компаний уже получают прибыль от инвестиций в это направление.

Основатель и ведущий эксперт по данным компании V-Squared Data Strategy Consulting Вин Вашишта (Vin Vashishta) считает, что проблема заключается в сложности и длительности обучения таких специалистов. Проходит 6-8 лет прежде чем выпускники ВУЗов смогут найти достойную работу, а краткие тренинги и boot camp’ы не позволяют людям получить достаточно знаний.

/ фото Universitat Pompeu Fabra CC BY-ND

Директор Institute of Coding (площадки для дистанционного образования) отмечает, что «если не решить проблему нехватки data scientist’ов, в будущем это приведет к катастрофическим последствиям для всей индустрии».

Для того, чтобы решить проблему, ученые из Великобритании предлагают правительству развернуть государственную программу развития направления data science, повысить зарплату специалистам в этой области и не «привязывать» их к конкретному министерству. Однако если говорить о мире в целом, помимо громких заявлений, государственных программ пока никто не предложил.

P.S. О чем еще мы пишем нашем блоге об IaaS:

P.P.S. Наши материалы на Хабре:

Let's block ads! (Why?)

От наброска до Google Play или как я сделал свое первое android приложение

Привет хабр! В этом посте я расскажу о том, как я хотел сделать простое приложение «для себя», а получилось вполне достойное Google Play приложение с множеством функций, которых у подобных приложений нет.

Начну с того, что меня зовут Андрей и я учусь в 9 классе. Разработкой под android я начал интересоваться в начале декабря прошлого года (до этого изучал python). Примерно за месяц я научился самым основам и дальше стал писать простые приложения, потихоньку закрепляя пройденное и узнавая новое.

И вот, в начале февраля я вспомнил, как долго и утомительно было считать полугодовые оценки калькулятором. Конечно, первой идеей было написать свое приложение. Изначально это было только поле ввода для чисел, куда просто вводились оценки, и TextView с результатом.

На этом я, конечно, не остановился и решил сделать хоть какой-то интерфейс и расширить возможности приложения. Поле ввода исчезло, но были добавлены клавиатура — 12 кнопок (10 с оценками и 2 для стирания) и индикатор с последними оценками. Этого было вполне достаточно для удобной и быстрой работы. Так стало выглядеть приложение:

Спойлер

Делал все это я неторопливо, считая что на доработку этого приложения у меня еще предостаточно времени. И вдруг, около 20 числа, я узнал, что оказывается есть конкурс, который заканчивается 28 числа (начался первого), и я вполне могу поучаствовать в нем со своим приложением (другие приложения были сделаны исключительно для повышения навыков). Правда, приложение нужно было еще допиливать, да к тому же конкурс российский, и десятибалльную систему там вряд ли была бы полезна.

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

Очень хотелось добавить голосовой ввод (т.е. чтобы можно было диктовать оценки), для чего был выбран yandex.speechkit, но разобраться с ним я тогда не смог, не понял чего-то ключевого, из-за чего приложение было заброшено.

Во второй половине апреля я решил заново попробовать разобраться со speechkit и (чудо!) все сразу оказалось простым и понятным! Я сразу прикрутил распознавание, синтез и даже голосовую активацию к своему приложению. Раздражало только то, что все это требовало интернет, а выкладывать в google play не хотелось из-за ограниченного числа запросов.

К счастью, распознавание и синтез (гугловский после яндекса звучит отвратительно) речи от гугла оказались бесплатными, а к тому же не требовали интернета, потому было решено использовать именно их. Голосовая активация от яндекса осталась, но к сожалению единственной более-менее подходящей фразой было "Поехали!", а повторять это постоянно как-то нет особого желания.

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

Так выглядит приложение теперь:

Cпойлер

Google Play

Довольно неприятно в самом начале расстаться с 25$ за регистрацию. Тем более что приложение полностью бесплатное и я с него ничего не получил. Приложение я выложил 10 мая. Загрузка приложения и заполнение всех сопутствующих форм заняло больше времени чем я предполагал.

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

С 10 мая по 16 июня приложение набрало 178 установок. Из них 75 из Молдовы, 48 из России, 24 из Беларуси, 17 из Украины и по 4 из Казахстана и Латвии. Из остальных стран меньше. Я из Молдовы, но почему из нее столько установок я не могу понять. О приложении знают от силы 20 человек.

И тут я наткнулся на камень. Что такое 178 установок? Хорошо это или плохо? Да, маркете есть приложения с намного большим числом установок. Но ведь это приложение ориентированно на узкую аудиторию (ученики/студенты и преподаватели), да к тому же нужно им только в определенный отрезок времени. Надеюсь сообщество поможет мне понять это.

Let's block ads! (Why?)

«Так можно было»: необычные, но эффективные способы использования «аудио»-технологий

У всех технологий есть принципы целевого использования, в том числе и у аудиотехники. Но иногда и она работает в необычных и непредсказуемых условиях. Так появились уже привычные для нас эхолоты и аппараты УЗИ: в этих приборах звук помогает выполнить якобы «нецелевую» для него функцию — видеть то, что скрыто для обычного глаза, ориентироваться в пространстве.

И сейчас некоторые аудиогаджеты и «аудио»-технологии можно использовать совсем не так, как мы привыкли. Сегодня рассказываем про несколько кейсов необычного — и удивительно эффективного — применения аудиотехники или физических свойств звука.

Фото B Rosen CC BY-ND

«Наушники» с ароматическим эффектом

Для того, чтобы успокаивать аэрофобов, Французский Национальный политехнический институт изобрел специальные наушники с микрофоном, который на самом деле микрофоном не является.

Выносной микрофон у этих наушников — это канал для распространения «успокаивающего» запаха (мяты, лаванды, ромашки или цветов апельсина). Пахучие вещества, необходимые для работы гаджета, введены в состав биополимера. Емкость с нитями из этого биополимера помещается в подлокотник кресла, к которому по «стандартному» (внешне) разъему и «подключаются» наушники.

Провод наушников в действительности снабжен пустотелой трубкой, по которой в микрофон и нагнетается запах (по мнению разработчиков, если бы источник запаха располагался прямо в микрофоне, аромат ощущался бы слишком интенсивным и не оказывал бы расслабляющего эффекта). Такой подход позволяет не просто дозировать запах, но и «изолировать» его, сделать его в полной мере индивидуальным (по похожему принципу ранее наушники сделали индивидуальным звук). Ведь ароматы, которые нравятся и успокаивают одних, другим могут быть неприятны — особенно если речь идет о долгом пребывании в замкнутом пространстве.

Основная задача таких наушников — с помощью музыки и запахов успокаивать пассажиров, страдающих аэрофобией. Пока это — только разработка, которая, возможно, в течение нескольких лет появится в самолетах. Её название — С2АО, от слов casque (наушники), aero, audio и olfactif (офлактивные, обонятельные).

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

В разъеме TRRS для наушников есть четыре контакта — в том числе один для микрофона и два для вывода звука (левый и правый). Кроме того, разъем передает небольшое количество энергии. Но эту энергию можно использовать и для других целей — например, передавать в микропроцессоры дополнительных устройств, которые необязательно связаны с аудио.

Так, есть технологии, которые позволяют превратить устройство с «джеком» для наушников в термометр, осциллограф и даже в прибор, который может создавать 3D-снимки реальности. Ещё одно устройство претендует на звание «самой маленькой погодной станции» в мобильном: оно позволяет замерять температуру, атмосферное давление, уровень ультрафиолетового излучения, влажность и окружающее освещение.

Сильная сторона таких устройств — легкость и небольшой размер, потому что им не нужны батареи или аккумуляторы, а также приемники интернет-сигнала, так как все эти функции выполняет смартфон.

Акустическая левитация

Мы используем звуковые волны для решения разных задач. Какие-то способы применения звука давно стали для нас привычными, а какие-то всё ещё в новинку — несмотря на то, что принципы, которые за ними стоят, открыты давно.

Один из таких принципов — использование физических свойств звуковых волн для того, чтобы поднимать в воздух предметы из разных материалов и разной формы. Этот принцип получил название «акустическая левитация». Она возможна благодаря стоячим звуковым волнам. При определенной амплитуде колебаний давление звука становится сильнее действия гравитации — предмет начинает «левитировать» в воздухе.

Эксперимент с управляемой акустической левитацией

Основная проблема акустической левитации в том, что контролировать движение объектов в стоячих звуковых волнах очень сложно. Но в 2013 году ученым из Швейцарской высшей технической школы Цюриха удалось достичь значительных успехов в развитии технологии контролируемой акустической левитации — они смогли поднять в воздух деревянную зубочистку, покрутить её и более или менее точно перенести из точки А в точку Б. Сейчас проводятся эксперименты с левитацией и более крупных объектов — исследователи ищут (и находят) способы поднимать в воздух предметы всё больших диаметров.

Звуки в медицине

Ещё одно применение звуковых волн — медицина. Мы используем ультразвук и инфразвук для того, чтобы диагностировать и лечить самые разные заболевания. Но в этой сфере тоже регулярно происходят открытия.

В 2009 году компания Medical Acoustics разработала так называемую «легочную флейту» — Lung Flute. Это прибор для лечения некоторых заболеваний дыхательных путей: эмфиземы, бронхита, хронической обструктивной болезни легких и т.д. Традиционно их лечат медикаментозно, но Lung Flute помогает избавиться от слизи в бронхах с помощью низкочастотных звуковых волн.

Прибор состоит из длинной пластиковой трубки и стержня — пациент дует в трубку, а вибрация стержня порождает акустические волны в грудной полости. Похожим образом вибрируют реснички, покрывающие эпителий бронхов и в норме помогающие избавиться от грязи и слизи, которая туда попадает. По сути, Lung Flute работает так же, как и одна из естественных систем организма, помогая ей справляться с «очисткой» бронхов и облегчая процесс дыхания. Сейчас этот прибор используется в Канаде, Европе, Японии и США.

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

Но для «нецелевого использования» аудиотехники не всегда нужны исследования и долгие разработки. Иногда для того, чтобы победить социальные ожидания, нет необходимости даже модифицировать привычный гаджет — достаточно использовать его в нестандартной обстановке. Так, например, американский студент недавно пришёл на экзамен с портативным виниловым проигрывателем, наушниками и стопкой пластинок. Он хотел слушать музыку во время выполнения работы, а телефоны на экзаменах запрещены, чтобы студенты не могли списывать — с помощью «классического» проигрывателя он необычным образом решил эту проблему.

О чем еще мы пишем на Хабре:

Let's block ads! (Why?)

Используем беспроводной выключатель на 433МГц для управления ПК

Привет geektimes habr.

У меня дома скопилось несколько беспроводных выключателей на 433МГц, стало интересно, можно ли их использовать для каких-либо задач, например для управления компьютером или для интегрирования в систему «умного дома».

Эти выключатели удобны своей дешевизной и стабильной работой, выглядят они примерно так:

Как это работает, и что с ними можно сделать (гусары молчать:), подробности под катом.

Теория

Скажу сразу — как работает такой выключатель, я не знаю, хотя и примерно догадываюсь. Значит нужно будет произвести небольшой reverse engineering.

Первым делом сигнал нужно принять, для чего используем многим уже известный RTL-SDR приемник, у радиолюбителей часто называемый просто «свисток». Этот девайс ценой всего в 10$ позволяет принимать радиосигналы в диапазоне примерно от 50 до 1250МГц, для нас то что нужно. Тема старая, но если кто не читал — https://habr.com/post/149698/.

Делаем первый шаг анализа — внимательно смотрим на выключатель. Обнаруживаем что сзади на корпусе у него написано «Made in China» (кто бы мог подумать?) и, что более важно, указана частота 433МГц. Теперь можно подключить SDR-приемник, запустить SDR# и убедиться, что данные действительно передаются.

Симметрия сигнала на спектре подсказывает про наличие AM-модуляции. Кстати справа виден более слабый «чужой» сигнал — их тоже можно принимать и декодировать, про них будет подробнее сказано отдельно. Впрочем, вернемся к сигналу. Записываем его в формате обычного WAV и нажимаем кнопки на пульте — для примера я нажал кнопки ON и OFF на канале «1».

Открываем звуковой файл в любом аудиоредакторе, и воспользуемся для сравнения сигналов другим профессиональным инструментом аналитиков — программой Paint. Размещаем 2 сигнала c разных кнопок один над другим, чтобы увидеть разницу:

Нетрудно видеть, что мы имеем обычную битовую последовательность, отличие в которой как раз в одном бите, соответствующем кнопке ON или OFF. Пока кнопка нажата, выключатель просто циклически повторяет эту последовательность в эфир.

Из этого кстати можно сделать один важный вывод — сигналы таких выключателей (речь о дешевых моделях) передаются в эфир «как есть», без какой-либо аутентификации, защиты или шифрования. Такой выключатель или беспроводную розетку с таким выключателем не стоит использовать для каких-то ответственных функций, например для включения мощных обогревателей или тем более для открытия входной двери или гаража. Дело тут даже не в хакерах (шанс что кто-то будет взламывать мой дом беспроводным способом я оцениваю меньше чем шанс падения на мой дом МКС), а в том, что сосед может случайно купить такой же выключатель, и коды у них могут совпасть (впрочем на выключателе есть возможность выбора между 4 каналами). По моему опыту использования, 2-3 раза за год выключатель таки включался «сам», то ли помеха, то ли действительно принимался далекий сигнал от такой же модели.

Разумеется, это не относится к более сложным системам, таким как Lora или Philips Hue, там с шифрованием все впорядке.

Впрочем, вернемся к нашей задаче. Можно написать декодер таких сигналов самостоятельно, но к счастью, это уже сделали до нас, в проекте называемом «rtl_433». Изначально программа была создана для Linux, Windows-версию можно скачать по адресу https://cognito.me.uk/computers/rtl_433-windows-binary-32-bit/ Linux версию можно скачать с https://github.com/merbanan/rtl_433.

Запускаем программу из командной строки: «rtl_433.exe -F json»

Мы получили данные, осталось написать программу для их обработки.

Raspberry Pi

Первое, что интересно рассмотреть, это Raspberry Pi. Для установки rtl_433 на Raspbian распаковываем архив github.com/merbanan/rtl_433/archive/18.05.tar.gz и выполняем следующие команды:

sudo apt-get install libtool libusb-1.0.0-dev librtlsdr-dev rtl-sdr build-essential autoconf cmake pkg-config
cd rtl_433/
autoreconf --install
./configure
make
make install

Вторым шагом, напишем программу которая будет получать эти данные, и в зависимости от них, выполнять нужные действия. Код на Python весьма несложный:

from __future__ import print_function

import os, sys, io
import json
import subprocess

print("RTLSDR listening started")
transmitter_name = "Waveman Switch Transmitter"
transmitter_channel = 1

proc = subprocess.Popen(["rtl_433 -F json"], stdout=subprocess.PIPE, shell=True)
while True:
    try:
        line = proc.stdout.readline().encode('ascii','ignore')
        proc.poll()
        data = json.loads(line)
        print(data)
        m,st,ch,btn= data['model'],data['state'],data['channel'],data['button']
        if m==transmitter_name and ch==transmitter_channel and btn==1 and st=='on':
            print("ON")
        elif m==transmitter_name and ch==transmitter_channel and btn==1 and st=='off':
            print("OFF")
    except KeyboardInterrupt:
        break
    except:
        pass

print("RTLSDR listening done")

Чтобы запустить код, нужно сохранить его в файле (например rtl_listen.py) и запустить командой «python rtl_listen.py».

Как можно видеть, программа запускает процесс с помощью subprocess.Popen и читает из него данные. Дальше все просто, код вполне читабельный, и внести изменения будет не сложно. В данном примере, при нажатии кнопки «1» выводится сообщение print(«ON»), вместо этого можно делать что-то другое, например, активировать пин GPIO, включать реле, посылать данные на сервер и пр.

Кстати, сам RTL-SDR-приемник по сравнению с Raspberry Pi выглядит так:

Windows

К сожалению, под Windows 10 вышеприведенный код не заработал. Но как подсказал поиск на github, работает асинхронное чтение данных из отдельного потока. Почему так, выяснять было лень, просто приведу под спойлером работающий код.

Исходный код

from __future__ import print_function

import os, sys
import subprocess
import time
import threading
import Queue
import json

class AsynchronousFileReader(threading.Thread):
    # Helper class to implement asynchronous reading
    def __init__(self, fd, queue):
        assert isinstance(queue, Queue.Queue)
        assert callable(fd.readline)
        threading.Thread.__init__(self)
        self._fd = fd
        self._queue = queue

    def run(self):
        # The body of the tread: read lines and put them on the queue.
        for line in iter(self._fd.readline, ''):
            self._queue.put(line)

    def eof(self):
        # Check whether there is no more content to expect
        return not self.is_alive() and self._queue.empty()

def replace(string):
    while '  ' in string:
        string = string.replace('  ', ' ')
    return string


def read_rtl_data():
    process = subprocess.Popen(["rtl_433.exe", "-F", "json"], stdout=subprocess.PIPE, stderr=subprocess.PIPE)

    # Launch the asynchronous readers of stdout and stderr.
    stdout_queue = Queue.Queue()
    stdout_reader = AsynchronousFileReader(process.stdout, stdout_queue)
    stdout_reader.start()
    stderr_queue = Queue.Queue()
    stderr_reader = AsynchronousFileReader(process.stderr, stderr_queue)
    stderr_reader.start()

    transmitter_name = "Waveman Switch Transmitter"
    transmitter_channel = 1

    # Check the queues if we received some output
    while not stdout_reader.eof() or not stderr_reader.eof():
        # Show what we received from standard output.
        while not stdout_queue.empty():
           line = stdout_queue.get()
           print("Line1:", repr(line))
           data = json.loads(line)
           # print("Data:", repr(line))
           m,st,ch,btn= data['model'],data['state'],data['channel'],data['button']
           if m== transmitter_name and ch== transmitter_channel and btn==1 and st=='on':
               print("ON")
           elif m== transmitter_name and ch==transmitter_channel and btn==1 and st=='off':
               print("OFF")

        # Show what we received from standard error.
        while not stderr_queue.empty():
            line = replace(stderr_queue.get())
            print("Line2:", line)

        # Sleep a bit before asking the readers again.
        time.sleep(0.1)

    stdout_reader.join()
    stderr_reader.join()

    # Close subprocess' file descriptors.
    process.stdout.close()
    process.stderr.close()

if __name__ == '__main__':
    print("RTLSDR listening started")
    
    read_rtl_data()
    
    print("RTLSDR listening done")

С этим кодом мы можем использовать любые действия в обработчике, логика такая же как и в коде на Raspberry Pi.

Пример: допустим, у нас есть компьютер, выделенный под домашний кинотеатр, и мы хотим выключать его нажатием кнопки с пульта. Заменяем код 'print(«OFF»)' на

               os.system('shutdown -s')
               sys.exit(0)

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

Заключение

Как можно видеть, все довольно-таки просто, и есть место для экспериментов. Наконец, небольшой бонус для тех кто дочитал до сюда. На 433МГц работает большое количество разных устройств, которые rtl_433 может декодировать, можно просто оставить программу работать несколько часов, и посмотреть что «поймается». Под спойлером пример такого лога, записанного ранее:

Лог

2018-01-10 21:15:17 : Prologue sensor : 5 : 15
Channel: 1
Battery: OK
Button: 0
Temperature: 6.00 C
Humidity: 11 %

2018-01-10 21:15:28 : inFactory sensor
ID: 71
Temperature: 6.67 °C
Humidity: 99 %

2018-01-10 21:16:07 : Toyota : TPMS : 61511475 : 60e5006b : CRC

2018-01-10 21:20:33 : Prologue sensor : 5 : 15
Channel: 1
Battery: OK
Button: 0
Temperature: 6.00 C
Humidity: 11 %
: Waveman Switch Transmitter
id: A
channel: 2
button: 1
state: on
: Waveman Switch Transmitter
id: A
channel: 2
button: 1
state: on
: Waveman Switch Transmitter
id: A
channel: 2
button: 1
state: on

2018-01-10 21:21:21 : Akhan 100F14 remote keyless entry
ID (20bit): 0x41
Data (4bit): 0x4 (Mute)
: Waveman Switch Transmitter
id: A
channel: 2
button: 1
state: off

2018-01-10 21:32:31 : Ford : TPMS : 00268b1f : a34a0e : CHECKSUM
2018-01-10 21:32:32 : Ford : TPMS : 00268a5c : 9c440e : CHECKSUM
2018-01-10 21:32:37 : Ford : TPMS : 016dbfce : 99430e : CHECKSUM
2018-01-10 21:32:39 : Ford : TPMS : 002671a0 : 9c4a0e : CHECKSUM

Есть интересные данные, например давление в шинах у соседского автомобиля (TPMS, tire-pressure monitoring system), или наружняя температура +6 с чьего-то датчика. Это позволяет например, выводить наружнюю температуру, если у соседей случайно окажется совместимая с этим протоколом метеостанция.

Всем удачных экспериментов.

Disclaimer: Я понимаю, что использование SDR и цифровой обработки для чтения сигналов OOK-модуляции — это по сути, стрельба из пушки по воробьям. Возможно, на aliexpress существуют готовые приемники за 1-2$, которые делают то же самое, с меньшей ценой и меньшим энергопотреблением. Если кто знает такие модели, напишите в комментариях.

Let's block ads! (Why?)

Получение разрешения на работу в Чехии: случай дуальной трудовой карты

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

Введение

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

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

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

Поиск работы

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

Итак, процедура следующая: для подачи документов на дуальную трудовую карту нужно заключить договор на трудоустройство на одну из специальных вакансий, которые опубликованы на специальном портале MPSV (так называемые компании — держатели трудовой карты, по-чешски držitele zaměstnanecké karty). Здесь действует такое правило: если на такую вакансию в течении месяца не находят подходящего кандидата-чеха, то на нее могут взять соискателя-иностранца и только в этом случае соискатель имеет право подать на получение трудовой карты.

На странице поиска на портале MPSV можно легко найти вакансии по любому интересующему направлению, в определенном городе и крае и найти позиции для определенной компании. Каждая вакансия на этом портале кроме прочего должна иметь название вакансии (Požadovaná profese) и номер вакансии (Číslo volného místa).

Здесь существует определенная возможность трудоустройтва и на вакансию, которая ранее не была опубликована на портале MPSV. Однако в этом случае будет необходимо договориться с компанией о том, что компания опубликует вакансию на этом портале и только по истечению месяца будет возможно заключить договор и подать на получение трудовой карты. Не все компании готовы на такой шаг.

Подготовка документов к подаче на получение карты

Во-вторых, нужно подготовить все необходимые документы. Для подачи заявления на трудовую карту необходимы следующие документы: бланк заявления (его можно скачать отсюда), трудовой договор с фирмой, договор на проживание (договор аренды или договор с общежитием) и нострификацию диплома с заверенной копией перевода. Кроме того необходимо приобрести почтовые марки на сумму 1500 крон.
Так выглядит заверенная копия перевода диплома:

А вот подтверждение о признании диплома о высшем образовании (нострификация):

Теперь приступаем к заполнению заявления. Первую страницу заполняем следующим образом:

В секции A отмечаем галочкой «požadovaná pracovní pozice je v centrální evidenci volných pracovních míst obsaditelných držiteli zaměstnanecké karty» и в поле Číslo volného místa указываем тот самый номер позиции, о котором я говорил выше. Затем в секции B указываем свои персональные данные (имя, фамилию, телефон, электронную почту, дату и место рождения, пол, семейный статус, полученное образование).

Вот так примерно должна быть заполнена вторая страница:

В секции C указываем данные о выбранной вакансии. В поле Pracovní zařazení указываем в точности название позиции из описания позиции на портале mpsv.cz. В секции E указываем свой чешский адрес. Больше на этой странице ничего не нужно заполнять.

На третьей странице только указываем информацию о последнем долговременном пребывании в Чехии в секции H (Předchozí pobyt na území České republiky delší než 3 měsíce) и данные загранпаспорта в секции I. На странице 4 указываем данные родителей аналогично тому, как мы это указывали в бланке заявления на долговременное проживание с целью обучения.

Подать документы необходимо в местном отделении Министерства внутренних дел — Полиции иностранцев (Cizinecká policie). После подачи всех документов работник вам даст номер заявления для прослеживания статуса. Максимальное время рассмотрения заявки — два месяца.

На этом все. Желаю всем удачи в поиске работы и получении разрешения на проживание! Буду рад ответить на любые интересующие вас вопросы в комментариях.

Let's block ads! (Why?)

Владислав Здольников, владелец TgVPN, подал иск против Роскомнадзора

Вчера стало известно о том, что владелец прокси-сервиса для Telegram TgVPN Владислав Здольников подал иск против Роскомнадзора. Истец просит суд признать блокировку используемых его сервисом IP-адресов незаконной, пишут «Ведомости». Права Здольникова защищает юрист «Роскомсвободы» Саркис Дарбинян.

Как оказалось, иск был подан в Арбитражный суд Москвы еще 13 июня. Правда, его подал не лично Здольников, а компанией Private Networks, зарегистрированная в Шотландии, которая является владельцем TgVPN. В документе указано, что прокси-сервис получил от Роскомнадзора уведомление о блокировке в тот же день, когда был заблокирован и Telegram.
Истец выступает против того, что в качестве основания для блокировки ведомство назвало распространение запрещенной информации. В свою очередь, представители Роскомнадзора заявляют, что на принадлежащих прокси-сервису IP-адресах были обнаружены материалы с призывами к экстремистской деятельности, а также материалы в поддержку сирийских вооруженных группировок, которые запрещены в России.

По словам же Здольникова, на всех заблокированных IP не было ничего, кроме официального сайта-визитки tgvpn.com. Эти IP выполняют чисто техническую функцию и если кто-то попробует зайти на них, то такой пользователь получит просто пустую страницу.

В прошлом году Здольников с коллегами обратились в Следственный комитет, заявив о том, что чиновников Минкомсвязи и Роскомнадзора необходимо привлечь к ответственности сразу по трем статьям Уголовного кодекса (293, 285 и 306). Причина обращение — наличие дыр в системе блокировок Роскомнадзора, которые позволяли заблокировать в РФ любой ресурс.

Let's block ads! (Why?)

Разработка велоспидометра на базе дисплея от Nokia 3310

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

У меня всегда было желание иметь подобное устройство. При этом я сформулировал ряд собственных требований, которым оно должно удовлетворять. Прежде всего, мне очень хотелось, чтобы по мере движения на дисплее пририсовывался график изменения скорости в зависимости от расстояния или времени, накопленный за небольшой период. А также, фиксировать (логировать) измерения на запоминающее устройство для дальнейшей передачи статистических данных на компьютер, их более детального просмотра. Дешёвые модели не полностью соответствуют моим требованиям, а за дорогие модели переплачивать не хочется.
Исходя из вышесказанного, я принял решение о создании собственного велоспидометра на базе микроконтроллера ATmega8. Было множество вопросов, в частности о применяемой периферии. Случайно наткнулся на статьи про использование дисплея от некогда популярного мобильного телефона Nokia 3310. Прочитав на него даташит и убедившись в простоте его управления, у меня не оставалось и сомнений, что велоспидометр будет изготовлен в корпусе вышеупомянутого телефона с его же родным дисплеем. Корпус довольно неплохой, да и сам аппарат найти не составляет труда.

В качестве ПЗУ для записи статистики измерения я решил поставить классическое ПЗУ 24XX512 (на 512 Кбит), которая управляется по интерфейсу I2C. Заморачиваться на применении карты памяти SD/MMC я не стал. Ещё одной немаловажной функцией в устройстве являются часы. Они служат для привязки некоторых измеряемых определённых параметров (например, максимальная скорость) к дате и времени, а также, необходимы для записи временных отметок в статистике. В качестве часов я применил отдельную от микроконтроллера микросхему часов реального времени (RTC), которая имеет независимое питание от батарейки и также общается с контроллером по I2C.

Дополнительные второстепенные требования я реализовывал в функционале устройства на этапе написания программы. Сюда относятся всякие организационные вопросы: количество задействованных кнопок, расположения на дисплее тех или иных элементов, навигация по интерфейсу и так далее. В плане навигации я заранее решил не усложнять программу, например, не реализовывать меню настроек, в частности, настройки даты и времени. Настройка часов осуществляется один раз. Часы «тикают» независимо в самой микросхеме RTC благодаря кварцу 32.768 КГц и батареи питания, которой хватает на длительное время. Настройка даты и времени осуществляется через UART интерфейс велоспидометра, подключающийся в COM-порт компьютера, одним нажатием. Через этот же интерфейс предполагалось считывание данных статистики из ПЗУ в компьютер. Для всего этого необходимо написать соответствующую программу для компьютера. Однако, как показала дальнейшая практика, от последнего пришлось отказаться. Во-первых, была проблема реализации приёма данных из контроллера в компьютер на этапе написания компьютерной программы. И, что ещё существеннее, увеличивался объём программы для контроллера. Гораздо было интереснее разместить ПЗУ (в SMD корпусе SOIC-8) на съёмной площадке, соразмерной с SIM-картой и использовать соответствующий свободный слот мобильного телефона. Для этого необходимо изготовить устройство считывания ПЗУ на основе SIM ридера по одной из известных схем программатора I2C ПЗУ. Как оказалось в дальнейшем, это решение не вызвало лишних неудобств.

Ещё один из немаловажных вопросов – вывод символьной (в том числе и цифровой) информации на графический дисплей. Для этого необходима графическая информация о том или ином символе. Данная информация тесно связана с таким параметром, как размер отображаемого шрифта. Для отображения основного параметра, скорости движения, для хорошей наглядности желательно применять крупный шрифт. Однако, как будет показано в дальнейшем, подобная графическая информация о десяти цифрах не уместится в память МК, а применение того же внешнего более ёмкого ПЗУ замедлит скорость прорисовки шрифта. Мной было принято решение в качестве самого крупного шрифта использовать шрифт высотой 8 точек. Графическую информацию для этого шрифта я стянул из файла «8X8.FNT» какой-то программы от MS DOS, предварительно разгадав его структуру и сделав дальнейшую обработку.

Как в дальнейшем оказалось на практике, этого размера вполне достаточно для наглядности скорости. В качестве размера для дополнительного шрифта я выбрал размер 3x5 и самостоятельно нарисовал графику для цифр такого размера. Этими мелкими цифрами отображаются дополнительные параметры: дата/время, средняя и максимальная скорость, путь.

Графическая информация обоих шрифтов хранится в определённых двумерных массивах. Каждый элемент массива, размером в 1 байт, обозначает распределение пикселей определённого столбца определённой цифры. Для крупного шрифта на каждую цифру выделено 8 столбцов, а для мелкого – 3. Для этого же мелкого шрифта, размером 3X5, формальная высота составляет не 5, а 8 точек (округление до одного байта). Это позволяет заранее предусмотреть расположение 5-позиционного шрифта в пределах 8-позиционной зоны в вертикальном направлении одним из 4-х возможных способов. Данные факты хорошо отображены на рисунке ниже, где продемонстрировано моделирование графики для первых двух цифр этого шрифта. Для моделирования отлично подходит всем известная программа Excel. Исходными данными являются расстановки «единичек» в соответствующие поля для требуемой графики. Из них по формулам рассчитываются значения массивов, вплоть до кода языка Си, который в дальнейшем может быть скопирован в текст программы для микроконтроллера.

Теперь речь пойдёт об особенностях управления применяемого дисплея. Данный дисплей монохромный и его размеры – 84 на 48 пикселей. Управление дисплеем от МК осуществляется по SPI интерфейсу. Переданные байты по SPI интерпретируются в дисплее в двух режимах: байты для вывода на дисплей и байты команд конфигурации. Эти режимы задаются самим МК по определённому пину дисплея (D/C). Полный перечень команд приведён в даташите на дисплей. Часть этих команд используется в моём устройстве, и служат для первоначальной инициализации дисплея при подаче питания на устройство: температурный коэффициент, контрастность, режим последовательной прорисовки (горизонтальный или вертикальный) и т.д. Сразу отмечу, что применяется горизонтальный режим прорисовки. Это значит, что при передаче байта в режиме вывода на дисплей, адрес автоматически увеличивается на единицу по строкам вправо. Когда заканчивается строка, адрес позиции переходит на начало следующей строки. Достаточно только предварительно отправить в дисплей специальную команду позиционирования на определённый адрес строки и столбца (начальная позиция), и затем отправлять байты данных последовательно один за другим для вывода графики. Стоит отметить особенность адресного пространства и интерпретации графики в зависимости от принимаемых дисплеем байтов. Замечу, что для монохромной графики один байт содержит информацию сразу о восьми пикселях. Рассматриваемый дисплей разделён в вертикальном направлении на 6 горизонтальных зон по 8 строк в каждой (6*8=48). Каждый столбец каждой зоны и будет соответствовать определённому байту, который отправляется с адресом соответствующего столбца (0…83) и номера зоны (0…5). Адрес считается не с единицы, с нуля. Например, если позиционироваться по адресу (34; 2) и отправить байт данных 255 (в бинарном виде «11111111»), то загорятся все 8 пикселей с 16 по 23 по вертикали и в 35-ом столбце по горизонтали. Из этой особенности следует, на мой взгляд, один из недостатков: невозможность управлять состоянием каждого пикселя по отдельности на аппаратном уровне. Байт является минимальной порцией данных для графики. При передаче байта по текущему адресу обновляются все 8 соответствующих пикселей в текущей зоне. Дисплей не поддерживает считывание текущей отображаемой графической информации в направление к микроконтроллеру. Поэтому, при необходимости, нужно заранее в МК хранить выводимую информацию в специально отведённом буфере, а для изменения состояния каких-либо пикселей (битов) применять битовые маски для байтов из этого буфера и передавать их в дисплей заново.

Моделирование и продумывание расположения той или графической информации на дисплее производилось с учётом вышесказанной особенности. Так было предпринято для упрощения кода при написании программы. И совершенно не случайно размер шрифта рассматривался из разряда 8, 16, 24, т. е. кратным 8. Графическую информацию, по аналогии с дисплеем, я также разделил на 6 горизонтальных зон. В первой зоне мелким шрифтом отображаются абсолютное и текущее (с момента включения устройства) значения оборотов. Во второй зоне — абсолютное и текущее значения пути (в километрах с округлением до сотых). В третьей зоне – средняя скорость. В четвёртой – максимальная скорость и крупным шрифтом – текущая скорость. В пятой зоне отображаются два прогресс бара для индикаций заполнения ПЗУ и количества перезаписи. В шестой, последней зоне, – дата и время. Именно пятая зона является тем самым исключением, когда в вертикальном направлении любого взятого столбца присутствуют пиксели, относящиеся к разной информации. Поэтому данная информация с применением битовых масок собирается в буфер, содержимое которого затем выводится на дисплей в эту пятую зону. Ещё, в 3-5 зонах присутствует информация для прорисовки рамки вокруг отображаемого значения скорости. В последней зоне каждый первый (самый младший) бит на всех столбца установлен в «1» для прорисовки линии сепаратора (40-ая строка). Для данного моделирования и наглядности адресов я изобразил всё вышесказанное в ячейках Excel.

Именно таким образом выглядит первое окно отображения. Всего два окна. Второе окно – вывод графика (гистограммы) движения. Для неё отведено 5 зон (40 строк) по вертикали и все 84 столбца по горизонтали. Шестая зона с часами для обоих окон одинакова.

При программировании мной было принято решение не прибегать к использованию какой-либо библиотеки для работы с данным дисплеем. Лично мне проще разобраться в даташите, реализовать часть функций самостоятельно, чем разбираться в библиотеке. Тем более, в этом нашлись определённые достоинства. Недавно, скачав одну из библиотек, я всё же разобрался в её функциональных особенностях. Она является универсальной, с её помощью можно управлять пикселями по отдельности и позиционироваться на реальный адрес пикселя. Но библиотека использует буфер, размером 84*6 Байт, и данный буфер по таймеру периодически отправляется в дисплей, производя обновление графики. Тем самым, занят таймер и часть памяти МК. В моём конкретном случае нет необходимости использования библиотеки, так как при моделировании я заранее позаботился о максимальном разделении информации по отображаемым зонам, поставленным в полное соответствие зонам дисплея. И нет необходимости периодически обновлять информацию на дисплее: информация обновляется только тогда и только в том месте, когда она изменяется (с каждым оборотом колеса, с каждым нажатием какой-либо кнопки и т.д.). Тем самым я ещё раз подчёркиваю: в зависимости от поставленной задачи можно избежать использования каких-либо библиотек.

Для работы с часовой микросхемой и ПЗУ я также не прибегал к использованию библиотек: все функции довольно простые и реализованы мной после изучения даташитов на данные компоненты.

Теперь рассмотрим электрическую схему устройства.

Схема велоспидометра относительно простая. Кроме всего перечисленного выше, схема содержит элемент IC5 MAX756, служащий преобразователем питания из 3 в 5 Вольт для надёжного питания от оригинальной батареи мобильно телефона Nokia 3310. Реализовывать схему под 3-вольтовое питание я не стал за неимением соответствующего МК и периферии. На текущий момент времени MAX756 я пока не приобрёл, и вся схема пока питается от выносной батареи «Крона» с применением регулятора LM7805 (не совсем оптимальный вариант). Она подключается к разъёму наушников с нижней стороны телефона. К порту прерывания INT0 МК (пин 32) подключен геркон SF1, являющийся датчиком оборота колеса. Он надёжно подключается с нижней стороны телефона к разъёму зарядки. К произвольным портам (пины 23, 27, 28) подключены функциональные кнопки S1-S3, совпадающие с кнопками «1», «2», «3» мобильного телефона. К пину 29 сброса МК подключена кнопка S4, совпадающая с верхней торцевой кнопкой включения питания мобильного телефона. Это я сделал просто так. Само же устройство не имеет дежурного режима и включается с подачи питания. К SPI порту контроллера (пины 15-17) подключен дисплей IC2 и разъём для перепрошивки X1. С разъёмом, который я хотел сделать на основе уже имеющихся «пятачков» на оригинальной плате для сопряжения с ПК (в этом же месте), получилась небольшая загвоздка, и в дальнейшем я перенесу его на другое место. На этот же разъём зацеплен UART интерфейс для пользовательского подключения к компьютеру, через который настраиваются дата и время на устройстве (пины 30-31, RX/TX). Дисплей к контроллеру подключен через делители на резисторах, служащие для снижения напряжения, ибо дисплей работает на напряжении 3.3 В. В дополнение, пины дисплея D/C (данные/команда), SCE (строб) и RES (сброс дисплея) подключены к произвольным портам МК PB0, PB1 и PB2 соответственно (пины 12-14). Питание дисплея осуществляется через диоды D1-D3 и резистор R6, которые служат для снижения напряжения с 5 до 3.3 В, избегая применения линейного регулятора. Кварц Cr1, тактирующий МК, номиналом 4.5 МГц выбран случайно, но обдуманно. Просто он мне попался под руку, и я решил применить именно его. К портам МК PD4 и PD5 (пины 2 и 9) подключены транзисторы Q1 и Q2, на которые нагружены светодиоды подсветки дисплея и клавиатуры. Контроллер предусматривает возможность управлять подсветками по отдельности, как это предусматривает оригинальная схема мобильного телефона (это было на аппаратном уровне, а не на пользовательском), хотя на практике этого не нужно. Шина I2C подключена к портам PC2-PC3 (пины 25-26) и для простоты реализована программно с применением соответствующей библиотеки (хотя и подключена к портам аппаратного TWI). На шине подвешены ПЗУ IC3 и часы реального времени (RTC) IC4. Сразу оговорюсь, чтобы не было критики в комментариях: я знаю, что DS1307 не лучшее решение, но на момент разработки схемы я не знал про существование DS3231. ПЗУ находится на съёмном разъёме, по аналогии с SIM-картой. Дополнительный порт контроллера PC1 (пин 24) служит для приёма импульсов с частотой 1 Гц с RTC, по которым обновляется время на дисплее. Все пассивные компоненты обвесов – согласно даташитам на каждый активный компонент.

Рассмотрим математические соображения для расчёта тех или иных параметров. Как уже в начале было сказано, принцип измерения скорости основывается на подсчёте периода оборота колеса, а расстояние вычисляется на основе измерения количества таких оборотов. Контроллер измеряет время между предыдущим и вновь приходящим импульсом с геркона. Результат измерения преобразуется в значение скорости путём деления значения периметра колеса на период оборота, и это значение обновляется на дисплее с каждым импульсом (оборотом колеса). Здесь стоит отметить, что, с точки зрения физики, вычисляется средняя скорость движения велосипеда на участке пути, соответствующем периметру колеса. Отдельно подсчитывается количество импульсов, преобразующееся затем в значение расстояния. Для измерения периода оборота колеса контроллер использует собственный таймер. В ATmega8 имеется 8-битный и 16-битный таймер. От разрядности таймера зависит динамический диапазон измерения. В моём случае применяется 16-битный таймер, так как 8 бит (256 градаций счёта) категорически недостаточно. Максимальный период измерения (до переполнения таймера) будет соответствовать минимально измеряемой скорости. Можно ввести так называемый программный таймер, который позволит измерять большие периоды. Однако для упрощения программы я этого делать не стал. При применяемом кварце 4.5 МГц и максимальном значении делителя 1024 в конфигурации таймера имеем: (1/(4500000/1024)) = 0.000227556 сек. Этому значению соответствует минимальный период счёта. А максимальный период счёта составит 0.000227556*65536 = 14.913 сек. Максимально измеряемая скорость, соответствующая минимально измеряемому периоду, составит порядка 30000 км/ч. Этого даже и не стоило оговаривать, «запас сверху» просто огромный. А вот минимально измеряемая скорость, соответствующая максимально измеряемому периоду, составит 2.26/14.913/1000*3600 = 0.54 км/ч. Здесь 2.26 – периметр велосипедного колеса (в метрах) в моём случае. Меня вполне устраивает данное минимально измеряемое значение. Если велосипед будет двигаться со скоростью меньше, чем 0.54 км/ч, велоспидометр будет фиксировать отсутствие движения (и переполнение таймера). При данном кварце 4.5 МГц UART интерфейс отлично работает на скорости 2400 бод с допустимой приемлемой погрешностью. Этой скорости также вполне хватает, тем более, UART используется у меня для разовой настройки часов с компьютера (для копирования даты и времени с компьютера в устройство). Если брать кварц по частоте выше, минимально измеряемая скорость будет увеличиваться, что будет для меня недопустимо, и появится необходимость использовать программный таймер. А если брать ниже, то снижается быстродействие устройства в целом. Поэтому я решил оставить именно этот кварц.

Замечу, что величины период и скорость лежат в обратно пропорциональной зависимости, а таймер микроконтроллера измеряет период дискретно. В нашем случае на диапазон измерения (0.000227556…14.913) равномерно нанесены точки в количестве 65535, разделяя его на множество равных интервалов. И эти точки соответствуют всевозможным измеряемым значениям. Применяя преобразование интервалов из времени в скорость, данная система интервалов преобразуется из равномерной в обратно пропорциональную. Следовательно, диапазон всевозможно измеряемых скоростей разбивается на неравномерные интервалы. Длина этих интервалов возрастает с возрастанием самого значения скорости. Учитывая этот факт, огромный «запас сверху», о котором я писал чуть выше, будет не лишним. На практике будет вполне достаточно за максимально измеряемую скорость велосипеда взять значение 100 км/ч. Это хотя бы для того, чтобы не вводить новый разряд (сотни) и не увеличивать ширину отображаемого параметра на дисплее. Посчитаем, чему равна длинна интервала между соседними возможными значениями на скорости в окрестности, например, 90 км/ч. По обратным формулам или подбором несложно подсчитать, что для значения таймера 397 (из 65536 возможных) соответствует измеренная скорость 90.06 км/ч. А при соседнем значении таймера 398 – 89.83 км/ч. А разность между скоростями – 0.23 км/ч, что уже более чем допустимо. А на более низких скоростях данная разность будет ещё меньше. Дисплей отображает значение скорости с точностью до сотых. Однако на практике обычно хватает округления до целого или до десятых. Из всего сказанного можно сделать вывод: неравномерностью «сетки» скоростей можно пренебречь, так как вызванная ею погрешность измерения не превосходит допустимую погрешность.

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

Теперь по поводу мелких особенностей интерфейса. Первая кнопка служит для переключения режимов (графический режим или режим отображения значений). Вторая кнопка – для вывода абсолютной (за всё время) максимальной скорости взамен относительной при её удерживании. Также, выводится дата и время достижения этой скорости на место текущей даты и времени. А ещё, выводится значение текущего адреса ПЗУ на место значения относительного числа оборотов (для контроля). Оценить это значение можно по горизонтальному прогресс бару на 38-ой строке дисплея. На данное ПЗУ, ёмкостью 65536 байт (512 кбит), осуществляется запись измеряемых параметров. Как будет сказано позже, достаточно записывать первоначально измеряемый параметр (период оборота колеса) с меткой начального времени. Все остальные параметры легко рассчитываются компьютерной программой на этапе сканирования ПЗУ. Третья кнопка предназначена для управления подсветкой. В отличие от эскиза экрана выше, я в дальнейшем убрал незначащие нули на второстепенных параметрах для более наглядного их отображения. В графическом режиме слева направо прорисовывается гистограмма скорости движения, которая наглядно демонстрирует процесс изменения скорости за небольшой участок расстояния в 84 оборота колеса. Значение гистограммы – скорость в масштабе 1 пиксель на 1 км/ч. Если скорость движения превышает 40 км/ч, масштаб изображения сокращается по вертикали в 2 раза во избежание зашкаливания. Доскональные особенности поведения устройства описывать здесь не нужно.

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

Печатная плата изготовлена методом ЛУТ по форме оригинальной платы применяемого мобильного телефона. При изготовлении платы я использовал программу «SLayout». При этом я заранее на сканере сделал снимок оригинальной платы с двух сторон и подложил изображения в SLayout как шаблон. Это необходимо для того, чтобы нарисовать площадки для коннекта дисплея, кнопок и разъёмов в исключительно нужных местах. При изготовлении платы возникала погрешность около 0.5 мм. Данная погрешность оказалось приемлемая в плане совмещения контактных площадок и элементов. Однако эта погрешность сказалась на качестве подстветки: запаянные светодиоды оказались смещены на доли миллиметров и не попали в фокус светорассеивающих оправок. Из-за этого яркость подстветки уменьшилась, снизив КПД. Ниже на рисунках показан вид печатной платы в SLayout вместе с тремя мелкими печатными платами для ПЗУ в форме SIM карты. Также, приведены сканы оригинальной печатной платы с двух сторон.

Часть элементов (кнопки, разъёмы) сообщаются между собой тонкими проводными перемычками за неимением возможности проложить дорожки. Предусмотрен запас по всем имеющимся кнопкам, т.е., есть возможность задействовать любую имеющуюся кнопку. Возможно, удобно будет большую кнопку по центру сделать кнопкой переключения режимов отображения. В верхнем левом углу на плате размещена 3-вольтовая батарея питания RTC. Вообще, все элементы на плате размещены грамотно с согласованием их габаритов с габаритами корпуса. В отличие от позолоченного оригинала, плата собственного изготовления покрыта обычным припоем. Как показала первоначальная практика, контакт с дисплеем и прочей периферией не теряется.

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

Address	Size	Data
0	4	n (for S)
4	2	t_min (for v_max)
6	6	Date of t_min
12	2	Address EEPROM
14	1	EEPROM RW Count
128	80	Digits 8X8
208	30	Digits 3X5

Первыми четырьмя байтами сохраняется пройденный путь, как количество оборотов колеса. Я специально выбрал 32-битный целочисленный тип для данной переменной, поскольку на практике значения пройденного пути сравнительно велики. К примеру, целочисленная 16-битная переменная смогла бы сохранить максимум 65536 оборотов (около 148 км), что естественно мало. Далее следуют два байта для сохранения абсолютной максимальной скорости. По факту сохраняется минимальное время оборота колеса. Переменная занимает два байта, поскольку её значение является результатом измерения 16-битного таймера. Следующие 6 байт – дата и время достижения вышесказанной максимальной скорости. Данные представлены ровно в том формате, в каком они считываются из микросхемы RTC (исключая номер дня недели). Далее – два байта, сохраняющие значение текущего адреса внешнего ПЗУ. Это своего рода указатель, который необходим для возможности продолжения записи статистики на ПЗУ после очередного включения устройства. МК должен знать, на какой позиции адресного пространства внешнего ПЗУ он остановился в последний раз. С этой позиции МК продолжит запись. Этому значению отведено 2 байта, так как адресное пространство внешнего ПЗУ 16-битное. Это следует из размера ПЗУ в 64 кБ. Далее – однобайтовая переменная, сохраняющая значение количества перезаписей ПЗУ. Перезаписью считается тот случай, когда вышеописанный указатель достигнет максимального значения и обратится в ноль. При этом вновь поступающая информация на ПЗУ начнёт записываться с самого начала, стирая имеющуюся на ней старую информацию. Целочисленная однобайтовая переменная способна сохранять максимум 256 значений. Напоминаю, что значения указателя адреса ПЗУ и количества перезаписей визуально индицируются двумя прогресс барами на дисплее. Далее, после большого резервного пробела EEPROM МК, начиная с адреса 128, хранится графическая информация о цифрах размера 8x8. Для неё отведено 80 Байт (8 Байт на каждую цифру, как уже говорилось ранее). И, наконец, начиная с адреса 208, хранятся 30 Байт для графической информации о мелких цифрах 3x5 (по три байта на цифру).

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

Первая программа позволяет скопировать дату и время с компьютера в велоспидометр через COM порт. Подключение велоспидометра к компьютеру осуществляется через микросхему MAX232. Средствами WinAPI программа получает текущую дату и время в специальную структурную переменную типа SYSTEMTIME. Из этой переменной извлекаются текущие день, месяц, год, номер дня недели, часы, минуты, секунды в десятичном формате. Все эти числа, за исключением года, не превышают двух десятичных разрядов (меньше 100) и лежат в пределах одного байта. Значение года преобразуется в двузначное число вычитанием из него числа 2000, значения текущего тысячелетия. Каждое из таких двузначных десятичных чисел преобразуется в двоично-десятичный формат, характерный для микросхемы RTC. В этом формате двузначное число также занимает объём в один байт. Старшими 4-мя битами кодируется цифра десятков, а младшими – цифра единиц. В дальнейшем из этих чисел формируется посылка, размером 13 Байт, согласно заранее определённому мной протоколу. Первые пять байт представляют собой слово «TIME=», согласно стандартной кодировке ASCII. Потом следуют секунды, минуты, часы, день недели, день, месяц, год. Последний байт представляет собой символ «#», как символ конца сообщения. Данная посылка отправляется с компьютера в устройство по COM порту. Программа микроконтроллера принимает посылку и проверяет её на корректность, согласно вышесказанному формату. Если первые пять байтов «TIME=», а последний «#», посылка считается корректной, и внутри стоящие байты интерпретируются в соответствующем порядке. Не изменяя эту цепочку байт, контроллер отправляет её в микросхему RTC по шине I2C, конфигурируя её на текущую дату и время. Отмечу, что эта микросхема поддерживает счёт дней недели от 1 до 7, хотя как таковым календарём, определяющим соответствие даты и дня недели, она не является. Вывод информации на дисплей о дне недели в своём устройстве я не предусматривал.

Вторая программа предназначена для обработки данных из содержимого внешнего ПЗУ. Изначально предполагалась, что данное содержимое должно переписаться из ПЗУ в файл-образ с помощью какой-либо известной программы, работающей с известными программаторами МК и ПЗУ (например, «icprog»). Однако, детальнее изучив принцип работы I2C, я сумел реализовать данный функционал и включил его в свою программу. Схема программатора ПЗУ такой серии, которую я применил в устройстве, представлена на рисунке ниже.

ПЗУ подключается к COM порту компьютера, который используется не как средство обмена информацией по RS-232 (где достаточно задействовать выводы TX, RX, GND), а как средство произвольного ввода-вывода логических сигналов. Через вывод TX осуществляется питание ПЗУ, которое стабилизируется до 5В регулятором 78L05. Управляя с компьютера выводом TX, мы можем включить или выключить микросхему ПЗУ. Однонаправленная линия тактирования SCL сосредоточена на пине RTS розетки COM порта, а двунаправленная линия данных SDA – на двух пинах: CTS (приём данных) и DTR (передача данных). Резисторы и стабилитроны D1 и D2 служат для ограничения уровня сигнала до TTL, на котором работает ПЗУ.

Данный стандартный программатор я изготовил для моего особого случая, где вместо панельки для ПЗУ применён SIM-ридер от сломанного мобильного телефона.

Средствами WinAPI программа обращается к пинам COM порта компьютера, устанавливает необходимые на них значения (0 или 1), а также снимает с пина CTS приходящее двоичное значение с ПЗУ. На базе этого инструментария реализован функционал для работы с I2C, согласно соответствующей спецификации, в подробности которой я вдаваться не буду. Программа может считывать содержимое ПЗУ в файл-образ (как и штатный программатор), а также обрабатывать такой файл, или обрабатывать информацию с ПЗУ напрямую. Обработка информации заключается в получении выходных файлов статистики в заранее определённом табличном формате на основе входной информации с ПЗУ. Каждый такой файл соответствует одной поездке (с момента текущего до момента следующего включения устройства). Сначала я кратко опишу формат входных данных, который я заранее определил. При каждом включении устройства записываются два байта нулей по текущему адресу, который считывается из EEPROM микроконтроллера. При начале вращения колеса (при первом импульсе) после таймаута или после включения устройства записывается текущая дата и время в двоично-десятичном формате (как она хранится в регистрах микросхемы RTC). А следом записывается два байта «единиц» 0xFF. Во время вращения колеса при каждом k-ом импульсе (k=2,3,...) записывается время оборота колеса между (k-1)-ым и k-ым импульсом двумя байтами (старшим и младшим). Очевидно, что данной информации достаточно для привязки текущего (не абсолютного) пройденного пути и скорости к дате и времени. Выходной формат является текстовым и представляет собой табулированную таблицу в файлах *.csv, которые открываются в программе Excel по «двойному щелчку» мыши. Строки этой таблицы соответствуют оборотам колеса, а значения столбцов приведены ниже.

ADR	Значение адреса ПЗУ
DATE/TIME	Дата и время начала движения
DEC	Значение таймера в десятичном формате
time	Текущее время
t	Время в пути с момента включения
v	Скорость
n	Число оборотов
S	Путь
an	Абсолютное число оборотов (только в пределах текущего ПЗУ)
aS	Абсолютный путь (только в пределах текущего ПЗУ)
n_day	Число оборотов за текущие сутки
S_day	Путь за текущие сутки
v_max	Максимальная скорость за текущую поездку
av_max	Абсолютная максимальная скорость (только в пределах текущего ПЗУ)
v_mid	Средняя скорость за текущую поездку

Скриншот содержимого такого файла в Excel представлен на рисунке ниже. Также, изображены графики изменения текущей, средней и максимальной скорости различными цветами в одной системе координат. Аргумент (ось X) – значения числа оборотов, как исходные данные. На рисунке представлены изменения параметров за первые 730 оборотов. С данной переменной линейной зависимостью связан пройденный путь (730 оборотов соответствует примерно 1650 м). Поэтому, можно сказать, что графики отражают зависимости скоростей от расстояния (с точностью до масштаба по горизонтали), в отличие от традиционной зависимости скорости от времени, на что следует обращать внимание. Как уже говорилось, данная особенность обусловлена идеологией и принципом измерения скорости по оборотам колеса. Но ведь каждому обороту колеса (моменту сближения магнита и геркона) приписан определённый момент времени. Естественно, данная последовательность временных меток не является равномерной. Однако, для формальности и удобства, в Excel есть возможность в качестве аргумента для графиков указать массив значений времени в пути или текущего времени. Но всё равно следует помнить, что реальная зависимость скорости от времени (на равномерных интервалах времени для дискретного случая) выглядела бы по-другому, с переменным масштабом по горизонтали.

На рисунке ниже изображена та же зависимость скорости от оборотов, но уже с применением фильтра методом скользящей средней с шириной окна в 11 оборотов. Все графики построены в программе Excel известными методами.

Сравнивая два графика изменения скорости, очевидно, что в отфильтрованном графике отсутствует высокочастотная компонента, т.е. удалён шум. Ширина окна скользящего среднего в 11 оборотов (около 25 м пути), на мой взгляд, великовата. Если действительно ставить вопрос о фильтрации показаний от шума, то достаточно взять небольшую ширину окна, например, равной трём. Этот алгоритм можно заложить в программу велоспидометра, т. к. он может применяться не только для анализа извлечённых показаний, но и для отображения этих показаний в реальном времени. Несмотря на простоту этого алгоритма, я не буду вдаваться в подробности его описания, так как эта тема освещается в курсе математики и выходит за рамки данной статьи. И здесь ещё одно уточнение по поводу средней скорости. Как я уже писал, средняя скорость это единственный параметр, который обновляется не с каждым оборотом колеса, а каждую секунду. Это я сделал для того, чтобы на дисплее наблюдалось изменение средней скорости даже при очень медленном движении. Поэтому, значения показаний на дисплее в реальном времени будут немного отличаться от значений, рассчитываемых в дальнейшем компьютерной программой на этапе сканирования ПЗУ. Также будут отличаться показания абсолютного числа оборотов, абсолютного пути и абсолютной максимальной скорости. На дисплее отображаются действительно абсолютные значения (за всё время существования устройства), а в выходных таблицах – только в пределах текущего считываемого ПЗУ.

Третья программа, по своей сути, является той же программой для прошивки микроконтроллера. Я работаю с простейшим программатором «STK 200», подключенным к LPT порту компьютера, а точнее, с его аналогом, если его так можно назвать, ибо в простейшем случае программатор вовсе не содержит активных элементов. Фактически, МК по SPI интерфейсу подключается к определённым пинам LPT порта напрямую и работает, как ведомое устройство. Программа реализует протокол обмена данными с контроллером ATmega8, согласно его даташиту (стр. 237). Физический уровень SPI реализован путём управления регистрами LPT порта с применением известной динамической библиотеки «inpout32.dll». Библиотека у меня подключается не как к проекту (так как я в «Dev-cpp» избежал создания как такового проекта, создав один простейший «сишный» файл), а с помощью функции LoadLibrary с применением структурного типа HINSTANCE. Переменной данного типа ставится в соответствие библиотека «inpout32.dll», и в дальнейшем в отдельные переменные извлекаются указатели на функции из данной библиотеки. В inpout32.dll имеются только две функции, которые отвечают за ввод и вывод данных. Обращение к этим функциям происходит по извлечённым заранее указателям. Управление пинами LPT порта по отдельности осуществляется при помощи битовых масок. В моём конкретном случае, написанная мной программа работает с EEPROM областью контроллера и предназначена для считывания, резервирования, записи, корректировки и восстановления из резервной копии хранящихся в ней данных, которые я расписал ранее. Как и все остальные программы, программа работает из командной строки. В таких случаях, для реализации многофункциональности программы применяются функции «switch-case» и текстовый пользовательский диалог, например, «введите ‘1’ для операции №1, …, введите ‘0’ для выхода из программы». Данные отображаются в различных удобных для меня форматах. В дополнение к сказанному, программа может выводить полный дамп EEPROM контроллера в 512 Байт на экран. Также, программа умеет записывать в память контроллера графическую информацию о применяемых шрифтах. В случае с мелким шрифтом, размером 3X5, программа берёт информацию из текстового файла «Fonts 3X5.txt», который находится с ней в одном каталоге. Файл содержит табулированную таблицу из 30 байтов (3 на 10), записанных в 16-ричном формате. При желании его можно легко отредактировать в текстовом редакторе, изменив, таким образом, графику данного шрифта. Как уже говорилось, этот мелкий шрифт настолько простой, что менять его графику не имеет смысла. Единственное, может только потребоваться его вертикальный сдвиг, так как имеется запас пространства по высоте в 8 пикселей, а шрифт имеет высоту, равную 5. В случае с крупным шрифтом, размером 8X8, которым отображается текущая скорость, я предусмотрел функционал куда интереснее. Графическая информация о данном шрифте представлена не в текстовом файле в виде таблицы байтов, а в графических наглядных файлах BMP. Каждой цифре соответствует один такой файл. Его параметры – размер 8X8, монохромный с чёрно-белой палитрой. Ниже показан скриншот известного графического редактора «MS Paint» с открытым в нём файлом «8.bmp».

Эмпирическим путём я изучил структуру монохромных BMP файлов, полученных из MS Paint», и на этой основе мне удалось научиться читать каждый пиксель монохромной BMP картинки (исключая использование структур и вспомогательных библиотек). На этапе построчного горизонтального чтения снизу вверх (именно так и организована структура BMP файла), программа преобразует информацию в вертикальный формат, свойственный применяемому дисплею. Эта операция осуществляется в один проход, где применяются битовые маски и накопление значения переменных. Ниже я покажу этот участок кода для i-ой цифры, обратив внимание на простоту процесса.

for(k=0; k<8; k++){
        fnt[i][k] = 0;
}
for(j=0; j<8; j++){
        fseek(f, 62+4*j, SEEK_SET);
        byte = ~fgetc(f);
        for(k=0; k<8; k++){
                if(byte & pow2(7-k)){
                        fnt[i][k] += pow2(7-j);
                }
        }
}

В первом цикле происходит инициализация элементов массива fnt нулями. В дальнейшем, каждый k-ый элемент этого массива (k=0…7) для i-ой цифры (i=0…9) будет нести графическую информацию о каждом соответствующем столбце каждой соответствующей цифры. Следующий цикл – пробег по строкам картинки BMP файла. Оператором fseek мы позиционируемся на байт по смещению 62+4*j заранее определённого BMP файла f. Специфика формулы, по которой рассчитывается смещение в зависимости от номера строки j, обусловлена структурой BMP файла. В промежуточную переменную byte мы получаем значение байта по вышесказанному смещению. Этот байт хранит информацию обо всех восьми пикселях монохромной картинки в текущей строке j. Оператором ‘~’ происходит побитовая инверсия байта, что приводит к цветовой инверсии каждого пикселя. Это связано с тем, что чёрный пиксель в палитре монохромного BMP файла соответствует логическому «0», а белый – «1». В применяемом же дисплее – всё наоборот. Во вложенном цикле происходит побитовый анализ байта и в тоже время накопление информации в выходной массив fnt. Функция pow2 – возведение двойки в неотрицательную целочисленную степень, написанная самостоятельно. Вместо этой функции можно применить более эффективный оператор побитового сдвига «<<», но на момент написания этой программы я им не пользовался.

Кроме этого, программа предусматривает возможность записать в память МК одну из нескольких графических вариантов этого шрифта на мой выбор. Эти варианты реализованы с помощью директорий (папок) с именем вида «v1», «v2», «v3» и т. д., которые располагаются в папке «Fonts 8X8» в одном каталоге с программой. А уже в этих папках лежат необходимые BMP файлы. Благодаря вышеописанному функционалу, имеется возможность в графическом редакторе поправить или нарисовать цифры с «чистого листа», сохранив и распределив их по директориям. У меня имеется три варианта шрифта. Первый вариант – оригинальный. Второй – как и оригинал, но с зачёркнутым нулём и видоизменённой единицей (без нижнего подчёркивания). Третий – шрифт с прямоугольной окантовкой.

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

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

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

Корпус для устройства я изготовил из куска оргстекла, толщиной 17 мм, на фрезерном станке ЧПУ. Для этого я предварительно набросал эскизы корпуса в программе SPlan, почти полностью не владея тематикой чертежей, САПР и т.д.

Данные наброски нужны для общего представления и получения координат опорных точек. На их основании пишется программа на станок ЧПУ, принимая во внимание общие принципы и последовательности фрезеровки. Программу ЧПУ я писал вручную в Excel, применяя функции автозаполнения на повторяющиеся операции.

Схему устройства я также немного подкорректировал, она представлена на рисунке ниже.

Вместо ненужной подсветки стоит для красоты один светодиод, который вспыхивает с каждым оборотом колеса. Также перерисованы разъёмы, и отсутствуют другие элементы, которые не понадобились в обновлённой версии конструкции. дальнейшем я нашёл и поставил кварц 4.433619 МГц, незначительно подкорректировав некоторые константы в исходном коде собственной программы. Было также сделано ещё несколько незначительных изменений в программе.

Фотография готового изделия представлена ниже. Устройство питается от АКБ, которая стоит на борту велосипеда. От неё же запитано освещение на случай поездок в тёмное время суток.

Именно в таком исполнении устройство заработало полностью без каких-либо сбоев. Единственный недостаток — применение не очень качественного чипа RTC: зимой при низких температурах время заметно спешит, приходится раз в месяц корректировать.

Let's block ads! (Why?)

[Перевод] Как я сделал абсолютно бесшумный компьютер

Почти три десятилетия я пытаюсь делать мои компьютеры тише. Жидкостное охлаждение собственного изготовления, гидродинамические подшипники с магнитной стабилизацией, акустические демпферы, силиконовые амортизаторы – я использовал всё, что можно представить. И на прошлой неделе я, наконец, сумел построить совершенно бесшумный компьютер. Без лишних слов, знакомьтесь: Streacom DB4. Корпус размером 26 x 26 x 27 см без единого вентилятора. У него вообще нет никаких движущихся частей. Полная тишина, 0 дБ.

Если снять с него верхнюю и четыре боковых стенки (штампованный алюминий, толщина стенки 13 мм), вы увидите минимальную раму и центральную монтажную пластину для материнской платы формата mini-ITX (порты ввода/вывода смотрят вниз, сквозь дно корпуса).

Когда я выбирал компоненты, то вариантов материнской платы такого формата было всего четыре:

• ASUS ROG Strix B350-I Gaming
• Gigabyte AB350N-Gaming-WiFi ITX
• MSI B350I Pro AC
• ASRock Fatal1ty AB350 Gaming-ITX/ac

Внимательный читатель заметит, что все материнки заточены под AMD (Socket AM4). Вся эта шумиха по поводу Meltdown/Spectre привела к тому, что мои предыдущие системы на базе Intel стали небезопасными, и для меня это стало последней каплей – всё, больше никаких Intel CPU.

В итоге я остановился на плате ASRock AB350 Gaming-ITX/ac.

Хотя теоретически в DB4 можно установить любую материнку mini-ITX, корпус разработан для пассивного охлаждения с тепловыми трубками, передающими тепло, создаваемое CPU и GPU на боковые панели, излучающие его и удаляющие при помощи конвекции. Тщательный анализ путей прокладки трубок и необходимых зазоров показал, что определённые материнки не подойдут для этого корпуса – будут мешаться компоненты.

• У Gigabyte коннектор питания ATX зачем-то расположен наверху платы, и это препятствие было никак не обойти.
• У Asus есть группа стабилизаторов напряжения, в которые эти трубки упирались бы. Любой человек, разбирающийся в конденсаторах и тепле, поймёт, что это был бы путь к катастрофе.
• У MSI имеется огромный радиатор для стабилизаторов напряжения, который мешался бы по меньшей мере одной (возможно, двум) трубкам.

ASRock оказалась единственной материнкой, которая уместится в DB4, и не будет мешаться дополнительному набору трубок LH6 Cooling Kit. Пожалуй, нагляднее будет продемонстрировать, как это выглядит после установки трубок:

Чтобы лучше понять, насколько малы оказались зазоры, вот фото с другого угла:

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

В комплекте с DB4 идёт оборудование, с помощью которого тепло от CPU передаётся на одну из боковых панелей – это четыре тепловые трубки и один распределитель тепла. Такая конфигурация поддерживает CPU мощностью 65 Вт. Если добавить LH6 Cooling Kit, то CPU можно подсоединить к двум боковым панелям шестью трубками и тремя распределителями, что позволит использовать CPU до 105 Вт.

В такой системе с пассивным охлаждением ограничением мощности CPU служат возможности по рассеиванию тепла. Для справки:

• Ryzen 5 2400G 4C8T 3.6GHz — 46-65 Вт
• Ryzen 5 1600 6C12T 3.2GHz — 65 Вт
• Ryzen 5 1600X 6C12T 3.6GHz — 95 Вт
• Ryzen 7 1700 8C16T 3.0GHz — 65 Вт
• Ryzen 7 1700X 8C16T 3.4GHz — 95 Вт
• Ryzen 7 1800X 8C16T 3.6GHz — 95 Вт

Так что стоковый DB4 поддерживает вплоть до 2400G/1600/1700 – без всякого разгона – а комплект DB4+LH6 поддержит даже 1600X/1700X/1800X — и позволит немного разогнаться.

В отличие от Intel, время поддержки сокетов у которой сравнимо со временем, необходимым для распаковки очередного процессора, у AMD время поддержки сокетов гораздо больше. AM4 будет поддерживаться до 2020. Отсюда и вырос мой хитрый план – начать в 2018 году с CPU, который без проблем смогут охлаждать DB4+LH6, который можно разгонять и подвергать стресс-тестам пару лет, а потом, если преимущества апгрейда будут очевидными, добавить более эффективный CPU, когда последние процессоры для AM4 сойдут с конвейера, на базе чего можно будет существовать ещё лет пять.

Всё это привело к тому, что я поставил Ryzen 5 1600 на 65 Вт. Поскольку материнка у меня B350, я имею возможность разгонять проц до 1600X/95 Вт без особых проблем.

Если вам хватает 65 Вт и не нужен разгон, вы можете отказаться от LH6 Cooling Kit. Тепловые трубки у DB4 короче, чем у LH6, и не заходят за край материнки – поэтому никаких ограничений, упомянутых в связи с платами Gigabyte, Asus и MSI, у вас не будет.

Что до памяти, тол я выбрал Corsair Vengeance LPX CMK32GX4M2Z2400C16 32GB (2x16GB) DDR4.

С Corsair Vengeance LPX RAM у меня никогда не было проблем. Она была указана в списке совместимых модулей для моей материнской платы, а ещё её смогли разогнать до 3200 МГц на точно такой же матери, что и у меня, поэтому я был уверен, что смогу достичь хорошего разгона с минимальными усилиями – естественно, с учётом «кремниевой лотереи». Я собирал компьютер не для игр и не использовал APU, поэтому для меня больше значения имел объём памяти, чем какие-то запредельные скорости.

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

Поскольку сзади на материнке есть слот M.2, я решил выбрать 1 Тб Samsung 960 Evo NVMe в качестве основного и 1 Тб Samsung 860 Evo SATA для страховочного.

Я бы предпочёл два диска NVMe (чтобы было меньше кабелей), но у материнки ASRock есть только один слот M.2. У Asus есть два таких слота, но она несовместима с LH6 Cooling Kit. Ну что ж – иногда приходится идти на компромиссы.

Для моих целей необходимы большие скорости передачи данных и ожидаемая продолжительность жизни не менее семи лет. Пространства на диске мне нужно порядка 600 Гб, поэтому взяв запас в несколько сотен гигов, я могу позволить накопителям определённый износ и достичь своей цели.

Хотя система не предназначалась для игр, никогда не повредит установить лучший из возможных GPU, который не расплавит температурные трубки. GPU Cooling Kit позволяет размещать GPU до 75 Вт, тепло с которого по трубкам будет идти к одной из стенок. Это ограничивает выбор платой не выше GTX 1050 Ti, если вы, как я, предпочитаете карты от Nvidia.

Мне хотелось MSI GeForce GTX 1050 Ti Aero ITX OC 4GB, но они закончились у моего продавца. Из-за безумств с криптовалютами не было известно, как скоро они появятся на складе, поэтому я удовлетворился второй по списку картой, ASUS Phoenix GeForce GTX 1050 Ti 4GB:

Обе эти карточки вмещаются в корпус, однако MSI на несколько сантиметров короче, чем Asus. Конечно, ни один из двойных вентиляторов у GPU никогда бы туда не влез.

Удалив вентиляторы, радиатор и корпус, я почистил GPU, добавил свежей пасты, а потом приладил GPU Cooling Kit:

Последний шаг – добавить радиаторы на каждый из четырёх чипов VRAM:

Тестирование потребления карточек 1050 Ti показывает, что под нагрузкой они и правда отъедают 75 Вт целиком, поэтому я достигаю пределов GPU Cooling Kit, и никакого разгона не предполагается.

Для питания всего этого я поставил Streacom ZF240 Fanless 240W ZeroFlex PSU:

Я изучил потребление всех компонентов и обнаружил, что у всех шин, за исключением шины в 12 В, запас довольно большой. Шина 12 В, теоретически, может дойти до 85% загрузки в 168 Вт, если CPU и GPU одновременно будут работать на 100%. Обычно я предпочитаю оставлять запас побольше, но поскольку система не предназначена для игр, а других вариантов, в которых я бы занял оба процессора одновременно, я не вижу, меня это не сильно волнует. Если это станет проблемой, я легко смогу установить БП SFX и добавить запаса.

С годами я стал осознавать важность кривых эффективности блоков питания и понял, что стоящая без дела система с крупным БП — это огромные траты энергии. Чтобы извлечь максимальную выгоду из вашего БП, его типичное использование должно находиться в рамках 25-75%%. Рейтинг эффективности ZF240 находится на уровне 93%, и я думаю, что мой выбор компонентов позволит ему регулярно достигать этого уровня – учитывая то, как, я думаю, будет использоваться компьютер.

Низкое энергопотребление особенно важно, если вы планируете работать в местах, где нет постоянного энергоснабжения.

Итоговые замечания

Погоня за тишиной может влететь в копеечку, и данный проект стал именно таким – в итоге он обошёлся почти в 3000 австралийских долларов. Если бы майнеры не взвинтили цены на оборудование, можно было бы уложиться в 2400 – всё равно много, но не так больно. Тем не менее, это меньше, чем три предыдущих собранных мною системы, а новый компьютер способен на то, что им не удавалось – обеспечить полную тишину.

Компьютер не шумит при старте. Он не шумит при выключении. Он не шумит при простое. Не шумит при большой загрузке. Не шумит при чтении и записи. Его не услышишь в обычной комнате днём. Его не услышишь в абсолютно тихом доме ночью. Его не услышишь с одного метра. Его не услышишь с одного сантиметра. Его просто не слышно. Чтобы достичь такого эффекта, потребовалось 30 лет, и, наконец, я его достиг. Путешествие закончено, и это здорово.

Если вы пытаетесь собрать беззвучный – не просто тихий, а бесшумный компьютер, я крайне рекомендую корпус с пассивным охлаждением, тепловые трубки и твердотельные накопители. Устраните все движущиеся части (вентиляторы и жёсткие диски), и вы устраните шум – это не так сложно. И это не обязательно будет очень дорого (мои системные требования не были средними, поэтому не думайте, что все системы на базе DB4 такие дорогие). Тишину (и очень приличный компьютер) можно получить и за половину указанной цены.

Обращаю ваше внимание на то, что это перевод. Ссылка на оригинал – вверху, под заголовком [прим. перев.]

Let's block ads! (Why?)