на момент самостоятельного вылета должен быть пройден ВЛЭК, а там требований будет гораздо больше. Чуть проще, чем у линейных пилотов, но в разы жестче водительской медкомиссии
просто формат данных очень похож на тот, что в моих датчиках — предположил, что там используется один и тот же чип. В моих датчиках все было логично — 5 байт: 4 данных и 5й — сумма. Все сошлось с первого раза, другие варианты даже не пробовал. Но у вас с передачей нибблами, возможно, все совсем иначе
датчик у меня вот такой.
А если сделать перестановки для всех байт пакета и просуммировать, может тогда CRC совпадет с суммой? Вряд ли там слишком много модификаций электроники.
Пакет у меня выглядел вот так:
Но вы смотрели уже с выхода приемника, может это повлияло на длительность импульсов
у вас какой-то странный порядок бит в таблице, подозреваю что при разборе пакета полубайты перемешиваются. Например, если поменять местами полубайты в первой посылке: 1001 0110 0101 1011 1000 0110 1000 0010 0001 1111 Key:0 Ch:2 H:40%, T:25.2 C
на
1001 0110 0101 0110 1000 1011 0010 1000 0001 1111
то получим:
0010 1000 = 40, это влажность. Дальше
0110 1000 1011 = 1675 — температура. Переводим по формуле
(1675-320)*5/9-500=252, или 25,2 градуса Цельсия.
Буквально несколько дней назад разбирался с подобным датчиком. Тоже довольно быстро нашел биты канала, биты поля влажности, и столкнулся со странным форматом поля температуры. Помог хабраюзер ValeriVP — он прямо указал что температура в таких датчиках передается в долях Фаренгейта и CRC рассчитывается как младший байт арифметической суммы всех байт пакета.
Кстати, я смотрел сигнал прямо со входа передатчика цифровым осциллографом и увидел там типичный манчестерский код. Соответственно алгоритм приема у меня реализован по-другому. Сначала идет четыре импульса по 700 мкс, потом 40 бит данных в формате MSB first. Если последовательно записать эти 40 бит, то разбирать их можно будет в привычном формате.
CRC там может быть просто арифметическая сумма всех байтов в посылке. А температура — в десятых долях Фаренгейта. Как раз недавно разбирался с подобной.
используя три приемника, методами дифференциального GPS можно вычислить ориентацию в пространстве не хуже гироскопа. Расстояние между антеннами на дроне, правда, не слишком большое, но видимо точности достаточно
Как и вся реклама — привлекательная картинка (интересные задачи в данном случае), а на деле — предложение купить ненужную вещь (подписаться на статьи о маркетинге).
Было бы намного интереснее, например, почитать сколько именно программистов устроились на работу в Гугл таким образом, насколько этот способ поиска сотрудников эффективнее традиционных.
На хабре ожидаешь увидеть все-таки более серьезные статьи, иллюстрации в которых связаны с текстом. А с таким стилем появляется ощущение, что читаешь глянцевый журнал — можно просто посмотреть узнаваемые картинки не читая текст вообще. Хотя сама статья интересная.
Я обрадовался, когда обнаружил, что rtkrcv уже поддерживает http в качестве входного потока. И огорчился, когда понял, что он не работает в виде request/response. Значит использовать один rtkrcv не получится. Тогда я написал передатчик между сервером и rtkrcv, который отправляет запросы, принимает данные и по сокету отправляет их в rtkrcv.
А почему не стали использовать стандартный для геодезистов протокол NTRIP? Ставим куда-нибудь бесплатный NTRIP-кастер (они есть и под линукс, и под виндовс), настраиваем базу на выдачу RTCM и транслируем измерения базы на кастер (в составе RTKlB есть средства для этого). На ровере rtkrcv штатно подключается к кастеру. Если вдруг будут моменты, сходные с:
Сначала я подумал, что данные повреждаются в процессе передачи и это мешает расчетам.
можно через консоль rtkrcv смотреть в реальном времени состояние потока с базы, или параллельно подключить к тому же источнику rtknavi и посмотреть в удобном диагностическом вьювере, что не так с измерениями базы.
можно было бы использовать энкодеры вместо резисторов и добавить экранчик — получилась бы «классическая» микроволновка с электронным управлением. Ну и напрашивается еще остановка таймера по открытию дверцы. Потом, как сказано выше, добавить датчик температуры блюда и реализовать адаптивное время включения. Интересный проект, если нечем себя занять )
А если сделать перестановки для всех байт пакета и просуммировать, может тогда CRC совпадет с суммой? Вряд ли там слишком много модификаций электроники.
Пакет у меня выглядел вот так:
Но вы смотрели уже с выхода приемника, может это повлияло на длительность импульсов
1001 0110 0101 1011 1000 0110 1000 0010 0001 1111 Key:0 Ch:2 H:40%, T:25.2 C
на
1001 0110 0101 0110 1000 1011 0010 1000 0001 1111
то получим:
0010 1000 = 40, это влажность. Дальше
0110 1000 1011 = 1675 — температура. Переводим по формуле
(1675-320)*5/9-500=252, или 25,2 градуса Цельсия.
Буквально несколько дней назад разбирался с подобным датчиком. Тоже довольно быстро нашел биты канала, биты поля влажности, и столкнулся со странным форматом поля температуры. Помог хабраюзер ValeriVP — он прямо указал что температура в таких датчиках передается в долях Фаренгейта и CRC рассчитывается как младший байт арифметической суммы всех байт пакета.
Кстати, я смотрел сигнал прямо со входа передатчика цифровым осциллографом и увидел там типичный манчестерский код. Соответственно алгоритм приема у меня реализован по-другому. Сначала идет четыре импульса по 700 мкс, потом 40 бит данных в формате MSB first. Если последовательно записать эти 40 бит, то разбирать их можно будет в привычном формате.
Tracking Drone Orientation with Multiple GPS Receivers
Было бы намного интереснее, например, почитать сколько именно программистов устроились на работу в Гугл таким образом, насколько этот способ поиска сотрудников эффективнее традиционных.
кстати, а какой приемник был в качестве базы?На фото ровера видно, что там Навис.
Про RTCM сказал на автомате, rtklib поддерживает много форматов, может в конкретном случае логичнее использовать другой (BINR, если база тоже Навис)
увидел что тоже Навис
А почему не стали использовать стандартный для геодезистов протокол NTRIP? Ставим куда-нибудь бесплатный NTRIP-кастер (они есть и под линукс, и под виндовс), настраиваем базу на выдачу RTCM и транслируем измерения базы на кастер (в составе RTKlB есть средства для этого). На ровере rtkrcv штатно подключается к кастеру. Если вдруг будут моменты, сходные с:
можно через консоль rtkrcv смотреть в реальном времени состояние потока с базы, или параллельно подключить к тому же источнику rtknavi и посмотреть в удобном диагностическом вьювере, что не так с измерениями базы.
Похоже на СБМ-10 или СБМ-21. Немного отличаются размерами и временем счета. Но оба значительно «тормознутее» упомянутого СБМ-20.