Всем привет!
Меня зовут Денис nimpos Койвистойнен и я являюсь тестировщиком в компании RTL-Service.

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

Поехали

9:00
Начало нашего трудового дня. Первым делом смотрим какие письма пришли по электронной почте и перечень текущих дел на сегодня. Обычно список задач в отделе тестирования большой, у каждой из задач разные приоритеты — в первую очередь обращаем наше внимание на задачи со статусом «Срочно» и «Немедленно», которые ставят разработчики и менеджеры проектов.

Привет, дорогие читатели. Я – разработчик в компании “RTL Service”, в которой мои обязанности по разработке продукта пересекаются с обязанностями DevOps. Конкретнее – я создаю и поддерживаю инфраструктуру сборки и первичного тестирования наших продуктов еще до их попадания в отдел тестирования.

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

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

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

Проработав в разных компаниях инженером службы технической поддержки, впоследствии замечаешь абсолютно разный подход к решению задач/проблем клиента. У интернет-провайдеров все проблемы привязываются к конкретному потребителю. Осуществляется не столько поддержка услуг компании (IPTV, интернет), сколько решение задач, которые пользователь создает себе сам (вырванные провода, неработающий скайп, почему-то быстро закончившиеся деньги и т.д.). Исключение составляют лишь проблемы, вызванные неполадкой коммутирующего оборудования, линий связи и прочего.

В данный момент я работаю в службе технической поддержки компании «RTL-Service», которая занимается разработкой систем локального позиционирования с обеспечением голосовой связи. Подход нашей компании заметно отличается от прочих мест, где мне приходилось работать – поскольку клиентов меньше, чем у провайдера, вся поддержка строится для конкретной версии продукта, к которой изначально привязываются клиенты.

В данном цикле статей мы хотим познакомить хабрасообщество с опытом компании RTL-Service в изучении беспроводной технологии LoRa. На наш взгляд, данная технология обладает рядом особенностей, которые делают её очень интересной для решения определенного круга задач.
Мы рассмотрим историю появления технологии, то как она позиционируется, типовую архитектуру LoRaWAN сетей. Далее перейдём к детальному рассмотрению физических особенностей её реализации. И, наконец, нашему опыту работы с двумя реализациями трансиверов от Semtech и Microchip.

В данной статье речь пойдёт об опыте автоматизации функционального и нагрузочного тестирования API протокола RTLSCP. Серверная часть системы локального позиционирования RealTrac состоит из основного (core) сервера, который связывается с устройствами по протоколу INCP (InterNanoCom Protocol) и сервера приложений (appserver). Сервер приложений общается с внешними клиентами и основным сервером по протоколу RTLSCP (Real Track Location System Communication Protocol). Клиенты также могут напрямую обращаться к основному серверу по RTLSCP.

Доброго времени суток, хабравчане.
Сегодня я расскажу вам о работе sip-телефонии, а именно о том, как я организовывал звуковой сеанс между мобильными рациями (или ИКН) о которых вы слышали ранее из других статей нашей компании и web-клиентом через webRTC с использованием sipML5 в качестве библиотеки и asterisk 11 в качестве АТС.

Всем кому небезразлична данная тема — добро пожаловать под кат.

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

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

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

Введение.

В данной статье я расскажу о том, как в отделе контроля качества компании RTL-Service происходит автоматизированное тестирование стабильности сервера RealTrac при одновременном обслуживании большого количества мобильных локационных устройств. Для дальнейшего понимания, предлагаю ознакомиться с полезной терминологией:
RTLS-cервер RealTrac (сервер) — серверное программное обеспечение системы RealTrac, осуществляющее взаимодействие с аппаратными средствами системы и расчет местоположения устройств.

Сервер приложений RealTrac (сервер приложений) — серверное программное обеспечение, необходимое для работы web-приложения, предоставляющее программный интерфейс доступа к основным функциям системы.

Точка доступа RealTrac (далее ТД) — устройство, предназначенное для передачи данных между мобильными устройствами сети и сервером системы. Точки доступа стационарно устанавливаются на объекте, их координаты заносятся на карту клиентского программного обеспечения и фиксируются в базе данных на сервере системы. ТД может работать в режиме шлюза или ретранслятора. Режим определяется наличием проводного Ethernet подключения к сети (шлюз точка доступа, ШТД) и отсутствием такового (ретранслятор точка доступа, РТД). Обмен данными с сервером осуществляют только шлюз.

Наша компания «RTL-Service» занимается разработкой и продвижением решений локального позиционирования, в связи с чем мы уже знакомили наших читателей с разнообразием технологий локального позиционирования. В сегодняшней статье мы постараемся более подробно остановиться на методах локального позиционирования, в основе которых лежит использование радиоволн.

Работая в компании «RTL-Service», в последнее время мне не раз приходилось участвовать в обследовании шахт, причем как угольных, так и металлических, в которых ранее кем-то из наших партнеров была внедрена система локального позиционирования и голосовой связи RealTrac и она работала неправильно или нестабильно. И каждый раз оказывалось, что причиной такой работы системы являются не недостатки оборудования или программного обеспечения разработанного нашей компанией решения, а ошибки и просчеты при создании инфраструктуры для системы RealTrac.

Одной из задач компании RTL-Service, которая занимается разработкой систем локального позиционирования с высокой точностью и обеспечением голосовой связи по зашифрованному каналу, является разработка веб-клиента:

В нашей системе мирно сосуществуют 2 сервера. Основной сервер(ядро), написанный на JAVA и сервер приложений — NodeJS, именно ему и посвящена данная статья.
Изначально у сервера приложений существовало 2 фундаментальные задачи:

1) проксирование запросов к основному серверу для того, чтобы уменьшить неспецифичную нагрузку и сэкономить ресурсы для решения более важных задач;
2) реализация client-specific функционала для того, чтобы не пришлось вносить изменения в код ядра при появлении клиентских “хотелок”.

Строго говоря, наличие сервера приложений вовсе не обязательно для функционирования системы, т.к. ядро имеет полноценное REST API, реализующее весь основной функционал системы. Несколько слов о протоколе. RTLSCP (real track location system communication protocol) – протокол, работающий поверх HTTP и позволяющий получать данные и выполнять базовые операции с системой RealTrac с использованием запросов и ответов в формате JSON/KML/PNG.

Давным-давно, в далекой га…… начиналось всё с одного сервера, написанного на java. Данный сервер реализовывал полный спектр задач:

1. Коммуникация с “железками” — получение замеров, статусной информации, телеметрия, конфигурирование инфраструктуры и т.п.;
2. Realtime обработка поступивших данных;
3. Агрегирование полученных данных;
4. Высокоуровневый интерфейс с клиентским софтом на базу RMI (клиент в те стародавние времена тоже был на java/netbeans rcp).

Немного про UWB..

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

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

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

Использование RTLS (Real Time Location System, систем определения местоположения в режиме реального времени) зависит от поставленных задач и целей. Для того, чтобы правильно выбрать необходимую вам систему, необходимо понимать на основе какой из многочисленных технологий она работает.
Компания RTL-Service занимается разработкой таких решений, поэтому мы регулярно участвуем во всевозможных выставках, анализируем рынок различных систем локального позиционирования и проводим необходимые исследования. В процессе работы мы столкнулись с проблемой отсутствия более-менее полной классификации технологий локального позиционирования, в связи с чем нами была произведена попытка её создания.

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

• Радиолокационные технологии.
• Технологии инерциального позиционирования.
• Технологии, основанные на изменении магнитного поля.
• Оптические технологии.
• Ультразвуковые технологии.

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